[ad code=4 align=left]

David J. Anderson – Microsoft Corporation

Resumo

Os adeptos de metodologias ágeis se orgulham dos processos de conhecimento altamente produtivos, responsivos, pouco cerimoniosos, leves e de conhecimento tácito com pouco gasto, planejamento adaptável e geração iterativa e freqüente de valor. Assume-se freqüentemente que os processos compatíveis com CMMI devem ser pesados, burocráticos, lentos, altamente cerimoniosos e orientados a um plano. Os desenvolvedores ágeis freqüentemente percebem com ceticismo as iniciativas de melhoria de processos formais como ineficiência gerada pelo gerenciamento, que se interpõe à produtividade.

Na Microsoft, adotamos os ensinamentos de W. Edwards Deming e estendemos nosso método MSF para Desenvolvimento Ágil de Software para se ajustar aos requisitos do CMMI Nível 3. O resultado, MSF para o Aprimoramento do Processo CMMI, é um método de planejamento adaptável e altamente iterativo, com pouca documentação e fortemente automatizado por meio de ferramentas. Ele permite o gerenciamento e a organização de engenharia de software por meio do uso de métricas ágeis tais como velocidade e fluxo cumulativo, porém com uma dimensão adicional de entendimento de variação – adaptado dos ensinamentos de Deming.

Essa é a história de como a mistura de Deming e Agile produziu uma solução CMMI leve para desenvolvedores .Net em toda parte.

Introdução

Em agosto de 2004, nós (na Microsoft) começamos a desenvolver uma metodologia para o novo produto, Team System, que seria compatível com o CMMI (Capability Maturity Model Integration) do SEI (Software Engineering Institute) [SEI 2002]. Nesse momento, não imaginamos que a solução final seria vista como um método ágil. Assumimos que o mundo do CMMI e o mundo ágil eram como óleo e água. O CMMI e seu antecessor, o Software CMM [SEI 1993], foram amplamente associados a negócios de contratação, aeroespaciais e de defesa do governo – um mundo de programas grandes e de longa duração, freqüentemente em sistemas importantes para a vida, com exigências governamentais de auditabilidade e rastreabilidade.

Muitos desenvolvedores de software geralmente estão desconfiados do processo. O processo geralmente se coloca em seu caminho e retarda o andamento do desenvolvimento de software a um nível frustrante. O CMMI está associado em suas mentes a tais iniciativas de processo. Chegamos ao início do projeto do método MSF para Aprimoramento do Processo CMMI® [Microsoft 2005a] com preconceitos similares.

Para fornecer algum histórico, a Microsoft Consulting Services vem oferecendo treinamento em gerenciamento de projetos sob a marca MSF (Microsoft Solutions Framework) desde 1992. O MSF possui uma longa história e um corpo de conhecimento construído durante mais de uma década. O MSF v3.0 incorporou o conhecimento interno da Microsoft e fontes externas. Ele incorporou muito da ciência de gerenciamento estabelecida no final do século XX e abrangeu os conceitos de contabilidade de equipe, compartilhou responsabilidade, capacitação, delegação, pensamento de sistemas e muitos outros aspectos da prática de gerenciamento geral. O MSF não se parece muito com a tradicional orientação de gerenciamento de projetos de engenharia de software. Em muitos aspectos é muito ágil. A equipe do MSF v4.0 tinha de respeitar a história do MSF ao tentar criar um método que poderia corresponder aos requisitos do CMMI.

