VSTS 2010

Ferramentas de planejamento Agile no Visual Studio Team System 2010

Ajoy Krishnamoorthy

Este artigo se baseia em uma versão de pré-lançamento do VSTS (Visual Studio Team System) 2010. Todas as informações nele contidas estão sujeitas a alterações.

Sumário

Planejamento de longo alcance
Planejamento de lançamento e de iteração
Pastas de trabalho do Excel no VSTS 2010
Pasta de trabalho da lista pendências de produto
Planejamento de capacidade
Pasta de trabalho da lista de pendências de iteração
Relatórios

Seria "planejamento ágil" um paradoxo? Espero que você não pense assim mas, em um grupo de estudo recente realizado em Los Angeles, uma das participantes afirmou que sua organização havia deixado de ser ágil para adotar práticas mais formais. Quando pedimos mais detalhes, ela disse que sua equipe não podia mais fazer uma correção de código com base na solicitação verbal da gerente e implantá-la de imediato na produção. Agora, era preciso seguir um procedimento formal. Para ela, isso significava deixar de ser ágil.

Contudo, sua compreensão do desenvolvimento ágil está equivocada, e fico feliz em saber que sua organização instituiu um processo formal para alterações. O método Agile não significa agir às cegas ou ser descuidado em nome da velocidade. Em vez disso, trata-se de uma abordagem disciplinada de planejamento, baseada em dados empíricos.

O VSTS (Visual Studio Team System) 2010 introduz novos recursos e funcionalidades para ajudar as equipes Agile a fazer seu planejamento. Neste artigo, apresentarei as novas pastas de trabalho de lista de pendências de produto e de iteração, e também um conjunto de novos relatórios que ajudarão as equipes Agile a planejar e gerenciar lançamentos e iterações.

Planejamento de longo alcance

É comum a preocupação de não ter um plano preciso de longo alcance, e essa preocupação é levantada como uma barreira importante à adoção do método. Na Pesquisa de estado do desenvolvimento ágil de 2008, a ausência de planejamento avançado foi a principal preocupação quanto à adoção das práticas Agile nas organizações dos respondentes. Para muitos deles, imagino que a ausência de um planejamento preciso de longo alcance seja equiparada à ausência de qualquer tipo de planejamento. As equipes Agile optam por vários níveis de planejamento com correções de curso, em vez de um plano em estilo cascata, e com toda a razão.

Steve McConnell, discutindo seu Cone de incerteza para estimativas de software, sugere que as estimativas feitas no início do projeto poderiam chegar a 400% de imprecisão, com tendência a um alto nível de erro: "No início de um projeto, ainda não estão claros detalhes específicos sobre a natureza do software a ser criado, os requisitos específicos, a solução, o planejamento, a equipe e outras variáveis. A variabilidade desses fatores contribui com variabilidade para as estimativas do projeto."

Logicamente, nada disso significa que a gerência executiva adotará a estratégia de "não sabemos quando o projeto será realizado e como será quando estiver pronto". Na verdade, significa uma mudança na abordagem da forma como as equipes planejam os lançamentos e o escopo do trabalho concluído neles.

Figura 1 Lista de pendências de produto e de iteração

Planejamento de lançamentos e iterações

As equipes Agile fazem seu planejamento em dois níveis distintos: de lançamentos e de iterações. O planejamento de lançamentos é uma atividade de alto nível, que auxilia as equipes Agile a revisar um amplo espectro de recursos ou histórias de usuários. Os itens na lista de pendências são então classificados em pilhas, estimados e atribuídos a um conjunto de iterações. Observe que, nesta etapa, a estimativa é feita usando uma unidade semelhante a um tamanho de roupa (pequeno, médio, grande). A intenção, neste momento, é obter uma escala aproximada do custo dos diversos itens na lista de pendências, e não uma cotação precisa. Isso também ajuda o cliente a classificar os requisitos em pilhas, tendo em mente uma escala semelhante.

