Profissionais TI - Pra quem respira informação

Esse artigo trata de um assunto discutido por muitos coordenadores e gerentes de desenvolvimento em empresas de software. De um lado, temos o Desenvolvimento Ágil, uma metodologia que defende o software em funcionamento perante a documentação. E por outro lado, o MPS.Br, um programa de qualidade que exige a documentação dos processos como requisito de certificação. Logo, é possível conciliá-los?

Antes de entrar no assunto, é importante salientar que o Desenvolvimento Ágil não afirma que a documentação não é necessária. Esse mal entendido causa uma distorção da metodologia ao ponto de vista de alguns gerentes e diretores. A documentação é essencial em qualquer projeto, independente da metodologia utilizada. É a partir dela que os requisitos são classificados e processos são detalhados para que exista uma base para o escopo do projeto. Além disso, a documentação facilita a compreensão de novos integrantes da equipe e mantém um melhor controle das atividades de desenvolvimento.

Porém, eis que encontramos a seguinte proposição entre os manifestos ágeis:

“Software em funcionamento mais que documentação abrangente”

Isso significa que o projeto pode ser desenvolvido sem documentação?

Não. A documentação abrangente, segundo subentende-se neste manifesto ágil, diz respeito à documentação formal desnecessária, ou seja, páginas que causam mais volume do que o entendimento do projeto, geralmente encontradas no Desenvolvimento em Cascata. Ao tentar documentar demais (ou em excesso), ao invés de detalhar, acaba por dificultar a compreensão, trazendo uma complexidade que não deveria existir. Portanto, ao invés de gerar uma documentação excessiva, utilize o tempo para focar no funcionamento do software.

O MPS.Br, embora exija um gerenciamento de projetos fundamentado em documentações, não é uma controvérsia ao Desenvolvimento Ágil. Pelo contrário, há uma grande facilidade de relacionar as áreas de processo do Mps.BR com os conceitos das metodologias ágeis, de forma a trazer um equilíbrio no gerenciamento de projetos de uma empresa. Ao mesmo passo que os níveis do Mps.BR foram aprimorados, os métodos ágeis também contemplaram uma série de evoluções, principalmente os mais utilizados no mercado de desenvolvimento de software.

Se formos analisar ao pé da letra, notaremos que os fundamentos realmente são divergentes, mas em nenhum momento há informações de que são incompatíveis, visto que o Desenvolvimento Ágil e o Mps.BR possuem, em tese, a mesma finalidade. Em linhas gerais, significa que os métodos ágeis podem (ou devem, em alguns casos) ser formalizados, do mesmo modo que o Mps.BR não impõe nenhum obstáculo para a adoção dos métodos ágeis. Ao invés de entrarem em conflito, eles podem se encaixar e fazer a engrenagem girar.

Enfim, quer dizer que é possível conciliar o Mps.Br com Agile?

Sim, e sem nenhuma complexidade. Inclusive é possível encontrar várias empresas certificadas em MPS.Br que utilizam Scrum ou eXtremme Programming como metodologia, que souberam estender eficientemente a metodologia ágil para atingir os níveis de maturidade.

Só a título de exemplo, no nível C do Mps.BR temos duas áreas de processos:

• DRE – Desenvolvimento de Requisitos
• GRE – Gerência de Requisitos

Essas duas áreas podem ser facilmente associadas ao conceito de Backlogs no Scrum (Product Backlog e Sprint Backlog). Cada post-it no quadro do Scrum (Agile Radiator) representa uma estória do cliente, e cada estória se origina de um requisito validado. Ora, sendo assim, qual a dificuldade de introduzir o Scrum nessas duas áreas de processos, já que os Backlogs tratam de conjunto de requisitos? E digo mais: não é uma questão de “adaptação”, mas sim de melhoria nos resultados. Portanto, observe que as ferramentas propostas no programa Mps.BR podem ser encontradas e utilizadas no Desenvolvimento Ágil sem perder o foco de maturidade.
Na verdade, essa é uma dúvida que eu também tive no início, mas foi apenas falta de informação sobre o assunto. Alguns meses depois, trabalhei em uma empresa certificada no nível F do Mps.BR que utiliza Scrum nas equipes de desenvolvimento, e pude garantir que essa combinação de fato funciona.

Abraço!

Publicado originalmente no blog SubRotina