7.1 - ScrumButt

Posted on: qua, 08/28/2019 - 15:05 By: Mônica Chiesa

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.

 

 

Comentar

CAPTCHA Nosso portal usa esse mecanismo para evitar spam.