Bas Vodde, praticante e coach Scrum, conheceu várias empresas durante seu trabalho de disseminação de métodos ágeis onde o pessoal dizia que usava o Scrum, mas… (em inglês: We use Scrum, but…). O risco de se usar o Scrum, mas… é que esse “mas” é uma tendência à entrega à resistência interna, que tende a manter as empresas em ciclos tradicionais de desenvolvimento (o Waterfall) e, de fato, não implementar o Scrum, mas uma espécie de Scrum Bunda. Explico: Vodde foi quem veio com a brincadeira e o neologismo que uniu a expressão Scrum but… no termo ScrumButt – literalmente Scrum Bunda.
A empresa usa alguma coisa do Scrum, consegue um aumento modesto de produtividade e dá-se por satisfeita com seu Scrum Bunda. Isso não pode ser assim. Mais adiante, trataremos sobre a produtividade com o Scrum, mas, em resumo, não espere menos de 300% de aumento na produtividade de sua equipe ao adotar o Scrum. Não se permita ficar satisfeito com ganhos marginais trazidos pelo seu Scrum Bunda.
Para saber se o seu Scrum é dos bons ou se é um bundão, Bas Vodde criou um teste que é um ótimo complemento ao catálogo de cheiros sobre o qual você leu há pouco. Jeff Sutherland (você sabe, o pai do Scrum junto com Ken Schwaber) gostou e é um de seus grandes incentivadores e divulgadores. O ScrumButt Test é dividido em duas partes: na primeira, você identifica se está (ou não) fazendo um desenvolvimento iterativo e, na segunda, você identifica se, de fato, está usando o Scrum.
A iteração e a realimentação são aspectos basais do desenvolvimento ágil. No Scrum, elas acontecem na progressão dos Sprints. Para saber se seu desenvolvimento é iterativo, considere o seguinte:
- Seus Sprints têm, cada um, a mesma duração, e essa duração é de uma a quatro semanas (no máximo!);
- Ao final de cada Sprint, você entrega algo perfeitamente testado e funcional;
- Todos os seus Sprints iniciam com os itens de seu backlog bem definidos.
Você está, verdadeiramente, usando o Scrum se…
você sabe quem é o Product Owner;
- existe um Product Backlog priorizado de acordo com o valor do negócio para o cliente;
- as estimativas para o desenvolvimento dos itens do Product Backlog foram criadas pela equipe;
- a equipe gera seus Burndown Charts e conhece a sua velocidade;
- não há nenhum gerente (ou nenhuma outra pessoa) atrapalhando o trabalho da equipe.
Estimativas são o assunto do próximo capítulo, o último desta Parte II do livro. Você já se inteirou de todos os demais itens e, para avançar na sua aprendizagem, as seções relativas a recursos e ferramentas lhe darão muito mais horas e horas de diversão.
Modelo Waterfall
Figura 7.2 – O modelo Waterfall. Fonte: Wikimedia O modelo de desenvolvimento em cascata (Waterfall) pressupõe um conhecimento tão profundo do que deve ser desenvolvido que todos os requisitos podem ser determinados de antemão, e o projeto segue, em cascata, por suas fases de modelagem, implementação, verificação e manutenção continuada sem que, em nenhum momento, seja necessário voltar a uma fase anterior. Esse modelo, por mais que seja criticado, jamais foi totalmente defendido pelos que o documentaram inicialmente. Sua primeira apresentação data de um simpósio de métodos avançados de programação, de 1956, em que Herbert D. Benington falou sobre o desenvolvimento de um software para a defesa aérea americana durante a Guerra Fria. Em 1983, o próprio Benington republicou o artigo original, com um prefácio destacando que o processo de desenvolvimento não foi simplesmente em cascata, mas suportado por um protótipo em que os requisitos eram validados e até modificados durante o processo de desenvolvimento. O trabalho mais citado sobre o modelo Waterfall, porém, é de Winston W. Royce, que em 1970 apresentou esse modelo como um exemplo de um processo que não teria sucesso, em uma crítica bastante similar à que é feita, ainda hoje, por praticantes de métodos ágeis. De forma interessante, Royce jamais usou o termo “Waterfall” em seu artigo. |
| Apesar de tudo isso, o modelo tornou-se popular graças a um padrão definido pelo departamento de defesa americano (DoD STD 2167) para o desenvolvimento de software, que explicitamente exigia que o Waterfall fosse o modelo usado em qualquer contratação de desenvolvimento de software. Anos mais tarde, o principal autor do padrão declarou-se arrependido de tê-lo criado, já que não estava totalmente familiarizado com requisitos dinâmicos e desenvolvimento iterativo, algo que teria recomendado se pudesse, novamente, escrever o padrão. Toda essa história é contada com detalhes por Craig Larman em seu livro Agile and iterative development: a manager’s guide (Addison-Wesley, 2004). O departamento de defesa americano iniciou, em 2014, um processo de modernização de seu desenvolvimento e adoção do Scrum, com a contratação de Jeff Sutherland como consultor. |
