Seus problemas acabaram!

Por diversas vezes em palestras ou workshops que ministro percebo que as pessoas esperam do MSF Agile (ou MSF CMMi) junto com o VSTS uma espécie de ferramenta mágica que resolverá todos os possíveis e inimagináveis problemas dos projetos de software...

por Fabio Camara

Por diversas vezes em palestras ou workshops que ministro percebo que as pessoas esperam do MSF Agile (ou MSF CMMi) junto com o VSTS uma espécie de ferramenta mágica que resolverá todos os possíveis e inimagináveis problemas dos projetos de software.

A resposta mais rápida e sincera é: Se alguém te oferecer uma ferramenta ou metodologia que promete este resultado mande chamar a polícia, pois você estará diante de um estelionatário.

Vamos separar a questão em três partes: A metodologia (ou guia de processos e técnicas), a ferramenta e o líder de projetos.

A primeira informação é que o líder é o responsável e deve se responsabilizar pela condução dos projetos e seus respectivos resultados. Independente de metodologia, independente de ferramenta, os bons líderes de projetos conseguem através de suas habilidades atingir expectativas de resultados favoráveis. Para isso, o líder de projetos deve saber delegar!

Delegar vem do latim "delegare" que significa: _ dar uma parte de si em execução a um outro para realizar um aspecto de um projeto. Perceba como é importante entender o que é delegar, pois é dar uma parte de si. É muito comum as pessoas passarem atividades para outros e simplesmente acharem que se os outros falharem, problemas deles, eles (os outros) é que são incompetentes.

O processo de delegar implica em riscos. Delegar deve ser uma das atividades mais sérias do líder de projetos. O resultado mais comum quando este assunto não é levado a sério é: _ os melhores pagam na própria carne o erro do arbítrio dos outros para os quais delegaram o próprio poder.

Para delegar, você deve ter certeza que a pessoa que recebeu a atividade está apta a executar a mesma - entenda por apta estar capacitada tecnicamente e que compreendeu perfeitamente a atividade. Depois disso você deve ser capaz de responsabilizá-la. Por último você deve evitar as desculpas desta pessoa que tentará de mil formas não entregar a atividade como uma espécie de auto-sabotagem inconsciente.

Quando eu escrevo "auto-sabotagem inconsciente" quero afirmar que as pessoas geralmente não resolvem os problemas que ocorrem no decorrer da atividade delegada, as pessoas na maioria das vezes tendem a "avisar" do problema, comentar sobre o problema...

Um bom exemplo de evitar desculpas é agir responsabilizando a pessoa delegada por trazer problemas e não soluções. Observe o seguinte cenário:

O desenvolvedor recebeu uma atividade e após 6 horas na mesma volta para o líder de projetos informando que há um problema para a conclusão da atividade solicitada.

Opção 1: O líder de projetos simplesmente aceita o problema e envolve outras pessoas para resolvê-lo. O desenvolvedor fica com uma postura passiva ou é designado para outra atividade.

Opção 2: O líder de projetos responsabiliza o desenvolvedor dizendo: _ "Vamos partir de uma premissa para este problema. Estou considerando que você já fez tudo que é possível e imaginável ao seu alcance para resolvê-lo e não conseguiu. Então, encontramos seu limite de competência! Vamos trabalhar ativamente neste ponto para poder fazer seu crescimento profissional". Não permite uma atitude passiva do desenvolvedor e fica ao seu lado (ou designa alguém mais apropriado para isso) até resolver o problema.

O que ocorre é que na opção 1 há uma permissividade a ausência de responsabilidade e crescimento profissional. O desenvolvedor na opção 1 nunca se sentirá responsabilizado, não é desafiado a superar seus limites, não há ganho de conhecimento e aprendizado constante.

Pode parecer que a opção 2 é humilhante, mas reflita cuidadosamente. Não é vergonha nenhuma saber de seus limites de competências e trabalhar a evolução deles tornará este desenvolvedor um profissional realizado.

No fundo todos os problemas dos projetos estão mais relacionados as pessoas do que as técnicas e ferramentas. O líder de projetos deve criar um ambiente com uma "forma mentis" adequada para os resultados esperados.

Forma = modo interno que especifica e diferencia uma coisa da outra.

Mente = faculdade de projetar, mensurar.

Forma mentis = é o conjunto de valores e modos de pensar que a pessoa tem como próprios com os quais se identifica. É a base das atitudes da pessoa frente as situações.

Para finalizar este ponto, pense nisso: Se não tivesse problema, não precisava de líder de projetos!

Metodologia e ferramenta - qual é a mágica?

Você sabe qual é a diferença entre CMMi e MSF for CMMi Process Improvement?

CMMi é um modelo que solicitam averiguações do seu estágio de maturidade através da satisfação de áreas chaves de processos.

MSF for CMMi Process Improvement é um guia de processos que visam atender as exigências de alguns níveis de maturidade qualificados pelo CMMi.

O MSF for CMMi Process Improvement ou o Visual Studio Team System é certificado para CMMi nível 2 ou 3? Claro que não! Qual é a mágica?

Eis a questão! As pessoas esperam que algumas coisas ocorram em um passe de mágica só porque estão aderindo a uma metodologia ou ferramenta.

É correto afirmar que o MSF for CMMi Process Improvement e o VSTS são aceleradores para o processo de certificação de maturidade do seu time de desenvolvimento, contudo entenda esta afirmativa com moderação. É um acelerador, não um solucionador.

Outro ponto importante: Muita gente torce o nariz quando ouve alguma coisa sobre adotar metodologias ágeis para seu time de desenvolvimento. A questão não é algum tipo de racismo, é porque estas pessoas acham que já são ágeis.

Há uma gigantesca diferença entre ser ágil (do ponto de vista praticar métodos ágeis) e o que frequentemente encontramos nas empresas brasileiras. No Brasil a metodologia mais praticada que existe é a metodologia Tarzan, ou seja, alguns heróis levam literalmente no grito os problemas do dia-a-dia dos projetos.

Mais uma vez, não há mágica. Se você pretende usar o VSTS em sua empresa e vai adotar o MSF for Agile Software Development como padrão dos processos e artefatos fornecidos pelo VSTS - prepare-se para estudar bastante e adequações.

O VSTS não é uma ferramenta mágica que vai organizar seus processos de construção de software. O VSTS é uma ferramenta que vai acelerar seus controles e tornar seus resultados mais previsíveis pelo fato de automatizar os pontos de controle de seus processos de construção de software.

Para usar o VSTS, é preciso estudá-lo. Instalar o VSTS sem um sério estudo de adequação de processos e pontos de controle é incluir um novo (e grave) problema no dia-a-dia de sua fábrica de projetos de software.

Pela última vez, não há mágica. Projetos com sucesso são um conjunto bem sucedido de bons líderes de projetos + métodos e técnicas adequadas + uma ferramenta confiável de controle de fontes e controle de atividades.

Qualquer coisa muito diferente disso pode ser considerado papo de "astronauta".

Sucesso em seus projetos.

Fábio Câmara, Microsoft MVP em VSTS e MSF Practitioner - É fascinado por estudar assuntos relacionados a liderança e acredita em resultados positivos em projetos usando MSF e VSTS. Escreveu os livros "Visual Studio Team System Rocks", "58+ Soluções em .NET" e "Orientação a Objeto com .NET" dentre outros.