BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

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

por Gustavo Castro em 27 Set 2011 |

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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Problema 7 by Victor Hugo Bueno

Temos a incidência do problema 7 no nossos projetos. A área de desenvolvimento depende do DBA que pertence à infraestrutura. Sempre quisemos trazer a parte do controle do banco enquanto desenvolvimento para nosso departamento, porém, isso nunca foi possível. A infra alega que não podem controlar em produção algo que não tinham dado opinião técnica enquanto desenvolvimento. Temos uma solução parcial para o problema, que é identificar no planejamento todas as histórias que necessitarão de alterações no banco, e estas alterações são solicitadas já no início da sprint. Mesmo assim, ainda nos encontramos fazendo entregas "parciais" devido ao atraso nas execuções de banco. Como poderíamos resolver de vez este problema?

Re: Problema 7 by Gustavo Castro

Olá Victor,
Para ajudar a minimizar esse problema, você pode trabalhar com virtualização de banco. Dessa forma durante o desenvolvimento você não necessita da construção física do banco de dados. Assim ao final da sprint todo o banco pode ser criado de forma estável.
Resumindo: Você trabalha na construção do software sem a dependência da infra, e ao final no momento de apresentar o resultado da sprint, vc terá uma versão estável do banco de dados.
Segue um link para te ajudar um pouco sobre virtualização de banco de dados: revista.newtonpaiva.br/seer_3/index.php/Revista...
Espero que tenha ajudado.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT