Quão relaxado (ou não) deve ser um sprint?

12

Qual deve ser a atitude em relação à realização de histórias atribuídas a um sprint? Obviamente, você deseja priorizar a realização deles no sprint, mas para mim o ponto principal do ágil é ser dinâmico: você não deseja procrastinar deliberadamente ou torná-lo "ok" perder a conclusão de histórias de usuário em um sprint, mas em Ao mesmo tempo em que coisas inesperadas surgem e essas histórias não são concluídas e são enviadas para o próximo sprint, você não quer ter a sensação de que fez algo errado. Isso não deveria ser uma experiência assustadora ou negativa, deveria?

As experiências negativas / assustadoras são aceitáveis ​​por compromissos de sprint perdidos? Os desenvolvedores devem ser responsabilizados por compromissos perdidos de sprint quando surgirem tarefas inesperadas que devem ser tratadas (por exemplo, suporte à produção)?

void.pointer
fonte
2
Isso depende tanto da equipe e da cultura da empresa, que não há uma resposta certa ... Votar para fechar como não construtivo.
Oded
2
@Oded que soa como uma resposta copiada. Você está basicamente dizendo que não há problema em uma empresa fazer uma experiência negativa e potencialmente abusiva com sprints? Vamos falar de ideais aqui. Não estou pedindo para você generalizar nada.
Void.pointer
1
No mundo ideal, com tempo e recursos ilimitados, não deve haver estresse. Isso não ajuda você, no entanto.
CodeART
2
@RobertDailey Não é nada fácil - essa não é uma pergunta respondível. É claro que é muito melhor o trabalho ser uma experiência positiva do que negativa, e o abuso real nunca é bom. Mas mesmo em um único local de trabalho, em um único projeto, a atmosfera varia. Às vezes há muita pressão, outras nem tanto. Isso vale para qualquer local de trabalho, ágil ou não. Se você estiver constantemente insatisfeito com o local de trabalho, faça algo a respeito (conserte ou saia), mas não espere que sua próxima empresa ofereça baixa pressão e alta satisfação 100% do tempo.
Caleb
1
@ Robert - Meus últimos comentários foram de natureza genérica e não uma reflexão sobre a questão como está agora. Eu estava tentando explicar ao bjarkef que votos próximos não são expressos com base no quão interessante (ou não) uma publicação pode ser. Meu último comentário para você também é uma tentativa de explicar que algumas perguntas não têm casa em nenhum site de SE. Novamente, essas são observações gerais, não diretamente relacionadas à questão.
Oded

Respostas:

7

Você deve absolutamente tentar fazer os itens em um sprint.

Um dos principais benefícios do SCRUM é que ele dá ao projeto um 'batimento cardíaco'.

Você prioriza, seleciona itens de uma lista, entrega-os, demonstra-os, reflete como eles foram e, em seguida, faz novamente em ciclos imprevisíveis.

Todo o planejamento, estimativas e priorização são baseados nesse conceito. Que podemos e iremos cometer pontos X no sprint e, com o tempo, podemos estabelecer uma velocidade a partir da qual podemos usar para um melhor planejamento.

Se você é muito despreocupado com o conteúdo e os compromissos de seus sprints, o SCRUM simplesmente quebra na minha opinião e você perde muitos benefícios.

É claro que o mundo real às vezes tem algo a dizer sobre isso, mas essa deve ser a exceção e não a regra ...

Benjamin Wootton
fonte
One of the main benefits of SCRUM is that it gives the project a 'heartbeat'.O mesmo pode ser dito de qualquer metodologia Agile.
maple_shaft
5

A chave é que é preciso haver responsabilidade em não deixar as histórias completas.

Isso significa que deve haver uma razão sólida para que uma história não esteja completa e que essa razão seja contabilizada no plano do projeto daqui para frente, para que não seja repetida.

Essa razão precisa ser mais do que uma vaga "coisa que surgiu".

Por exemplo, se uma história não foi concluída porque um membro da equipe teve que trabalhar em um problema de produção, essa possibilidade precisa ser tratada em iterações futuras - planejando menos horas com esse membro da equipe ou organizando outra cobertura.

Se o motivo puder ter sido evitado com mais diligência ou trabalho duro antecipadamente, sim, essa responsabilidade pode ser um pouco dolorosa. Felizmente, a dor é da variedade "Isto é o que precisamos fazer melhor da próxima vez" em vez da variedade "Você não está fazendo seu trabalho".

JohnMcG
fonte
4

Isso não deveria ser uma experiência assustadora ou negativa, deveria?

Se isso acontece uma ou duas vezes, não, então não deve ser uma experiência negativa. Se isso acontece regularmente, você tem um problema. A equipe está sempre supercomprometida. Melhore a estimativa e pense duas vezes sobre o que você compromete em um sprint, mas não fique ansioso.

Sprints relaxados significam que você teve um comprometimento insuficiente.

Sprints relaxados significam que você teve um comprometimento excessivo.

Eu apenas entrego o que comprometo e tento melhorar na execução. Somente em circunstâncias especiais eu mudaria uma história para o próximo sprint. Eu prefiro ter uma leve pressão todos os dias do que sofrer um pouco de pressão pouco antes de alguns prazos.

Falcão
fonte
A experiência negativa cobre muitos cenários diferentes. Um amigo teve a experiência negativa do sprint principalmente devido à equipe "ainda" não ter entendido o conceito do sprint. Em seu esforço para melhorar o ciclo de lançamento, eles basicamente aceleraram a marcha da morte e a chamaram de corrida.
Edwin Buck
4

Com base na minha experiência - Como qualquer outra coisa no Agile, nos adaptamos a um sistema de feedback contínuo, incluindo a estimativa.

