Processos Ágeis e MSF

Neste artigo vamos primeiramente compreender o que é uma proposta ágil, conhecer seus valores e princípios e em seguida estudar as características do MSF Agile.

por Fabio Camara

Desde fevereiro de 2001 quando um grupo de 17 metodologistas formaram a Agile Software Development Alliance (www.agilealliance.org) e definiram um manifesto para encorajar melhores meios de desenvolver software de forma direta e menos burocrática, observamos atentamente uma forte tendência entre as empresas fabricantes de softwares em estudar esta nova proposta. Posicionando-se com antecipação segura à maturidade da proposta, o MSF (Microsoft Solutions Framework) publica uma derivação denominada MSF Agile e promove-a ao processo "default" sugerido ao desenvolvimento de projetos, utilizando sua nova ferramenta (ainda em versão Release Candidate), Visual Studio Team System, ou simplesmente VSTS.

Neste artigo vamos primeiramente compreender o que é uma proposta ágil, conhecer seus valores e princípios e em seguida estudar as características do MSF Agile.

Por que precisamos ser ágeis?

O principio de tudo é o atual cenário nos resultados de desenvolvimento de software, muito aquém do ideal há bastante tempo. Os sistemas estão sendo entregues invariavelmente com atraso ou com o orçamento estourado, isso quando efetivamente são entregues.

Os raros entregues, geralmente não atendem aos requisitos de nossos clientes. Nossos clientes, por consequência, ficam extremamente descontentes com estes fatos e não apresentam mais disposição para confiar em nós e nem para trabalhar conosco.

Curiosamente, em muitos projetos em que fui chamado como um consultor de metodologia, gestão e processos de desenvolvimento, para conciliar partes e direcionar soluções aos projetos, percebo que no fundo, no fundo, as pessoas participantes não querem salvar o projeto e sim apontar culpados. Apelidei carinhosamente este tipo de consultoria que presto como "Resgate do soldado Ryan".

Os alvos convenientes para receber a culpa são geralmente os chefes, que os desenvolvedores duvidam serem capazes de amarrar os próprios cadarços. Em segundo lugar os analistas de sistemas, que os desenvolvedores chamam de criadores de papéis inúteis entre departamentos e por último, acreditem, os clientes usuários. Piadas como a sigla "BIOS" (Bicho Ignorante Operando o Sistema) fazem parte do cotidiano dos desenvolvedores e são utilizadas irracionalmente para justificar problemas em projetos.

A relação entre desenvolvedores e usuários sempre foi terrível, com acusações de ambas as partes. Os usuários reclamam que os desenvolvedores estão tão preocupados com linguagens e tecnologias que esquecem o negócio e os desenvolvedores acusam os usuários de nunca saberem o que querem, e quando sabem, o solicitado não faz sentido.

Possivelmente o cenário descrito acima não é nenhuma novidade ao técnico experiente, contudo por mais óbvio ululante que seja, ninguém posiciona-se de forma a mudar isto. Ninguém até o surgimento do manifesto ágil.

Por que utilizar de processos ágeis?

Vários fatores contribuem para o cenário descrito anteriormente, os programadores de linguagem e os processos prescritivos são os mais influentes na minha leitura.

Os programadores de linguagem são os jovens técnicos que focam seu aprendizado e o trabalho na tecnologia. Descrevem a si mesmo como ".NET Developer" e para eles a tecnologia é o mais importante. Como as tecnologias estão sempre mudando, entram em um ciclo de estudar sempre o novo e prendem-se neste universo fundamentado no código de baíxo nível. Com o tempo, eles acabam aprendendo que o básico pode ter sido aprendido ou não na escola, mas é efetivamente tudo igual. Mudam os nomes, uma ou outra pequena coisa, contudo ainda será muito similar. Isso acontece geralmente na idade de 30 anos, idade típica da busca pela estabilidade, entretanto é também a fase que acontece a migração de desenvolvedor para arquiteto ou coordenador de projetos. Enfim, o ciclo sempre se repete.

