Este trabalho tem como objetivo único facilitar a divulgação de um modelo de melhoria de processos que vem sendo muito utilizado e tem trazido resultados positivos àqueles que o estão usando.

Foi observado que um dos principais problemas de divulgação do CMMI das práticas do modelo reside no fato do mesmo estar escrito em inglês. Diante disto, decidiu-se traduzi-lo e torná-lo público, esperando com isto facilitar o acesso de mais pessoas ao assunto.

Faça o download do CMMI Versão 1.2 em português

Posts Relacionados

• Como a Microsoft expandiu o Agile para se adequar ao CMMI Nível 3
• Estágios do CMMI
• Qualidade de software com CMMI
• Conhecendo o Scrum: metodologia ágil de desenvolvimento de software
• Modelo e definição de Project Charter
• Project Charter

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

Posts Relacionados

• Introdução ao Microsoft Solution Framework – MSF e ao Agile
• Tradução do CMMI versão 1.2 para desenvolvimento de projetos
• Microsoft e Toyota fazem parceria de rede digital para carros
• iPad está “matando” o mercado de netbooks, diz Microsoft
• [Review] Windows Phone 7
• Microsoft espera enterrar iPhone e Android com Windows Phone 7
• Hyper-V Server 2008, solução Microsoft para virtualização de servidores
• Microsoft entra na guerra dos smartphones
• Estágios do CMMI
• Qualidade de software com CMMI
• DreamSpark: Microsoft fornece ferramentas gratuitas para estudantes
• Microsoft Web Expression, o novo Front Page
• Lançada versão final do ASP.NET MVC2
• Conhecendo o Scrum: metodologia ágil de desenvolvimento de software
• Abertas as inscrições gratuitas para o Students to Business 2010

Estudando o Microsoft Visual Studio Team System 2008 vi que podemos implementar várias metodologias de Gerência de Projetos configuráveis diretamente no software. Uma das que vi a possibilidade é o Scrum e por isso resolvi postar sobre essa metodologia ágil.

O Scrum é uma metodologia ágil para Gerenciamento de Projetos.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo “The New Product Development Game” (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna conceberam, documentaram e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

Mesmo que idealizado para ser utilizado em gestão de projetos de desenvolvimento de software ele também pode ser usado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.

Características de Scrum

• Cada sprint é uma iteração que segue o (ciclo PDCA) e entrega incremento de software pronto.
• Um backlog é conjunto de requisitos, priorizado pelo Product Owner (Responsável pelo ROI e por conhecer as necessidades do cliente);
• Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints;
• Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipa geralmente ficam em pé para não prolongar a reunião).
• Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
• Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de “controle”. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de “receita de bolo” do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto.

Planejamento de sprint

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum simplificado

Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível (“stealth”), usando os três passos:

• Agende uma demonstração do software com seu cliente em um mês a partir de agora;
• Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
• Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.

Algumas características de Scrum

• Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
• Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
• Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
• Discussões diárias de status com a equipe;
• A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
  • O que fiz desde ontem?
  • O que estou planejando fazer até amanhã?
  • Existe algo me impedindo de atingir minha meta?
• Transparência no planejamento e desenvolvimento;
• Reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
• Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
• Locais e horas de trabalho devem ser energizadas, no sentido de que “trabalhar horas extras” não necessariamente significa “produzir mais”.

Agendando discussões diárias

Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes estão focadas no trabalho e não em questões pessoais.

Scrum Solo

Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

Fonte: Wikipedia

Posts Relacionados

• Maré de Agilidade – Evento sobre desenvolvimento ágil em Vitória
• Novidades TI Especialistas – 17/04/2011
• Novidades TI Especialistas – 10/04/2011
• Novidades TI Especialistas – 03/04/2011
• Novidades TI Especialistas – 27/02/2011
• Novidades TI Especialistas – 20/02/2011
• Novidades TI Especialistas – 13/02/2011
• Novidades TI Especialistas 06/02/2010
• Novidades TI Especialistas – 23/01/2011
• Novidades TI Especialistas 16/01/2011
• Novidades TI Especialistas 09/01/2010
• Novidades TI Especialistas 12/12/2010
• Novidades TI Especialistas – 28/11/2010
• Novidades TI Especialistas 14/11/2010
• Novidades TI Especialistas 07/11/2010