Na metodologia Scrum, esse conjunto de histórias de usuários é mantido em uma lista, chamada de lista de pendências de produto (veja a Figura 1). O escopo do trabalho a ser realizado em cada iteração depende em grande parte da velocidade da equipe. A definição de um lançamento depende em grande parte de quando você terá um conjunto confiável de requisitos prontos segundo a demanda dos clientes. Por exemplo, se são necessárias quatro iterações para obter o primeiro conjunto de recursos, então o primeiro lançamento será agendado após a quarta iteração.

O planejamento de iterações é uma atividade muito mais detalhada, que ocorre antes do início de cada iteração. As histórias de usuários de alto nível da lista de pendências de produto são revisadas e divididas em histórias menores, da forma mais adequada. Neste ponto, a equipe está pronta para dividir as histórias de usuários em histórias menores e definir as tarefas necessárias para concluir uma história de usuário. Essas histórias de usuários e as tarefas associadas são, então, estimadas em horas. Agora, a equipe pode compreender o escopo de uma iteração.

O Microsoft Office Excel é geralmente encontrado na caixa de ferramentas de uma equipe Agile, juntamente com fichas e notas adesivas. O VSTS 2010 introduz duas novas pastas de trabalho do Excel para ajudar as equipes Agile a gerenciar as listas de pendências de produto e de iteração. Mas vejamos rapidamente o novo modelo de processo Agile do VSTS 2010, antes de passar para as pastas de trabalho.

Um modelo de processo no VSTS inclui tipos de itens de trabalho, consultas, relatórios e orientação textual. Os itens de trabalho são as entidades principais. Podem ser uma história de usuário, uma tarefa, um bug, e assim por diante. Para começar, você configura um projeto de equipe no TFS (Team Foundation Server) e escolhe o modelo VSTS Process for Agile Software Development v1.0 no assistente New Team Project. Esse modelo inclui os seguintes tipos de itens de trabalho:

• Tarefa
• História de usuário
• Bug
• Problemas
• Caso de teste

Você pode criar seu próprio tipo de item de trabalho ou personalizar um item de trabalho específico. Saiba mais sobre a personalização de itens de trabalho no artigo de dezembro de 2008 de Brian Randell sobre o uso e a personalização de modelos de processo do TFS, "Team System: simplifique projetos de equipe com modelos de processos."

Agora, vamos nos aprofundar nas pastas de trabalho do Excel e ver como esses itens de trabalho fluem pelo processo de desenvolvimento, auxiliando no fluxo de valores de planejamento e gerenciamento.

Pastas de trabalho do Excel no VSTS 2010

No artigo intitulado "Ferramentas para agilidade," Kent Beck fala sobre a grande incidência de transições nas equipes Agile, e sobre a necessidade de ferramentas que levem em conta essas transições. A integração de pastas de trabalho de planejamento baseadas no Excel ao controle de itens de trabalho do TFS ajuda a minimizar a sobrecarga de transições. Permite eliminar ou otimizar muitas atividades menores, que vão desde manter as listas de pendências de produto e de iteração sincronizadas até capturar automaticamente a atualização do status de uma história de usuário ou de um item de trabalho de uma tarefa na lista de pendências de iteração ou gerar uma grande variedade de relatórios.

Eis aqui uma sugestão de fluxo que pode ser utilizada por uma equipe Agile para gerenciar as listas de pendências de produto e de iteração com o VSTS 2010:

• Criar um novo projeto de equipe usando o modelo Agile do VSTS 2010.
• Criar a lista de pendências de produto, adicionando a história do usuário à planilha da lista de pendências de produto ou adicionando itens de trabalho a partir do Visual Studio.
• Começar a atribuir os itens a uma iteração com base em sua classificação por pilha na lista de pendências de produto. Por padrão, são criadas as Iterações 0, 1 e 2. Você pode criar iterações adicionais usando as configurações de projeto de equipe.
• Configurar consultas para extrair histórias de usuários, tarefas e outros itens de iterações específicas e mapeá-los para as planilhas de listas de pendências de iteração correspondentes.

