As 10 melhores práticas para se construir software.

1 - Desenvolva uma visão do produto.

2 - Trabalhe de modo iterativo e evolutivo.

3 - Envolva o cliente no processo.

4 - Gerencie requisitos.

5 - Acolha mudanças.

6 - Construa o design e a arquitetura incrementalmente.

7 - Diminua o tempo de feedback.

8 - Gerencie riscos.

9 - Aplique técnicas de engenharia.

10 - Confie na equipe.

Devagar com o Andor que o Santo é de Barro

Recebi vários emails de pessoas que ficaram confusas com meu último post... Muitos acharam que havia uma incoerência em defender uma prática comum no PMBOK - a gestão de riscos- já que sou um estudioso e propagandeador de métodos ágeis de gestão e desenvolvimento de software.

Deixe-me esclarecer melhor: por mais que eu escreva coisas como nesse post aqui, não é a minha intenção desmerecer um trabalho de anos realizado pela comunidade do PMI. Em qualquer método, framework e guia de práticas, sempre haverá pontos positivos e negativos, relativizados de acordo com o contexto de  aplicação em cada organização ou projeto. O próprio Scrum, que sou entusiasta como muitos na comunidade agile, é cheio de lacunas em áreas como engenharia e risco.

O que aprendi é que realmente não existe uma "bala de prata" em processos da área de TI. É preciso conhecer (e estudar) vários deles para obter aquilo que melhor se encaixa ao ambiente em que estamos trabalhando e que irá contribuir para o resultado do negócio.

Logo, por mais que gostemos de Agile, Scrum, XP, Lean e Kanban não podemos ignorar que RUP, CMMI, PMBOK, SWEBOK têm grande valor e que devem ser considerados por qualquer profissional sério da área de software e/ou TI.

O Poder do Pensamento Negativo

Recentemente, li um artigo intrigante sobre o poder do pensar negativamente a respeito das coisas. Esse autor defende uma tese muito interessante: de que ter uma visão mais pessimista nos torna mais preparados diante das situações do dia a dia, devido ao comportamento "pé atrás" que passamos a assumir ao agir. Em vários pontos do texto, ele mete o malho nos "polianas" de plantão e nos propagadores de ideias como "lei da atração", o "segredo" e outras baboseiras clássicas. 

De fato, esse "pessimismo defensivo" é um excelente neutralizador de surpresas desagradáveis. Ao pensar no que pode dar errado, bolamos maneiras de contornar o problema e proteger nossas atividades dos inevitáveis imprevistos.

Em gestão de projetos essa atitude tem um nome: chama-se Gestão de Riscos.

E o que seria um risco para o projeto? Segundo o PMBOK, a definição é a seguinte:

"Evento ou condição incerta que, caso ocorra, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade."

Esssa definição é interessante pois mostra que há também riscos positivos para qualquer projeto. Muitos acreditam que o risco é sempre algo negativo e que sempre resultará em efeitos adversos à atividade realizada. Obviamente, não estamos preocupados com os efeitos positivos inesperados e sim com os de efeito negativo.

Métodos e frameworks como RUP, PMBOK e CMMI encorajam uma abordagem disciplinada a respeito dos riscos de um projeto. A ideia é listar, tão cedo quanto possível, os riscos principais do projeto e tratá-los logo nas primeiras iterações. Entretanto, frequentemente essa prática é sumariamente ignorada pelas equipes, em prol da realização de atividades que mostrem "mais serviço pronto" ao chefe, como o desenvolvimento dos cadastros de uma aplicação. Essa atitude é a que provoca falsos inícios em um projeto, postergando as atividades de maior risco que podem gerar surpresas desagradáveis mais à frente (e é o que geralmente acontece).

Por isso, entre sempre com o "pé atrás" em qualquer projeto.

Ajuda a evitar dores muito fortes de cabeça...

Scrum e a Gestão Ágil

É consenso de que em projetos ágeis de software não há lugar para o gestor do tipo sabe-tudo,  aquele que controla o projeto por completo, assumindo a total responsabilidade pelo seu sucesso ou fracasso. Esse papel é frequentemente desempenhado pelos profissionais que seguem a cartilha do PMI, criando pouco (ou nenhum) espaço para adaptação e colaboração.

Por outro lado, há sim a necessidade de um modelo de gestão. É um erro achar que projetos ágeis se auto-gerenciam, como corretamente apontam Mike Cohn e Ken Schweber no artigo "The Need for Agile Project Management":

"One of the common misperceptions about agile processes is that there is no need for project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception."

Para gerenciar projetos, o Scrum trabalha com o modelo de gestão compartilhada, distribuindo responsabilidades entre os vários papéis presentes na equipe do projeto, a saber:

1 - Product Owner 

• Responsável pela Visão do produto.
• Controla o Product Backlog.
• Monitora o projeto contra os objetivos de ROI e Visão.
• Prioriza e refina o Product Backlog, medindo o seu sucesso.

2 - Scrum Master

• Monitora o processo para garantir o sucesso da equipe.
• Permite que o time se auto-organize.
• Remove obstáculos.
• Blinda o time contra perturbações externas.
• Promove rápidas reuniões diárias.
• Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint.

3 - The Team

• Seleciona e desenvolve as estórias do Sprint Backlog
• Expande as estórias em tarefas mais detalhadas.
• Completa 100% de cada tarefa escolhida.
• Gerencia e auto-organiza o próprio trabalho.
• Diariamente inspeciona o projeto para atingir os objetivos do Sprint

Cada papel dentro da Gestão Ágil direciona esforços para entrega frequente de valor e antecipação do ROI do projeto. Em projetos tradicionais espera-se a finalização completa do projeto para se ter retorno sobre o investimento aplicado; em Scrum gera-se valor a cada pequeno incremento durante o tempo, retornando o investimento muito antes da entrega do release final e oferecendo oportunidades reais de lucro antecipado.

 

Na Gestão Ágil a responsabilidade pelo sucesso de cada projeto depende da colaboração e do comprometimento de cada um dos papéis da equipe, o que diminui o risco de se ter o destino da empreitada nas mãos de uma única pessoa.