O CMMi, sigla para Capability Maturity Model Integration, é definido como um modelo de referência que contém práticas necessárias à maturidade em áreas/disciplinas específicas, como engenharia de sistemas, engenharia de software, desenvolvimento de processo, entre outros (fonte: wikipedia, br).
Trocando em miúdos, define um conjunto de boas práticas de gerenciamento para o processo de desenvolvimento de software.
Parte-se da premissa de que a qualidade do produto final (os sistemas entregues) está diretamente ligada à maturidade do processo responsável por sua construção. Embora tenha perdido parte de sua popularidade, o CMMi continua importante, em especial para fábricas de software, pois diversas organizações somente adquirem software ou serviços relacionados de empresas com certificação nível 3 – entre elas o governo americano, possivelmente um dos maiores compradores de software do mundo.
Scrum, por sua vez, é uma metodologia de gerenciamento ágil de projetos, que vem ganhando ampla adesão da comunidade e empresas ligadas ao processo de criação de software. Entre outras razões, destacam-se os resultados obtidos, além da simplicidade do processo.
É considerado um dos métodos “light”, pois possui poucas práticas e controle, quando comparado a métodos mais “tradicionais”. A pergunta que fica é: é possível para uma organização adotar as práticas do Scrum e ainda assim obter o grau de CMMi? O método é suficiente para obter a certificação?
O CMMi é dividido em níveis de maturidade. Quanto mais avançado em seus níveis, mais estável é o processo de desenvolvimento da organização e maior o seu grau de maturidade. De forma resumida:
- Nível 1: processo ad-hoc. Não definido, não existe um processo claro de desenvolvimento. Nesse nível, os resultados não podem ser previstos.
- Nível 2: processo repetido. Nesse nível, um processo inicial é definido e seguido sempre.
- Nível 3: processo definido. Aqui o processo é claramente definido; suas entradas, etapas e saídas estão claras, e ele é seguindo sempre.
- Nível 4: gerenciado. O processo é medido e são tomadas ações corretivas (gerenciamento).
- Nível 5: melhoria continua. O processo inclui, em si mesmo, revisões frequentes, com o objetivo de otimizá-lo continuamente.
.
No início o CMMi foi relacionado ao modelo tradicional de desenvolvimento de software, ou “waterfall”. Essa comparação, embora natural, não é uma restrição do modelo. Se compararmos os níveis de maturidade do CCMi com as práticas previstas no Scrum, começando pelo nível 2, veremos que ele atende muitos dos requisitos previstos:
Nível 2 – processo repetido
Ao adotar Scrum como metodologia, a organização passa automaticamente a contar com um processo sobre o qual operar.
As reuniões de planejamento de releases servem para construir uma visão para o projeto, bem como definir os objetos e o produto final, ainda que em alto nível, sem o grau de detalhamento previsto em outras metodologias.
As reuniões de planejamento de Sprint definem ou reavaliam prioridades, decisões e soluções adotadas, adaptando o projeto à realidade corporativa, que está em constante evolução.
As reuniões diárias servem como ponto de comunicação constante entre os membros da equipe, realinhando e adaptando o projeto em uma base diária.
Nível 3 – processo definido
Da mesma forma, Scrum passa a ser o processo definido para a organização. Entretanto, será necessário (re)definir as práticas de engenharia de software que serão aplicadas – Scrum é um método para gerenciamento de projetos e não prevê organicamente nenhuma dessas práticas. Para atingir esse estágio, será necessário complementar o processo, com a ajuda da(s) equipe(s), já que a metodologia é empírica.
Nível 4 – processo gerenciado (quantitativo)
Existem poucos controle “formais” previstos no Scrum, destacando-se o burndown chart, que permite avaliar a taxa de “consumo” do backlog, tando dos sprints como dos releases. Além disso, é possível medir a velocidade da equipe, a taxa com que ela consegue entregar software completo e funcional (itens do backlog).
Com isso em mãos, é possível tomar medidas corretivas e buscar aumentar a velocidade – ferramentas, automação de processos repetitivos etc., que são a chave para o próximo nível.
Fica a critério da organização definir controles e métricas adicionais que julgar necessários. Vale lembrar, contudo, que a maioria dos controles do Scrum ocorre nas diversas reuniões previstas, de maneira mais informal. Esses checkpoints se configuram como as melhores fontes de informação para identificar se o projeto está nos trilhos.
Nível 5 – melhoria continua
Sprint Review e Sprint Retrospective são previstos como momentos para apresentar o trabalho desenvolvido e para que a própria equipe encontre métodos para melhorar o trabalho, baseado na experiência passada, respectivamente. As lições aprendidas devem ser registradas, devem passar a fazer parte da base de conhecimentos da empresa e transmitidas aos demais times. Com essas informações, a gerência e o próprio time podem tomar medidas que ampliem a capacidade de resposta do time, melhorem a qualidade e eliminem processos desnecessários.
Em seu livro Agile Projet Management with Scrum, Ken Schwaber faz um breve comparativo entre algumas das KPAs (key practice areas) dos niveis dois e três do CMMi e as práticas do Scrum, que reproduzo aqui. Uma marca simples significa aderência parcial, uma dupla significa aderência completa:
Level – Key Process Area – Rating
2 – Requirements management – **
2 – Software Project planning – **
2 – Software Project tracking and oversight – **
2 – Software subcontract management – **
2 – Software quality assurance – **
2 – Software configuration management – *
3 – Organization process focus – *
3 – Organization process definition – *
3 – Training program – *
3 – Integrated Software management – *
3 – Software product engineering – **
3 – Intergroup coordination – **
3 – Peer review – **
O que não está previsto no método – práticas de engenharia de software – são as principais adaptações que deverão ser incluídas pela organização. Essas práticas deverão provir das melhores práticas de arquitetura, complementadas com a experiência da equipe, obtida de forma empírica. Quando definidas, devem ser comunicadas, reforçadas e medidas pela gerência.
Uma combinação das práticas do Scrum (para projetos) e de XP (Extreme Programming), para complementar a engenharia de software, pode ajudar. Para níveis de maturidade superiores ao três, contudo, diversos novos processos de controle deverão ser adotados, tanto técnicos quanto gerenciais.
Conclusões
O que vimos é que Scrum pode fornecer o arcabouço sobre o qual construir (e evoluir) o gerenciamento de projetos de software, com algumas adaptações, sendo em uma primeira análise, compatível com a maioria dos processos do CMMi, ao menos até o nível 3.
Acima desse nível (4 e 5) serão necessárias diversas adaptações, incluindo novos processos e controles – de engenharia de software como de gestão. Valerá uma análise de custo-benefício com relação à adoção dessas práticas complementares. O desafio, como sempre, é manter a flexibilidade e agilidade, com a organização necessária para garantir a qualidade do produto final.
Mais sobre Scrum na Wikipedia.
Mais sobre CMMi na Wikipedia (em inglês).