Nossa interpretação da essência do desenvolvimento de software ágil era que este se torna possível pela confiança – acreditar que os desenvolvedores fazem a coisa certa e conquistar a confiança dos clientes por meio de entrega freqüente e atenção ao feedback. Isso fornece a pausa e a capacitação necessárias para permitir que boas coisas aconteçam. Por outro lado, a indústria aeroespacial e de defesa do governo pareceu ser um local em qual faltou confiança e dependeu da verificação de auditoria – um lugar onde nada aconteceu sem revisão e aprovação do comitê – aprovação esta sendo exigida freqüentemente em todo o ciclo de vida. Tudo deve ser delineado bidirecionalmente de modo finamente granulado para facilitar a auditoria. Além disso, a natureza auto-organizativa com autonomia do desenvolvimento de software ágil pareceu oposta a planejar o plano, planejar o trabalho, trabalhar o plano, abordagem de comando e controle, que parecia ser parte do CMMI. Parecia que o método CMMI precisava ser um método de grande planejamento antecipado e que não havia oportunidade de reutilizar nenhum trabalho feito para o método MSF para Desenvolvimento de software Agile [Microsoft 2005b] já em desenvolvimento.

Algumas tentativas anteriores de executar o ágil dentro de uma estrutura CMMI, [por exemplo, Alleman 2003], ofereceram essencialmente soluções pontuais, como a capacidade de utilizar alguns aspectos de programação extrema dentro de um ambiente de controle e comando otherwise, grande planejamento antecipado, não adaptável. Isso pareceu enfatizar a diferença filosófica entre os dois mundos. O que procurávamos alcançar era um método de ciclo de vida pleno que fosse realmente ágil, mas correspondesse aos requisitos do CMMI (no mínimo nível 3). O SEI [Paulk 2001, 2002] tem procurado oferecer tal orientação mais notavelmente neste ano [Konrad 2005]. Entretanto, essa orientação tende a ser focalizada em soluções pontuais como o XP, ou de alto nível, filosóficas e difíceis de implementar no sentido de um ciclo de vida pleno e genérico. A literatura existente resumiu que o CMMI e o ágil eram compatíveis, mas falharam em fornecer detalhes ou exemplos específicos.

Alcançamos nossa meta de um método CMMI ágil estendendo o método MSF para Desenvolvimento de software Agile para que se ajustasse. Temos cobertura de 20 das 25 áreas de processo, com exceção do Gerenciamento de Acordo do Fornecedor, Gerenciamento Integrado do Fornecedor, Foco no Processo Organizacional, Ambiente Organizacional para Integração e Treinamento Organizacional. As áreas de processo no escopo dos níveis 2 e 3 no modelo CMMI são totalmente cobertas, e as dos níveis 4 e 5 têm cerca de 50% de cobertura.

O que tornou isso possível? Qual foi a ponte entre o mundo CMMI e a filosofia do desenvolvimento de software ágil? A resposta reside nos ensinamentos de W. Edwards Deming. A Teoria do Conhecimento Profundo de Deming baseada em um entendimento da variação natural em processos e sua análise com controle estatístico de processosfoi a chave para liberar uma abordagem do CMMI ágil do ciclo de vida completo.

Deming e Ágil

A filosofia base de W. Edwards Deming sobre o gerenciamento é baseada no conceito de feedback. O ciclo de Deming de PDCA (Planejar-Fazer-Verificar-Agir). Deming utiliza esse ciclo de feedback para orientar mudanças com base em análise estatística objetiva. Além de técnicas objetivas rígidas como o controle estatístico, Deming também introduziu orientação subjetiva mais maleável com base em sistemas que pensam com seus 14 pontos de gerenciamento [Deming 1982]. Dos 14 pontos, os de mais interesse à comunidade ágil são:-

3. Cessar a dependência do controle de qualidade para alcançar qualidade, e ao invés disso se concentrar na garantia de qualidade em todo o ciclo de vida.
4. Conquistar confiança e fidelidade dos fornecedores
6. Treinamento sobre o trabalho
7. Liderança
8. Prosseguir sem medo
9. Quebrar barreiras entre
departamentos
12. Remover barreiras para se orgulhar da mão-de-obra, focalizar o gerenciamento na qualidade em vez de números da produção