Processos prescritivos também chamados de processos de software "peso-pesado", são os processos que abusam de controles e documentações com a ilusão que os gerentes estarão sempre com o controle total do projeto e os desenvolvedores serão "plug and play". Bons exemplos de processos prescritivos é o RUP (Rational Unified Process), o processo OPEN e Processo de Software Orientado a Objetos (ou OOSP).

Os processos prescritivos são tipicamente baseados no paradigma comando e controle, que glorifica a informação de que a gerência tem tudo sobre suas vistas e pode solucionar os problemas do projeto. Já as "entidades plug and play" é a crença pregada pelos processos prescritivos que com o processo certo, no lugar certo e com o número de artefatos necessários, você pode trocar as pessoas em um projeto com relativa facilidade.

Confesso que particularmente acreditei em "entidades plug and play" há algum tempo atrás, mas com a vivência em projetos percebi que isso só é real quando a pessoa substituída não é produtiva e não tinha um papel atuante no projeto.

MSF Agile

Considero-me, na política de modelagem ágil, um partidário de centro-direita. Nunca fui adepto de metodologias prescritivas, porém também considero radical ou difícil de aplicar na prática algumas posições do eXtreme Programming. Um exemplo de minha posição de centro é achar o Martin Fowler um gênio na maioria das vezes (não todas) e considerar o Kent Beck muito "ortodoxo" e inflexível. Outro exemplo: acho a proposta de Refactoring muito bonita mas nunca presenciei um projeto que "alguém" pagasse por isso.

Neste ponto sempre considerei o MSF uma proposta equilibrada, aonde seus 2 modelos e suas 3 disciplinas nunca se apresentaram como uma espécie de bíblia sagrada, determinística ao sucesso ou fracasso de seu projeto. Inclusive na versão 3.1 do MSF, antes deste modismo por propostas ágeis, um dos conceitos chaves ensinados já era: _ Stay agile, expect changes. Uma prova incontestável ao bom senso que é pregado no MSF.

O MSF 4.0, ainda em versão beta, possui duas novas orientações: MSF Agile e MSF for CMMI Process Improvement. Estas metodologias já nascem totalmente integradas ao Visual Studio Team System, que contém templates para os documentos, controles e papéis.

Podemos afirmar que o MSF Agile é um mix de posições equilibradas de ambas as partes (MSF 3.1 e Agile Model), pois defende um SDLC (Software Development Life Cycle) mais curto com iterações de no máximo 4 semanas, contudo preserva a importância dos papéis definidos previamente e abomina a linha "todo mundo pode fazer tudo no projeto". Outro quesito de destaque nesta fusão são os testes unitários e a preocupação com a cobertura de 100% do código fonte.

Um tema muito forte dentro do MSF Agile é integração. Metodologias ágeis nescessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto. Para isso são constituídos cenários de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor. Estes cenários fazem parte de uma determinada iteração do plano de iterações. Esta iteração agrupa os cenários de desenvolvedores e os cenários de testes (que são efetuados em seguida ao desenvolvimento). Desta forma controla-se a integração de um time com papéis diversos dentro do projeto (usuário, desenvolvedor e analista de testes).

Com esta filosofia balanceada de modelagem ágil e melhores práticas da Microsoft, o MSF Agile surge como um salutar guia de processos para o seu projeto, permitindo a compreensão do dinamismo existente no mesmo, a integração necessária para seu desenvolvimento e tornando mais eficiente a construção de seu sistema. Sucesso em seus projetos.

Fabio Camara (fabio.camara@csharpbr.com.br) é MCP, MCSA, MCAD Charter, MCDBA, MCSE, MCSD.NET e MSF Practitioner - Utiliza MSF em seus projetos há mais de 5 anos com positivo histórico de resultados e acredita que o MSF Agile é uma proposta ainda melhor, principalmente para as características do mercado brasileiro.