#+TITLE:     Manual de Utilização da ferramenta Agile
#+AUTHOR:    
#+EMAIL:     
#+LANGUAGE:  pt
#+OPTIONS:   H:4 num:t toc:2 \n:nil @:t ::t |:t ^:t f:t *:t TeX:t LaTeX:t skip:nil p:nil
smf: rever as minhas notas dadas ao Pedro!
* Introdução

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.

** Características Principais

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.

* Conceitos

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:

 + Feature - Um requisito novo;
 + Bug - Resolução de um bug;
 + Enhancement - Melhoramento ou extensão de um requisito já implementado.

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:
 + Proposed - Criada mas ainda não planeada numa iteração;
 + Planned - Planeada numa iteração;
 + Implementation - Pelo menos uma das tarefas que compõem a
  história já foi iniciada;
 + Completed - Todas as tarefas que compõem a história estão
  terminadas.

*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:
 + Code - Tarefa de codificação simples;
 + Refactor - Tarefa de refactorização de código;
 + Documentation - Tarefa de documentação ou de modelação, que pode
  incluir definir requisitos, descrever casos de uso ou outros modelos
  UML, ou ainda documentação técnica e de utilização da funcionalidade
  a implementar.
 + Research - O cumprimento de uma tarefa pode implicar a pesquisa
  de informação, tarefas deste tipo podem ser usadas para submeter
  trabalho neste tipo de actividade.
 + Test - Testes de integração ou outros, excepto testes unitários,
  cujo esforço já deve ser incluído nas tarefas de codificação ou
  refactorização.

As tarefas, tal como as histórias passam também por um conjunto de
estados:
 + Proposed - Criada mas não atribuída;
 + Assigned - Atribuída a um membro da equipa, mas não iniciada;
 + Implementation - Tarefa com trabalho reportado;
 + Completed - Tarefa marcada como terminada.

* Instalação e Configuração da Ferramenta

** Requisitos