O pensamento de Deming está muito alinhado ao manifesto ágil e as práticas de muitos métodos ágeis. O número 3 poderia ser comparado à prática de desenvolver o teste primeiro, por exemplo. Ágil compreende tudo o que se refere à criação de confiança entre desenvolvedores e clientes (no. 4). Práticas, como programação em pares, encorajam o treinamento durante o trabalho (no. 6). Suporte a conceitos, como passo sustentável, e à transparência de geração de relatórios dentro de equipes auto-organizativas que prosseguem sem medo (no. 8). Funções generalistas e trabalho de equipe colaborativo quebram barreiras entre departamentos (no. 9). Ciclos curtos de entrega iterativa em que todos na equipe verão o trabalho finalizado e o demonstrarão ao cliente a cada poucas semanas, removendo barreiras em se orgulhar da mão-de-obra e concentrando-se na qualidade (no. 12). A qualidade, de acordo com Deming, é definida pelo cliente e não pela especificação (ou seja, a alteração deve ser adotada se for o que o cliente quiser). Isso é muito ágil.

Deming ensinou que a qualidade é conformidade ao processo em vez de conformidade à especificação. Em vez de mensurar a conformidade à especificação utilizando departamentos de controle de qualidade, é melhor criar garantia de qualidade no processo e mensurar a conformidade ao processo. A implicação é que se você estiver fazendo coisas do modo correto, então a coisa certa será produzida e o cliente ficará feliz. Esse é o gerenciamento de 2ª ordem — gerenciamento do processo.

Teoria do Conhecimento Profundo

A Teoria do Conhecimento Profundo tenta fornecer um mecanismo objetivo para mensuração se um processo está sob controle – se uma equipe está fazendo a coisa certa ou não. A teoria é muito simples: procura entender a variação natural nas tarefas que os trabalhadores devem realizar e mensura a variação. Utilizando a matemática desenvolvida por Walter Shewhart [Shewhart 1939], os limites de controle superior e inferior são definidos. Se o processo estiver variando dentro dos limites de controle, então se diz que o processo está sob controle. Sob controle significa essencialmente que o processo está em execução conforme projetado e não é influenciado indevidamente por fatores externos fora do controle de gerenciamento imediato. Quando o processo está variando fora dos limites de controle, então se diz que está fora de controle. Em outras palavras, algum fator externo afetou o desempenho do processo e colocou a qualidade do resultado em risco.

A epifania de Deming

O CMMI é um modelo para melhoria do processo que tem por objetivo levar uma organização a um nível em que o aprimoramento contínuo em produtividade e qualidade seja possível [Chrissis 2003]. Essa filosofia básica é baseada no trabalho de W. Edwards Deming [Deming 1982]. Entretanto, o modelo de 5 níveis que foi apresentado pelo CMM de Software original para permitir que a avaliação da maturidade em empreiteiras governamentais para os contratos da Força Aérea dos Estados Unidos fosse baseada n modelo de fabricação de Philip Crosby [1979] O nome de Crosby é mais associado à definição de qualidade como conformidade à especificação [Crosby 1979]. Portanto, para mensurar a qualidade, alguém devem ter uma especificação completa no início e no final a variação derivada da especificação é mensurada e a qualidade é avaliada. Para projetos de software, o sucesso é mensurado com a utilização da métrica de qualidade, interpretada como entrega de um projeto no momento certo, no devido orçamento, com a funcionalidade acordada. A influência de Crosby no CMM de Software é tão proeminente que não é amplamente apreciado que a filosofia e meta subjacentes do CMMI é alcançar aprimoramento contínuo como descrito e ensinado por Deming.

O modelo de maturidade do CMMI é mapeado ao pensamento de Deming. Os níveis 2 a 4 se referem à criação da capacidade organizacional para eliminar a variação de causa especial e, portanto, evitar erros de gerenciamento n. 1 e n. 2 (consulte a seção após a Figura 3), enquanto o nível 5 fornece aprimoramento contínuo por meio da redução gradual da variação de causa comum. Se o CMMI estivesse realmente enraizado na filosofia de Deming, nos pareceria que deve ser possível criar um método CMMI realmente ágil.

Foi essa constatação, em novembro de 2004, que nos fez abandonar o trabalho feito até então no MSF para Aprimoramento de processo CMMI. Decidimos começar novamente e criar um modelo de processo baseado em nosso método MSF para Desenvolvimento de software Ágil.

