Um cardápio de metodologias ágeis
Autor: Hebert | Publicado: 2010-06-06T22:46:00-03:00

Boa noite...Este documento não foi de minha autoria, e sim achei em um blog na rede quando andei pesquisando sobre algumas metodologias recentemente para poder estudar e conhecer um pouco mais além de Scrum e XP.
Segue pra vcs agora o texto criado por Fábio Camara em "Um cardápio de metodologias ágeis".
------------------------------------- 
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 ProgrammingMé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 DevelopmentCriado 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&nbsp; result&nbsp; object Exemplo:action O valor total de vendasresult Faturamento bruto mensalobject Produtos vendidos no períodoMSF - Microsoft Solutions FrameworkDisseram-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.SCRUMSCRUM é 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 é:   
A 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!
-------------------------------------
É isso ai pessoal.