Para instalar a ferramenta Agile é necessário proceder previamente à
instalação do seguinte software:
 + Eclipse 3.3
 + Mylyn 2.3.x [[http://www.eclipse.org/mylyn]]

** Procedimento de Instalação

Para instalar o Mylyn 2.3.x seguir os seguintes passos:
 + No eclipse aceder ao menu Help > Software Updates > Find and
  Install;
 + Escolher a opção 'Search for new features to install';
 + Escolher o site Mylyn e carregar no botão Finish;
 + Seleccionar todas as features propostas e instalar.

Instalado o Mylyn, o próximo passo é instalar a ferramenta Agile:
 + No eclipse aceder ao menu Help > Software Updates > Find and
  Install;
 + Escolher a opção 'Search for new features to install';
 + Através da opção 'New Remote Site...', adicionar o seguinte
  update site: [[http://disciplinas.ist.utl.pt/leic-es/agile]]. (O nome identificador é
  irrelevante);
 + Seleccionar o update site criado e carregar no botão 'Finish';
 + Seleccionar todas as features propostas e instalar.

* Configuração

 + Abrir a perspectiva 'Planning'[1]

 + Criar um repositório do tipo Agile Na vista 'Task Repositories',
  seleccionar, no menu de contexto, a opção 'Add Task Repository' e
  escolher o tipo de repositório Agile.  Na janela que fica disponível,
  preencher os campos de acordo com a figura seguinte, substituindo o
  User ID pelo seu numero de aluno e a password pela password que lhe
  foi entregue pelo corpo docente.

[[file:images/new-repository.png]]

/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.


* Descrição Geral da Interface

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'.

** Vista Projects

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.

** Vista Task List

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.

** Editores

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.

[[file:images/common.png]]

Neste exemplo foram identificadas e numeradas as funcionalidades que
são comuns. Segue-se uma descrição de cada uma:
 1. Toolbar: Nesta barra de ferramentas existe um conjunto de
  operações comuns e algumas específicas do tipo de editor aberto. As
  comuns são:
   - Delete - permite apagar o elemento e todos os elementos
    dependentes. O conceito de 'dependente' é bastante intuitivo, na
    prática considera-se que todos elementos abaixo na árvore da vista
    'Projects', são dependentes. Se por exemplo se apagar uma equipa,
    as suas releases e iterações serão também apagadas (mas não os
    membros, ou as histórias)[2]. Além disto, falta referir que nenhum
    elemento pode ser apagado se já tiver sido iniciado, ou seja, uma
    tarefa na qual já tenha sido reportado trabalho, não pode ser
    apagada.
   - Save - grava as alterações no servidor, esta operação é
    equivalente à acção global de 'Save' de um editor que por omissão
    está associada ao 'ctrl+s'.
   - Para além destas duas acções existem acções de criação de
    sub-elementos, nomeadamente, no editor de projectos a toolbar
    permite a criação de histórias e equipas, no editor de equipas
    permite-se a criação de releases, no editor de releases permite-se
    a criação de iterações e assim sucessivamente.
 2. Nome: Aqui pode-se editar o nome do elemento, o nome deve
  ser único para elementos do mesmo tipo e no contexto em que está
  inserido. Permite-se, por exemplo, que duas iterações de releases
  diferentes tenham o mesmo nome.
 3. Owner: O owner é a pessoa responsável pelo elemento, e a
  única com permissões para o apagar.
 4. Esta área apresenta informação não editável sobre o
  elemento. Comum a todos existe um ID único, uma data de criação e a
  data da última modificação. Para as tarefas existe também o estado e
  a prioridade.
 5. Path: Aqui são mostrados um conjunto de links que permitem
  abrir os editores dos elementos ao qual o item pertence.
 6. Description: A descrição é um texto livre que descreve o
  elemento, no caso da história este campo é especialmente relevante
  porque é aqui que se descreve a funcionalidade a implementar.
 7. Comments: Esta secção é um pequeno e rudimentar fórum de
  discussão associado ao elemento. No caso de histórias e tarefas pode
  ser um importante elemento de comunicação entre os elementos da
  equipa.

[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.

* Gestão  de Equipas

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.

[[file:images/team-management.png]]

[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.

* Planeamento

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.

** Criação de Histórias

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:
 + A estimativa (em horas) para a implementação da história,
  incluindo testes unitários;
 + O tipo de história;
 + O 'theme' se existir;
 + A prioridade, risco, e valor;

O cliente não é importante no contexto do projecto de ES+SD.

[[file:images/story-editor.png]]

** Release Planning

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.

[[file:images/release-planning.png]]

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.

** Iteration Planning

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.

** Criação de Tarefas

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:
 + A prioridade;
 + O tipo;
 + A estimativa.

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.

** Atribuição de Tarefas

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.

* Execução do Plano

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'.

** Visibilidade das Tarefas

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.

[[file:images/query.png]]

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.

* Tracking

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:

$velocidade \times \frac{numero\ de\ dias\ uteis\ ate\ ao\ fim\ da\
iteracao}{numero\ de\ dias\ uteis\ da\ iteracao}$

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:

$total\ de\ horas\ estimadas - \sum_{tarefa} tarefa.horas$

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:

$\sum_{historia} max(historia.estimativa, \sum_{historia.tarefa}
tarefa.estimativa))$

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.

[[file:images/iteration-tracking.png]]

Estes números foram obtidos da seguinte forma: o trabalho restante esperado é
calculado por $40\times\frac{5}{10} = 20$; o trabalho restante real é
calculado por: $40 - 16 = 24$. 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 horas[4].

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.

** Políticas de replaneamento

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, no
estado /Implementation/ ou posterior (smf: não é anterior?!). Se possível, o
replaneamento deve ser feito com recurso a mover uma ou mais histórias
inteiras, caso não haja nenhuma ainda não iniciada (smf: refrasear), 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.