Organização do CMMI

O CMMI é tanto um modelo de capacidade quanto um modelo de maturidade. O modelo pode ser implementado em etapas. Essa é a idéia de que uma organização alcança a maturidade nível 2 por meio de todas as práticas pertinentes e então o nível 3, e assim por diante. Também pode ser implementado de modo contínuo, em que a capacidade em práticas individuais é mensurada. Uma organização pode atingir um alto nível de capacidade em uma prática específica, mantendo ao mesmo tempo apenas um nível 2 em outras práticas. É o método em etapas de atribuir níveis de maturidade que é associado ao mercado de contratação governamental Americano e é, portanto, melhor conhecido na América do Norte.

O modelo CMMI atualmente consiste em 25 áreas de processo. Dentro de cada área de processo, um número de metas específicas são enumeradas. Cada meta, por sua vez, possui um conjunto enumerado de práticas específicas. As práticas estão em um nível prescritivo em que descrevem o que deve ser feito e quais artefatos devem ser produzidos como resultado. Por exemplo, o Planejamento de projeto (PP) 2.1 nos pede para”identificar dependências da tarefa” e espera um “Método de caminho crítico CPM ou um gráfico de Técnica de avaliação e revisão de programa (PERT)” [Chrissis 2003] como resultado.

Muitas dessas práticas, como documentadas, seriam inaceitáveis para um desenvolvedor de software ágil. Por exemplo, a subprática 2 do PP 1.1 nos pede para “Identificar os pacotes de trabalho em detalhe suficiente de modo a especificar estimativas do projeto, tarefas, responsabilidades e programação” e continua com “A quantidade de detalhe no WBS nesse nível mais detalhado ajuda no desenvolvimento de cronogramas mais realistas, minimizando, dessa forma, a necessidade de gerenciar reservas”. É muito fácil interpretar isso como requisito para grande planejamento antecipado. O PMC (Monitoramento e controle de projetos) 1.1 nos pede para comparar “a conclusão real de atividades e marcos históricos frente à programação documentada no plano do projeto, identificando desvios significativos oriundos das estimativas no plano do projeto”. Isso soa como planejamento, comando e controle pesado e é antitético ao conceito ágil de auto-organização e alocação de trabalho atrasada. A TS (Solução técnica) 2.2 nos pede para “estabelecer um pacote de dados técnicos” e sugere artefatos como “descrição de arquitetura de produto, requisitos alocados, descrições de componente de produto, características de produto, requisitos de interface, condições de uso” e assim por diante. Novamente, é fácil interpretar isso como um requisito para a documentação pesada. Também prescreve o design antes da codificação, que é detestável para a filosofia de desenvolvimento orientada ao teste extremo, em que o design é emergente via refatoramento.

Além disso, o CMMI tem uma reputação de documentação pesada. Algumas literaturas [Ahern 2005] informam que tantos quantos 400 tipos de documentos e 1000 artefatos são necessários para facilitar uma avaliação.

Alcançando agilidade com CMMI

Uma chave para alcançar mais agilidade com o CMMI é perceber que as práticas são primariamente consultivas ou indicativas somente. Para corresponder a uma avaliação do CMMI, uma organização deve demonstrar que as metas de uma área de processo estão sendo atingidas. Isso é feito identificando-se a evidência de práticas. Entretanto, as práticas não precisam ser as descritas na especificação CMMI. A organização é livre para propor práticas alternativas e evidência apropriada.

O avaliador deve então estar de acordo que isto seja apropriado para demonstrar a meta. Isso fornece um designer de processo com uma grande quantidade de liberdade.

