XPManager - Gerência de Projetos de Software
Gerência de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atingir os requisitos do mesmo. A gerência eficaz de projetos é conseguida através do uso de processos, tais como: iniciar, planejar, executar, controlar e encerrar (PMI, 2000). Esta é a premissa tradicional de gerência de projetos, dentro de uma técnica bastante utilizada atualmente, a PMI.
A PMI foi desenvolvida pelo Project Management Institute, uma entidade internacional sem fins lucrativos que congrega profissionais que atuam em áreas relacionadas à gerencia de projetos (MARTINS, 2002). Ela é bastante aceita dentro da gerência tradicional de projetos, uma vez que trata do ciclo de vida do projeto da maneira pela qual ele é visto pelas principais metodologias de desenvolvimento, com suas fases bem definidas. No caso da XP, estas fases não estão distribuídas de maneira tão clara, como a que a PMI se propõe a controlar, mas sim difusas dentro de todo o projeto.
A gerência é um item fundamental
dentro de um projeto de software, e deve estar presente durante todo o ciclo de vida do desenvolvimento de um sistema.
A XP, como qualquer outra metodologia de desenvolvimento, precisa de gerenciamento. Por outro lado, prezando sempre
a simplicidade e a comunicação, não pode ser gerenciada da mesma maneira que as metodologias
tradicionais de desenvolvimento. Neste capítulo tratar-se-á de gerência de projetos, mais especificamente,
sobre a gerência em XP.
A figura 1 mostra um projeto típico de XP, onde o centro é o planejamento de releases, feito durante o planning game, e o acompanhamento do release plan, testes de aceitação e velocidade de desenvolvimento, que geram as métricas de velocidade e qualidade do projeto.
Figura 1: Projeto XP
As
quatro variáveis
de um sistema
Na Extreme Programming, são consideradas
quatro as variáveis que estão presentes no desenvolvimento de um projeto: custo, tempo, qualidade
e escopo (BECK,
2000). O planejamento dentro da XP é feito
sempre da mesma maneira: as “forças externas” (clientes e gerentes) escolhem o valor de três destas
variáveis, e a equipe de desenvolvimento projeta o valor conseqüente da quarta variável.
A distribuição é
feita desta forma a fim de evitar que o projeto se torne um “projeto virtualmente impossível”, como os descritos
por Edward Yourdon em seu livro Death March (YOURDON,
1999). Se o cliente decide, por exemplo, em ter
um projeto com o menor custo, no menor prazo e com a qualidade máxima, a quarta variável, neste caso
escopo, deve ser definida de acordo pela equipe de desenvolvimento, ficando neste exemplo bastante prejudicada.
Interação
entre as variáveis
É muito difícil encontrar
uma relação ideal entre o peso de cada variável, sendo que
a redução nos valores aceitáveis
de uma nem sempre causam a mesma variação positiva em outra.
•Custo – poucos recursos para um projeto podem trazer sérios prejuízos
para as demais variáveis, pois com um orçamento muito apertado normalmente não se consegue
contar com a equipe que se gostaria, e isto pode trazer problemas para a efetiva resolução do problema
do cliente.
•Tempo – um prazo maior para a entrega final do sistema aumenta a qualidade
e o escopo do mesmo, dentro de um limite. Por outro lado, caso o prazo seja muito pequeno, prejudica-se o escopo
da aplicação.
•Qualidade – Pode-se ter
ganhos pequenos (dias ou semanas) sacrificando
a qualidade em alguns pontos do projeto, como por exemplo definindo-se um número menor de unit tests para
uma classe, a fim de poupar tempo de programação. Contudo, esta prática não é
recomendável, pois este ganho tende a desaparecer na medida em que a baixa qualidade pode causar problemas
que tomarão tempo para serem corrigidos.
•Escopo – um escopo menor pode melhorar a qualidade, pois se tem menos tarefas
para serem desenvolvidas, e também reduz o prazo e o custo.
As variáveis
custo e tempo normalmente são decisão
do cliente, pois é dele a decisão sobre quando precisa do sistema implementado e qual o valor que
está disposto a pagar por isto. A variável qualidade não deve ser sacrificada. Portanto, normalmente
a variável sobre a qual a equipe de desenvolvimento acaba tendo o controle é sobre o escopo. Isto
deve ficar claro desde o início do projeto, tanto para o cliente quanto para o desenvolvedor.
Habitualmente, as ferramentas e metodologias
de controle de projeto focam apenas nas três primeiras variáveis, pois partem do princípio
que um projeto de software é inteiramente definido em seu processo, logo o escopo não entra na questão
de controle.
Os
papéis de cada membro de uma equipe de XP
Para tornar possível o controle
de um projeto de XP, faz-se necessário conhecer os membros de uma equipe de desenvolvimento que utiliza
esta metodologia. É importante salientar que pessoas podem ocupar mais de um papel dentro da equipe, e que
como a modelagem, o projeto e o desenvolvimento são feitos por todos a todo instante, os papéis de
engenheiro de software e de analista de sistemas não existem neste tipo de equipe da maneira pela qual se
está acostumado a ver. Na verdade, na XP todos os desenvolvedores são também engenheiros e
analistas. Os papéis dentro da XP são:
•Customer – É quem define o sistema. O cliente é parte ativa
de uma equipe XP, pois ele deve estar a
todo momento fornecendo feedback sobre o desenvolvimento,
escrevendo Stories, testes de aceitação e sendo o responsável pela aprovação
do sistema, iteração por iteração. Também é função deste
membro da equipe decidir sobre prioridades e eventualmente decidir sobre redução no escopo da iteração
a fim de que a mesma seja entregue no prazo. Ocasionalmente este papel pode apresentar uma divisão, tendo
um membro exclusivamente destinado a executar e dar retorno sobre os testes de aceitação. Neste caso,
o mesmo é chamado de Acceptance Tester.
•Programmer – É o responsável por todo o planejamento, projeto
e implementação do sistema. Entre suas principais atribuições estão: fornecer
estimativas para as user stories, definir engeneering tasks
a partir das mesmas, estimar estas como se fossem
stories, implementar os unit tests, implementar o programa em si e assegurar que o mesmo seja aprovado em todos
os testes.
•Coach – É o responsável pelo gerenciamento da equipe.
Ele deve sempre motivar a equipe a não perder o foco, a não abandonar as técnicas e
deve auxiliar a equipe em tudo que for possível. Ele também é o responsável pela negociação
com o cliente quanto ao escopo de cada iteração e pela coordenação do planning game.
•Tracker – É o membro da equipe que faz o acompanhamento e medição
das tarefas sendo implementadas, sendo responsável pelas métricas. Ele deve coletar os dados e publicar
os resultados para toda a equipe e repassar qualquer
problema imediatamente para o coach.
Como foi dito anteriormente, estes papéis
muitas vezes são acumulados pela mesma pessoa dentro da equipe. No entanto, o recomendável é
que o tracker seja alguém que não tenha que estar demasiadamente envolvido na implementação
da solução. Este papel pode ser alternado, ficando a cada iteração com um membro diferente
da equipe.
Release
Plan
O Release Plan é o plano de desenvolvimento
gerado a partir das sessões de planning game. Neste plano estão definidas quais as stories farão
parte de cada iteração dentro da
release, qual o desenvolvedor responsável
por cada story e a estimativa de prazo.
Um termo importante dentro do planejamento
de projetos XP é velocity. A velocity é a relação entre funcionalidades entregues e
as funcionalidades planejadas por cada desenvolvedor. Para medir a velocity de cada desenvolvedor, deve ser feita
a medição em uma iteração. Se um desenvolvedor não teve tempo suficiente, seu
load factor foi
estimado muito baixo para aquele período. Por outro lado, se ele não teve tarefas suficientes seu
load factor estimado foi muito alto. Combinando o load factor
de todos os desenvolvedores se obtém a velocity.
Como a medição da velocity
requer que pelo menos uma iteração esteja concluída, o planejamento feito para a primeira
iteração é o mais sujeito a erros e não deve jamais servir como um compromisso de entrega
junto ao cliente.
A velocity deve estar sempre presente
no planejamento, pois na hora de realizar o planning game com o cliente, o coach deve multiplicar sempre a estimativa
dada pelos desenvolvedores pela velocity da equipe.
Métricas
Toda metodologia de desenvolvimento deve fornecer ao seu gerente condições para avaliar o andamento do projeto, através de medições de qualidade (tanto do produto quanto do processo de desenvolvimento) e prazos. Estas medições são conhecidas no desenvolvimento de sistemas como métricas. As métricas mais importantes na XP são:
•Velocity – Número de funcionalidades entregues comparado ao número de funcionalidades prometidas. O coach pode, durante o desenvolvimento de uma iteração, ir verificando o quão próximo do seu encerramento ela está, baseando-se na velocity de cada story. A XP prega que se deve sempre trabalhar baseado
na quantidade de dias gastos até o momento e na quantidade de dias que o desenvolvedor acha que ainda vai precisar, e não com percentual de compleição da tarefa.
•40
Hour Week – Quantidade de horas trabalhadas por
semana por desenvolvedor. Esta métrica é importante para medir a qualidade interna do trabalho, pois
como prega a XP trabalhar longos períodos por muito tempo é contraproducente.
•Test Coverage of the Code – Quantidade de Unit Tests por classe, também é uma métrica de qualidade interna de trabalho, pois serve para medir o quão testado está um sistema.
•Acceptance
Test Coverage – Quantidade de testes de aceitação do projeto como
um todo.
•Acceptance
Test Pass – Percentual de testes de aceitação aprovados para
cada iteração enviada, em relação ao total de testes de aceitação da
mesma.
•Relative Bug
Density – Quantidade de erros encontrados pelo usuário para cada
classe multiplicado pelo tempo que cada um levou para ser corrigido. Para fazer o cálculo, atribui-se
pontos para cada unidade de tempo gasta. Por exemplo, 1 ponto se for corrigido em até meia hora, dois pontos
se levar até 2 horas e quatro pontos por turno adicional de serviço, etc...
Baseado nestas métricas, o coach
pode ajustar a qualquer momento o projeto, tanto na questão de prazos e estimativas quanto no quesito de
qualidade, sugerindo um maior número de unit tests, por exemplo, se verificar que os indicadores Acceptance
Test Pass e Relative Bug Density começarem a demonstrar muitos problemas de qualidade.
Estas medidas são possíveis
graças ao caráter dinâmico da XP, onde o cliente pode fornecer feedback sobre o desenvolvimento
durante o mesmo, e não apenas após ter o produto final em suas mãos. Por este aspecto, e também
por suas características de ser fortemente calcado em testes, tanto unitários quanto de aceitação,
que a gerência de projetos em XP difere tanto da gerência tradicional.
Tracking
Tracking é o acompanhamento,
a medida das métricas dentro da metodologia XP. O tracker deve, uma ou duas vezes por semana, coletar os
dados relativos às métricas escolhidas para acompanhamento pelo coach e elaborar os gráficos
de medida correspondentes às mesmas.
Este trabalho deve ser o menos invasivo
possível, a fim de não burocratizar o processo de desenvolvimento e de não gerar perda de
produtividade por parte da equipe de desenvolvedores. Por este motivo, qualquer ferramenta que auxilie o tracker
na sua tarefa deve ser integrada ao dia-a-dia da equipe.
Considerações
Finais
Existem técnicas de gerência
de projeto para as mais diversas metodologias de desenvolvimento. Para a maioria delas, as técnicas são
comuns, uma vez que estas possuem fases bem definidas dentro do projeto.
A XP, pelas suas características,
precisa de uma gerência diferente de projetos, onde o seu caráter de planejamento contínuo
possa ser implementado, levando-se muito em conta o fator de ser uma metodologia que prega a informalidade do processo.
Qualquer metodologia de gerência de projetos que se queira aplicar à XP deve ser centrada nas user
stories, nos testes de aceitação e no tracking das métricas da XP.
Por estes motivos as técnicas
tradicionais de gerência de projetos, e conseqüentemente as ferramentas desenvolvidas para elas, como
é o caso do MS-Project, da Microsoft, não são adequadas para gerência
de projetos XP, uma vez que não prevêem a natureza dinâmica e as características de gerenciamento
da metodologia.