A integração entre essas planilhas e o TFS é obtida com o uso de consultas. A Figura 2 mostra a configuração da planilha da lista de pendências de produto. Na faixa de opções do Excel, na guia Team (Equipe), no grupo Work Items (Itens de Trabalho), clique em Configure List (Configurar Lista). Isso abre a caixa de diálogo Configure List Properties (Configurar Propriedades da Lista). Nessa caixa de diálogo, você pode escolher uma consulta do TFS. Você verá o resultado dela na planilha.

Figura 2 Consulta em planilha do Excel

As consultas são criadas no projeto de equipe. Por padrão, quando você configura um projeto de equipe, é criada uma pasta chamada Work Items\Team Queries (Consultas da Equipe)\Workbook Queries (Consultas da Pasta de Trabalho). Nessa pasta, você encontra as consultas padrão para as pastas de trabalho das listas de pendências de produto e de iteração.

Para ter uma idéia melhor de como as pastas de trabalho funcionam, vejamos o exemplo de aplicativo DinnerNow, incluído no VSTS 2010 de outubro de 2008 e na CTP do .NET Framework 4.0 (você encontra o download mais recente da CTP no Team Suite Developer Center). As pastas de trabalho das listas de pendências de produto e de iteração podem ser encontradas na pasta \DinnerNow\Documents (Documentos)\Shared Documents (Documentos Compartilhados), no Team Explorer.

Pasta de trabalho da lista de pendências de produto

A lista de pendências de produto serve principalmente como uma lista dos requisitos desejados pelos clientes em um aplicativo. Já ouvi termos como epopéias ou temas serem usados pelas equipes para referir-se a esse conjunto de requisitos de alto nível. Coletar esse conjunto de requisitos em uma lista, priorizá-los e estimá-los em alto nível ajuda a responder a duas perguntas importantes nesta etapa do planejamento:

1. 1. Quais são os requisitos do aplicativo?
2. 2. Quanto ele custará? Logicamente, a resposta a esta pergunta se baseia em estimativas. Já vi equipes usarem pontos de história, tamanhos de roupa ou horas para fazer estimativas nesta etapa.

Respondendo a essas perguntas, as equipes podem ter um bom nível de controle sobre como será o próximo ou os próximos lançamentos, e para quando esses lançamentos serão agendados. Geralmente, existe uma restrição de orçamento ou de cronograma; por exemplo, no caso de uma futura campanha de marketing, de um requisito legal ou de atividades sazonais. Isso ajuda a planejar o escopo do lançamento, uma vez que é possível gerenciá-lo com base na restrição.

Se houver um prazo definido para o lançamento, o escopo do trabalho será gerenciado com a decisão de quais os requisitos incluídos nas iterações dentro do intervalo de tempo até o lançamento. Por exemplo, se o planejamento começa em dezembro e a data de lançamento está definida para junho, você buscará, basicamente, executar de quatro a cinco iterações (pressupondo que sejam iterações de um mês) para concluir o trabalho.

Se houver flexibilidade quanto ao prazo, a agenda do lançamento dependerá de quando um conjunto mínimo de requisitos poderá ser concluído. Por exemplo, se for possível concluir um conjunto mínimo de recursos necessários em três iterações, o lançamento 1 poderá ser definido para depois de três iterações. Se o próximo conjunto de recursos puder ser concluído em cinco ou seis iterações, o lançamento 2 será definido para depois dessas cinco ou seis iterações.

A Figura 3 mostra a planilha da lista de pendências de produto do projeto DinnerNow. Você vê aqui uma lista de pendências de histórias de usuários. Várias dessas histórias já estão atribuídas a uma iteração específica, e algumas delas já foram concluídas na Iteração 0 e na Iteração 1. Logicamente, quando você inicia um novo projeto, começa com uma pasta de trabalho em branco e cria essas histórias de usuários de alto nível.

