Nota prévia: Este artigo encontra-se em edição deste 23 de Dezembro de 2008 nunca tendo sido concluído. Algumas secções encontram-se incompletas!
Tendo a apresentação sido feita anteriormente, dispensa este artigo um parágrafo introdutório.
Numa fase em que preparo o arranque de um projecto pessoal, aproveito a oportunidade para “experimentar” esta metodologia e regrar a fase de desenvolvimento.
Quanto à metodologia eXtreme Programming toda a sua essência está condensada no diagrama1 abaixo, a partir do qual farei uma análise dos vários tópicos.
eXtreme Programming Workflow
User Stories
Embora distintos, facilmente são confundidas com Use Cases.
Escritas pelo cliente e em linguagem não técnica, não devem ser mais do que a descrição sucinta (no máximo três frases) de uma funcionalidade da aplicação.
Servem essencialmente para estimar o tempo de implementação, atribuição de prioridades no desenvolvimento e como guias para a elaboração dos testes de aceitação.
A minha abordagem
User Stories Cards
Criei cartões 8 x 8cm de três cores distintas por forma a lidar com as prioridades:
- Vermelho = Alta – Quanto todas as tarefas deste tipo estiverem implementadas é lançada uma major version2
- Amarelo = Média – A implementação de todas a funcionalidades deste tipo conduzem ao lançamento de uma minor version
- Verde = Baixa – A implementação de todas as funcionalidades culmina com o lançamento de uma maintenance version
O cliente usará um lado do cartão para descrever a funcionalidade que pretende ver implementada, sendo o outro usado por mim para anotações que complementem a informação inscrita pelo cliente.
Após a implementação o cartão é datado e assinado pelo programador.
Desta forma tenho uma boa base para planear o(s) lançamento(s), bem como estabelecer os testes de aceitação.
Embora não o tenha feito, parece-me interessante seriar as várias categorias de cartões para uma mais fácil referência ao longo do processo de documentação.
Architectural Spike / Spike
Numa análise inicial do projecto devem identificar-se os pontos críticos na implementação do mesmo. Identificados que estejam, a produção de um protótipo3 será uma mais valia para, entre programadores, se encontrar a solução ideal.
Muitas vezes, ao tentarmos expor uma ideia, o nosso discurso conduz a interpretações várias. O mesmo não acontece quando a mesma ideia é apresentada em forma de algoritmo. Qualquer programador a quem seja dado a analisar perceberá inequivocamente o seu intuito e daí poderá partir para a resolução do problema.
Nada obriga a que estes protótipos sejam desenvolvidos com recurso às mesmas tecnologias a usar no desenvolvimento da aplicação.
A minha abordagem
Sempre que identifico um ponto crítico no desenvolvimento, isolo-o e desenvolvo um protótipo de baixa fidelidade.
Este será codificado na linguagem que me garantir um tempo de estudo/implementação mais baixo.
Existem linguagens com características óptimas para a Prototipagem de Software que devem ser tidas em consideração nestes casos.
Release Planning
O compromisso “tempo de produção” é talvez, dos mais difíceis de tomar. Assim, numa reunião com todas as partes envolvidas, deve ser estipulado um calendário de desenvolvimento que todos possam cumprir.
Com base nas User Stories e no tempo estimado de implementação de cada uma, deve ser estimado o tempo total de desenvolvimento em semanas ideais de trabalho. Uma semana ideal representará o tempo necessário para implementar uma determinada user story não tendo absolutamente mais nada para fazer: sem dependências, sem trabalhos extra mas incluindo testes.
Relativamente ao desenvolvimento, no período compreendido entre o início dos trabalhos e a data estipulada para o lançamento da primeira versão, devem ser implementadas todas as funcionalidades identificadas como prioritárias.
Nestas condições o planeamento pode ser feito por:
- tempo: quantas user stories podem ser implementadas antes de uma determinada data;
O número de user stories que podem ser completadas nesse período de tempo é obtido multiplicado o número de iterações pela velocidade do projecto4. - metas/objectivos: quanto tempo determinado conjunto de user stories demoram a implementar;
O número de iterações é obtido pelo quociente entre a número de user stories e a velocidade do projecto.
O tempo de desenvolvimento nunca deve ser subestimado, na certeza que nestas condições causará problemas no futuro. Deve sim ser negociado entre as partes: client(es), programador(es), gestor(es) e outros.
The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.
A minha abordagem
A cada user story atribuo o tempo estimado para implementação que é anotado no verso do cartão. Esta estimativa é feita em “dias ideais”, ou seja, um dia útil (de Segunda a Sexta Feira) excepto feriados de calendário (não incluídas festas religiosas) que corresponderá a oito horas de trabalho.
Um simples somatório resultará numa estimativa da duração de desenvolvimento que é ainda alvo de ajustes para prevenir imprevistos. Este ajuste nunca prolongam o período de desenvolvimento por mais de dez dias úteis.
De acordo com a prioridade atribuída a cada user story (pelo sistema de cores), o lançamento da primeira versão corresponderá à implementação de todas as funcionalidades cuja prioridade foi considerada Alta (cartões vermelhos).
Iteration
asdasdasd
Small Releases
The development team needs to release iterative versions of the system to the customers often. The release planning meeting is used to discover small units of functionality that make good business sense and can be released into the customer’s environment early in the project. This is critical to getting valuable feedback in time to have an impact on the system’s development. The longer you wait to introduce an important feature to the system’s users the less time you will have to fix it.
Acceptance Tests
A cada user story está associado um conjunto de teste de aceitação com o intuito de aferirem a exactidão da implementação. O cliente assiste à realização destes testes decidindo quais não cumprem os requisitos. É estabelecida uma ordem de prioridade para correcção das falhas detectadas.
Na metodologia eXtreme Programming a existência de um departamento de QA é imperativa o qual deve trabalhar em estrita colaboração com a equipa de desenvolvimento.
Determinada user story considera-se completamente implementada quando passa todos os testes de aceitação.
A minha abordagem
Quando a equipa de desenvolvimento se resume a um programador, muitas das etapas aqui enumeradas são descartadas e normalmente os testes de aceitação são realizados em paralelo com o desenvolvimento.
Sempre que o enquadramento humano o permite e para projectos de pequena/média dimensão, existe um responsável de QA. Regra geral um indivíduo com conhecimentos básicos em TI com boa capacidade oral e escrita, capaz de produzir relatórios sucintos, em linguagem não técnica, das falhas detectadas aquando da realização dos testes de aceitação.
1 O diagrama é interactivo, encontrando-se as ligações sinalizadas com uma lupa.
2 Este esquema tem como base o processo designado por Software Versioning.
3 Recomendo a leitura da entrada Prototipagem e Prototipagem de Software na Wikipedia, onde é abordada a vertente na Engenharia de Software.
4 http://www.extremeprogramming.org/rules/velocity.html
[...] This post was mentioned on Twitter by planetgeek. planetgeek said: Paulo Silva: eXtreme Programming http://bit.ly/coqGqq [...]