Um projeto de software está com sérios problemas e quando acordei percebi que não era um pesadelo. Peguei um livro e li: O mau gerenciamento pode incrementar os custos de um projeto de software mais rapidamente que qualquer outro fator, escreveu Barry Boehm em 1981. Temi pelo meu emprego e pensei: antes de desistir vou contratar muitos desenvolvedores. Peguei outro livro e li: Adicionar pessoas faz um atrasado projeto atrasar ainda mais, escreveu Frederick Brooks em 1995.

Neste cenário assustador questionei-me: o que vou fazer diferente se preciso de resultados diferentes? Como compreender os verdadeiros obstáculos do gerenciamento de um projeto de software?

Procurei por muitos caminhos mas a resposta que mais gostei me foi ensinada pelos métodos ágeis. Entre muitos aprendizados que tive, li que o pensamento ágil reconhece 5 obstáculos no gerenciamento de projetos de software. São eles: pessoas, tempo, funcionalidades, orçamento e recursos (excluindo pessoas). Com isto em mente, coloquei em prática um pouco de 4 propostas ágeis que estudei.

Vamos conhecer um pouco destas propostas ágeis. São elas XP, MSF, SCRUM e FDD.

eXtreme Programming

Métodos ágeis são propostas incomuns de técnicas para projetos de software. XP, como o nome sugere, é algo um pouco mais radical. Propostas estranhas de técnicas esquisitas fazem os gerentes de projetos temerem utilizá-las em grandes projetos. Para atrapalhar ainda mais as poucas iniciativas de se quebrar paradigmas, o radicalismo de alguns pensadores de XP afastam a compreensão sobre as reais vantagens e os benefícios para o negócio que podemos alcançar com estes métodos.

A programação em pares, um dos mais diferentes e originais métodos do XP, traz para o gerente do projeto a necessidade de uma posição sem hipocrisia. Ou você ama, ou você odeia. Até hoje não encontrei um gestor “em cima do muro” sobre esta técnica.

Como exemplo, vamos citar Karl Wiegers, famoso autor de livros técnicos, que afirma em seus ensinamentos que a programação em pares como forma de inspecionar código não é efetiva na redução dos defeitos. Segundo o mesmo, entre 25 % e 35 % é o ganho atingido no aspecto “defect reduction”. Esta afirmativa é questionada por David Anderson, outro grandioso autor, que defende um número percentual em torno de 50%.

Já em minha própria vivência, as reuniões em pé (stand-up meeting) são fabulosas em quase todos os aspectos. Particularmente acredito no pensamento de Jonh Kennedy, ex-presidente dos EUA, que dizia: quando se quer não fazer nada fingindo que está trabalhando, entre em uma reunião.

Listamos a seguir os principais métodos polêmicos do XP.

• Pair Programming;
• Continuous Integration;
• Stand-Up Meeting;
• Collective Ownership (código fonte coletivo);
• Refactoring;
• On-Site Customer;
• Generalists.

Na minha leitura, o XP é uma proposta muito completa de ciclo de vida de desenvolvimento de software, agradando ou não um gestor de projetos. Um dos principais fundadores do XP chama-se Kent Beck.

FDD – Feature Driven Development

Criado entre 1997 e 1999 em Cingapura por um time liderado pelo Jeff De Luca, é uma simples compilação de práticas estabelecidas nos últimos 30 anos. Um de seus maiores desenvolvedores, Peter Coad, definiu a idéia de Feature Definition e Feature List. Diversos renomados autores participaram da concepção das idéias do FDD. Dentre estes destacamos: Tom De Marco, Tim Lister, Jerry Weinberg e Frederic Brooks.

Em sua essência, FDD é mais um método de gerenciamento de software do que um ciclo de vida de desenvolvimento de software.

Resumidamente, FDD é dividido em 5 fases que explicam sua função. São elas:

• Shape Modeling – é uma forma de questionar se todos compreendem o que é para fazer, analisar requisitos não-funcionais e modelo de arquitetura;
• Feature List – É a representação do escopo listando a compreensão do que é para ser feito e os requerimentos a serem desenvolvidos;
• Plan by subject area – É a modularização da lista em conjuntos de funcionalidades relacionadas, permitindo o desenvolvimento de parte do sistema autonomamente;
• Design by feature set – É uma orientação que determina o desenvolvimento com base no domínio do problema. Sugere-se nesta fase uma modelagem profunda e detalhada em UML;
• Build by Chief Programmer Work Package – É o empacotamento de pequenas funcionalidades, uma redução evolutiva que nasce na fase 2 até a fase 4. Prioriza-se este pacote, codificando sua funcionalidades e criando unit tests.

FDD define também 4 camadas de arquitetura de software:

• UI – User Interface;
• PD – Problem Domain (lógica do negócio);
• DM – Data Management;
• SI – Systems Interfaces.