Figura 3 Planilha da lista de pendências de produto

As colunas nessas planilhas são os campos do item de trabalho que, por sua vez, fica armazenado no armazenamento de dados do TFS. A integração entre o Excel e o TFS adiciona uma faixa de opções Team (Equipe) ao Excel (veja a Figura 4) com itens de menu para publicar os itens da lista de pendências no TFS, atualizar a lista de pendências com os itens de trabalho atualizados no TFS e muito mais.

Figura 4 Guia Team na faixa de opções do Excel

Cada linha da lista de pendências é armazenada como um item de trabalho no TFS, conforme mostrado na Figura 5. Com esse tipo de integração, os membros da equipe que utilizam o Visual Studio já podem atualizar histórias de usuários e outros itens de trabalho a partir do próprio Visual Studio. Agora, é possível atualizar o status de uma história de usuário, a estimativa ou o trabalho restante sem precisar alternar entre diferentes ferramentas.

Figura 5 Item de trabalho no TFS

Planejamento de capacidade

Como parte do planejamento de um lançamento, as equipes Agile dedicarão bastante tempo a adicionar novas histórias de usuários à planilha, estimar essas histórias e, o mais importante, priorizá-las. Mas a atenção ao status do lançamento é igualmente relevante. A pasta de trabalho da lista de pendências de produto inclui uma planilha para planejamento de capacidade. Essa planilha ajuda a obter controle rapidamente sobre as iterações propriamente ditas, com base nas estimativas das histórias de usuários e na iteração à qual o trabalho correspondente está atribuído.

O planejamento de capacidade é uma atividade importante no planejamento de lançamentos. Ele ajuda a compreender que recursos podem ser concluídos nas diversas iterações. O ponto de dados principal para esse cálculo é a velocidade. Velocidade é a quantidade de trabalho concluída pela equipe em uma iteração. Se você tiver dados de iterações anteriores, esse será o melhor ponto de partida.

Figura 6 Usando iterações anteriores para calcular a velocidade

Em geral, isso é chamado de "previsão baseada em dados anteriores". Na verdade, a planilha de planejamento de capacidade pode extrair dados históricos do data warehouse do TFS, se estiverem disponíveis. Conforme mostrado na Figura 6, posso selecionar a Iteração 1 como aquela da qual serão obtidos dados de histórico, e digitar os dados referentes a data de início, data de término e número de membros da equipe. Nesse caso, obtenho uma velocidade de 816 horas. Isso significa que a equipe conseguiu concluir 816 horas de trabalho na Iteração 1. Insatisfeitas com esses dados, as equipes podem partir de uma estimativa e usar a velocidade da primeira iteração para planejar as iterações futuras.

Na planilha de planejamento de capacidade, você pode especificar o intervalo de datas para as iterações, o número de membros da equipe e as possíveis interrupções durante a iteração, como feriados. Esses dados, combinados com as estimativas de histórias de usuários e a velocidade, criam um gráfico que proporciona uma noção da carga de trabalho referente à iteração. Se você perceber que o trabalho estimado excede a barra da expectativa de capacidade, provavelmente vai querer mover histórias de usuários entre as iterações para obter uma alocação favorável.

No meu caso, não tenho nenhum trabalho planejado na Iteração 2. Posso adicionar algumas das histórias de usuários restantes à lista de pendências da Iteração 2. Agora, o gráfico de capacidade tem a aparência mostrada na Figura 7. Essa é uma boa situação — o trabalho estimado não excede a capacidade.

Figura 7 Gráfico de capacidade com trabalho atribuído à Iteração 2

A planilha da lista de pendências de produto também pode ser usada para ter uma visão geral do status das diversas histórias de usuários, com o projeto já em andamento. Mas você pode obter muito mais informações em relatórios como Burndown and Velocity (Progresso e Velocidade), Remaining Work (Trabalho Restante) e Stories Progress (Andamento das Histórias). Esses relatórios estão incluídos no modelo Agile e podem ser encontrados na pasta Report (Relatório), dentro do projeto de equipe. Abordarei os relatórios mais adiante neste artigo.

