Vantagens do Scrum para os próprios desenvolvedores? [fechadas]

Sendo o Scrum uma metodologia de gerenciamento de projetos, como você o venderia aos desenvolvedores em uma equipe razoavelmente satisfeita com a situação atual?

Parece-me fácil explicar ao nosso gerente de produto como o Scrum permitirá que ele obtenha versões regulares, altere requisitos e faça com que a equipe se concentre nas histórias de alta prioridade primeiro. Achei fácil explicar o que o TDD ou a Integração Contínua traz na vida cotidiana de um desenvolvedor.

Mas como os desenvolvedores podem ser convencidos a adotar o Scrum? Como o Scrum facilitaria sua vida?

O Scrum fornecerá muito mais visibilidade sobre o que está acontecendo . Má administração, mudanças de última hora, pressões e todo tipo de coisa que um desenvolvedor geralmente enfrenta.

No entanto, também trará muita visibilidade aos procrastinadores, desenvolvedores de má fé, individualistas insanos, ... em outras palavras, desenvolvedores ruins.

Scrum é uma faca de dois gumes

O Scrum oferece a você oportunidades para resolver esses problemas. É por isso que é tão poderoso.

Quebrar o grande objetivo ("executar o software") em pedaços menores - histórias - e decidir qual deles executar no sprint atual melhora a produtividade e reduz o estresse. Quando você sabe especificamente o que deveria fazer agora , pouco se preocupa e pode se concentrar em fazer o pedacinho, em vez de se sentir sobrecarregado com o todo.

O Stack Ranks / Backlog evita que as etapas do marco sejam marchas da morte

Como desenvolvedor, o 'padrão destrutivo' que eu mais vejo no desenvolvimento de software é quando algum 'controlador externo' (por exemplo, gerenciamento de projetos, gerenciamento executivo) fica muito empolgado com o fato de que o 'recurso favorito' não será ativado ' data do calendário "e ordena uma marcha da morte.

Scrum, porque classifica os "recursos importantes" em uma lista de pendências ajuda os desenvolvedores a gerenciar essa tensão de maneira proativa de duas maneiras. Primeiro, você pode classificar o 'recurso favorito' no topo da lista de pendências, de modo que é mais provável que ele seja feliz. Segundo, ele fornece uma resposta muito visual e concreta para "desde que movemos os 'widgets piscantes' para a classificação 1, é muito provável que não vamos conseguir 'coelhinhos saltitantes' neste sprint, já que agora está na classificação 7. você está confortável com essa troca? "

Também descobri que, com sprints curtos, os 'controladores externos' ficam menos preocupados com o adiamento do trabalho. Se 'widgets piscando' não chegar ao 'marco 1' e 'marco 2' não terminar até daqui a nove meses, o patrocinador dos 'widgets piscando' ficará muito chateado. Mas se os 'widgets piscantes' estiverem na pilha 7, em vez de 1, porque realmente existem 6 coisas mais importantes que precisam ser feitas primeiro, isso significa que provavelmente chegaremos a isso no sprint + 1 ou, na pior das hipóteses, sprint + 2, o que significa ele será exibido daqui a 12 ou 18 semanas (usando sprints de 6 semanas). Na minha experiência, esperar três meses é 'aceitável' para o impaciente. Além disso, de volta ao modelo 'cascata' de marcos com mais de três meses,

Por fim, se estivermos chegando ao final do sprint e as coisas demorarem mais do que o esperado, é muito bom poder enviar os itens de backlog 5-6-7 para o próximo sprint e garantir que concluímos o 1-2-3 -4 com alta qualidade e sem 70 horas por semana. Afinal, teremos 5-6-7 no próximo sprint. Mais uma vez, dados os prazos mais curtos envolvidos no adiamento, os 'controladores externos' geralmente se sentem mais à vontade com isso e não insistem em que reduzamos o marco de duas semanas e pedimos jantares a cada noite 'para avançar'.

As pessoas de uma equipe Scrum decidem muitas coisas sozinhas: o que será feito durante o próximo sprint, como quebramos essa história em tarefas, quem trabalha com o quê etc. Isso as capacita e é quase exatamente o contrário do micro -gestão.

O fato de os requisitos mudarem é levado em consideração desde o início. Os desenvolvedores não precisam criar especificações detalhadas com estimativas precisas e passar semanas desenvolvendo um recurso apenas para perceber que o cliente muda de idéia assim que vê o resultado ...

Para mim, você pode auto-atribuir tarefas a partir da lista não processada, o maior ponto de venda do ponto de vista do desenvolvedor. Além disso, a intimidade com o cliente / proprietário do produto ajuda a entender o esquema maior das coisas.

Um par de coisas:

• Com base no argumento de Xavier sobre os requisitos mudarem desde o início - uma atmosfera menos política se desenvolve quando todos aceitam desde o início que algumas coisas não serão como o cliente espera. Entrega e revisão rápidas significarão que o custo de comunicação incorreta é baixo e, em vez de jogar o jogo da culpa, os desenvolvedores podem simplesmente mudar as coisas para que funcionem conforme o cliente espera.

• Pontos da história! Qual desenvolvedor não gosta de ganhar pontos por fazer coisas !!?! Sério, é melhor do que obter crachás no SC2 ou Stack Overflow.

Há várias coisas que eu, como desenvolvedor, gosto no scrum.

Os desenvolvedores tendem a receber mais informações antecipadamente. O proprietário do produto precisa explicar todo o trabalho que será realizado durante o próximo sprint em detalhes suficientes para permitir boas estimativas.

A estimativa just in time significa que essas estimativas são razoavelmente precisas. Todo mundo geralmente tem uma idéia razoavelmente boa do que será concluído em um sprint. Isso fornece aos programadores e gerentes de projeto as ferramentas para combater demandas irracionais.

É bom voltar a cada três a quatro semanas, respirar e, pelo menos, mudar de ritmo.

Equipes auto-organizadas parecem dar um pouco mais de variedade no trabalho.

Em teoria, pelo menos, durante o sprint, há menos interrupções e 'emergências'.

A reunião diária de pé obriga os programadores a dizer várias palavras todos os dias.

É mais fácil ver o progresso sendo feito, pois as histórias são explicitamente concluídas e revisadas no final de cada sprint.

Os gráficos de queima são um meio bastante eficaz de acompanhar o progresso.

A vantagem para o desenvolvedor é o feedback inicial (do cliente, testador, proprietário do produto etc.).

Também como desenvolvedor, estou sempre interessado em fazer as coisas passo a passo, sem distração. O Scrum fornece isso.

PS: scrum não é uma metodologia, é uma estrutura.