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.