Notamos que o “core” de todas as fases e das camadas de arquitetura é a funcionalidade (feature). Cada funcionalidade é definida com uma fórmula simples, que permite ser repetível e confiável. A fórmula da funcionalidade tem a seguinte estrutura:

<action> <result> <object>

Exemplo:

<action> O valor total de vendas

<result> Faturamento bruto mensal

<object> Produtos vendidos no período

MSF – Microsoft Solutions Framework

Disseram-me que MSF só funciona em projetos com tecnologias da Microsoft. É impressionante a associação restritiva que naturalmente os desinformados impõem as coisas. Também já ouvi que metodologias ágeis só são recomendadas para projetos pequenos. Pior que isso! Ouvi de uma diretora de TI de um banco: _ Hoje nós somos ágeis (referindo-se a ausência de gestão e de análise de requisitos de seu departamento), queremos ser mais organizados.

Estudando o assunto há 9 anos, eu 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 da formalização das propostas ágeis no ano de 2001, tinha como conceito chave: _ Stay agile, expect changes.

O MSF 4.2, possui duas novas instâncias: MSF for Agile Software Development e MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile é um mix de posições equilibradas, 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).

• Para o MSF, um projeto precisa dos seguintes pápeis (entende-se papéis como responsabilidades que devem ser assumidas por algum membro da equipe):
• Program Manager
• Product Manager
• User Experience
• Tester
• Developer
• Architect
• Release Manager

É árduo afirmar que foi o fundamentador do MSF, porém o grande patrocinador sempre foi a própria Microsoft. Para não ficar em branco com nomes, Michael Cusomano, Steve McConnell destacam-se entre muitos outros como personagens da história do MSF.

SCRUM

SCRUM é um método de gerenciamento de software que pode ser usado com XP ou MSF. É baseado na teoria do controle empírico de processos e seus fundamentos são originados na indústria de manufatura japonesa.

Ciclo de vida empírico é um ciclo baseado na observação dos fatos. Muitos gerentes de projetos não gostam do método reativo sugerido pelo SCRUM e preferem trabalhar com um planejamento que na minha leitura é um trabalho especulativo, pois tenta prever uma seqüência de atividades lineares. Por mais que o cronograma tenha um valor que é o planejamento prévio, ou seja, pensar antes de sair fazendo, perde muito em tentar prever atividades distantes cheias de dependências predecessoras e não facilita o controle das mudanças de requisitos.

Segundo o SCRUM, o desenvolvimento deve ser trabalhado em 3 níveis: Sprint, Release e Product.

O ponto central é que os requisitos são convertidos em uma lista que contém valores do cliente chamada Product Backlog. Um sub-conjunto desta lista é criado e chamado de Release Backlog. Este sub-conjunto é particionado mais uma vez transformando-se em Sprint, uma espécie de acordo de desenvolvimento de funcionalidades que após aceito pela equipe não deve ser mais alterado.

Praticando SCRUM, o que mais chama a atenção é a simplicidade. Controlar projetos desta forma é participar de um jogo competitivo e saudável em que todos se auto-avaliam todos os dias (daily stand-up meeting) tornando possível resultados e técnicas de melhoria contínua.

O gerente de projetos como conhecemos hoje, na proposta SCRUM, é chamado de SCRUM Master. Suas principais responsabilidades resumem-se em duas: Proporcionar a passagem técnica e retirar todos os impedimentos. A equipe do projeto é dividida em apenas 3 pápeis: o SCRUM Master (coach), o Product Owner e a equipe.

Em diversos aspectos, as técnicas do SCRUM diferenciam-se das propostas convencionais. Destaque para:

• Product Backlog;
• The 30-Day Sprint;
• The SCRUM Meeting;
• Team Size;
• The Sprint Review.

Para saber mais sobre SCRUM, é imprescindível ler algum dos títulos lançados por Ken Schwaber.

O que experimentar

Independente de sua curiosidade para novos sabores, os métodos ágeis são uma honesta resposta a pergunta: o que vou fazer diferente se preciso de resultados diferentes?

Baseados em processos iterativos incrementais e empíricos, os métodos ágeis são indiscutivelmente diferentes das propostas tradicionais que são fundamentadas em processos cascata. Esta diferença pode ser a resposta a sua dúvida também.

Meus resultados mudaram significativamente quando entendi a diferença essencial da proposta ágil em comparação ao modelo que eu havia aprendido nos ensinamentos do PMI – Project Management Institute.

A orientação PMI é:

Orientação PMI

A orientação ágil é:

Orientação Ágil

Considere na imagem que a seta vermelha é uma constante, a seta verde é mais ou menos variável e a seta lilás é a mais variável.

Compreendendo a diferença entre as duas e alinhando com as características das expectativas de seus “stakeholders”, você conseguirá alcançar resultados diferentes.

Experimente!