Processos Ágeis para desenvolvimento de Software – Parte 02


3. XP, SCRUM e MSF Agile.

 

Os conceitos do manifesto ágil aproximam-se melhor com a forma que pequenas empresas de Tecnologia da informação trabalham e respondem a mudanças.  Muitos desenvolvedores focam na tecnologia e esquecem-se da informação que é na verdade o que o cliente busca.

As metodologias ágeis buscam deixar estas variáveis em equilíbrio. Existem vários métodos ágeis, dentre eles podemos citar: Extreme Programming (XP), SCRUM, DSDM, Crystal e outros. 

 

3.1. XP

 

A Extreme Programming (XP) é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Dentre as principais diferenças da XP em relação às outras metodologias estão:

·                     Feedback constante

·                     Abordagem incremental

·                     A comunicação entre as pessoas é encorajada.

O primeiro projeto a usar XP foi o C3, da Chrysler que após anos de fracasso utilizando metodologias tradicionais, com o uso da XP o projeto ficou pronto em pouco mais de um ano.

 

3.2. SCRUM

 

O foco da metodologia SCRUM é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança.

A idéia principal da SCRUM é que o desenvolvimento de softwares envolve muitas variáveis técnicas e de ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O resultado do processo deve ser um software que é realmente útil para o cliente.

A metodologia é baseada em princípios semelhantes aos da XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento.

No entanto, as dimensões em SCRUM diferem de XP. A SCRUM divide o desenvolvimento em iterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (requisitos) definidas no início de cada sprint.

A equipe é responsável pelo desenvolvimento desta funcionalidade. Na SCRUM existem reuniões de acompanhamento diárias. Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze minutos), são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) são identificados e resolvidos.

O ciclo de vida da SCRUM é baseado em três fases principais, divididas em sub-fases:

1)                  Pré-planejamento (Pre-game phase): os requisitos são descritos em um documento chamado backlog. Posteriormente eles são priorizados e são feitas estimativas de esforço para o desenvolvimento de cada requisito. O planejamento inclui também, entre outras atividades, a definição da equipe de desenvolvimento, as ferramentas a serem usadas, os possíveis riscos do projeto e as necessidades de treinamento. Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos requisitos descritos no backlog são identificadas, assim como seus possíveis riscos.

 

2)                  Desenvolvimento (game phase): as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas durante o desenvolvimento. Ao invés de considerar essas variáveis apenas no início do projeto, como no caso das metodologias tradicionais, na SCRUM o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Nesta fase o software é desenvolvido em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em seguida o projeto, implementação e testes. Cada um desses ciclos é planejado para durar de uma semana a um mês.

 

3)                  Pós-planejamento (post-game phase): após a fase de desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração, testes finais e documentação.

 

3.3. MSF Agile

 

O Microsoft Solutions Framework surgiu em 1994 como um conjunto de boa práticas compiladas pela Microsoft a partir de sua experiência na produção de software e em serviços de consultoria. Desde então, o MSF evoluiu, tornando-se um framework flexível para nortear o desenvolvimento de projetos de software. Essa evolução também teve o intuito de acompanhar tendências bem sucedidas no meio da engenharia de software, como a capacidade de responder à necessidade de mudanças rapidamente.

O MSF 4.0 será nosso objeto de estudo e suas principais características serão avaliadas.