Marcel Fleming

Como eu havia prometido, está aqui o segundo texto sobre os “Jogo dos 7 erros em Scrum”.

Apenas rememorando, os 7 erros que sugeri estão abaixo.

1- Sair usando a metodogia sem se preparar.

2- Começar projeto sem escopo definido.

3- Achar que nenhum planejamento é necessário.

4- Confundir “seguir a metodologia” com “aproveitar o que a metodologia traz de bom”.

5- Não rever a forma de contratação.

6- Achar que Scrum Master é o mesmo que Gerente de Projetos.

7- Não praticar a essência do Scrum: rituais (meetings), gestão coerente do “Product Backlog” e alocação das pessoas certas aos papeis de “Product Owner” e “Scrum Master”.

Portanto, hoje vamos falar do erro n. 2 – “Começar projeto sem escopo definido”.

Bem, imagino que um agilista mais xiita que visse esse subtítulo iria esperar com ansiedade o momento pra “descer a lenha” nesse pmbokiano inveterado que não consegue entender a ideia por trás das práticas Ágil.

Espero decepcionar esse tipo de cara.

É claro que, na proposta ágil, o escopo pode e, certamente, vai mudar. Lembre-se: a proposta é aceitar, abraçar e adaptar-se às mudanças. E tem que ser assim mesmo se considerarmos uma das principais razões pelos quais os métodos ágeis vieram para ficar.

Aí tem uma das minhas insatisfações com a interpretação do PMBoK(r). Os agilistas dizem que o PMBoK(r) desencoraja a mudança. Discordo.

O que o PMBoK diz é que toda requisição de mudança deve ser: avaliada quanto ao seu custo-benefício; validada por um stakeholder relevante; formalmente aceita ou recusada; essa decisão deve ser documentada e, se aceita, gerar um replanejamento (alteração no plano do projeto).

Agora vamos pensar bem: o que é que o Scrum propõe em termos de escopo e “gestão de mudanças”?

1- Todo projeto inicia com um Product Backlog, uma lista de funcionalidades que devem ser entregues.

2- Esta lista é inicial e sofrerá alterações ao longo do projeto.

3- O Product Owner tem uma prerrogativa definida a priori que o permite alterar o PB. Ou seja, o controle de mudança se resume a uma regra: o Product Owner é o responsável por aprovar ou rejeitar mudanças no PB (ou seja, no escopo). Na minha opinião, a formalidade está implícita no papel do PO.

Em outras palavras: há gestão de mudança de escopo, assim como no PMBoK (r), porém o processo de gestão de mudança está “embutido” no processo com um grau de formalismo menor e menos documentação normalmente.

Dito isto, me parece claro que a proposta do Scrum é começar o projeto sempre com uma versão inicial de escopo – e não sair fazendo sem ter uma “lista inicial de recursos e funcionalidades”.

Em Sliger e Broderick (2008, p. 70) as autoras explicam que no início de um projeto deve ser definido um Product Roadmap: “(…) o product roadmap mostra como o produto deve evoluir ao longo dos próximos 3 a 4 releases, tipicamente trimestres. O product roadmap é uma representação de alto nível de que funcionalidades ou temas devem ser entregues em cada release (…)”.

Vamos lembrar que no início do projeto deve haver um planejamento de releases, e uma estimativa do número de sprints e do tamanho dos mesmos.

Isto está associado a uma questão prática e relevante: as empresas precisam ter uma ideia de custo e prazo, ainda que de alto nível, antes de começar um projeto. Como fazer isso sem ter pelo menos um backlog estimado como referência?

Até posso entender que em alguns casos, com base nos dados históricos de projetos, a empresa consiga fazer uma estimativa confiável a priori – por exemplo, uma empresa que implanta sempre um determinado tipo de software específico.

Nesses casos, a empresa pode ter um conjunto de modelos típicos de projetos, com estimativas padrões de duração, tamanho da equipe, custos típicos.

Mas se pensarmos bem, esses dados históricos são uma forma de planejamento antecipado.

O erro que percebo associado a este ponto é que, em alguns casos, os projetos ágeis iniciam-se sem uma definição inicial do Product Backlog. Quando muito tem-se algumas definições de itens para os próximos 2 ou 3 sprints, mas sem a definição de um product backlog e de um release planning.

Pode até ser, não descarto, que em alguns casos esta forma de trabalhar possa funcionar. Talvez em uma situação em que se queira produzir um protótipo, fazer uma prova de conceito.

Mas eu não sei como um diretor ou um cliente assinariam um contrato para iniciar um projeto de maior porte e esperando obter valor com o produto a ser desenvolvido sem ter uma ideia inicial do que se pretende entregar.

Para algumas situações, acho interessante a proposta do Disciplined Agile Delivery (DAD) desenvolvida pela Rational IBM (Lopes, 2013), pois na minha visão ela mescla bons aspectos da metodologia RUP com o Scrum. Só lembrando que o RUP já propunha a ideia de iterações curtas.

No final das contas, independente de “ideologias”, o importante na minha opinião é manter uma mente aberta, mas reconhecer que no mundo real é preciso ter sempre uma visão inicial de onde se quer chegar, sabendo que ao longo do caminho mudanças ocorrerão.

 

 

Referências

Sliger, Michele; Broderick, Stacia. The software project manager’s bridge to agility. Boston: Pearson Education, Inc. 2008.

Lopes, Dennis. Uma Introdução ao Disciplined Agile Delivery – Parte I. Disponível em: https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/uma_introdu_c3_a7_c3_a3o_ao_disciplined_agile_delivery_parte_i19?lang=en . 2013. Consultado em 21/03/2014.

PMBoK é marca registrada do Project Management Institute.