O uso de métodos ágeis para gestão de projetos de software tem crescido em todo o mundo, principalmente no Brasil, tendo o framework do Scrum como principal base para gestão.

O Scrum é muito simples e divide as atividades de gestão em três importantes papéis: Product Owner (PO), que representa o cliente; Scrum Master (SM), que atua como líder e responsável pela manutenção do processo; e Time, que é formado pelas pessoas encarregadas por desenvolver o software.

O Scrum baseia-se no conceito de desenvolvimento interativo e incremental, usando ciclos curtos de 2-4 semanas conhecidos como Sprint, permitindo uma colaboração contínua entre todos os interessados, sempre focando na entrega de valor a cada Sprint e, com a proximidade do PO, você consegue ir direto ao ponto buscando a satisfação com o alinhamento no desejo de negócio.

O Team Foundation Server (TFS) é uma plataforma de colaboração para projetos de software unindo gestão de código fonte, gestão de projetos, qualidade de software e integração de todo o ciclo de desenvolvimento, seja para projetos ágeis ou formais, implementando um conceito conhecido como Application Lifecycle Management (ALM) funcionando como o ERP para quem desenvolve software seja em .NET, Java ou qualquer outra plataforma.

O Visual Studio Scrum 2.0 é um template de processo 100% baseado no framework do Scrum para permitir o uso do mesmo em conjunto com o Team Foundation Server, possibilitando assim usar os principais artefatos, utilizando a mesma nomenclatura e funcionalidade, mantendo os mesmos padrões até para os mais puristas no framework.

Como toda a comunicação no projeto é gerenciada pelo TFS, você vai encontrar no template Visual Studio Scrum o recurso Work Items, que é a uma espécie de formulário para entrada de dados, customizado automaticamente de acordo com o template de processo adotado no projeto. Como estamos usando o Visual Studio Scrum, teremos os seguintes itens: Product Backlog Item (histórico do usuário), Task (Tarefas), Impediment (Impedimentos), Bug (Problemas),Test Case (Casos de teste) complementando com os relatórios: Release Burndown, Sprint Burndown e Velocity.

Como você está observando, toda a comunicação será baseada nos próprios termos já usados no Scrum, mantendo a total compatibilidade com o seu framework. Para a gestão de um projeto ágil não é necessário TFS, porém no dia a dia de um projeto temos diversas ações que precisam ser tomadas que vão além do uso de postit, tornando-se mais desafiador ainda quando você trabalha com vários times, inclusive tendo pessoas em locais diferentes.

Para se comunicar com o TFS você pode usar Excel, Project, Visual Studio, Eclipse e o portal web do projeto, permitindo assim, independente do ambiente desejado uma integração total entre as informações trocadas nos projetos.

Em um cenário clássico o PO pode publicar um user story utilizando o Work Item (Product Backlog Item) fazendo com que essa informação apareça para todos os projetos. O Time ao capturar uma estória de usuário durante a reunião de planejamento do Sprint vai quebrar em tarefas usando o Work Item (Task), estimando em horas cada atividade. Um outro desenvolvedor pode pegar um Work Item (Task) e associar ao seu usuário mudando o status para InProgress e depois durante CheckIn relacionar o código com esse Work Item.

Agora você começa a entender a diferença que o TFS vai provocar no seu projeto. Sem mudar nada no seu processo você ao fazer um Check In de código relacionado a uma tarefa (Post It) está sem esforço documentando eletronicamente o seu código fonte. A qualquer momento você pode voltar naquele código e saber se o mesmo teve aquela linha modificada pelo desenvolvedor em função de uma tarefa xyz relacionada a uma estória de usuário criada pelo Product Owner. O mesmo acontece no caso de um registro de bug.

Essa mesma integração vai se refletir no servidor Build (Continuous integration) que durante a geração da versão do seu software, além de validar os testes unitários integrados, politicas do projeto, vai emitir um relatório dos Work Items vinculados nessa versão, respondendo de forma simples a uma grande dúvida no final do Sprint “O que tem nessa versão “.

Transparência, inspeção e adaptação

Um principio básico oferecido pelo Team Foundation Server é colaboração e transparência que você pode perceber imediatamente já na primeira visão ao entrar no portal do projeto, conforme demonstrado na Figura 01.

 

Figura 01 – Visão pública do Dashboard com detalhes do projeto.

Analisado o Dashboard temos informações sobre o seu Sprint que está em andamento, Burndown para acompanhar a tendência, informações sobre registros de Work Items abertos como quantidade de itens no Sprint Backlog, tarefas em andamento e qualquer consulta adicional que você julgue importante mostrar para seu time. Essa mesma tela é complementada com um item estratégico que é o relatório de Build, consolidando a gestão com o feedback contínuo.

Product Backlog 

O Product Owner pode adicionar ou priorizar novos itens a qualquer momento o backlog, conforme você pode observar na Figura 02 com uma visão do trabalho sendo realizado no portal do projeto. Nesse portal o dia a dia do PO é facilitado, pois além de simples e leve todas as informações são centralizadas e as alterações já refletem para todos no projeto.

Figura 02 – Product BackLog

A priorização de atividades faz parte do dia a dia de qualquer PO, e nesse momento você observa na Figura 02 como é simples bastando arrastar e colocar no local desejado. Com isso, automaticamente ele já se auto-organiza, definindo uma nova endentação de prioridade que em projetos ágeis é um item fundamental para manter o desenvolvimento sempre próximo do valor de negócio.

A qualquer momento o PO pode detalhar um item de backlog (User Story). Ao clicar no mesmo ele tem acesso ao formulário completo, conforme apresentado na Figura 03. Um item importante que você pode observar além do descritivo detalhado é a possibilidade de se adicionar links e anexos que o PO julgue importante para esclarecer o valor de negócio.

