Este documento é um manual de utilização da ferramenta Agile. Esta ferramenta tem como objectivo a gestão de equipas utilizando a metodologia eXtreme Programming.
A ferramenta baseia-se num princípio de proximidade com o ambiente de desenvolvimento. Todas as funções de planeamento, submissão de horas de trabalho, e monitorização do plano são feitas no Eclipse IDE.
Nesta secção apresenta-se uma breve descrição dos conceitos utilizados na ferramenta Agile.
Projecto. Um projecto é composto por releases. Cada uma dessas releases está associada a um equipa responsável pela sua execução. Os projectos têm data de início definida, mas não têm um fim definido.
Equipa. Uma equipa é constituída por um conjunto de membros. Esses membros implementam tarefas no contexto de um plano de execução composto por releases e iterações.
Release. Uma release corresponde a um deliverable, ou seja, um produto entregue ao cliente. As releases são executadas num período de tempo fixo, e não deve haver sobreposição temporal entre releases da mesma equipa. Numa release implementam-se histórias, que representam os requisitos a incluir no deliverable.
Num projecto com mais de uma equipa existirá uma sequência de releases por cada equipa. Por norma, estas sequências são temporalmente paralelas, ou seja, cada uma das releases da sequência deve começar e terminar ao mesmo tempo que nas outras equipas.
Iteração. Uma iteração corresponde a um ciclo de desenvolvimento mais curto, com visibilidade apenas para os membros da equipa, não correspondendo a nenhum objectivo de negócio. Numa release executam-se várias iterações. Estas são também definidas por um período de tempo, sem sobreposição no contexto da mesma release.
Velocidade. A velocidade corresponde ao número de horas de histórias que uma equipa consegue implementar numa release ou iteração de duração fixa.
História. Uma história corresponde a um requisito a cumprir. A cada história está associada uma estimativa em horas para a cumprimento desse requisito. As histórias podem ser de três tipos:
Além do tipo, as histórias podem também ser categorizadas em função sua prioridade, valor e risco. Finalmente, as histórias podem ou não estar associadas a um theme.
Durante a implementação de um projecto a história passa por um conjunto de estados, a saber:
Theme. Os themes são tipos de histórias mas no contexto do projecto. Geralmente o theme é usado para categorizar as histórias nos módulos do projecto no qual se inserem, por exemplo, 'Módulo de Gestão de Vendas', Módulo de 'Gestão de Stocks', etc.
Tarefa. Uma tarefa corresponde a um passo na implementação de uma história. Uma história é geralmente composta por várias tarefas. Cada tarefa tem também uma estimativa em horas. As tarefas são apenas categorizadas em função da sua prioridade e do tipo, havendo no entanto um maior numero de tipos de tarefas, a saber:
As tarefas, tal como as histórias passam também por um conjunto de estados:
Para instalar a ferramenta Agile é necessário proceder previamente à instalação do seguinte software:
Para instalar o Mylyn 2.3.x seguir os seguintes passos:
Instalado o Mylyn, o próximo passo é instalar a ferramenta Agile:
Importante: A ferramenta assume a disponibilidade da ligação com o servidor pelo que não é possível trabalhar offline para a maior parte das operações.
O repositório representa uma ligação a um servidor que contém o projecto, a sua equipa e o seu plano de execução, bem como todos os dados referentes ao processo de monitorização (tracking) do plano. Essa ligação tem associado um utilizador que se diz estar 'em sessão'. Esta informação é usada automaticamente em vários contextos que serão descritos mais à frente.
1 Nota: Caso a vista de projectos apresente um erro ao carregar, reinicie o Eclipse com a perspectiva 'Planning' aberta. Na prática o que é necessário é que umas das vistas do plugin Mylyn esteja aberta quando o Eclipse inicia: 'Task List' ou 'Task Repositories', qualquer que seja a perspectiva.
Nesta secção descrevem-se alguns aspectos gerais da interface de utilizador. A interacção com a ferramenta organiza-se em duas perspectivas, a perspectiva 'Planning' e a perspectiva de 'Java' ou 'Java EE' (dependendo do tipo de projectos).
A perspectiva 'Planning' tem como objectivo suportar as operações de criação de histórias e tarefas, bem como o seu planeamento. Na perspectiva de Java, já existente, apenas se acrescenta a vista 'Task List' que contém as tarefas a implementar pelo utilizador em sessão.
A perspectiva 'Planning' é composta pelas seguintes vistas: 'Planning', 'Task List', e 'Task Repositories'.
A vista 'Projects' mostra os vários projectos (apenas um no contexto do projecto de Sistemas Distribuídos e Engenharia de Software) a que o utilizador que está em sessão está associado. Não havendo repositório configurado esta vista não tem nada para mostrar, e não permite criar nada.
Um projecto estará associado a um utilizador (e, consequentemente, visível na vista Projects) se esse utilizador for membro de pelo menos uma das equipas do projecto. Nesta vista considera-se que os projectos são compostos por equipas, as equipas por releases, e as releases por iterações.
Na parte superior da vista estão os projectos e os seus sub-elementos até ao nível da iteração, na parte inferior estarão as histórias e tarefas associadas ao elemento seleccionado na parte superior.
A vista 'Task List' mostra as tarefas para o utilizador em sessão. As tarefas presentes nesta vista, ou foram criadas pelo utilizador em sessão, ou foram importadas do servidor através de uma Query. O mecanismo de Queries, e os restantes detalhes de utilização desta vista serão detalhados mais à frente.
Além das vistas descritas, a ferramenta disponibiliza um editor para cada um dos principais elementos utilizados, nomeadamente: projectos, equipas, releases, iterações, histórias, e tarefas. Estes editores têm vários aspectos comuns que serão aqui descritos. A figura seguinte mostra um exemplo de editor de uma iteração.
Neste exemplo foram identificadas e numeradas as funcionalidades que são comuns. Segue-se uma descrição de cada uma:
2 Se uma release/iteração tiver histórias estas deixam de estar associadas à release/iteração, mas mantêm a sua ligação ao projecto.
Por omissão, cada grupo terá já criados um projecto e uma equipa com todos os elementos do grupo. A ferramenta permite a criação de mais equipas e a redistribuição dos membros. Para criar uma nova equipa usar o menu de contexto: New > Team no projecto na vista 'Projects', ou usar a acção 'New Team' na toolbar do editor do projecto. Na criação da equipa deve apenas ser inserido o nome da mesma.
Para gerir os membros da equipa, abrir o editor da nova equipa na tab 'Members'. Em cima estão os membros da equipa, em baixo estão os membros de outras equipas do mesmo projecto. Note-se que o utilizador que criou a equipa é automaticamente adicionado à lista de membros, é também ele o único que pode editar os seus membros. Arrastar elementos entre as duas tabelas insere, ou retira membros da equipa, as alterações só serão submetidas para o servidor após a acção de 'Save'3. Note-se ainda que adicionar elementos a uma equipa não dissocia esses elementos de outras equipas. Um utilizador pode sempre estar em mais do que uma equipa.
Um cenário típico será um grupo que quer dividir o trabalho em duas equipas. Dado que a equipa criada por omissão não pode ser alterada, deverão ser criadas duas novas equipas, metade dos elementos inseridos numa, e a outra metade inserida noutra. As releases deverão ser criadas nas duas equipas novas, a equipa com todos os elementos do grupo pode ser deixada vazia.
A figura seguinte mostra o estado final do cenário descrito.
3 A coluna 'Teams' não se actualiza mesmo após o 'Save'. Se se fechar e voltar a abrir o editor a coluna já se encontrará actualizada.
O planeamento é feito a dois níveis: release e iteração. Em ambos o conceito fundamental é o de velocidade. O objectivo é planear histórias até a soma das suas estimativas estar próxima da velocidade da equipa na release/iteração em planeamento. Para isso é preciso criar previamente as histórias, a secção seguinte descreve o processo de criação das mesmas.
No caso mais usual as histórias são criadas no contexto do projecto (através do menu de contexto New > Story da vista Projects, ou na toolbar do editor do projecto).
Na criação de uma história deve-se indicar um nome para a história e a sua descrição. A descrição deve ser a descrição de um caso de uso. A história criada fica automaticamente visível na área inferior da vista 'Projects'. Os restantes detalhes da história são inseridos no editor da mesma. Neste editor, apresentado na figura seguinte deve-se indicar:
O cliente não é importante no contexto do projecto de ES+SD.
O processo de planeamento começa com a criação de uma release. A release é criada para uma equipa, logo, o acesso ao wizard de criação é feito pelo menu de contexto da equipa, ou pelo editor da mesma. Além do nome e descrição, a equipa precisa de definir o período de duração da release.
O release planning é uma actividade bastante simples executada na tab 'Planning' do editor da release. A figura seguinte mostra o editor de uma release de exemplo.
No topo temos uma barra de progresso que indica o valor actual da soma das estimativas das histórias contra um máximo que corresponde á velocidade estimada para esta release. A tabela superior ('Planned Stories') contém as histórias planeadas para a release, a inferior ('Unplanned Stories') contém as histórias do projecto ainda não planeadas em nenhuma release. Para planear uma história para a release corrente, deve-se seleccionar a história na área 'Unplanned Stories' e arrastar para a área 'Planned Stories'. Automaticamente as horas estimadas para a release aumentam. O objectivo será planear histórias na release até que a barra de progresso se aproxime do máximo, ou seja, a soma das estimativas está próxima da velocidade. Mais uma vez, como em todos os editores as alterações serão submetidas após a acção de 'Save'.
É preciso notar, no entanto, que na primeira release, esta velocidade é um valor por omissão, e portanto a barra de progresso é tornada inútil, devendo o planeamento ser efectuado apenas com base no bom senso da equipa. As releases seguintes, se as houver já beneficiarão desta informação dado que a velocidade nesse caso já será baseada em valores medidos anteriormente.
O processo de planeamento da iteração começa com a criação da iteração. A iteração é criada sob uma release, e deve ser definida com um período de duração contido na duração da release a que pertence.
O iteration planning consiste num processo equivalente ao do release planning com um passo extra de criação e atribuição das tarefas de cada história. Existe uma tab 'Planning' do editor da iteração que deve usado para planear histórias na iteração em edição. Nesse ecrã a tabelas de baixo ('Unplanned Stories') contêm apenas as histórias planeadas para a release da qual a iteração faz parte, excepto as já planeadas noutra iteração da mesma release.
Tal como no release planning também são válidas as limitações no planeamento da primeira iteração.
Para criar as tarefas pode-se usar o menu de contexto na parte inferior da vista Projects, ou usar a toolbar do editor de uma história facilmente acessível por um duplo-clique no história no ecrã de planeamento.
Ao contrário dos restantes a criação de tarefas não passa por um wizard, é imediatamente aberto um editor. Nesse editor além do nome e de uma descrição da tarefa, que deve incluir uma descrição dos passos a cumprir, existem algumas propriedades que devem ser preenchidas, nomeadamente:
Outros dados da tarefa são apenas locais, e servem apenas para o gestão pessoal do utilizador em sessão. A propriedade 'Category' permite ``arrumar'' as tarefas na vista 'Task List' por categorias, a propriedade 'Scheduled For' permite planear a tarefa para um dia em particular (entre os vários dias no período da iteração), as questões de planeamento pessoal serão discutidas mais à frente.
A atribuição da tarefa a um dos membros da equipa é feita no editor da tarefa na secção 'People'. Pode ser feito logo na criação da tarefa, ou abrindo o editor posteriormente à criação. Os possíveis contemplados para a atribuição da tarefa são os membros da equipa que contém a release, que contém a iteração, que contém a história à qual a tarefa pertence. A atribuição serve principalmente para limitar a visibilidade da tarefa na vista 'Task List', sendo que cada utilizador apenas vê as tarefas que lhe estão atribuidas, além daquelas que criou.
A principal diferença entre a ferramenta Agile e as restantes ferramentas de apoio à gestão de projecto consiste na forma como se submete as horas de trabalho nas tarefas. As tarefas são activadas quando se começa a cumprir a tarefa, e desactivadas no final.
Para este efeito a vista 'Task List' deve estar facilmente acessível quando o programador está a desenvolver o projecto, aconselha-se a colocação da vista numa das laterais do workspace ou em 'fast view'. (Provavelmente a vista já se encontrará aberta no workspace). Para começar uma tarefa o programador deve usar o menu de contexto na tarefa que pretende activar e seleccionar a opção 'Activate'. Para terminar a sessão de trabalho usar o mesmo menu de contexto e seleccionar a opção 'Deactivate', ou simplesmente fechar o Eclipse.
O tempo gasto na tarefa é automaticamente medido e submetido para o servidor, é possível no entanto fazer correcções a este tempo, especialmente útil para tarefas desenvolvidas fora do Eclipse. Para acrescentar horas (ou minutos) de trabalho a uma tarefa começa-se por abrir o editor da tarefa, e na secção 'Actions' preencher as horas e minutos que se pretende somar ao tempo medido, após o carregar em 'Submit' esta informação é publicada no servidor.
Importante: O tempo submetido é apenas referente ao dia corrente, o que implica que esta submissão seja feita diariamente. Se por exemplo num dia se submeterem mais 2 horas além das 3 medidas pelo sistema, no dia seguinte ambos os valores de 'Today's measured Work' e 'Today's extra Work' voltam a zero. No entanto, durante o dia o valor do trabalho extra mantem-se o mesmo e pode sempre ser alterado.
Quando a tarefa estiver terminada, o programador deve marcá-la como tal, para isso abrindo o editor da mesma seleccionar a opção 'Mark as Completed' na secção 'Actions' e carregar no botão de 'Submit'.
A vista 'Task List' é organizada através de Queries. Sem a utilização de Queries cada utilizador apenas veria as tarefas que criou, através deste mecanismo torna-se possível o utilizador fazer um 'download' de mais tarefas de acordo com alguns parâmetros. Cada utilizador deve ter pelo menos um Query que importe todas a tarefas que lhe estão atribuídas. Para tal usar o menu de contexto na 'Task List' e seleccionar a opção New > Query..., no ecrã resultante escolher o repositório do tipo Agile que definiu previamente e prima 'Next'. A figura seguinte mostra o passo seguinte do wizard de criação de uma query.
No campo 'Name' o utilizador deve colocar o nome da query (o qual será usado no nome da pasta na 'Task List' que conterá as tarefas resultantes da Query).
Os restantes campos são filtros nos tipos de tarefa. O filtro 'Task Type' permite mostrar apenas as tarefas dos tipos seleccionados, Os filtros 'Tasks from Stories of Type' e 'Tasks from Stories with Theme' permite mostrar apenas tarefas que pertençam a histórias dos tipos, ou themes seleccionados, respectivamente. Nestes três filtros existe sempre uma opção sem texto na lista, esta opção inclui, ou exclui, as tarefas que não tenham a propriedade filtrada preenchida.
Qualquer Query, independentemente dos filtros definidos mostrará sempre apenas as tarefas da iteração corrente e a atribuídas ao utilizador em sessão.
As funções de tracking são o contributo principal da ferramenta. Através da informação produzida pela ferramenta a equipa consegue perceber e medir o atraso (ou avanço) em relação ao plano.
O tracking é feito a dois níveis: release, e iteração; resumidamente, o tracking consiste em confrontar um trabalho restante esperado (estimado com base na velocidade da equipa) com um trabalho restante real (calculado pela diferença entre a velocidade e as horas já gastas).
Em detalhe, o trabalho restante esperado é calculado da seguinte forma:
Quanto ao trabalho restante real, calcula-se pela diferença entre o total de horas estimadas e o total das horas de trabalho realizado, ou seja:
em que o total de horas estimadas é calculado pela soma, para cada história, dos máximos entre a duração estimada da história e a soma das estimativas das tarefas dessa história, ou seja:
Tomemos como exemplo uma iteração de 10 dias úteis, com uma equipa capaz de uma velocidade de 40 horas. Nesta iteração foram planeadas 4 histórias de 10 horas cada. Vamos supor que ao fim de 5 dias de trabalho tinham sido cumpridas por toda a equipa 16 horas (não interessa em que histórias ou tarefas). O tracking mostrado pela ferramenta encontra-se na figura seguinte.
Estes números foram obtidos da seguinte forma: o trabalho restante esperado é
calculado por 
; o trabalho restante real é
calculado por: 
. Com esta informação percebemos que a equipa já
deveria ter reportado mais 4 horas do que de facto reportou. Antes de se
considerarem as medidas a tomar é importante perceber alguns pressupostos que
devem ser tidos em conta ao interpretar os resultados. Em primeiro lugar a
velocidade é uma estimativa, pode não ser exactamente igual ao numero de horas
que a equipa irá gastar nesta iteração em particular; mais ainda, nas
primeiras iterações de uma equipa recém formada este valor pode estar
consideravelmente longe da realidade, visto que foi estimada sem dados
concretos do passado. Estes valores assumem também que a equipa como um todo
trabalha o mesmo número de horas por dia, isto pode não ser verdade quando a
equipa não trabalha em full-time no projecto. Finalmente, quanto ao cálculo do
trabalho restante real, o facto de ser calculado pela diferença de uma
estimativa e um valor real, assume que a estimativa está sempre actualizada
com as expectativas da equipa, ou seja, se numa tarefa de 10 horas a equipa já
gastou 8h mas pensa ainda precisar de mais 5 (em vez de 2), então deve
actualizar a estimativa dessa tarefa para as 13 horas4.
O desvio pode ter várias causas, cada causa será apresentada com um cenário e as medidas a tomar para resolver o desvio.
Estimativa Errada. A causa mais frequente será muito provavelmente uma estimativa inicial irreal. Assumindo que a equipa mantém a estimativa das tarefas de acordo com a estimativa de trabalho restante, apesar de as horas gastas continuarem a incrementar em conformidade com a velocidade da equipa, o trabalho restante real não diminui em igual proporção. Por exemplo, num cenário em que a velocidade por dia útil é de 20 horas, uma equipa cumpre as 20 horas de trabalho, no entanto aumenta a estimativa das tarefas em que trabalhou num total de 6 horas, logo, o trabalho restante desce apenas 14 horas em vez das potenciais 20. Em resposta a este desvio a equipa deve assumir que não cumprirá com o plano inicial e delegar trabalho para a iteração seguinte.
Má distribuição diária do tempo. Num determinado dia da iteração, a equipa pode trabalhar mais (ou menos) horas do que a velocidade diária, isto ocorre porque a equipa tem outras tarefas além deste projecto ou porque um dos elementos não trabalhou nesse dia, ou outros motivos, qualquer que ele seja o tracking indicará sempre um desvio. Cabe à equipa perceber se esse desvio será corrigido em breve, ou se deverão ser tomadas medidas mais drásticas para o corrigir, replaneando a iteração. Por exemplo no caso de uma equipa de alunos que tem uma avaliação na terça-feira pode assumir um compromisso de trabalhar menos horas na segunda e compensar após a avaliação. É no entanto importante notar que se assume uma distribuição homogénea do tempo pelos dias por um motivo: deixar tudo para o final pode comprometer o cumprimento da iteração.
Replanear implica tirar ou acrescentar horas de trabalho a uma iteração. Existem três acções possíveis: acrescentar histórias, retirar histórias, ou partir uma história e retirar uma das partes. Em qualquer dos casos uma regra deve ser sempre mantida, só se pode replanear elementos que ainda não tenham sido iniciados, ou seja, elementos que ainda não estejam no estado Implementation ou posterior. Se possível, o replaneamento deve ser feito com recurso a mover uma ou mais histórias inteiras. Caso já estejam todas iniciadas, então o replaneamento deve ser conseguido apagando uma ou mais tarefas de uma história, e criando outra história na iteração seguinte com uma cópia dessas tarefas.
4 A estimativa da história que contém a tarefa em causa deve ser mantida, isto não afecta o tracking porque é usado o máximo entre a estimativa da história e da soma das tarefas, mas ao mesmo tempo permite comparar a estimativa inicial com a actual.
Data: 2008/04/09 13:33:53