O CMMi, sigla para Capability Maturity Model Integration é definido como um modelo de referência que contém práticas necessárias a 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 à 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. Quando mais avançada 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 seguindo 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 freqüentes, 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 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 a realidade coorporativa, que está em constante evolução.
As reuniões diárias serem 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 como que ela consegue entregar software completo e funcional (itens do backlog). Com isso em mãos, é possível tomar medidas corretivas e buscando 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 prevista, 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, 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 liveis dois e três do CMMi e as praticas 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 analise, compatível com a maioria dos processos do CMMi, ao menos até o nivel 3. Acima desse nível (4 e 5) serão necessárias diversas adaptações, incluindo novos processos e controles, tanto de engenharia de software, como de gestão. Valerá uma analise de custo-benefício com relação a 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.
