O que há de novo no MSF

O novo MSF 4.0 (Microsoft Solutions Framework), representado por duas derivações evolutivas chamadas MSF for Agile Software Development e MSF for CMMI Process Improvement, certamente apresenta a grande maioria dos conceitos sugeridos em todas as metodologias surgidas nesta década, principalmente as propostas ágeis.

por Fabio Camara

Todo ano, começa projeto, atrasa projeto, cancela projeto, troca time do projeto, começa projeto... e assim caminha o lamentável mundo atual dos projetos de software.

Muitas das novas propostas de metodologias surgiram exatamente como uma sensata tentativa de mudança para os terríveis resultados que vêm sendo observados nos projetos de software.

Quando estudadas profundamente, percebemos que, de fato, as principais mudanças sugeridas pelas novas metodologias em comparação as mais “velhinhas” são três:

1. Um foco maior em testes como agente “garantidor” de qualidade;

2. Iterações mais curtas visando ter respostas rápidas e proporcionar uma homologação constante;

3. Atitude.

O novo MSF 4.0 (Microsoft Solutions Framework), representado por duas derivações evolutivas chamadas MSF for Agile Software Development e MSF for CMMI Process Improvement, certamente apresenta a grande maioria dos conceitos sugeridos em todas as metodologias surgidas nesta década, principalmente as propostas ágeis. Mas afinal, o que há de novo no MSF?

O histórico

Historicamente o MSF, que surgiu em 1993 timidamente como um guia de boas práticas baseadas em experiências dentro da própria Microsoft, sempre teve uma proposta menos formal que a de seus “concorrentes” da época. Da mesma forma que a linha ágil, o MSF preocupa-se mais com o conteúdo do que com a forma. Em outras palavras, não importa se são rabiscos em um papel de rascunho, se a informação é útil será tratada como uma especificação válida.

No meu ponto de vista, as propostas ágeis registradas no manifesto ágil de 2001 e que podem ser estudadas na integra no site http://www.agilealliance.com possuem muitos conceitos introduzidos pelo MSF e obviamente evoluídos. Agora presenciamos a troca de momento histórico, em outras palavras: primeiramente o Agile Manifest provê melhorias a conceitos introduzidos pelo MSF. Em 2005 o MSF introduz melhorias para alguns conceitos das propostas ágeis, nitidamente presentes na derivação MSF for Agile Software Development.

A própria derivação evolutiva criada para atender as áreas de processos chaves do CMMI também foi baseada em conceitos do MSF 3.0 e do, acreditem se puder, MSF Agile. Na prática isso é uma delícia, pois prova de maneira incontestável que não precisamos ser burocráticos para atender as exigências de padrões e qualidade de software, visando posicionar nossas fábricas no mercado internacional.

As propostas novas

Você pode estar pensando que é extremamente excitante ter uma metodologia totalmente integrada a uma ferramenta de automação. Sem dúvida nunca presenciamos uma novidade como esta, ou seja, o Visual Studio Team System foi planejado para atender os requisitos de automação e controle das novas versões do MSF. Entretanto, você pode usar as novas versões do MSF sem a ferramenta VSTS, se assim desejar.

Além da automação, existem conceitos realmente novos que o convencerão a experimentar o MSF em uma de suas derivações. Vamos apresentar os mais efetivos conforme minha leitura nas linhas a seguir.

1) Formalização do papel do arquiteto do projeto.

2) Orientação por iterações pequenas que permitem reduzir a margem de erros nas estimativas do projeto e provê informações “feedback” sobre a precisão dos planos.

3) Plano de governança baseado em 5 premissas: Objetivos revisados, avaliação de progresso, testes evolutivos de qualidade, riscos identificados e mitigados e “pronto” para implantação.

4) Parceiros como clientes – Usuários como parceiros.

5) O hábito da implantação, entregas frequentes.

6) Qualidade é definida pelo cliente.

Estudando estas propostas, mesmo que superficialmente, entendemos que o MSF é muito mais que um conjunto de atividades que você deve seguir. O MSF persegue um objetivo de criar uma cultura de desenvolvimento no seu time totalmente orientada ao resultado, consequentemente provendo o sucesso do seu projeto.

A atitude que faz a diferença

Eu costumo explicar para meus alunos ou nos trabalhos de consultoria que ministro que “adoro” a abordagem “socrática” (utilizado pelo filósofo Sócrates) de ensinar, principalmente para novos conceitos que envolverão quebra de paradigmas. A abordagem socrática de ensinar fundamenta-se em duas teses:

1) Levar você a respostas através das perguntas ao invés de simplesmente responder para você;

2) Permitir que um erro aconteça, mesmo que previsto pelo facilitador da aula ou do trabalho, marcando com maior profundidade a reflexão dos interessados quando comparado a devida explicação do conceito.

Em outras palavras, quando você aprende sentindo em sua própria pele a conseqüência do erro é muito mais efetivo que simplesmente ouvir como prevenir-se do erro. Quando você alcança uma resposta por sua própria compreensão é muito mais efetivo que receber a resposta.

Na grande maioria dos projetos em que sou chamado para direcionar como o mesmo deve proceder para sair de uma crise, percebemos que o problema é muito mais de atitude dos participantes do que questões técnicas ou metodológicas. Estas questões de atitudes possuem várias origens, desde questões culturais até quesitos organizacionais.

Visando apenas exemplificar brevemente as duas questões que citamos, para assuntos culturais podemos citar a diferença entre “estar comprometido com o projeto” e “estar envolvido com o projeto”. Isso nasce em nossos primórdios lingüísticos, pois na língua inglesa as palavras “ser” e “estar” são a mesma palavra, o verbo “to be”. Por diversas vezes ouvi um membro de um time de projeto em crise afirmar-me: _ Sou desenvolvedor C# e estou coordenador deste projeto. Sinceramente, o que podemos esperar de um recurso responsável pela coordenação do projeto que faz uma afirmativa como está? Quando ouço isso, imediatamente classifico o recurso como “envolvido com o projeto” e não comprometido. Normalmente este é o atalho para compreender a origem da crise no projeto supra.

Tratando do outro exemplo sobre as questões organizacionais, citamos as organizações hierárquicas – exemplo da grande maioria das empresas brasileiras – que gerenciam seus projetos sem nenhuma orientação “projetizada” no time de desenvolvimento. Neste tipo de organização é muito comum ter como resposta _ “Agradar o chefe!” _ para a pergunta: _ O que é mais importante para você, agradar seu chefe ou entregar o projeto? Esta orientação mental inconsciente, ou consciente em alguns casos, coloca sempre o projeto em segundo plano. É uma espécie de boicote encoberto que o time do projeto pratica.

Com base nestes exemplos citados, muito comuns no Brasil e também em outras empresas mundo afora, que o MSF preocupa-se em explanar sobre “Mindsets” que livremente traduzimos como “atitude mental”.

Se você estudar a documentação oficial do MSF (http://msdn.microsoft.com/vstudio/teamsystem/project/default.aspx?pull=/library/en-us/dnvsent/html/vsts-msf.asp) ou os “guidelines” presentes no template de projetos do Visual Studio Team System encontrará definições para atitudes mentais como:

1) Vontade de aprender sempre;

2) Orgulho de seu próprio trabalho ou orgulho do trabalho bem feito;

3) Qualidade deve existir em todo trabalho feito todos os dias;

4) Trabalhe com foco em compartilhar a visão do projeto;

5) Incentive a comunicação aberta.

Por mais que possa parecer “religioso”, algo como uma orientação comportamental, seus resultados, quando corretamente empregados no time do projeto, são perceptíveis em curto prazo e com baixo risco de implementação ou possibilidade de perda.

Podemos traduzir como um ditado popular que desconheço o autor: “Quem quer fazer, faz, quem não quer arruma desculpas”. Sucesso em projetos precisa de técnicas, metodologia e processos, entretanto sem atitude por parte dos integrantes do time nada disso será válido ou alcançará os objetivos. As atitudes são culturas inseridas no time do projeto através de seus líderes.

O resultado

Seja utilizando MSF for Agile Software Development ou MSF for CMMI Process Improvement, a disciplina Mindset está disponível para que os gerentes de projetos inspirem-se a apliquem nos seus liderados.

A proposta do MSF, desde suas primeiras versões, nunca foi “reinventar a roda”. De forma muito transparente o MSF sempre se baseou nas práticas das fábricas e na engenharia de produção.

O Microsoft Solutions Framework, como todas as novas linhas ágeis de metodologia, preocupa-se mais com o resultado do projeto do que com a forma que ele foi produzido, como podemos compreender nos termos (em inglês) “Product Mindset” e “Customer Mindset”.

Particularmente, prego a seguinte atitude em todas as iterações que tenho com projetos, seja liderando-os ou fazendo consultoria “coaching” ou “mentoring”: _ “Nada justifica o detrimento do resultado”. Tenha isso em mente nos seus projetos e conte-me quais foram os resultados no final.

Sucesso!