Conforme se concentra, o MSF para Aprimoramento do processo CMMI não requer quaisquer práticas alternativas com a exceção da prática e evidência para a prática específica REQM 1.4, que solicita uma completa rastreabilidade de ponta-a-ponta de artefatos. Isso poderia ser considerado oneroso para muitos projetos ágeis. A razão pela qual as práticas alternativas não eram requeridas tem mais a ver com a interpretação da intenção. Quando uma prática solicita que um plano seja feito e outra um comprometimento com programação, orçamento e especificação, há freqüentemente a suposição de que esses comprometimentos devem ser precisos – que há uma filosofia subjacente de conformidade ao plano e à especificação. Quando outra prática solicita uma revisão do planejado versus real e a criação de um relatório detalhando o desvio da especificação, há a suposição de que é para auditar a qualidade como conformidade à especificação – qualquer desvio sendo uma falha na qualidade. Embora seja um entendimento comum em muitas organizações que praticam o CMMI, é preciso que seja verdadeiro. É aceitável documentar a abordagem como conformidade ao processo e os mecanismos de mensuração para serem conscientes da variação e definidos dentro de limites de variação de causa comum. Essa é a chave que destranca a possibilidade de uma implementação CMMI realmente ágil em todo o ciclo de vida.

Então, os planos e as especificações não precisam definir números e datas precisos, mas devem definir uma variação de números e datas aceitáveis. Enquanto esse é o entendimento organizacional comunicado e aceitável ao cliente, então é aceitável dentro do esquema de especificação e avaliação do CMMI. Por exemplo, um plano, baseado em dados de velocidade histórica de 1,7 cenário por desenvolvedor por semana com uma variação de poucos recursos de 0,8 e de alta capacidade de 2,5, deve oferecer conservadoramente o desenvolvimento de 80 cenários em 10 semanas, com 10 desenvolvedores, e definir uma meta expandida de 250 cenários. Um plano levemente mais agressivo poderia utilizar 8 semanas com um buffer de 2 semanas para variação e oferta de um mínimo de 8 x 17 = 136, com a mesma meta expandida de 250.

Gerenciamento de velocidade e fila

No nível mais alto de maturidade, o CMMI necessita de aprimoramento contínuo executado sob condições de controle objetivo. É recomendado que isso seja alcançado com uso de controle estatístico do modo promovido por Deming em sua Teoria de Conhecimento Profundo. Era desejável para nós entregar um método que correspondesse ao CMMI nível 3, mas preparasse o terreno para uma futura versão que poderia conduzir totalmente nossos clientes ao nível 5. O SEI acredita firmemente que os benefícios econômicos do CMMI são gerados em níveis de maturidade mais altos. Na Microsoft, acreditamos que nossos clientes desejarão essencialmente fazer a transição para o nível 5 e quisemos facilitar isso com um caminho incremental tranqüilo, utilizando nosso modelo existente de processo. Era, portanto, necessário considerar o nível 5 em nosso planejamento e, ao mesmo tempo, manter o foco na geração de uma solução de nível 3.

Se devemos seguir uma abordagem de Deming para atingir o nível 5 do CMMI, deve haver um mecanismo que permita a monitoria do controle estatístico. A compatibilidade com métodos ágeis pode ser alcançada pela mensuração da velocidade de produção dos itens valorizados pelo cliente e pela utilização dessa métrica no planejamento. No MSF, os itens de valor são definidos como cenários de utilização [Carroll 2000]. Os cenários não devem ser confundidos com casos de uso ou caminhos via casos de uso. Lá a herança é bem diferente e nascida do campo de engenharia da usabilidade. Os cenários são descrições concretas de utilização que não tentam adivinhar a implementação de sistemas subjacentes. No MSF, os cenários, como os requisitos do cliente, são analisados e decompostos em tarefas de arquitetura, desenvolvimento, teste e experiência do usuário. A Figura 1 mostra a velocidade de conclusão da tarefa (ou o índice de produção do processo). Isso é muito diferente da abordagem mais tradicional de gerenciamento de projetos de estimar o tempo de cada tarefa e então acompanhar o desempenho planejado versus real. O último simplesmente mensura a variação na estimativa da habilidade ou falta de conformidade com o compromisso local individual, enquanto o primeiro mensura a variação em todo o sistema da produção de valor ao cliente.

Figura 1. Velocidade de conclusão (ou índice de produção) em um gráfico de controle XMR

