BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Defendendo o time-box: sprints mais longas raramente são a solução

Defendendo o time-box: sprints mais longas raramente são a solução

Favoritos

O Scrum Coach Richard Lawrence discute em artigo recente os riscos de aumentar o tamanho das sprints, quando os resultados não estão sendo obtidos como esperado no tempo definido. Ele apresenta sete dos principais problemas que levam a essa decisão que considera muitas vezes precipitada, e apresenta uma série de recomendações.

Lawrence destaca que em suas consultorias e treinamentos costuma ouvir algo como: "o tamanho da nossa sprint é muito pequeno, queremos alterá-lo de X para Y". E reitera a importância do conceito de time-box em Agile, por permitir a identificação rápida de problemas no desenvolvimento e na equipe. Antes de aumentar o tamanho da sprint, Lawrence recomenda identificar os reais motivos para essa mudança. Veja a seguir os sete problemas identificados por Lawrence e as recomendações correspondentes.

Problema 1. Tentar fazer "mini-waterfalls"

É muito difícil executar um ciclo de desenvolvimento em cascata (waterfall) dentro de uma ou duas semanas, diz Lawrence, pois o tempo seria curto demais para essa forma de desenvolvimento. Caso os testes iniciem regularmente no final do sprint, por exemplo, a recomendação é experimentar algo como ATDD (Desenvolvimento orientado a testes de aceitação) para iniciar os trabalhos de testes mais cedo e tentar trabalhar com um menor número de histórias por vez.

Problema 2. Evitar a divisão de histórias

Para aumentar a previsibilidade nas sprints, Lawrence recomenda planejar de seis a dez histórias por sprint. Ele ressalta que às vezes, equipes veem necessidade de aumentar o tamanho da sprint por não se sentirem à vontade em dividir as histórias para que caibam em sprints de duas semanas. A habilidade de dividir as histórias é algo que exige tempo e prática para desenvolver, mas a tarefa não deve ser evitada, sob pena de comprometer o projeto.

Problema 3. Reuniões muito longas

Pode acontecer, diz Lawrence, que as reuniões diárias, e principalmente as reuniões de planejamento, sejam percebidas como longas e dolorosas. Sendo assim, será natural querer fazê-las com menos frequência. Veja algumas recomendações para melhorar esta situação:

  1. Fazer regularmente reuniões de grooming a cada um ou dois dias, apenas com os membros necessários;
  2. Planejar usando Story Points em vez de estimativa de horas;
  3. Criar atividades somente quando necessário;
  4. Realizar a reunião de planejamento em várias fases: discussões em alto nível e compromisso em Story Points e, em seguida, uma discussão detalhada de cada história, conforme necessário.

Problema 4. Dificuldades em realizar deploy, merge ou integração

Segundo Lawrence, quando isso acontece, talvez se esteja tentando implantar histórias completas em algum tipo de ambiente formal, ou até mesmo dependendo de um gerente externo para isso, o que dificulta o processo e gera resistências em fazê-lo. Como solução, Lawrence propõe a prática de Continuous Delivery, proposta por Jez Humble e David Farley, e recomenda seguir o conselho dos autores: "se alguma coisa for difícil de fazer, faça-a com mais frequência para que deixe de ser difícil".

Problema 5. Não ter nada pronto em duas semanas

Lawrence relata que frequentemente as equipes dizem algo como: "não conseguimos entregar nada de valor em duas semanas, por isso temos que aumentar o tamanho da sprint." Porém mudar o tamanho da sprint de duas para quatro semanas não muda o valor entregue em duas semanas! Quanto a isso, ele recomenda duas ações:

  1. Usar a técnica MMF (Minimum Marketable Feature) para agrupar histórias e ter um maior valor entregável.
  2. Fazer uso de técnicas de causa-raiz para identificar porque não se consegue entregar o esperado. Talvez seja um problema de tecnologia usada no desenvolvimento; ou o gargalo pode estar no especialista, porque as competências são distribuídas de forma desigual na equipe.

Problema 6. Demora ao obter feedback

Se o Product Owner (PO) leva cerca de uma semana para responder às perguntas da equipe, provavelmente será muito difícil entregar algo de valor em uma semana ou duas. Para Lawrence, aumentar a duração da sprint nesse caso também não seria a solução. Veja algumas das suas sugestões:

  1. Assumir algumas responsabilidades do PO para que ele ou ela possa concentrar-se em seu trabalho;
  2. Dar ao PO, ou à equipe, mais autoridade para tomar decisões sem depender de outras partes interessadas;
  3. Trabalhar para ampliar o conhecimento da equipe sobre o negócio. Isso reduziria a necessidade de contatos externos.

Problema 7. Dependência de um especialista externo

Há momentos em que o time não consegue finalizar uma história sem a ajuda de um especialista (como um DBA, Arquiteto, ou especialista em certa tecnologia). Além disso, essa pessoa costuma ser "dividida" com outras equipes. Antes de aumentar o tamanho da sprint para contornar esse problema, Lawrence sugere reduzir a dependência, tentando:

  1. Trazer o especialista para dentro do time;
  2. Reduzir a quantidade de atividades do especialista para que ele possa atender o time;
  3. Investir para estender as habilidades e a autoridade do time para que não necessite tanto do especialista.

Richard Lawrence conclui dizendo:

Se mesmo após enfrentar todos os problemas e tentar resolvê-los, sua sprint ainda for pequena, tente aumentá-la. Mas não perca a oportunidade de fazer melhorias antes de estender a duração da sprint.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT