MSF e CMMI não são inimigos

Quando o assunto é processo formal e controle, existe uma pré-disposição cultural em pensar que a Microsoft não se adequa a qualquer proposta dita “burocrática”. Com este pensamento a ser explanado, colocamos de um lado o CMMI, com suas áreas de processo chave que formalizam procedimentos para uma empresa de desenvolvimento de projetos de software e do outro lado o MSF, famosa metodologia da Microsoft que tem como conceitos chaves o foco no resultado, o foco no produto e o foco na satisfação do cliente.

por Fabio Camara

Quando o assunto é processo formal e controle, existe uma pré-disposição cultural em pensar que a Microsoft não se adequa a qualquer proposta dita "burocrática". Com este pensamento a ser explanado, colocamos de um lado o CMMI, com suas áreas de processo chave que formalizam procedimentos para uma empresa de desenvolvimento de projetos de software e do outro lado o MSF, famosa metodologia da Microsoft que tem como conceitos chaves o foco no resultado, o foco no produto e o foco na satisfação do cliente.

Primeiramente, não conseguimos determinar "como" e "onde" começou a visão que as propostas são antagônicas, nem sequer descobrir o motivo deste pensamento. Em nossos estudos não foi evidenciada nenhuma informação técnica respeitável que sugerisse, mesmo que sutilmente, esta orientação.

Abrangendo um pouco mais profundamente a questão, o MSF - Microsoft Solutions Framework, que foi criado em 1993 através da fusão de práticas da Microsoft Consulting Services e boas práticas padronizadas do mercado, é um conjunto de diretrizes e orientações para o desenvolvimento de software.

Evoluindo continuamente a partir destas práticas testadas e comprovadas dentro do dia-a-dia da própria Microsoft, tem como característica muito positiva o fato de que é facilmente extensível e customizável. Sendo assim cremos que da mesma forma que o CMMI está repleto de interpretações incorretas sobre sua finalidade e aplicação, também as diretrizes sugeridas pelo MSF costumam ser mal-interpretadas.

Recentemente ministramos um treinamento especialista para uma grande corporação, no qual o foco inicialmente era UML mas compreendendo melhor a necessidade do contratante sugerimos uma proposta de ciclo de vida de desenvolvimento baseado em MSF. A primeira resposta do contratante foi negativa com a seguinte dúvida: "MSF não é aplicável somente para projetos de menor porte?" Depois de demonstrada a incoerência da pergunta, ministramos a capacitação que foi muito funcional aos desafios do contratante.

Sabemos, obviamente, que soluções do tipo "one size fits all" não funcionam. Diversos relatos históricos comprovam esta afirmativa e nos responsabilizamos pela credibilidade desta orientação aos leitores.

Face ao exposto decidimos aplicar em nossa empresa, um modelo prático funcional que atendesse tanto às nossas expectativas de resultados quanto às exigências do CMMI - estamos no nível 3. Para tanto, MSF adicionado a automação da ferramenta Visual Studio Team System e nossa percepção de qualidade e resultados foi a receita deste caso de sucesso.

Bom, mas afinal o que o MSF e o CMMI têm em comum? À primeira vista, para a maioria das pessoas, a resposta é "absolutamente nada". O foco da Microsoft ao criar o MSF é desenvolvimento ágil (agile development), ou seja, produzir com a maior produtividade possível sem perder o controle das diferentes equipes envolvidas no processo. Pórem, não é justamente isso que procuramos também no CMMI? Aumentar a qualidade, eficiência e produtividade de nossa equipe, por meio de processos bem descritos, claros e organizados?

Com essa conclusão afirmativa em mente, de que o MSF e o CMMI têm objetivos comuns, a Microsoft oferece dois modelos de processos (process templates) junto com seu Visual Studio Team System:

• MSF for Agile Software Development: Para equipes com uma estrutura formal mais flexível, com menos artefatos e processos menos rígidos. Ideal para times de desenvolvedores que não têm um processo de desenvolvimento totalmente estabelecido.

• MSF for CMMI Process Improvement: Por fornecer templates e artefatos mais completos, de maneira a gerar boa parte das saídas previstas pelas PAs do CMMI, é indicado para processos de desenvolvimento mais formais e para empresas de grande porte.

A história do MSF for CMMI Process Improvement

