Já se passaram muitos anos desde os primeiros documentos sobre MSF que datam do ano de 1991. De lá para cá, o que aconteceu? Como ficou o passado e como será o futuro? O que muda no MSF por causa do Visual Studio Team System?

Respondendo estas e outras questões, decidimos simular uma entrevista real neste artigo. Apostamos que a objetividade desta proposta será muito mais eficiente que qualquer texto narrativo. Em nossa proposta, simplesmente numeramos as perguntas e colocamos o autor, ou seja o próprio que escreve agora, para responder.

Estas são as perguntas:

1)      Qual a definição do MSF, metodologia ou disciplina?

Resp.: Na minha leitura, está mais para metodologia do que para disciplina. Uma disciplina de engenharia de software se propõe a tratar um tema vertical com profundidade. O MSF apresenta assuntos horizontais e em muitos deles numa superficialidade maior do que eu gostaria. Da mesma forma, muitas pessoas me perguntam se é um framework como o próprio nome sugere. Ao meu ver, falta muito para ser um framework pois está mais na sugestão, modelo e direção do que na proposta prática de documentos e técnicas.

2)      Qual o seu tempo de expêriencia com o MSF?

Resp.: Comecei em 1998 a estudar e em 2000 tive a oportunidade de praticar em um gigantesco projeto. Na época fui felizardo em trabalhar com pessoas da Microsoft que conhecem profundamente o MSF, como por exemplo o Otávio Pêcego e o Ricardo Mendes (técnicos que sou fã até hoje). De lá para cá tenho estudado muito e questionado muito o modelo de ciclo iterativo incremental, pois mesmo funcionando em meus históricos, tenho gostado mais de praticar ciclos empíricos.

3)      Qual foi a melhor versão do MSF já lançada?

Resp.: Sinceramente tenho dúvidas se é a versão 2.5 ou a 3.0, as duas eram extremamente de vanguarda com os melhores príncipios de agilidade numa época que só se falava em ciclo waterfall e processos prescritivos para projetos de software. Quanto a pior, certamente é a 4.2 que acompanha o Visual Studio Team System hoje. Seja a instância para CMMi como a instância para Agile, conseguiram fazer algo complexo demais e incompleto demais. Fico triste pela metodologia, que está precisando de novos (velhos) gurus[i], fico triste pelo efeito disso no VSTS, pois acredito que para uma empresa usar esta excelente ferramenta na plenitude obrigatoriamente terá que personalizar seu próprio modelo de processos (Process Template).

 4) Qual o diferencial principal do MSF do seu ponto de vista em relação ao RUP e PMI?

Resp.: As duas propostas se assemelham mais do que se diferem. O RUP é mais formal, mais completo e mistura um pouco de ciclo iterativo incremental com pitadas de ciclo waterfall. Já o MSF é mais informal, incompleto em diversos aspectos, porém com “atitudes mentais” (em inglês, mindset) muito positivas visando produtividade e qualidade – fundamento isso nos valores “foco no cliente” e “foco no produto” do MSF. O modelo de equipe do MSF é também um belo exemplo a ser seguido, pois formaliza uma série de responsabilidades imprescindíveis para um projeto de software. O fato do MSF ser incompleto em diversos aspectos pode ser bom ou ruim, dependendo do ponto de vista. Por exemplo, se você quer usar algumas técnicas de XP (eXtreme Programming) com MSF certamente será mais simples que usar XP com RUP. Comento isso considerando que você quer preservar a origem e a essência do modelo MSF e do modelo XP. No caso do RUP, certamente você estaria criando um processo personalizado e desfiguraria a essência e o modelo. No meu caso prático, eu gosto muito de usar o modelo de equipes do MSF, com métodos de gestão e ciclo empíricos do SCRUM, com técnicas de levantamento de requisitos do APM – Agile Project Management e do Agile Modelling (Scott Ambler), com técnicas de codificação do XP (exceto Pair Programming) e TDD – Test Driven Development.

5) O modelo de equipe do MSF, sem hierarquia, funciona na prática?

Resp.: A resposta sincera está mais para “não” do que para “sim”. O problema, na minha leitura, não é o MSF Team Model. É a cultura de nosso país, de nosso povo. Modelos democráticos não funcionam no Brasil, somos acostumados a ser ordenados, a seguir outros e não a liderar. Somos acostumados com a “Lei de Gerson” e outros predicados que não funcionam numa equipe. Tem também a questão da formação acadêmica. Os cursos de ciências exatas não trazem nenhuma disciplina humana, por isso o aluno sai do curso uma “fera” em algoritmos e linguagens de programação, mas não sabe lidar com o amigo de trabalho ao lado da mesa, com seu cliente e com o seu chefe. Enfim, não quero fazer desta entrevista um manifesto político. Em resumo, o modelo não hierárquico do MSF tem como funcionar na prática, desde que forme-se um modelo de auto-gestão individual em cada membro da equipe. Entenda-se aqui como auto-gestão, o próprio individuo se responsabilizar pelas suas atividades e por seus “check-lists”.

6) Você poderia citar um caso de sucesso, no qual foi utilizado o MSF para guiar o projeto?