Pasta de trabalho da lista de pendências de iteração

A iteração é uma atividade fundamental para uma equipe Agile. As equipes Agile que adotam o Scrum conhecem essa prática como "sprint". A duração da iteração normalmente varia. As equipes que usam eXtreme Programming adotam uma iteração de uma ou duas semanas; já aquelas que utilizam o Scrum geralmente seguem um sprint de quatro semanas.

O planejamento de iteração ajuda a definir o escopo de uma iteração específica. Durante uma reunião para o planejamento de iteração, normalmente as equipes analisam as histórias de usuários atribuídas a uma iteração específica, coletam requisitos detalhados, adicionam tarefas associadas e estimam o tempo necessário para concluir cada tarefa. Nessa reunião, os responsáveis pelo produto, juntamente com o resto da equipe, priorizam histórias de usuários com base em diversos fatores: dependências, estimativas de custo, requisitos detalhados e possíveis evidências de que determinada história não é tão importante quanto foi considerada durante o planejamento do lançamento.

Vamos começar examinando a lista de pendências de iteração no projeto de equipe do DinnerNow. Há pastas com os nomes Iteration (Iteração) 0, 1 e 2 dentro da pasta Shared Documents (Documentos Compartilhados) no projeto de equipe. Dentro de cada uma dessas pastas de iteração, encontramos a lista de pendências de iteração. Cada planilha de lista de pendências de iteração está conectada a uma consulta específica, que obtém somente as histórias de usuários e as tarefas daquela iteração específica.

Se você adicionou outros tipos de item de trabalho, como recursos, temas ou epopéias, deverá adicioná-los a essa consulta, para que esses itens de trabalho adicionais também possam ser recuperados da lista. O projeto de equipe do DinnerNow já tem várias tarefas, adicionadas como itens filho às histórias de usuários na Iteração 2. Mas, em geral, como parte da reunião de planejamento de iteração, as equipes adicionam e estimam tarefas, a fim de obter um bom plano para a Iteração 2. A Figura 8 mostra a lista de pendências de iteração.

Figura 8 Lista de pendências de iteração com tarefas filho

Agora, o TFS oferece suporte a itens de trabalho hierárquicos, o que permite criar árvores pai/filho. Neste caso, as seguintes novas tarefas são adicionadas como tarefas filho à história de usuário "Os usuários devem ser capazes de usar o DinnerNow em seus celulares":

• Identificar as partes da interface do usuário a serem usadas no telefone
• Usar uma arquitetura de "pilha de cartas" na interface do usuário
• Identificar os celulares mais populares
• Reduzir o número de pressionamentos de tecla necessários para fazer um pedido

Agora, a equipe está pronta para passar à atribuição de tarefas. A quantidade de trabalho assumida por cada membro da equipe depende de vários fatores, entre eles a capacidade do membro da equipe para aquela iteração, a experiência na área e há quanto tempo o membro faz parte da equipe.

A pasta de trabalho da lista de pendências de iteração tem planilhas adicionais para ajudar em outros aspectos do planejamento e da execução. A planilha para planejamento de capacidade é semelhante àquela na pasta de trabalho da lista de pendências de produto. Você pode usar essa planilha para ter uma noção da capacidade da equipe.

A planilha de balanceamento de carga mostra-se útil durante o planejamento e a iteração propriamente dita. As equipes Agile continuam seu planejamento ao longo da iteração para fazer correções de curso conforme tornam-se disponíveis novas informações sobre uma história de usuário específica, quando é descoberta uma dependência técnica em um tarefa ou quando um membro da equipe torna-se indisponível. Essas ocorrências exigem atualizações na atribuição de tarefas, e é aí que entra em cena a planilha de balanceamento de carga.