Figura 03 – Product BackLog Item

Conforme comentei no início, esse formulário apresentado na Figura 03 é uma visão de campos definidos pelo templates de processo Visual Studio Scrum. Outro ponto importante no mesmo é o esforço que é atualizado pelo time após a estimativa, seja usando Planning Poker ou técnica similar. Nesse exemplo usamos escala Fibonacci (1, 2, 3, 5, 8, 13) para definir a complexidade dos itens.

Sprint Planning 

Durante a reunião de planejamento do Sprint o Time se reúne com o PO para esclarecer dúvidas do backlog, estimar e capturar itens para montar o seu Sprint Backlog. Na Figura 04 você pode observar como é simples a atividade de capturar um item do Backlog e transformar em Sprint Backlog.

 

Figura 04 – Sprint Planning.

Ainda na reunião de planejamento do Sprint o Time vai detalhar o item do Sprint Backlog em tarefas (Task) relacionadas, conforme pode observar na Figura 05. Uma informação importante é que essas tarefas são relacionadas diretamente com o item de Backlog permitindo com isso rastreabilidade. Se você encontrar um código fonte com uma tarefa vinculada, você saberá qual o item do Sprint Backlog vinculado.

Figura 05 – Sprint Planning. 

Sprint 

Um Sprint em um projeto Scrum pode variar entre 2 a 4 semanas conforme o modelo adotado. Em cada print o Time se compromete com um conjunto de itens do backlog cujo objetivo é entregar valor ao final “Software funcionando”. Com o uso do TFS você terá um Scrum Board virtual, conforme apresentado na Figura 06, dispensando o uso de PostIt. Cada membro do Time vai pegar um PostIt e arrastar para a área IN PROGRESS, alterando automaticamente o status do Work Item de “TO DO” para “IN PROGRESS” e já relacionando o nome da pessoa que pegou essa atividade.

Figura 06 – Scrum Board.

Daily Scrum Meeting 

Durante o Sprint temos uma reunião diária com duração estimada em 15 minutos. É um dos principais momentos do Time, pois o objetivo é fazer uma rápida sincronização sobre o andamento das atividades. É importante registrar que não é um momento para bater papo, falar de futebol e, sim, responder a três perguntas chaves: O que você fez ontem? O que você fará hoje? Há algum impedimento no seu caminho? 

Durante a reunião diária é comum você atualizar a sua atividade informando quanto tempo falta, conforme você pode observar na Figura 07 e, se necessário, registrar impedimentos, conforme você pode observar na Figura 08.

Figura 07 – Scrum Board.

Figura 08 – Registrando um impedimento

Burndown 

O gráfico de Burndown é estratégico para o Time Scrum e consolida uma visão atualizada com a projeção e tendência de entrega do Sprint. É uma informação importantíssima para o Time. Na Figura 09 você pode observar um exemplo de Burndown.

Figura 09 – Visualizando o Burndown

Um ponto muito importante é que pessoas em qualquer lugar podem ter acesso ao mesmo, inclusive pessoas externas ao projeto, permitindo assim que outras pessoas tenham visibilidade sem necessidade de ficar perguntando como está indo o projeto. Acho que você sabe bem o que estou falando. Não existe pergunta mais chata que “E ai?”. Vale ressaltar que esse Burndown é uma informação exclusiva do Time e o mesmo é o único responsável pelo Sprint. Ao PO interessa a entrega final após a conclusão do Sprint.

Velocity 

Uma métrica importante em um projeto Scrum é a velocidade do time. Esse número é calculado após a entrega de alguns Sprints e é atualizado com frequência. É uma referência importante, baseando-se em quantos pontos um time está entregando por Sprint. O Time usa essa informação para saber até quantos pontos de complexidade eles consegue assumir por Sprint. O TFS, usando o histórico dos Sprints gera para você, conforme pode observar na Figura 10.

Figura 10 – Visualizando o gráfico Velocity.

Forecast 

Independente do modelo de projeto, sendo ágil ou formal, uma pergunta recorrente é quando estará pronto? Com um Scrum temos duas respostas para essa pergunta. A primeira se for relacionada ao conjunto de itens do Sprint Backlog a resposta é ao final do Sprint. Se a pergunta for relacionada ao Backlog o Team Foundation Server pode ajudar você, conforme pode observar na Figura 11 uma previsão quebrando em Sprints futuros usando a velocidade como base. É mais uma forma ágil de usar a tecnologia para facilitar o seu dia a dia no projeto.

Figura 11 – Forecast

Relacionando informações 

Um dos principais pilares na estratégia de ALM usando Team Foundation Server é justamente reunir as informações dos projetos e usar de forma integrada. Na Figura 12 você observa como durante o Check In é possível vincular uma atividade. Com esse simples passo você está documentando o seu software. O TFS, em cada Check In gera um identificador chamado de Changeset que permite rastrear todas as informações relacionadas.

Figura 12 – Check In associando uma tarefa “PostIt”.

Conforme a política de integração continua atotada eu projeto é possível após durante a geração da versão validar estratégias do projeto como padronização de código usando Code Analysis, padronização da arquitetura, testes unitários e saber quais funcionalidades foram implementadas nessa versão conforme você pode observar na Figura 13. 

Figura 13 – Gerando uma versão

Utilizar o Scrum dentro do Team Foundation Server é muito fácil e ágil, permitindo justamente ampliar ainda mais a colaboração, atuando como elo entre todos os participantes do projeto. Quando falamos do universo Application Lifecycle Management, diversos outros recursos são facilitados por se trabalhar em um modelo colaborativo e integrado, permitindo uma gestão mais efetiva de todo o ciclo de desenvolvimento.