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!
Pergunta
by Niler Barcelos,
Pergunta
by Niler Barcelos,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Pelo que entendi, então em uma empresa que possua MPS.BR e CMMI, as documentações relacionadas aos processos seriam incluídas no backlog como histórias para o Gerente de Projetos?
Att.