Em nossa empresa, temos uma equipe trabalhando em 3 projetos diferentes ao mesmo tempo, onde normalmente apenas uma ou duas pessoas estão envolvidas em cada projeto. O trabalho do projeto geralmente envolve o domínio de novas tecnologias e a solução de bugs, levando a tarefas difíceis de estimar. Nessa situação, a gerência ainda insiste em usar o SCRUM e não permite alocar um buffer de segurança no final do sprint para situações inesperadas. A reunião de stand-up acontece para toda a equipe, embora praticamente todos trabalhem juntos em componentes de software não relacionados ou em diferentes projetos de software.
Gostaria de saber se alguém viu o SCRUM funcionando bem para um projeto com um único desenvolvedor e tarefas difusas, e como você fez o processo funcionar bem?
Como estimar tarefas que envolvem pesquisa / domínio de novas tecnologias (isso envolve o aprendizado de novas linguagens de programação, plataformas e ferramentas de desenvolvimento)?
Alguém conseguiu convencer a gerência a não usar o SCRUM em projetos específicos e, em caso afirmativo, quais argumentos foram mais bem-sucedidos?
Obrigado!
Respostas:
Procure "Personal Scrum" ... Eu vi algumas ou três postagens no blog de pessoas fazendo isso. O Full Scrum tem algumas noções que não se traduzem perfeitamente em equipes individuais. (Minha experiência - uma certa "massa crítica" de cerca de 4 pessoas parece fazer o trabalho em equipe funcionar bem.)
http://blog.jgpruitt.com/tag/personal-scrum/, por exemplo.
Mas coisas como estimativa de tarefas, velocidade e sprints com limite de tempo durante os quais a lista de tarefas é "protegida" funcionam bem mesmo para 1.
fonte
Claro que não. Seus exercícios diários seriam muito curtos e incrivelmente chatos!
No entanto, você pode escolher os bits que acha que poderiam ajudá-lo; os cartões fazem sentido, embora você não precise preenchê-los tão completamente; parar após um determinado período de tempo para verificar seu progresso também faz sentido. Mas se você estiver fazendo isso, consulte Kanban, Crystal e todos os outros métodos Agile também para obter bits que possam ajudá-lo.
fonte
Não, você não pode fazer scrum sem uma equipe. A equipe definida pela SCRUM é "Um grupo multifuncional de pessoas responsáveis por gerenciar a si próprio para desenvolver o produto", que é um papel importante na SCRUM.
De acordo com http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf
No entanto, você ainda pode ser ágil e talvez usar as outras características do SCRUM, como manter a carteira de produtos / sprint, planejar e trabalhar com sprints / iterações, revisar e obter feedback de todas as partes interessadas, re-planejar e assim por diante. Leia mais sobre o scrum, pois é muito mais do que o descrito aqui.
fonte
Estou trabalhando em uma loja semelhante. Como outros observaram aqui, o que você descreve pode ser ágil, mas não scrum. Eu também acrescentaria que o fato de fazer ou não os registros e sprints de volta faz sentido depende se é um novo trabalho ou manutenção e suporte contínuo. No primeiro caso, uma abordagem em cascata faria mais sentido para uma equipe de uma pessoa. Caso contrário, da perspectiva do gerente de projetos, o que eles estão fazendo parece uma boa abordagem se tiverem vários projetos em seu portfólio.
Para os entusiastas do Agile, a mera menção ao uso de cascata é sacrilégio. Mas as pessoas precisam usar o bom senso.
Deixe-me dar um exemplo de um projeto recente meu. Eu estava liderando uma equipe de 3 desenvolvedores em uma agressiva linha do tempo de cinco meses para redesenhar dois dos principais sites. Tivemos reuniões diárias de stand-up. Mas era um projeto em cascata porque era uma equipe pequena, com um ciclo de vida limitado, e os desenvolvedores eram todos contratados a curto prazo comprometidos com o projeto somente até o lançamento. O projeto seguiu um ciclo de vida em cascata muito tradicional. Absolutamente nada de errado nisso. Exceto pelo fato de termos trabalhado de maneira "ágil", mantivemos as reuniões de pé e as melhores práticas de desenvolvimento ágil. Nossa pequena equipe foi dispensada das reuniões semanais de planejamento de sprints da equipe maior. Por quê? Porque não tivemos implantações semanais. E nossa equipe não dependeu ou influenciou o trabalho que está sendo realizado por qualquer outra equipe. De fato, trabalhamos quase de forma autônoma. Depois que os sites foram lançados, passamos para um processo ágil para manutenção e suporte contínuos. Os outros desenvolvedores agora estão trabalhando em outros lugares. Todas as melhorias são planejadas de acordo com implantações periódicas.
O ponto é que é melhor usar os processos que fazem mais sentido para o tamanho, a complexidade e a maturidade de cada projeto. Se você está pesquisando bastante, é difícil fazer uma estimativa para os próximos cinco meses, portanto, agilidade é provavelmente uma abordagem melhor do que a cascata.
Parte do problema é que algumas pessoas pensam que você pode planejar os próximos cinco sprints com antecedência. Esse tem sido o meu caso antes. Você não deve planejar mais de dois sprints porque, se estiver, estará derrotando todo o propósito de ter sprints. Um sprint deve ser um compromisso de fornecer uma quantidade realista de aprimoramentos dentro de um período de tempo definido. Você não deve se comprometer com algo que não tem certeza. O planejamento de sprint é, por natureza, um planejamento de curto prazo, mas esse é o ponto. Se você tiver um cronograma de longo prazo, pense em dividir as coisas em entregas menores. Ou configurando reuniões de ponto de verificação com base em onde você está no SDLC.
O planejamento da sprint deve ser um compromisso realista sobre o que é garantido que será concluído dentro de um determinado período de tempo. Se você achar que o planejamento não está respondendo a variáveis desconhecidas, talvez deva começar a fornecer faixas ou estimativas pessimistas. Ou, como sugerido, use pontos da história. Os sprints também não devem ser reservados completamente para permitir derrapagens e outras tarefas importantes que surgirem.
fonte
Não deve haver apenas uma pessoa em sua equipe e duvido que realmente exista. Uma "equipe" no SCRUM não é apenas os desenvolvedores. Você é o representante do cliente, scrum master, desenvolvedor, etc ...? Você é realmente a única pessoa que faz algo relacionado a este produto, toma decisões sobre ele ou tenta vendê-lo?
Quanto à estimativa da pesquisa, você faz isso como uma história. Você cria uma história especificamente para "Pesquisa XXX" e fornece pontos para a história (lembre-se, você não está calculando tempo aqui, mas dificuldade). Você também deve ser capaz de estimar adequadamente a dificuldade de implementar algum recurso, mesmo que precise pesquisar tecnologias. Às vezes, esse último fato simplesmente transforma uma história em "dificuldade máxima".
Não, você realmente não deveria se encontrar com todos os desenvolvedores como seu suporte. Você deve se reunir com sua equipe , que novamente não são apenas os desenvolvedores.
Boa sorte. Espero que vocês entendam.
fonte
Supondo que você tenha um proprietário do produto e um scrum master (se não for, não é scrum), o scrum pode funcionar para uma equipe. Os artefatos do Scrum (backlogs, gráficos de burddown) serão usados da mesma forma que são usados na equipe de várias pessoas. Agora sobre reuniões:
Standups diários: você usaria o standup diário para atualizar todos, por exemplo, o proprietário do produto, o scrum master ou qualquer outra pessoa interessada no progresso. O Scrum Master usará essas reuniões para aprender sobre quaisquer impedimentos que você tiver. O proprietário do produto pode ajudá-lo a revisar o escopo, se / quando necessário.
Revisão do Sprint: no final de cada sprint, você entregaria o incremento de trabalho do seu software para o proprietário ou cliente do produto. Se o objetivo do sprint era aprender "algo", você demonstrará um PoC que pode ser usado pelo gerenciamento (ou seja, geralmente cliente para PoCs).
fonte