Há pouco tempo li o livro “User Stories Applied“, do Mike Cohn, recomendado a mim por Fabrício Paiva. O autor dispensa apresentações para a comunidade Agile, e o material é também de ótima qualidade.

Muito explicativo, e com diversos exemplos da vida real, é o livro de cabeceira para Analistas de Negócio e Gerentes de Produto que trabalham com desenvolvimento ágil.

Especificamente no meu caso, por estar me aprofundando nos estudos e aplicação do Scrum já há algum tempo, gostei muito do conteúdo. Há tempos que procuro um texto mais completo sobre o trabalho e o papel do Product Owner, sendo que em grande maioria os conteúdos disponibilizados na internet e em livros se destinam mais a Scrum Masters ou desenvolvedores de equipes Scrum, descrevendo brevemente o papel do PO.

Fica a dica para os atuais e futuros Product Owners e Scrum Masters. Lembrando que, apesar de fazer referência a Scrum e a XP em suas páginas, o livro não é amarrado a nenhum framework ou metodologia ágil especificamente. Curiosidade: Kent Beck, criador do XP, assina o prefácio do livro.

Scrum mal aplicado

Não é culpa do Scrum. Desenvolvimento ágil não trata apenas de boas práticas de engenharia. É também sobre o reconhecimento da importância das pessoas no processo de desenvolvimento, formando equipes multidisciplinares, com comunicação em larga escala, constantemente refletindo e melhorando, entregando valor, e mudando planos para melhor aproveitar as oportunidades.
E Scrum inclui todos esses pontos. Diz, por exemplo, para colocar a equipe em um ambiente de trabalho compartilhado. Diz que no final de cada Sprint um produto de valor deve estar pronto para ser entregue, e diz também que a equipe deve se auto-organizar, descobrir impedimentos e removê-los.
Scrum também tem algumas poucas coisas mecânicas a respeito de Sprints mensais e Scrum diário. Coisas triviais comparadas com todo o resto. Mas, infelizmente, é essa a única parte que muitas pessoas adotam. Ciclos rápidos, mas nada daquelas boas práticas que fazem o ciclo rápido ser sustentável.

Você está fazendo errado

Neste momento, há muitas equipes falhando com o desenvolvimento ágil. Esses times estão trabalhando em ciclos pequenos. A crescente freqüência de planejamento deu-lhes um maior controle sobre seu trabalho e eles estão descobrindo e consertando alguns problemas. Eles se sentem bem, e eles realmente parecem mais bem sucedidos do que eram antes.

Mas eles não estão trabalhando em ambientes de trabalho compartilhados, nem enfatizando a necessidade de comunicação de larga escala. Eles não mantêm os clientes por perto do local de trabalho. Eles nem mesmo terminam todas as suas Estórias até o final de cada Sprint, e certamente não utilizam boas práticas de engenharia.

Esses times se dizem ágeis, mas eles estão apenas praticando um tipo de “planejamento freqüente”. Ciclos curtos e capacidade de re-planejar são apenas os benefícios que o desenvolvimento ágil lhe dá. É a recompensa, não o método. Essas equipes pseudo-ágeis estão comendo a sobremesa toda noite e pulando o prato principal, os vegetais. Deixando de lado todo o resto (o ‘resto’ realmente ágil), elas estão bem encaminhadas para “dentes cheios de cáries”, “obesidade” e, conseqüentemente, estão fadados a falhar. No começo se sentem bem, mas isso não dura por muito tempo.

Resumindo, pare e pense: você está querendo pular o arroz-com-feijão, os brócolis e a salada, para ir direto a sobremesa? Se sim, você está, como muitos, deturpando os valores defendidos no manifesto ágil, e está no caminho errado.

Metodologias ágeis são tão boas quanto as pessoas que as usam!

Por quê precisamos de analogias? Programadores sabem o que estão fazendo, eles programam computdores! E eles sabem o que isto significa, simplesmente pelo fato de que eles o fazem.

Porém, para os stakeholders – gerentes, presidentes, clientes, parceiros – desenvolvimento de software é um mistério. Eles não estão interessados em saber tudo sobre o assunto, mas querem saber o bastante para fazerem previsões. Precisam então de uma abstração, uma analogia.

Matemática e Engenharia são duas analogias comumente utilizadas. Na primeira tudo pode ser matematicamente provado ou desmentido. Na segunda, o grau de previsibilidade é altíssimo e as técnicas de trabalho são consolidadas e padronizadas. É perfeitamente possível substituir um engenheiro por outro, e ainda assim obter-se resultados similares.

Olhando para tais considerações, identificamos grandes diferenças para os programadores. Mudar um programador significa mudar os resultados.

Segundo Eckel, programadores são – essencialmente – escritores.

Escritores como autores de livros, de novelas, de roteiros. Existem bons e maus escritores, e existem empresas que precisam de ótimos escritores, como também existem aquelas que precisam apenas de escritores, não tão bons assim. E mais, ter um bom escritor não implica na produção de um best-seller.

O que o autor defende, em resumo, é que esta analogia não ajuda a aumentar o grau de previsibilidade de o que fazem os programadores, mas, a exemplo da escrita, que é um trabalho artístico, estranho e difícil de medir, ajuda aos stakeholders a entenderem o quanto tal atividade é imprevisível.

Leia o artigo na íntegra clicando aqui.