Para se começar um projeto utilizando as premissas do PMBOK temos que antes de tudo oficializar o projeto. Para tanto utilizamos um documento denominado Termo de Abertura de Projeto ou Project Charter. Na confecção deste documento oficializamos que existem um projeto em curso. Esse documento em geral é elaborado pela alta gerência da empresa ou pelo sponsor (patrocinador) do projeto. O projeto deve ter um nome chamativo e que suscite nos membros da equipe um sentimento cumplicidade no projeto.

O Project Charter ainda deve contemplar as responsabilidades do projeto e do gerente do projeto. Os dados que devem ser contidos no documento são:
- Nome do projeto;
- Introdução ou resumo das condições que definem o projeto;
- Nome do gerente de projetos, suas autoridades e responsabilidades;
- Necessidades do projeto;
- Descrição do produto do projeto;
- Cronograma;
- Estimativas de custo;
- Recursos inicialmente requiridos;
- Necessidade de suporta da organização;
- Gerenciamento das informações;
- Aprovação pelo responsável do pelo projeto.

Abaixo segue um exemplo de um Project Charter desenvolvido pela www.gmsl.it.

Posts Relacionados

• Project Charter
• Novidades – Ganhe um iPad fazendo o curso ITIL + COBIT + PMP
• Tradução do CMMI versão 1.2 para desenvolvimento de projetos
• Como a Microsoft expandiu o Agile para se adequar ao CMMI Nível 3
• O que é a Certificação PMP do PMI
• Conhecendo o Scrum: metodologia ágil de desenvolvimento de software
• Qual impacto dos novos padrões PMI nas Certificações PMP?
• Fases de um projeto segundo o PMBOK
• Conceito de Gerência de Projetos
• Entenda o que é PMI, PMBOK e PMP na Gerência de Projetos

Meu primeiro post!!! Não sei como começar. Acho que tudo que nos propomos a fazer começam com esse sentimento.

Ainda não tenho bem definido o escopo deste blog, mas acredito que será sobre assuntos que eu considere relevantes e não sobre algo específico. É… eu sei… não adiantou muito minha descrição. Então vamos ser um pouco mais diretos. Os temas que eu abordarei aqui serão relativos à área de desenvolvimento profissional e pessoal, tecnologia, política, economia e esportes. Posso, vez ou outra, seguir caminhos diferentes do proposto mas sei que serão assuntos significativos.

O título do meu primeiro post é motivado pelo início dos estudos sobre Gerência de Projetos utilizando o PMBOK. Como trato esse blog como um projeto pessoal, decidi entitular este post como “Project Charter” que seria o Termo de Abertura do Projeto. Daqui a algum tempo estarei postando como um PMP, “Trabalhe e Confie”, parafraseando a bandeira do estado do Espírito Santo.

BlogBlogs.Com.Br

Posts Relacionados

• Modelo e definição de Project Charter
• Novidades – Ganhe um iPad fazendo o curso ITIL + COBIT + PMP
• Tradução do CMMI versão 1.2 para desenvolvimento de projetos
• Como a Microsoft expandiu o Agile para se adequar ao CMMI Nível 3
• O que é a Certificação PMP do PMI
• Conhecendo o Scrum: metodologia ágil de desenvolvimento de software
• Qual impacto dos novos padrões PMI nas Certificações PMP?
• Fases de um projeto segundo o PMBOK
• Conceito de Gerência de Projetos
• Entenda o que é PMI, PMBOK e PMP na Gerência de Projetos