A mensuração da velocidade não é suficiente por si só para identificar variação de causa especial no processo. Shewart chamou as causas especiais de “causas atribuíveis”. Em outras palavras, deve haver um evento atribuível específico que possa ser identificado como a causa raiz. Um registro de problemas do projeto é uma boa fonte para a identificação da variação de causa especial. O registro de problemas está armazenando o histórico de solicitações da engenharia por ajuda. Por implicação, as solicitações de ajuda indicam variação potencial ou real de causa especial. Poderia ser o caso em que uma causa especial não seria identificada inicialmente e ficaria invisível. O gerenciamento pode optar por investigar ou simplesmente minimizá-la como inexplicada. Organizações claramente mais maduras são melhores nesta investigação da causa raiz e mostram que os processos estão sob maior controle.

Podemos acompanhar bloqueios no WIP (Trabalho em andamento) monitorando o enfileiramento do trabalho para processamento. David Anderson [2003] mostrou como fazer isso utilizando fluxogramas cumulativos [Figura 2] com base no trabalho de Reinertsen [1997]. O monitoramento do nível WIP com uso de controle estatístico [Figura 3] permite várias coisas. Os níveis WIP predizem o tempo de produção e, portanto, a futura influência no cronograma do projeto. Os níveis de WIP podem também indicar o bloqueio de itens de trabalho e onde no ciclo de vida o bloqueio está ocorrendo.

Deming sugeriu que havia apenas 2 tipos de erro que um gerente poderia cometer. Ele os chamou de Erro nº. 1 e Erro nº. 2. O Erro nº. 1 está interferindo quando tudo está normal — quando o processo mostra controle estatístico. Ele chamou isso de adulteração. Quando um processo está sob controle, deveria ser deixado em paz. Os microgerentes têm uma tendência a adulterar, pois reagem a flutuações sem considerar o quadro maior. Portanto, o microgerenciamento geralmente conduz ao erro nº. 1. Quando um processo está sob controle, deve-se permitir que os trabalhadores se auto-organizem sem a intervenção do gerenciamento. Esse conceito soa muito ágil. O Erro nº. 2 é uma falha ao intervir quando um processo está fora de controle. Um processo fica fora de controle quando algo externo o afeta. Em linguagem comum, chamamos isso de problemas. Quando um problema está bloqueando o fluxo de valor em um processo de desenvolvimento de software ágil, todos entendem que alguém (normalmente um gerente de projeto) deve ser designado para eliminá-lo. Métodos como o Scrum [Schwaber 2001] tornam isso muito explícito. Evitar o erro nº. 2 tem a ver com o gerenciamento agressivo de problemas e bom gerenciamento de riscos. Um risco, afinal de contas, é simplesmente um problema que ainda não aconteceu!

O registro de problemas deve refletir as tendências no WIP. O registro de problemas deve conter detalhes das causas atribuíveis para variações de causa especial.

O registro de problemas e WIP bloqueado podem ser utilizados para avaliar a capacidade da organização em eliminar a variação de causa especial. A Figura 4 mostra o fluxo cumulativo de problemas no registro de problemas. Os gerentes de projeto trabalharão para resolver problemas e encerrá-los. Ocasionalmente, os problemas não serão encerrados rápido o suficiente, resultando em trabalho em andamento bloqueado no registro posterior do projeto (ou interação) principal. Isso é mostrado no gráfico de linhas sobrepostas. Uma falta de bloqueio de trabalho indicaria uma falta de variação de causa especial, enquanto o inventário WIP e os gráficos de Velocidade de conclusão mostram a extensão da variação de causa comum.

Um entendimento da variação de causa comum pode ser utilizado para o planejamento e avaliação do projeto. Um entendimento do risco associado à variação de causa especial pode ser utilizado para calçar o plano de projeto com buffers (efetivamente, garantia) contra deslizes da programação ou geração de funcionalidade reduzida, devido ao deslize de velocidade.

Planejamento iterativo e adaptável

