Na primeira parte deste artigo vou apresentar uma breve descrição das metodologias adoptadas em cada projecto. Na segunda irei fazer uma pequena comparação entre estas duas metodologias, enumerando as vantagens e desvantagens de cada uma delas. É claro que será apenas uma comparação baseada na minha experiência pessoal, ausente de qualquer justificação científica.
Na primeira fase do projecto A houve um levantamento de requisitos, seguido das fases de análise, desenho da arquitectura, implementação, testes e finalmente a entrada em produção. Este processo foi efectuado em espiral, ou seja, existiram sucessivas iterações entre a fase de análise e as que a sucedem.
O projecto B teve um processo de desenvolvimento bastante diferente. Existiu uma pequena fase de análise com os principais objectivos de se definir qual a tecnologia a utilizar, elaborar um calendário com diversas ‘milestones’ e acordar as linhas orientadoras do processo. Após esta breve fase começou-se o desenvolvimento, puro e duro.
Antes de se fazer uma linha de código criava-se um teste unitário (Unit Test). Se o teste falhasse (o mais comum) fazia-se o desenvolvimento da funcionalidade, e em seguida fazia-se o ‘refactoring’ do código. Depois corriam-se os testes unitários na totalidade para verificar se não se estragou nada do que estava feito até à data.
Os ‘milestones’ acordados na primeira fase foram Feature Complete (FC), Zero Bugs Bounce (ZBB), Beta 1, Beta 2 e finalmente Final Release. Em baixo faço a descrição de cada ‘milestone’.
FC: todas as ‘features’ foram terminadas até esta data, ou seja, a partir deste ‘milestone’ apenas se catalogaram e corrigiram ‘bugs’. Gostaria de realçar que neste projecto nem todos os ‘bugs’ foram resolvidos. Foi feita uma selecção de quais valeria a pena resolver ponderando a sua criticidade e os efeitos secundários da sua resolução. Além disso tentou-se sempre atrasar a resolução de um bug o mais possível, assim garantíu-se que as tarefas mais importantes eram sempre realizadas primeiro. Alias, esta filosofia aplicava-se também às ‘features’, mas este comportamento é comum a quase todas as metodologias que eu conheço.
ZBB: Quando este ‘milestone’ foi atingido os bugs a resolver tinham no máximo 24 horas. Ou seja, era obrigatório que todos os ‘bugs’ reportados num dia fossem resolvidos no dia seguinte, caso se optasse pela sua resolução.
Beta 1: Primeira versão a enviar para produção num grupo restrito de clientes. Aqui foram feitos testes de integração e de aceitação.
Beta 2: Versão para substituir a anterior no mesmo universo de clientes.
FR: “Abram uma garrafa de ‘Don Perignon’ e metam na conta do chefe”.
Para finalizar, gostaria de notar duas particularidades acerca desta metodologia.
- O cliente faz parte da equipa de desenvolvimento.
- As ‘features’ são acordadas através de ‘User Stories’
Isto quer dizer que o próprio processo de desenvolvimento é feito em ciclos muito curtos, e o projecto tem o comportamento de um protótipo evolutivo. Pode-se observar as fases de cada ciclo neste diagrama (autoria de J. Donovan Wells).
No próximo artigo irei fazer a prometida comparação entre estas duas metodologias, focando alguns pontos comuns em qualquer projecto. Será uma experiência realmente interessante, porque apesar do objectivo passar sempre por entregar um produto final no prazo acordado e deixar o cliente satisfeito, estas duas metodologias seguem filosofias opostas.
Gostaria apenas de salientar que irei fazer uma comparação tendo em conta o seguimento destas metodologias tal como foram descritas. Projectos com duração considerável sofrem sempre de alguns imprevistos, e quer num caso quer no outro não foram feitas análises de risco. Quando os imprevistos aconteceram... improvisou-se.
Também vou salientar que o um dos projectos ainda está a decorrer, e eu já não sou membro da equipa. O que quer dizer que na segunda parte do artigo irei especular acerca da sua conclusão, supondo sempre que esta será um sucesso (acredito que sim pois a equipa é liderada por pessoas com grandes capacidades nesta área).
Sem comentários:
Enviar um comentário