Outra planilha interessante é a fornecida para o controle de velocidade. Quem estiver familiarizado com o jogo de críquete reconhecerá os termos "taxa atual de runs" e "taxa necessária de runs". Essas duas estatísticas são usadas para ter uma boa indicação do desempenho do time em uma partida. Em geral, se a taxa necessária de runs é superior à taxa atual, o time que está rebatendo precisa acelerar o passo para evitar uma derrota. Por outro lado, se a sua taxa atual de runs é superior à taxa necessária, então o time que está rebatendo encontra-se em boas condições.

Antes que um leitor especialista em críquete chame a minha atenção por causa disso, direi que outros indicadores de status, como os wickets perdidos e os overs restantes, são importantes para ter uma visão completa da situação. E o mesmo se aplica a um projeto Agile. A planilha de controle de velocidade permite uma percepção rápida da velocidade atual da equipe e da velocidade necessária para concluir as histórias de usuários em uma iteração. Assim como no críquete, outros indicadores de status, como os dias restantes, são importantes para ter uma visão completa da sua posição atual na iteração. Por exemplo, talvez a equipe precise reduzir o escopo se a sua velocidade atual não estiver alinhada à velocidade necessária. Mais uma vez, é essencial ter transparência para com os clientes e fazer os ajustes necessários com base no trabalho em equipe.

Relatórios

Claro que você não precisa se tornar um grande fã do críquete para começar a gerenciar projetos com o VSTS 2010. Você pode contar com relatórios como os de progresso e de trabalho restante para monitorar o andamento de um projeto.

A Figura 9 mostra o relatório de progresso da Iteração 1. Um relatório de progresso mostra as horas de trabalho concluídas, as horas de trabalho restantes e a taxa de andamento. Como você pode perceber pelas horas restantes no gráfico, a equipe não concluiu todas as tarefas alocadas para a iteração.

Figura 9 Gráfico de progresso

As linhas de tendência também mostram esse status. Como você pode ver no gráfico, a linha de tendência atual indica que o trabalho não será concluído a tempo com a taxa atual da equipe durante a Iteração 1. A equipe pode observar o progresso ao longo da iteração e fazer as correções de curso necessárias, além de informar os clientes sobre o possível impacto no plano de lançamento.

O relatório de trabalho restante também é muito útil. Como mostra a Figura 10, a equipe tem feito progressos constantes no sentido da conclusão do trabalho. Nenhum trabalho adicional foi acrescentado à lista de pendências durante a iteração, o que é um bom sinal. O progresso da equipe declinou perto do final da iteração, gerando algumas tarefas inacabadas.

Figura 10 Trabalho restante

Como você já percebeu, as ferramentas e as planilhas de planejamento Agile para o VSTS 2010 proporcionam às equipes um front-end no Excel e um armazenamento de dados integrado capaz de capturar e extrair dados desde o planejamento de lançamento até o planejamento de iteração e desde a execução de testes até a avaliação de qualidade da compilação. Isso representa uma ótima ferramenta para os gerentes encarregados de planejar e gerenciar projetos Agile, e também para os desenvolvedores e os testadores da equipe. Eles podem trabalhar em conjunto, avaliar o andamento, fazer as alterações necessárias e gerenciar todo o projeto. Essa integração elimina muitas das atividades manuais monótonas desempenhadas pelas equipes Agile para coletar dados e gerar relatórios.

Para uma abordagem diferente, baseada na matemática, do planejamento avançado, consulte a coluna "Execução de teste" do Dr. James McCaffrey nesta edição.

Ajoy Krishnamoorthy é líder de planejamento de produto na equipe de padrões e práticas da Microsoft. Antes disso, Ajoy foi gerente sênior de produto do Microsoft Visual Studio Team System. Nessa função, era responsável pelo gerenciamento, pela estratégia e pelo marketing do produto. Ele tem mais de dez anos de experiência consultiva em diversas funções, inclusive como desenvolvedor, arquiteto e gerente técnico de projetos. Conheça o seu blog em blogs.msdn.com/ajoyk.