Ao definir um conjunto de métricas ágeis, mas construindo-as dentro de uma estrutura de controle estatístico, preparamos o terreno para um método ágil comparável ao CMMI nível 5. O que é necessário agora é um mecanismo de planejamento iterativo e adaptável que possa ser reconhecido como ágil.

A solução é fornecer um plano de projeto flexível, que se aproxime do escopo de um projeto completo e defina um plano para uma série de interações que definem aproximadamente o que será desenvolvido em cada uma. O segredo é evitar o grande planejamento antecipado. Alcançamos isso definindo uma pequena série de cenários de ponta-a-ponta CTQ (Críticos para qualidade) e esboçando cada um. Como definido anteriormente, a qualidade é definida pelo cliente. É importante obter o quanto antes, mesmo que aproximado, um entendimento mútuo disso. O cliente deve concordar que esses cenários CTQ representam a ampla intenção do produto ou serviço idealizado como o resultado de um projeto. Os CTQs são então atribuídos em relação a interações no plano de projeto. Então, o plano de projeto é muito flexível e aproximado, embora detalhado o suficiente para comunicar ao cliente a essência do que obterão em cada estágio do projeto. É importante que o cliente comunique o que representa uma cadência adequada de interações a partir de sua perspectiva. É provável que o ciclo comercial natural dite como o cliente deve absorver nova funcionalidade e perceber o seu valor. Então, o cliente determinará o comprimento da interação. Um compromisso para um plano de projeto é, portanto, possível a partir de todas as partes interessadas. Esse compromisso é parte crítica dos requisitos do CMMI.

O planejamento detalhado é então deixado para o início de uma interação, em que um conjunto de cenários detalhados e específicos ganha corpo ao redor dos cenários CTQ previamente identificados. Os testes de aceitação são escritos para cada cenário e, juntos, requisitos e testes formam o escopo do plano de interação. Os cenários são classificados utilizando as regras MoSCoW [DSDM 2005]. A métrica para a velocidade e a variação é utilizada para determinar um nível mínimo de produção para a interação, com base na extremidade inferior do intervalo de capacidade, e uma meta de expansão baseada na extremidade superior é determinada. Requisitos do tipo “deve ter” são atribuídos em relação ao nível mínimo e requisitos “deveria ter” ou “poderia ter” em relação à meta de expansão. O plano então é acordado por todas as partes interessadas e os comprometimentos são feitos.

Durante a interação, solicita-se que os engenheiros continuem a se concentrar na conformidade ao processo, utilizando os relatórios de fluxo de velocidade e cumulativos junto com o registro de problemas e relatório de WIP bloqueado. A variação na velocidade será um item que requer atenção. Uma estimativa precisa do escopo que será realmente produzido pode ser feita diariamente. Deveria continuar a permanecer dentro dos limites do nível mínimo e da meta de expansão ou deveria haver uma causa atribuível para explicar por que não. A atenção do gerenciamento pode então ser focalizada em tais problemas e as ações de recuperação iniciadas. Ao fazer isso, os requisitos para a análise de causa raiz e ação corretiva no CMMI são abordados.

Novamente, mesmo no nível de interação, o planejamento permanece flexível. O plano para uma interação contém apenas um registro posterior classificado em requisitos do tipo “deve ter”, que compõem o nível de comprometimento mínimo, e outros que representam um buffer para a variação natural no método de desenvolvimento de software sendo utilizado. A equipe tem autonomia para se auto-organizar dentro de uma interação. O plano é calculado com uso de médias obtidas de dados históricos. Quando não houver histórico disponível o plano deve ser baseado em uma melhor suposição e monitorado freqüentemente com uso dos relatórios mostrados nas figuras 1 a 4. O plano pode ser ajustado de acordo. Isso afeta apenas a primeira interação de um novo projeto com uma nova equipe.

Expandindo o MSF para Desenvolvimento de software Ágil