Por que foram criados dois modelos de processo? Porque ao desenvolver o MSF 4.0, o plano da Microsoft era atender a dois tipos diferentes de mercados: o de empresas "ágeis", que têm times menores e um nível de confiança mútua que permite um menor controle dos colaboradores; e as empresas com CMMI Nível 3, de processo mais formal. Originalmente, assumiu-se que as duas vertentes eram diametralmente opostas: ágil não é formal, e formal não é ágil.

O conceito de processo "formal" foi associado inicialmente a empresas que têm contratos com o governo ou o Departamento de Defesa americanos, que são extremamente exigentes quanto à formalidade do processo de desenvolvimento de software. A seguir, associou-se o conceito às empresas que adotaram o CMMI. Com isso, "CMMI" e "formal" viraram sinônimos.

Partindo do princípio que todos os que desejam utilizar um processo formal querem um modelo similar ao usado pelo Departamento de Defesa americano, notoriamente rígido, a equipe do MSF concluiu o processo formal ocorre num ambiente de "baixa confiança", pois há uma enorme quantidade de documentação, controle, monitoramento, supervisão e verificação do trabalho produzido, de maneira que se possa rastrear o "culpado" por algum problema no projeto. Assim, seria necessário criar uma série de pontos de controle no processo do MSF for CMMI (que era então conhecido pelo codinome "MSF Formal") de maneira a atender a toda essa "formalidade".

Felizmente, para nossa sorte, a Microsoft compreendeu melhor o CMMI e se deu conta de que formalidade não implica necessariamente em falta de confiança. Assim ao invés de criar um processo inchado e extremamente burocrático, que não traria benefícios a ninguém, conseguiram criar um modelo que permite as empresas que optaram pelo CMMI continuarem sendo ágeis e ainda assim atender às exigências definidas pelo SEI (Software Engineering Institute). É essa agilidade e aderência ao CMMI que deram à nossa companhia a tranqüilidade necessária para evoluir nos estudos de adoção do MSF como modelo padrão de desenvolvimento de softwares.

Microsoft, CMMI e o mercado

É visão comum no mercado que a Microsoft pretende "acabar" com o CMMI, empurrando o MSF "goela abaixo" da comunidade. Entretanto isso não poderia ser mais equivocado e injusto. Adotar em uma empresa o MSF for CMMI, ajustado de acordo com os processos que são produzidos por seu SEPG, pode representar um diferencial estratégico capaz de distingui-la ainda mais no mercado, além de oferecer um ambiente de desenvolvimento integrado em que desenvolvedores, analistas, coordenadores e gerentes efetivamente interajam e trabalhem como uma equipe coesa.

Assim, encaminhamos a vocês alguns feedbacks que pudemos encontrar na Internet sobre empresas que têm usado o MSF for CMMI. Comprove a aceitação e faça suas próprias conclusões.

"What many people don"t realize is that if your organization is rigorously applying the principles of the Agile software development methodology, you"re already doing much of CMMI without knowing it," says Bill Phifer, an EDS fellow and SEI-authorized lead CMMI appraiser.

"One of our main goals with the CMMI toolkit was to make the process of generating the artifacts [documentation] necessary for an assessment to be a natural outcome of using the product," says Sam Guckenheimer, a group product manager on the Visual Studio team.

"VSTS uses several different approaches to help an organization get to a certain level with the target goal of Level 3. First of all, we have tried to instrument the process and treat evidence gathering as a by-product of the normal development cycle. Secondly, we use reporting as the artifact generation tool and not document writing," says Guckenheimer.

Mesmo considerando que o MSF ainda é novidade para muitos appraisers (pessoas que avaliam se uma empresa atende às exigências do CMMI, dando-lhe o "diploma"), a Microsoft preparou um workshop aberto a todos aqueles interessados em saber de que forma avaliar se uma empresa com MSF está atendendo a todas as exigências do CMMI. Mais uma prova de que, ao invés de serem inimigos, o MSF é um parceiro do CMMI para os desenvolvedores de produtos na plataforma Microsoft.

Para saber mais:

• MSF for CMMI Receives Positive Feedback
• MSF for CMMI Process Improvement
• Trust is the essence of Agile
• Not so Formal

Fabio Camara, Microsoft MVP VSTS, MCSD.NET, ITIL Foundations e MSF Practitioner, é Consulting Manager da FórumAccess e esta atualmente implantando VSTS com MSF for Agile Software Development ou com MSF for CMMI Process Improvement para diversas empresas no Brasil.

Igor Leite, MCAD, é arquiteto global da FórumAccess. Estuda o VSTS desde as versões Beta e participa dos grupos de trabalho TS, CM e PI para as KPA do CMMI nível 3.