Existe ainda na comunidade de gerenciamento de projetos grande resistência aos métodos ágeis, pois muitos profissionais acreditam que "ser ágil" é o mesmo que não seguir processos, não ter documentação, "pular etapas". Em outras palavras, ser ágil seria não seguir regras ou normas; fazer o que se quer, em estado de anarquia. Já os outros processos formais de desenvolvimento são tratados com maior seriedade e profissionalismo.
A verdade é que muitos da comunidade de gerência desconhecem a essência da filosofia ágil e sua forma de trabalho, e esse desconhecimento leva a julgamentos equivocados. Por outro lado, muitos agilistas julgam os modelos tradicionais como burocracia.
Para entender melhor se essas críticas procedem ou não, vamos explorar alguns conceitos e definições.
Gerenciamento e agilidade
O gerenciamento de projetos é a aplicação de conhecimentos, ferramentas, técnicas e um conjunto de atitudes nos projetos para buscar o seu êxito (atender as expectativas dos interessados). Isso se constitui num conjunto de processos de gestão e os frameworks ágeis fazem parte desse grupo.
O Agile é uma filosofia e visa nortear atitudes e comportamentos. Ser ágil é:
- Focar na entrega de valor de negócio;
- Permitir que todos participem da construção do resultado, desde a etapa do planejamento, passando pela execução e finalizando com a entrega dos produtos e a avaliação do ciclo de entrega;
- Criar um ambiente onde todos sejam responsáveis também pelo gerenciamento das atividades, e onde todos são responsáveis pela entrega dos produtos;
- Seguir as cerimônias de abertura (planejamento), de gestão (reunião diária) e fechamento (revisão e retrospectiva) de cada ciclo de entregas (Sprint), e ter disciplina na execução e no cumprimento dos objetivos/regras que norteiam cada uma dessas cerimônias.
A partir dessa filosofia, surgiram diversos frameworks com boas práticas de gerenciamento, sendo o Scrum o mais popular. No Scrum existem papéis bem definidos (Product Owner, Time/Equipe e Scrum Master) e cerimônias que devem ser executadas, além da definição de um resultado a cada ciclo de entregas visando agregar valor ao negócio.
Modelos de qualidade e o Agile
Observa-se no mercado de desenvolvimento de software, uma relação, a meu ver equivocada, entre os modelos de qualidade (ISO, MPS.BR e CMMI) e Agile, em que se conclui que empresas certificadas nesses padrões não podem utilizar a filosofia ágil.
Porém, como vimos, os modelos de gerenciamento baseados em Scrum/Agile visam agregar valor ao negócio e fornecer entregas num menor espaço de tempo. E todos os artefatos e produtos do MPS.BR ou CMMI agregam valor; portanto serão tratados como entregas que serão planejadas, executadas e monitoradas até a sua conclusão.
Exemplificando, o MPS.BR exige que seja criada uma matriz de rastreabilidade de requisitos. Além dos outros itens do backlog que o time deve executar dentro de um ciclo de entrega (Iteração ou Sprint), a criação desse documento será mais um item que será estimado e considerado como entrega.
Como se vê, caso a empresa tenha certificados ISO, MPS.BR, CMMI etc. ou procedimentos a serem seguidos e políticas internas, ela poderá usar Agile sem nenhum problema. A única diferença é que, além das entregas aos clientes (produto pronto = software funcionando), o valor a ser agregado também contempla os documentos e artefatos a serem produzidos referentes a essas entregas.
Importante também deixar claro que existe uma diferença entre os processos ágeis de gerenciamento e os métodos ágeis de engenharia de software. Os processos se relacionam à gestão do valor das entregas; os métodos se referem aqueles usados na construção do produto que compõe essas entregas. Se forem utilizadas somente as práticas de gerenciamento baseadas em Agile, como o Scrum por exemplo, para melhorar a produtividade da equipe, isso não definirá a maneira como a equipe documenta e constrói os produtos.
A maneira como a equipe produz (as etapas de construção do software, por exemplo) cabe aos modelos de engenharia. Portanto, a utilização de métodos de gestão Agile não determina se existe ou não documentação. Isso cabe aos modelos de engenharia de software utilizados - ágeis ou não.
Burocracia positiva
Ser Agile é seguir regras, procedimentos definidos (cerimônias), com cada um executando seu papel no ambiente de construção do resultado. Portanto, o Agile é sim burocracia! E é muito importante entender que qualquer método de trabalho é burocrático.
Mas ser burocrático não é o problema, pois as regras são necessárias para nortear qualquer tipo de trabalho. O problema reside, é claro, em ser excessivamente burocrático, gerando atividades/produtos que não agregam valor e consomem desnecessariamentee tempo da equipe.
E então? Você prefere uma burocracia que atrapalha, que emperra as atividades e desmotiva a equipe, ou uma burocracia que foca em atividades que geram produtos (documentos, artefatos, software) que agregam valor ao negócio? Ser ágil é uma atitude orientada a resultados. Faça sua escolha e seja feliz nos seus projetos!