Aquivos por Autor:

>É sempre muito difícil no começo escolher a metodologia que mais possa se adaptar a uma equipe, gestão ou pensamento. E porque não o contrário? A equipe, gestão ou pensamento se adaptar a uma metodologia? Isso explicaria o porque a utilização da metodologia ágil entra de forma atrasada na maioria das empresas, em muitos casos, causada pela falta de iniciativa dos próprios desenvolvedores!

O pensamento ágil reconhece 5 obstáculos no gerenciamento de projetos de software: pessoas, tempo, funcionalidades, orçamento e recursos.

Acreditar em antigos dogmas como trazer mais desenvolvedores pode alavancar de vez o projeto, acabar com o atraso nas entregas… Sabemos a tempos que isso não vai acontecer. Mas podemos sugerir a utilização de uma metodologia, e que de preferência isso ocorra antes do projeto iniciar claro. Então o porque de não fazer, temos sim que nos envolver muitas vezes, pois a visão de chão de fábrica pode ser a salvação do prazo para aquele projeto, pois temos a experiência e as condições de sugerir.

Adicionar pessoas faz um atrasado projeto atrasar ainda mais. – Frederick Brooks em 1995.

Venho trabalhando com metodologias mas acredite, estou sozinho, e como se trabalha com uma metodologia feita para uma equipe, sozinho? Alguns inventaram o SCRUM solo, eu uso, E quem sabe falo sobre ele e como utilizo em outro post

O mau gerenciamento pode incrementar os custos de um projeto de software mais rapidamente que qualquer outro fator – Barry Boehm em 1981.

Abaixo descrevo as 4 metodologias que conheço, já usei e algumas ainda uso, outras desejo muito usar:

SCRUM
SCRUM é um método de gerenciamento de software que pode ser usado com XP ou MSF. Originado na indústria de manufatura japonesa.
Segundo o SCRUM, o desenvolvimento deve ser trabalhado em 3 níveis: Sprint, Release e Product.

No SCRUM os requisitos são convertidos em uma lista que contém valores do cliente chamada Product Backlog.
Podem ser divididos e explicados como:

• Release Backlog – um subconjunto Backlog ;
• Este subconjunto é novamente dividido e transformando em Sprint;
• Durante os Sprints os desenvolvedores existe o daily stand-up meeting;

O gerente de projetos chamado de SCRUM Master tem como principais responsabilidades proporcionar a passagem técnica e retirar todos os impedimentos.
A equipe do projeto é dividida em apenas 3 papéis: o SCRUM Master (coach), o Product Owner e a equipe.

eXtreme Programming(O Radical)
Kent Beck é um dos principais fundadores do XP, que tem a programação em pares, um dos mais diferentes e originais métodos do XP, claro que não é o único, porém o que mais define a metodologia.
Como exemplo, citamos Karl Wiegers, 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”. Questionada por David Anderson, outro autor, que defende um número percentual em torno de 50%.

MSF – Microsoft Solutions Framework
Diferente do que pensa a maioria, somente por ter sido criada pela Microsoft, não quer dizer que esta seja usada somente em projetos com tecnologia microsoft.
O MSF possui duas 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”.
Tem como vantagens destacada:

• A integração no MSF Agile;
• Não necessita que os “stakeholders” estejam presentes o tempo todo durante o projeto;
• Constitui cenários de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor;
• Agrupa os cenários de desenvolvedores e os cenários de testes (que são efetuados em seguida ao desenvolvimento);
• Maior integração do time com papéis diversos dentro do projeto (usuário, desenvolvedor e analista de testes).

FDD – Feature Driven Development
Criado entre 1997 e 1999 em Cingapura por um time liderado pelo Jeff De Luca. 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.
Tem como essência, ser mais que um método de gerenciamento de software do que um ciclo de vida de desenvolvimento de software. Resumidamente, FDD é dividido em 5 fases:

• 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.

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:

Exemplo:
< action > O valor total de vendas
< result > Faturamento bruto mensal
< object > Produtos vendidos no período

Bom, não sou fã de posts longos, mas descrever as 4 mais da metodologia ágil não pode ser mais resumido que isso.