O MSF para Desenvolvimento de software Ágil correspondeu à intenção básica do CMMI, mas houve falta de alguma formalidade e orientação específica para algumas áreas do processo. Em muitos métodos de desenvolvimento ágil, muito da infra-estrutura para desenvolvimento de confiabilidade de software está implícito ou deixado para resolução por meio de um método de gerenciamento de problemas de propósito geral. Por exemplo, se a falta de um ambiente de gerenciamento de configuração é um problema de bloqueio, então a resolução seria colocar um em vigor. O CMMI, baseado em décadas de experiência de engenharia de software, já inclui muitos desses aspectos. A criação de ambientes adequados, o comissionamento de ferramentas apropriadas, a iniciação de projetos com visão suficiente, a comunicação dessa visão com eventos de lançamento e planejamento para a percepção de valor por meio de desenvolvimento são todos parte da prescrição do CMMI.

Não há nada particularmente em conflito com a filosofia ágil nessas coisas. A principal diferença é que são explicados explicitamente.

Era, portanto, necessário aprimorar o MSF para o Desenvolvimento de software Ágil com atividades adicionais para cobrir esses aspectos do CMMI.

Isso não era trivial. A área do material de orientação para o MSF para o Aprimoramento de processo CMMI é 150% maior que a do MSF para Desenvolvimento de software Ágil. Assim, grande quantidade de expansão foi necessária. Por exemplo, o MSF para Desenvolvimento de software Ágil tinha 25 objetos de produto de trabalho enquanto o método CMMI tinha 59. Havia 9 gráficos de métricas com o método ágil, enquanto o método CMMI tinha 12. Entretanto, uma típica implementação do processo CMMI tinha mais de 400 objetos [Ahern 2005]. Uma combinação de ferramentas integradas e uma abordagem ágil geral para o projeto do processo reduziu a sobrecarga – o peso – no processo em cerca de 85%.

O resultado é um modelo de processo maior do que um típico processo ágil com levemente mais formalidade com respeito a aprovações, assinaturas e auditorias, mas que tem um núcleo ágil e adaptável, e é leve em comparação a uma tradicional abordagem CMMI. Acreditamos que o MSF para Aprimoramento do processo CMMI representa uma metodologia ágil altamente produtiva, que inclui um mecanismo formal de qualidade e encoraja uma cultura de aprimoramento contínuo.

Conclusões

As implementações do processo CMMI estão freqüentemente associadas à conformidade ao plano, a ambientes de baixa confiança e a estruturas de comando e controle. Elas requerem uma grande abordagem de projeto antecipado com auditoria de conformidade e implicações de punição por não conformidade. Isso gera medo, e o medo encoraja maior foco em planejamento conjunto mais detalhado, com disposição cega para seguir tal plano. Como resultado, as necessidades do cliente tornam-se desconectadas do trabalho e a alteração orientada pelo cliente torna-se inaceitável, pois a alteração deve estar refletida no plano para que o resultado esteja em conformidade com o plano. O efeito é uma grande quantidade de retrabalho adicional sem valor.

Este documento mostra que é errado associar esses comportamentos de engenharia de software indesejáveis ao CMMI. Não tem de ser dessa maneira.

Ao adotar os ensinamentos de W. Edwards Deming e entendendo sua relação com princípios e práticas ágeis, é possível desenvolver um processo de ciclo de vida completo realmente ágil, que corresponda aos requisitos para todos os 5 níveis no modelo CMMI. Especificamente por utilizar métricas ágeis, como velocidade, fluxo cumulativo e tendências em questões abertas, concebemos os métodos de planejamento e monitoramento que adotam a variação e permitem comprometimento postergado e tardio e planejamento iterativo adaptável.

Fazendo assim, o processo adota as idéias do manifesto ágil [Cunningham 2001], como valorizar a colaboração do cliente acima da negociação do contrato e responder à mudança acima de seguir um plano. Ao adotar a variação e aceitá-la como parte de um processo centralizado no humano, abrangem-se indivíduos e interações acima de processos e ferramentas. E, finalmente, pelo uso de ciclos iterativos, acordados em uma cadência aceitável para o cliente, gera-se software em funcionamento acima de documentação abrangente.

Fonte: MSDN

[ad code=4 align=left]