Resp.: Primeiro vamos definir o que é um caso de sucesso. Se para você caso de sucesso é um projeto entregue no prazo previsto no primeiro momento e com o orçamento previsto na primeira estimativa, isso não faz parte de minhas crenças. O plano perfeito (ou seja, o cronograma imútavel e os requisitos congelados) são fábulas de livros de engenharia de software. Todo projeto evolui em comparação a sua primeira estimativa e por isso, para mim, caso de sucesso é entregar um projeto que teve requisitos, orçamento e prazo alterados conservando a satisfação do cliente contratante do projeto. Agora que alinhamos o que é caso de sucesso, posso afirmar que o MSF Essentials orienta uma série de valores que conduzem ao resultado positivo. Mais uma vez, os valores “foco no cliente” e “foco no produto”, se corretamente compreendidos pela equipe do projeto, proporcionarão uma série de atitudes e técnicas comprometidas com a satisfação do cliente e com a entrega do produto final.

 7)  Quais os grandes diferenciais no modelo de times do MSF?

Resp.: Certamente é a formalização das responsabilidades do usuário em um projeto de software. O papel “User Experience” traz valores que adicionam muito mais uma parceria real do que o papel “Product Manager[ii]” e seus similares em outras metodologias. Traduzindo a frase anterior: inserir no projeto o papel formalizado do que o usuário deve fazer em um projeto de software transcende as outras propostas metodológicas que apresentam apenas o papel de Product Manager, ou Business Analyst, ou Product Onwer, ou qualquer stakeholder com a finalidade de definir e especificar o que deve ter o produto. Com este papel, atendemos uma série de expectativas de usuários reais, como usabilidade, ergonomia, requisitos não funcionais relacionados com desempenho e facilidade de uso. Outro diferencial é o papel Release Manager. Apesar de, na minha leitura, haver uma certa superficialidade na formalização deste papel pela metodologia, considerar em seu projeto um membro responsável por infra-estrutura para o desenvolvimento, por controle dos códigos fontes (administração da ferramenta) e por máquinas de compilação (administração de versões) pode significar a diferença entre resultados previsíveis e desastres de última hora.

8) Do seu ponto de vista, o MSF é realmente eficaz, ou possui pontos que podem ser aperfeiçoados?

Resp.: No meu ponto de vista, usar uma só metodologia em seus projetos é torná-los míopes. As receitas mudam de resultado conforme quem as implementa. É fundamental permitir-se a revisão se o método do MSF ou de qualquer outra metodologia é o mais adequado para determinado projeto constantemente. Em meus históricos de projetos, conclui que o fator mais importante é o líder do projeto e não importa muito qual metodologia ele usa. As metodologias são importante para formalizar procedimentos e permitir uma cultura única no desenvolver de um projeto. A metodologia formal também facilita a entrada de novos participantes, pois pode-se contratar técnicos com os conhecimentos necessários para a cultura do projeto. A metodologia é também uma espécie de braço direito do líder, pois orienta-o procedimentos, gestão e check-lists. Agora respondendo exclusivamente sua pergunta, o MSF é bastante maduro, fato que patrocina sua eficácia, porém perdeu muito da indentidade Microsoft nos útimos anos. Muita gente competente, como Steve McConnell, Randy Miller e David Anderson entre muitos outros que injustamente não estou citando, contribuíram para o enriquecimento do MSF como uma metodologia de mercado. No meu entender, este foi o problema. Quando o MSF não estava preocupado com o mercado e simplesmente em ser a forma como a Microsoft desenvolvia seus produtos internamente, a metodologia era muito autêntica. Hoje, depois de tantas transformações, temo que as empresas que usam MSF (incluindo a própria Microsoft) na verdade usem uma versão própria derivada do MSF. O problema disso é que em breve não teremos mais os fundamentos essenciais do MSF para personalizar e utilizar em nossos projetos – teremos algo sem “predigree”. Acreditando nisso, rogo para que o MSF não tenha mais aperfeiçoamentos, mas sim recupere sua matrizes genéticas, tornando-se novamente “o MSF”, uma metodologia ímpar.

9) O que muda no MSF por causa do Visual Studio Team System e qual o futuro do MSF?

Resp.: O VSTS enriquece o MSF. De certa forma, todas as empresas que desenvolvem projetos possuem algum tipo de ciclo fabril, seja tácito aos participantes ou muito bem formalizado. Este ciclo fabril, corretamente mapeado e cobrindo todas as necessidades para a construção do projeto pode ser chamado de ciclo de vida de desenvolvimento de software (em inglês SDLC[iii]). O VSTS é uma ferramenta para automatizar o ciclo vida de desenvolvimento de software. Como todo o SDLC é inspirado em alguma metodologia, podemos afirmar que o VSTS automatiza o MSF amplificando os possíveis resultados propostos pelos princípios e valores da metodologia. Sobre o futuro, acredito na sensibilização de gestores da Microsoft para a continuidade evolutiva (como comentei na resposta 8, voltando as raízes) do MSF. Acredito nisso porque o MSF vai se tornar mais popular do que nunca foi em virtude de sua distribuição e primeira opção de utilização junto do VSTS.

10) É possível usar o MSF sem o Visual Studio Team System?

Resp.: De novo, o VSTS enriquece o MSF. O VSTS não canibaliza nenhuma metodologia, simplesmente a automatiza. Respondendo assim afirmamos que você pode usar o VSTS com SCRUM, com RUP ou com XP assim como você pode usar o MSF com StarTeam (da Borland) ou sem nenhuma ferramenta de automação de processos fabris. Minha recomendação para as empresas que desejam utilizar o MSF sem o VSTS, que baseiem-se na versão 3.0 do MSF.

Quero registrar meu agradecimento ao aluno Anderson Suzuki, de um curso de Ciência da Computação de alguma universidade no nosso país, que resolveu fazer seu TCC sobre MSF e de tanto me enviar perguntas, me inspirou a fazer este artigo (principalmente neste formato).

Sucesso em seus projetos,

Fábio Câmara