Não há problema em perder um prazo para o primeiro sprint (início do projeto), mas você APRENDE daquilo que deu errado (subestimação, sem conhecer os pontos fortes da equipe etc.). Então você pega o feedback e o alimenta para o próximo sprint e obtém uma estimativa melhor.

Pela minha experiência, já faz 11 meses em meu novo projeto ágil que raramente perdemos o prazo agora, se é que o perdemos. Mas perdemos o prazo para o primeiro sprint, porque não conhecíamos o ritmo e a força dos membros da nossa equipe.

Algumas pessoas argumentam que "alocam" mais tempo para o primeiro sprint superar o primeiro problema do sprint.

java_mouse
fonte
Portanto, se você raramente perde um prazo, naturalmente não terá nada para fazer no final do sprint. O que você faz então, recebe novos itens ou apenas tira uma folga? :)
Bjarke Freund-Hansen
@bjarkef Depois que o sprint termina, iniciamos o próximo sprint e o rodamos. Sempre achei que o tempo de inatividade ao usar o "scrum" é muito menor comparado ao desenvolvimento "tradicional".
Java_mouse
Para não ter um comprimento fixo do sprint, você inicia o novo quando o antigo terminar?
Bjarke Freund-Hansen
1
@bjarkef - fixamos uma duração de 2 semanas. uma vez que as semanas terminem e sejam entregues, começaremos a próxima primavera imediatamente.
Java_mouse # 3/12
2

É interessante ver as respostas / comentários aqui. Em todos os projetos ágeis (do tipo) nos quais trabalhei, a principal vantagem era espalhar a pressão do prazo por muitos mini prazos, em vez de uma marcha de morte no prazo final de um projeto. Na IMO, os sprints devem ser levados a sério. Quaisquer falhas no prazo ou na funcionalidade entregues devem ser vistas como possíveis problemas no gerenciamento ou no desenvolvimento do projeto.

tzerb
fonte
Você está constantemente trabalhando sob pressão? Isso soa como um ambiente de trabalho adorável.
Bjarke Freund-Hansen
1
Pressão suficiente para que a equipe faça um upload, mas não uma pressão esmagadora que às vezes pode vir com a conclusão de um projeto. Mas sim, não é para todos.
Tzerb
2

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente. - Princípios por trás do Manifesto Ágil

Se é uma experiência assustadora ou negativa, e acontece o tempo todo, você tem um problema. O desenvolvimento de software deve ser divertido. Não é negativo ou assustador.

No entanto, se a equipe se comprometer a terminar algumas histórias em um sprint e não entregar continuamente, você também terá um problema. Este problema quase certamente não será resolvido, adicionando mais pressão à equipe para concluir as histórias. Se o problema é devido a fatores externos, eles precisam ser gerenciados. Se a equipe está comprometendo demais, o ScrumMaster pode orientá-la a se comprometer com menos pontos na história. Pode haver muitos motivos e cada um pode precisar ser tratado de maneira diferente. Uma equipe enérgica e motivada deve ter muita motivação para seguir em frente.

Idealmente, qualquer que seja o problema, ele é levantado durante a retrospectiva e corrigido.

Não deve ser tão complicado para a equipe descobrir o que eles podem realizar durante o período relativamente curto do sprint e depois realizá-lo (uma história ocasional que é levada para o próximo sprint é OK, a velocidade pode flutuar, as coisas mudam etc. .). Se você não conseguir fazer isso razoavelmente bem após alguns sprints, estará fazendo algo errado.

Guy Sirton
fonte
1

Realmente depende da sua linha do tempo.

Às vezes, você precisará concluir todas as histórias, ou a maioria delas de qualquer maneira. Embora o Agile forneça alguma flexibilidade, você também precisará concluir o projeto, possivelmente em um cronograma apertado. Portanto, ter a maioria das histórias feitas permitirá que você conclua o projeto a tempo.

Com isso dito, no entanto, surgirão coisas que o impedirão de realizar todas as histórias, todos os sprints.

Se o produto estiver em uma linha do tempo e as principais histórias forem perdidas, essa falha poderá atrasar o produto. O atraso do produto em alguns casos pode prejudicar a posição competitiva de uma empresa. Portanto, nesse caso, você pode querer que seja uma experiência negativa a falta de histórias - isso pode fazer com que você faça tudo da próxima vez.

Alan Delimon
fonte
1

Quando administrado corretamente, o estresse é bom. Você quer não querer eliminar todo o estresse, apenas espalhá-lo de maneira mais uniforme no tempo. Mesmo quando você joga seu jogo favorito, você terá uma certa quantidade de estresse e sentimentos negativos. Você realmente obtém mais energia disso.

Uma equipe deve se sentir realmente mal com as histórias perdidas. Isso lhes dará energia para mudar alguma coisa na próxima vez (trabalhe de maneira diferente ou planeje menos histórias, ambas são boas). Eles também devem sentir orgulho quando fazem suas histórias, é claro.

Você também menciona tarefas inesperadas (suporte à produção). Isso levanta uma bandeira vermelha comigo. Deveria haver um prazo combinado para todas as questões não relacionadas às histórias. Caso contrário, o jogo não é justo, a equipe se sente desamparada e os sentimentos negativos não são usados ​​para melhorar.

Kris Van Bael
fonte
1

Você deve examinar os fatores que fazem com que seus compromissos falhem e tentar consertá-los. Grandes quantidades de eventos aleatórios continuarão atrapalhando seus sprints, tornando sua velocidade imprevisível. Corrija as causas disso ou introduza folga nos seus sprints. Eu prefiro consertar.

De qualquer forma, a equipe não pode ser responsabilizada se seu trabalho for perturbado por fatores externos. Use retrospectivas para analisar isso.

Martin Wickman
fonte