Gerenciamento de Projetos Scrum com o IBM Rational Team Concert Versão 2: Parte 1. Configure projetos, equipes e planos

A tecnologia Jazz é útil para o planejamento e gerenciamento de Agile

Usamos o IBM® Rational Team Concert™ (agora, por mais de um ano) para dar suporte às nossas equipes scrum, usufruindo sua variedade de recursos, convivendo com algumas de suas deficiências e mantendo em vista a próxima versão. Com a Versão 2, as equipes do Jazz e do Rational Team Concert produziram aprimoramentos dramáticos no suporte à estimativa e ao planejamento do scrum e do agile (sem mencionar o cliente da Web muito melhor e diversos outros novos recursos). Esta série de artigos apresenta um tutorial atualizado de introdução à Versão 2 e ao processo scrum e destaca os novos recursos e capacidades importantes para equipes scrum e seus gerentes. Ele atualiza o artigo publicado em 2008 que abordou o Rational Team Concert Version 1 and scrum project management.

Millard Ellingsworth, Software Developer, IBM Corporation

Millard Ellingsworth photoMillard Ellingsworth lives in the hills west of Portland, Oregon, where he works on developing the IBM Rational Collaborative Lifecycle Management community, improving how teams work together to build software that matters. During the small pockets of free time that leaves him, he divides his attention between playing golf, noodling on the guitar, woodworking, and tinkering with Android development. You can follow him on Twitter as @millard3 and on Google+.


nível de autor Contribuidor do
        developerWorks

Thomas Starz, Software Developer, IBM Corporation

Thomas Starz photoThomas Starz is a software developer and agile development coach with IBM Software Group and works as part of Tivoli Service Automation Manager team. He is a Certified Scrum Master and Practitioner and an enthusiastic user of Rational Team Concert. While working as a mentor and coach, he has also helped several teams get started with Rational Team Concert.



12/Nov/2009

O termo scrum [N. T.: 'uma formação em que oito jogadores ficam fortemente agrupados para proteger a reposição da bola no jogo'] provém do Rugby, uma modalidade esportiva, e é uma abreviação de scrummage ou scrimmage. No contexto de desenvolvimento de software, scrum é um método de gerenciamento de projeto em um processo de desenvolvimento agile. A finalidade é manter o foco em produzir o maior valor de negócio para as partes interessadas no menor espaço de tempo possível. O processo scrum é útil para assegurar que os recursos remanescentes mais valiosos sejam os próximos a serem desenvolvidos, e enfatiza que, no momento da entrega, o trabalho tem de estar concluído. O trabalho é estruturado em sprints, ou iterações, de duas a quatro semanas, com o software de produção gerado no final de cada sprint.

Para aprender a gerenciar seu projeto scrum com o IBM® Rational Team Concert™, você trabalhará na preparação de um projeto e dará prosseguimento a ele na sua primeira iteração. Os dados do projeto de amostra provêm do exemplo estendido do livro de Mike Cohn, Agile Estimating and Planning (Prentice Hall, 2005), que descreve uma equipe scrum nos Bomb Shelter Studios à medida que eles trabalham no Havannah, um novo jogo de computador. Os dados do exemplo estão no arquivo que acompanha este artigo, "Amostra de dados de scrum do Rational Team Concert" (consulte Downloads).

Este artigo parte da premissa de que você já está registrado no jazz.net e já transferiu por download e instalou o software (seguindo as instruções contidas aqui). Você deve estar no ponto em que o cliente Rational Team Concert pode se conectar ao repositório do IBM® Jazz™. Depois de uma introdução rápida ao processo scrum, passaremos à criação de um projeto do Rational Team Concert baseado em scrum.

Visão geral do processo scrum

A estrutura scrum é composta pelos seguintes aspectos inter-relacionados:

  • Roles
    • Product owner
    • Scrum master
    • Team member
  • Ceremonies (reuniões e encontros)
    • Daily Scrum
    • Sprint Planning
    • Sprint Review
    • Sprint Retrospective
  • Artifacts
    • Product Backlog
    • Sprint Backlog
    • Burndown Chart
    • Impediments List

Os requisitos em um projeto scrum são capturados como itens na Product Backlog. Esse é um dos artefatos mais importantes em um projeto scrum. É uma lista priorizada de todo o trabalho ou recursos desejados para o projeto. O product owner é responsável pela manutenção dessa lista e por revisar as prioridades dos itens, assim como pelos progressos do projeto e pelas mudanças do ambiente de negócios. Em um cenário ideal, os itens na Product Backlog são indicados em termos que incluem uma indicação dos valores de negócios para as partes interessadas.

O product owner é responsável pelo sucesso do produto. Essa pessoa define os recursos e o planejamento do release, e é responsável pela determinação do valor de negócios dos diversos recursos. O product owner refina constantemente a Product Backlog e redefine suas prioridades.

O scrum master gerencia o processo, assegurando que as práticas envolvidas no processo sejam devidamente executadas e que os valores do scrum sejam compreendidos pelos membros da equipe. Assegura que a equipe seja totalmente produtiva, eliminando obstáculos e isolando-a de qualquer interferência externa (pelo menos, no decurso de um sprint).

Uma equipe scrum deve ser uma combinação interdisciplinar das qualificações adequadas para executar o projeto (por exemplo: desenvolvedores, testadores, designers de interação, autores). Os membros devem estar comprometidos com a equipe scrum em tempo integral; caso contrário, a necessidade de manter os trabalhadores de meio-período no mesmo ritmo diminuirá a velocidade do restante da equipe.

A equipe participa de uma reunião de Sprint Planning no início de cada sprint. Nessa reunião, o product owner apresenta os recursos mais desejados para o sprint vindouro, descrevendo-os de modo que a equipe possa compreender o que se espera dela. O product owner e a equipe estabelecem uma meta para o sprint. Em essência, a meta é um enunciado da visão que conduzirá o trabalho nas próximas duas ou quatro semanas. Em seguida, a equipe determina como alcançar a meta do sprint e divide os recursos nas tarefas necessárias.

Essa lista de tarefas se transforma na Sprint Backlog. Os itens da lista são estimados em horas, assim a equipe pode determinar se eles podem ser concluídos no prazo. Quando o tempo não é suficiente, há a possibilidade de retirar um recurso da Sprint Backlog e retorná-la para a Product Backlog. A estimativa é feita como um exercício da equipe e não é determinada nem pelo scrum master, nem pelo product owner. A Sprint Backlog representa o trabalho que a equipe se comprometeu a concluir durante o sprint.

Durante a reunião Daily Scrum, os membros da equipe respondem a três questões:

  • O que fiz ontem?
  • O que farei hoje?
  • O que está impedindo o meu progresso (se for o caso)?

Essa não é uma reunião de status, mas de planejamento e de comprometimento. A coisa toda deve durar menos de 15 minutos. Comunicar regularmente o que cada um está fazendo e quais problemas está enfrentando pode eliminar a necessidade de outras reuniões, além de ajudar os membros da equipe a trabalharem mais eficazmente em conjunto.

No final de cada sprint, na reunião Sprint Review, a equipe apresenta suas consecuções. Essa é uma reunião breve e informal para a qual todas as partes interessadas são convidadas. Sua finalidade é demonstrar o software de produção (ou outros artefatos valiosos, como uma visão geral da arquitetura fundamental do produto) e colher comentários dos participantes e das partes interessadas sobre o software de produção.

Depois da Sprint Review, os membros da equipe fazem uma reunião interna para manter a Sprint Retrospective (algumas vezes, chamada de Reflection). Nessa reunião, eles falam sobre o que está indo bem — e o que não está — no que se refere ao projeto e a seu progresso. Essa reunião deve resultar em alguma mudança no modo em que eles atuarão nos sprints futuros, já que o objetivo é aprimorar continuamente a eficácia da equipe e sua prática. Considerando que o Rational Team Concert é muito configurável e adaptável aos ajustes do processo da equipe, essas reuniões podem resultar em ajustes e aprimoramentos que são implementados alterando o processo no Rational Team Concert.

À medida que os itens da Product Backlog são selecionados para execução na reunião de planejamento do sprint, eles se tornam parte da Sprint Backlog. Esta contém tarefas específicas associadas aos recursos da Product Backlog. Durante o sprint, o status dos itens de trabalho na Sprint Backlog é atualizado diariamente. O status atualizado torna possível a geração de um gráfico Sprint Burndown. Esse gráfico apresenta a quantidade de trabalho restante no projeto. Normalmente, contém também uma linha "ideal" indicando uma progressão gradual do trabalho do início ao fim do sprint. A linha ideal indica qual seria o progresso do trabalho se fossem mantidas as mesmas proporções de progresso em cada dia do sprint. Ainda que o progresso real do trabalho não siga essa linha, desvios importantes são causa de preocupação, principalmente se a tendência do progresso real for se distanciar do ideal.

Caso haja impedimentos ou bloqueios ao progresso, o scrum master pode manter uma Impediments List (ou Blocks List) como um artefato adicional do scrum. Todos os artefatos devem ser mantidos onde estejam prontamente disponíveis e visíveis para todos os membros da equipe.

O modelo Scrum Process do Rational Team Concert suporta todas as funções, cerimônias e artefatos importantes do scrum. O Rational Team Concert fornece acesso fácil a esses recursos e a muitos outros por meio de uma user interface (UI) rich client baseada em Eclipse e de uma UI da Web.

Ao gerenciar um projeto usando o método scrum, é necessário um lugar para manter a descrição das coisas que precisam ser feitas para o projeto, principalmente suas stories e tasks. Embora seja possível, simplesmente, colocar cartões em um quadro de avisos, usar o software pode ser preferível, principalmente se os membros da equipe estiverem distribuídos em diversos locais.

O Rational Team Concert oferece métodos fáceis para gerenciar tudo o que você necessita. Em uma Project Area, é possível gerenciar construções, origens, planos e muito mais. Este artigo se concentra nos aspectos de planejamento e gerenciamento do processo scrum. Depois de executar as primeiras etapas (por exemplo, estabelecer a conexão com um repositório e definir IDs de usuário para as pessoas que utilizarão a ferramenta), explicamos como criar plans e work items, e gerenciá-los durante as iterações de um release do projeto.


Configurando o repositório e os usuários do Rational Team Concert

Antes de estar pronto para examinar como o Rational Team Concert e o modelo Jazz Scrum Process dão sustentação às equipes scrum, é necessário manipular a configuração do projeto básico.

Criar uma conexão de repositório

  1. Verifique se o servidor Jazz está iniciado e se o cliente Rational Team Concert está aberto.
  2. Para criar uma nova conexão de repositório, clique com o botão direito do mouse em Repository Connections na visualização Team Artifacts (consulte a Figura 1) e selecione New > Jazz Repository Connection.
  3. Insira o URI e o ID de usuário, e a senha correspondente.

Dica:
Quando você usa uma instalação de servidor Jazz no seu sistema local, é possível que o URI seja, por exemplo, https://localhost:9443/jazz/, o ID de usuário inicial ADMIN e a senha ADMIN (ambos com distinção entre maiúsculas e minúsculas).

Nota:
Observe a letra S (minúscula) em "https", indicando que o Jazz está utilizando uma conexão segura. Dependendo do navegador, talvez você obtenha um comportamento inesperado caso se esqueça de incluir o "s".

Figura 1. Criando uma nova conexão de repositório
Criando uma nova conexão de repositório
  1. Clique em Finish.

Dependendo do sistema em que o servidor Jazz está instalado, pode levar algum tempo até que a conexão do repositório seja criada quando você se conecta pela primeira vez.

Adicionar ou importar usuários

A próxima ação é criar os usuários no Rational Team Concert. Os usuários pertencem ao repositório do Jazz, assim eles podem participar de mais de uma área de projeto e usar, potencialmente, outras ferramentas baseadas no Jazz que residem no servidor. Se você configurar o Jazz com um repositório de usuários externo (por exemplo, o seu servidor do LDAP corporativo), será possível importar usuários sem que seja necessário criá-los, como esclarece a barra lateral. Este artigo parte da premissa de que você usa o servidor de aplicativos Tomcat padrão e necessita criar usuários nesse novo repositório.

  1. Para criar um novo usuário, clique com o botão direito do mouse na conexão do repositório e selecione New > User.
  2. Selecione No ao receber um prompt sobre se os usuários devem ser importados (Figura 2).
Figura 2. Criando um novo usuário
Criando um novo usuário

Visualização ampliada da Figura 2

  1. Insira as informações do primeiro usuário.
    1. Como estamos seguindo o exemplo de Mike Cohn, o primeiro usuário é Sasha.
    2. Opcionalmente, é possível incluir uma foto.
    3. O endereço de e-mail é um campo obrigatório, assim o Jazz pode enviar uma notificação de e-mail sobre as diversas atividades da equipe. Para Sasha, insira sasha@bombshelterstudios.com.
    4. A senha inicial do usuário definida automaticamente é idêntica ao ID do usuário.
  2. Escolha os grupos de segurança do Jazz apropriados para o usuário. O usuário que administrará o projeto deve estar no grupo de repositórios denominado JazzAdmins (no exemplo, Sasha deve se tornar um JazzAdmin; caso contrário, ele não poderá executar todas as atividades de configuração necessárias).
    • Os JazzUsers possuem as permissões padrão em uma área de projeto. Esta, normalmente, permite que tais usuários criem e incluam itens de trabalho, visualizem relatórios e utilizem outros recursos definidos pelas configurações de segurança do projeto.
    • Os JazzAdmins podem acessar as diversas configurações relacionadas ao servidor Jazz e aos projetos.
  3. Selecione o tipo apropriado de licença do usuário.
    • As licenças Developer são obrigatórias para usuários que criam ou implementam modelos de processo, que criam áreas de projeto ou planos, e que criam ou editam páginas associadas. Tais licenças também são apropriadas para os membros da equipe que contribuirão com o código e executarão as compilações.
    • As licenças Build e ClearCase Connector, normalmente, são atribuídas apenas para usuários administrativos.
    • As licenças Contributor são uma boa opção para todos os usuários que necessitam do acesso somente leitura ao repositório. Com tal licença, um usuário também pode criar itens de trabalho.

A Figura 3 apresenta a tela resultante.

Figura 3. Especificando os detalhes do usuário
Especificando os detalhes do usuário
  1. Clique em Save.

Nota:
Posteriormente, os usuários precisarão configurar seus respectivos ambientes de trabalho e inserir suas ausências planejadas (consulte as guias na parte inferior da tela), a fim de que o tempo potencialmente gasto em um projeto possa ser devidamente calculado. Apresentaremos um exemplo mais adiante.

Para o projeto Havannah utilizado neste exemplo, será necessário incluir mais usuários (do mesmo modo descrito para Sasha.

  1. Crie outros usuários com os nomes Allan, Delaney, Frank, Prasad e Rose.
  2. Atribua-os ao grupo JazzUsers com uma licença Developer.
  3. Efetue logout como usuário ADMIN.

Agora, você concluiu as entradas como usuário ADMIN padrão. O modelo de segurança do Jazz concede privilégios administrativos básicos ao usuário no Jazz, mas não inclui nenhum direito especial em uma área de projeto específica. Por exemplo, o usuário ADMIN não pode criar e salvar novos planos de iteração na área de projeto, visto isso ser atribuição do master scrum ou do product owner.

  1. Clique com o botão direito do mouse na conexão do repositório e selecione Properties (Figura 4).
Figura 4. Especificando as propriedades do login
Especificando as propriedades do login
  1. Altere os campos User ID e Password de modo que eles correspondam às credenciais de Sasha (sasha e sasha, já que, por padrão, a senha adota o mesmo valor do ID do usuário). Opcionalmente, é possível selecionar (ou desmarcar) as caixas de opção "Remember my password" e "Automatically log in at startup", conforme indicado na Figura 5.
Figura 5. Especificando as propriedades do login
Especificando as propriedades do login

Como importar dados de usuários a partir do seu diretório do LDAP

Os usuários também podem ser importados a partir de um repositório de usuário externo (por exemplo, o seu servidor do LDAP corporativo). Para obter informações adicionais sobre como conectar o servidor da equipe a um diretório do LDAP, siga as instruções de LDAP Configuration for Newbies em Jazz.net.

  1. Ao clicar em OK, você estará conectado como Sasha, que é o master scrum dos Bomb Shelter Studios.

Configurando áreas para o projeto e pessoas

Crie uma área de projeto

A próxima ação é criar uma área de projeto, que servirá como contêiner para todos os planos, itens de trabalho e demais coisas relacionadas ao projeto que você está configurando.

  1. Para criar uma nova área de projeto, clique com o botão direito do mouse na conexão do repositório, na visualização Team Artifacts, e selecione New > Project Area.
  2. Insira o nome do projeto (Havannah, neste exemplo) e clique em Next.
  3. Quando você criar uma área de projeto pela primeira vez, é necessário implementar os modelos de processo previamente empacotados; portanto, clique em Deploy Templates. Isso pode levar alguns minutos.
  4. Em Available Process Templates, escolha o modelo Scrum e clique em Finish (veja a Figura 6).
Figura 6. Criação de uma área de projeto usando o modelo Scrum
Criação de uma área de projeto usando o modelo Scrum

Visualização ampliada da Figura 6

Pode levar alguns minutos até que a área de projeto seja inicializada no servidor. Quando a ação estiver concluída, você verá uma tela similar à ilustrada na Figura 7.

Figura 7. A área do projeto Havannah
A área do projeto Havannah

Visualização ampliada da Figura 7

Na coluna esquerda da visualização Team Artifacts, você verá a nova área de projeto com as pastas Builds, Plans, Reports, Source Control (fluxos) e Work Items (consultas úteis para localizar os itens de trabalho em diversos estados). Este artigo se concentra na seção Plans. No editor Project Area, há uma área Description que se destina a fornecer informações do projeto.

Nota:
Na Project Area, também há uma seção para inclusão de anexos. Essa se destina ao modelo Scrum Process e não é um lugar apropriado para colocar os anexos do projeto.

Inclua os membros e especifique suas funções

Como criador da Project Area, você é o administrador inicial. No entanto, a maioria das permissões para modificar a estrutura do projeto dentro do modelo Scrum Process pertence ao scrum master ou ao product owner. Assim, uma das primeiras coisas a fazer é incluir os membros no projeto e definir suas funções (pelo menos, para o scrum master e o product owner). Normalmente, a associação no nível da Project Area destina-se aos membros com responsabilidades administrativas. Em breve, você incluirá outros membros em uma Team Area.

Neste exemplo, Sasha criou a Project Area e tornou-se o administrador inicial (com autoridade para fazer qualquer alteração nela). Frank (o product owner de Havannah) é um membro no nível apropriado da Project Area, assim, inclua-o agora.

  1. Clique na seta à esquerda de Members para expandir o painel.
  2. Clique em Add para iniciar o assistente Add Team Members.
  3. Para incluir Frank como o product owner, digite um f (a letra F) na área de texto do nome e pesquise nomes correspondentes. Como Frank já está incluído como usuário do Rational Team Concert, seu nome estará na lista Matching Users.
  4. Clique em Select para movê-lo para a lista Selected Users.
  5. Em seguida, clique em Next.
  6. Selecione a função Product Owner, inclua-a na lista Assigned Roles e clique em Finish (veja a Figura 8).
Figura 8. Inclusão dos membros da equipe
Inclusão dos membros da equipe

Visualização ampliada da Figura 8

Como ilustrado na Figura 9, Frank foi incluído como o product owner do projeto.

Figura 9. Inclusão de membros no projeto Havannah
Inclusão de membros no projeto Havannah
  1. Salve a Project Area (pressionando o botão Save no canto superior direito do editor Project Area ou selecionando File > Save).

Depois de salvar suas alterações, você verá a lista dos novos membros da equipe e receberá um prompt perguntando se deseja enviar-lhes ou não um convite por e-mail. Se você tiver configurado o suporte a e-mail (quando configurou o servidor) e responder afirmativamente a esse prompt, os membros do projeto receberão uma mensagem de e-mail de boas-vindas, junto com os links e as informações necessárias para se conectar ao projeto.

  1. Como os usuários são fictícios, retire todas as marcas de verificação e clique em OK. (Se preferir, pressione Cancel para sair do diálogo, já que ele se destina apenas ao envio de e-mail.)

Descreva as linhas de tempo do release

A próxima etapa é planejar as linhas de tempo do projeto, o que significa especificar as datas de início e final do release e dos sprints. Ao configurar a sua Project Area, ajuste as datas apropriadamente. Isso é adequado para selecionar a data futuramente.

Dica:
É necessário estar autorizado para fazer as alterações no projeto. O usuário que criou o projeto tem direitos de administrador e pode fazer as alterações descritas nesta seção. Para configurar o seu próprio projeto, é necessário ser administrador da Project Area ou um membro com a função scrum master ou product owner. Caso contrário, você receberá um erro de permissão negada ao tentar salvar as alterações na linha de tempo.

No lado direito da janela do editor Project Area, em Timelines (consulte a Figura 10), é possível ver as iterações dos marcadores padrão que o modelo do processo estabeleceu ao criar a Project Area, incluindo o Sprint 1 e o Sprint 2, no Release 1.0.

  1. Selecione Release 1.0, em Process Iterations, e clique em Edit Properties para abrir o menu suspenso Edit Iteration (exibido na Figura 10).
Figura 10. Especificação das linhas de tempo do release e do sprint
Especificação das linhas de tempo do release e do sprint
  1. Mantenha o valor padrão em Iteration Type.
  2. O Identifier deve ser exclusivo, mas é possível alterá-lo se for necessário.
  3. Defina as datas Start e End do release (veja a Nota); selecione a caixa de opção "A release is schedule for this iteration" e clique em OK.

É possível editar as propriedades das iterações existentes do mesmo modo.

Nota:
Como o acompanhamento do trabalho é suscetível à passagem do tempo, as datas dependem de quando você trabalhará no exemplo. Inicie o release e a primeira iteração imediatamente ou em breve. Defina a data final do release para seis semanas, no mínimo. Cada sprint deve ter, no mínimo, duas semanas (normalmente, de segunda a sexta-feira, tirando os dias não úteis).

Nota:
Os decoradores triângulo azul pequeno no ícone do Release 1.0 e no ícone do Sprint 1 indicam o Release e a Iteração atuais.

Localize as tarefas atribuídas a você automaticamente

Algumas tarefas são criadas e atribuídas automaticamente à pessoa que cria a Project Area. Para listá-las, vá para Work Items > Shared Queries > Predefined e execute a consulta Open assigned to me. Execute essas tarefas para customizar a Project Area.

Dicas:

  • É possível fazer alterações adicionais à Project Area mais tarde. Para abrir tal área, clique com o botão direito do mouse nela e selecione Open (clique duas vezes para expandi-la ou retraí-la).
  • A Project Area é amplamente configurável. Na guia Process Configuration, em Project Configuration, há inúmeras opções para adaptar o projeto às suas necessidades. À medida que você se familiarizar com o Rational Team Concert, provavelmente desejará adaptá-lo à sua equipe (por exemplo, em virtude das discussões nas reuniões de Reflections). A customização do processo é uma ferramenta sofisticada que visa adequar o processo às necessidades da equipe, em vez de mudar o comportamento da equipe para que ela se adapte ao processo.
Figura 11. Configuração do projeto
Configuração do projeto

Especifique uma Team Area e inclua os membros

A tecnologia Jazz pode dar suporte a equipes razoavelmente grandes, com diversas linhas de tempo e subequipes. Em tais áreas, há as Team Areas que se destinam a organizar os membros da equipe. Apenas os membros na Team Area são elegíveis a serem designados ao trabalho relacionado à equipe. Mesmo que este exemplo apresente apenas uma equipe, ainda assim é necessário ocupar essa área com membros.

  1. Clique na guia Team Organization, na área de janela esquerda. Se esta não estiver aberta, use Window > Show View > Team Organization para abri-la.
  2. Expanda a pasta Havannah (que foi automaticamente criada na criação da Project Area).
  3. O nome padrão atribuído à equipe no momento da criação do projeto é Team 1. Clique com o botão direito do mouse na Team 1 e abra o editor Team Area.
  4. Digite Havannah Team para o nome da equipe.
  5. Inclua Allan, Delaney, Prasad e Rose como membros da equipe. Aja da mesma forma descrita anteriormente quando você incluiu Frank na Project Area. No assistente Add Team Members, é possível usar o caractere curinga * (asterisco) para retornar todos os membros (não tente utilizar tal caractere caso esteja usando um servidor do LDAP corporativo) e selecioná-los antes de atribuir a função Team Member.
  6. Inclua Sasha na função Scrum Master e, opcionalmente, atribua-lhe também a função Team Member; uma vez que, no contexto das funções do Rational Team Concert, os scrum masters não são automaticamente atribuídos como Team Members).
  7. Clique em Save.
Figura 12. Inclusão de membros em uma Team Area
Inclusão de membros em uma Team Area

Dica:
Normalmente, equipes grandes são compostas por subequipes. É possível refletir a estrutura da sua equipe, incluindo no seu projeto tantas subequipes adicionais quando apropriado.

Especifique a disponibilidade do membro da equipe

Para que os cálculos de carga de trabalho sejam precisos, ajuste a disponibilidade dos membros. Pode ser que um membro tenha outras responsabilidades (além da equipe) que limitem sua participação ou que ele tenha férias planejadas. Esses ajustes são feitos na página do usuário. Normalmente, espera-se que os próprios usuários mantenham essa área atualizada, no entanto, por ser parte importante do cálculo correto da Team Load, ela merece uma ilustração aqui.

  1. Caso ainda não tenha feito isso, clique na guia Team Organization (na área de janela esquerda) e expanda a pasta Havannah e Havannah team.
  2. Abra o user editor para Rose. Dê um clique duplo em um nome de usuário para abrir os detalhes do usuário.
  3. Rose está disponível para a equipe apenas 75% do tempo. Assim, clique na guia Work Environment (na parte inferior) e, na seção Work Assignment, clique na linha Havannah Team e na opção Change (veja a Figura 3).
  4. Por padrão, se um usuário estiver atribuído a apenas uma equipe, 100% do seu tempo (recursos) estará associado a tal equipe. Para reduzir a atribuição de Rose, selecione a atribuição e clique em Change. Reduza-a para 75% (veja a Figura 13).
  5. Clique em OK.

Isso ajustará o número de horas em que Rose estará disponível para as atribuições do trabalho.

Figura 13. Ajuste do ambiente de trabalho de um usuário
Ajuste do ambiente de trabalho de um usuário
  1. Ela também terá um dia de folga em breve. Alterne para a guia Scheduled Absences, clique em New (à direita da lista) e insira uma descrição e as datas da folga (veja a Figura 14).
  2. Clique em OK.
  3. Clique em Save para atualizar os detalhes do usuário Rose.
Figura 14. Inserção das ausências planejadas de um usuário
Inserção das ausências planejadas de um usuário

Criando a Product Backlog do projeto

Um dos artefatos mais importantes no método scrum é a Product Backlog.

  1. Para construí-la neste exemplo, vá para a visualização Team Artifacts (veja o lado superior esquerdo da Figura 15, abaixo) e, no projeto Havannah, selecione Release 1.0, clique com o botão direito do mouse para acessar o menu de contexto e selecione New > Plan.

Dica:
Talvez seja necessário abrir um ou mais nós da árvore para ver a iteração Release 1.0. Os planos adicionais de release e de sprint (quando disponíveis) ficam abaixo da linha de desenvolvimento (nesse caso, Main Development), mas o release e o sprint atuais estão visíveis no nível Plans para simplificar o acesso.

  1. Na janela New Plan exibida, insira a Product Backlog para o nome.
  2. Selecione Product Backlog como Plan Type
  3. Preserve os valores padrão em Team Members, Timeline e Iteration.
  4. Clique em Finish.

Dica:
Se não for possível salvar o plano, talvez você tenha de voltar e incluir a função Scrum Master nas configurações de Sasha.

Um editor de multipáginas será aberto para o plano de iteração Product Backlog (veja a Figura 15).

  1. Na página Overview, é possível inserir informações sobre o produto usando uma formatação estilo wiki.
  2. A área Attachments, na parte inferior da visualização do editor (visível apenas quando no modo de edição da página), é o lugar ideal para incluir todos os requisitos ou documentações em geral relacionados a esse release, de modo que eles fiquem prontamente disponíveis para todos os membros da equipe. A área da página também pode conter links para Web sites ou repositórios de documentos externos (quando necessário).
  3. Clique na guia Planned Items para iniciar a inclusão dos itens da lista não processada.
Figura 15. Editando a lista não processada
Editando a lista não processada

Visualização ampliada da Figura 15

Há diversos meios (conhecidos como modos) para se visualizar um plano. No lado direito da janela, é possível especificar como os itens no plano devem ser agrupados e que tipo de itens será excluído da visualização. Há vários modos de visualização predefinidos, denominados Lista não processada, Iterações, Equipes e Pane no Trabalho. Também é possível definir seu próprio modo de visualização customizado. Para fazer isso, use a opção Edit | Copy, no painel direito, abaixo de "View As". Os modos adicionais serão armazenados no servidor e ficarão disponíveis aos demais membros da equipe; quaisquer alterações nesses que sejam salvas afetarão todos os usuários da Project Area.

Agrupe os itens do plano por tipo

Para o Rational Team Concert Versão 1.0, os itens de um plano podem ser agrupados apenas por Owners, Categories, Tags, Planned Time, ou Folders. Os recursos da Versão 2.0 são muito mais sofisticados. Embora seja possível configurar os grupos de modos anteriores da V2.0, convém usar apenas estes modos mais recentes:

  • Lista não processada
  • Iterações
  • Equipes
  • Pane no Trabalho

Preencha a Product Backlog com os itens de trabalho

Na guia Planned Items da lista não processada, inicie a inclusão dos itens. Para o gerenciamento do projeto scrum, os itens na Product Backlog são denominados stories ou, quando maiores, epics (veja também os livros de Mike Cohn User Stories Applied e Agile Estimating and Planning - mencionados em Recursos). Uma story é uma descrição da funcionalidade a ser implementada no produto, frequentemente descrita nos termos de quais funções de usuário o recurso suporta e qual valor de negócios ele proporciona a tais funções. Uma story devidamente descrita inclui um resumo ou um título, alguma descrição ou explicação do recurso e as condições para a aceitação do recurso pelo Product Owner. No exemplo do Havannah, todos os itens estão redigidos como stories, assim você preencherá a sua lista não processada com stories. (Por questão de brevidade, a maioria das stories usadas neste exemplo inclui apenas o resumo e não deve ser confundida com uma story devidamente construída.)

  1. Defina o padrão para os novos itens como Story. Isso permitirá que você insira rapidamente os novos itens de trabalho usando Ctrl+Enter como um atalho de teclado.
    1. Clique com o botão direito do mouse na pasta Havannah Team.
    2. Selecione Add Work Item > Set Default > Story.
  2. Clique com o botão direito do mouse novamente na pasta Havannah Team, selecione Add Work Item e Story (ou use Ctrl-Enter).
  3. Insira o resumo para o novo item ilustrado na tela menor da Figura 16.
Figura 16. Itens planejados na lista não processada
Itens planejados na lista não processada

Visualização ampliada da Figura 16

  1. Inclua todos os itens solicitados pelo product owner.
  2. A qualquer momento, clique em Save, na parte superior da guia Plan, para salvar o seu trabalho.
  3. Depois da inclusão das stories, a próxima etapa do product owner é definir prioridades para elas. Os valores disponíveis para o atributo de prioridade são High, Medium e Low. As prioridades podem ser facilmente atribuídas usando o menu suspenso incorporado nos itens da lista (veja a Figura 17).

Dica:
Quando as prioridades predefinidas não são apropriadas para as necessidades do projeto, customizar a lista de prioridades na Project Area é fácil.

  1. Em seguida, é necessário classificar os itens dentro das prioridades. Tal classificação é realizada arrastando os itens para ordem apropriada dentro do grupo de prioridades. O sistema memoriza a ordem estabelecida pela ação arrastar e soltar (ou pelo uso do atalho Alt+cursor para cima ou para baixo). Se você arrastar uma story (por exemplo, de prioridade média) para um grupo diferente e soltá-la entre duas stories de prioridades diferentes, o Rational Team Concert redefinirá automaticamente o valor da prioridade de modo a corresponder às stories vizinhas.
Figura 17. Definição da prioridade dos itens de trabalho
Definição da prioridade dos itens de trabalho
  1. Quando a equipe incluir uma estimativa para a complexidade do item, insira Story Points usando os menus suspensos como ilustrado na Figura 9. (Consulte também os livros de Mike Cohn User Stories Applied e Agile Estimating and Planning, citados nos Recursos, uma vez que a discussão sobre estimativas e Story Points extrapola o escopo deste artigo.)
Figura 18. Definição da complexidade dos itens de trabalho
Definição da complexidade dos itens de trabalho

Epics e Stories

Por padrão, Epics e Stories são os itens de trabalho de uma Product Backlog. Caso a sua equipe também deseje consultar as tarefas ou algum outro tipo de item de trabalho (por exemplo, Defect) na Product Backlog, inclua o tipo de item de trabalho como um Top-Level Work Item Type na configuração da Project Area:

  1. Abra a Project Area na visualização Team Artifacts.
  2. Na guia Process Configuration, expanda Project Configuration, Configuration Data e Planning.
  3. Selecione Top-Level Work Item Types e inclua Tasks (ou outro tipo de item de trabalho) selecionando as caixas de opção correspondentes.

Evidentemente, essa não será uma grande Product Backlog se todos tiverem Story Summaries.

  1. Clique duas vezes em uma story para abrir seu editor (neste exemplo, ilustrado na Figura 19, a story diz "As a player, I can play against a weak engine that recognizes rings").
  2. No campo Description, forneça detalhes adicionais sobre o que se espera da story (uma descrição pode ser acrescentada ao incluir inicialmente a Story no plano). Neste caso, ele faz referência à documentação (fictícia) que está anexada à Project Area.
  3. O criador do item é automaticamente incluído no rol de assinantes do item. Se isso não for necessário, clique no link Subscribers, na parte inferior esquerda da seção Quick Information, e selecione Unsubscribe Me.
Figura 19. Detalhes de um item
Detalhes de um item

Visão ampliada da Figura 19

  1. Clique na guia Acceptance Test na parte inferior. Inclua os testes de aceitação identificados pela equipe e pelo product owner como prova de que a story foi concluída com êxito e de que ela satisfará às expectativas das partes interessadas.

Dica:
Outro meio eficaz para tratar a inclusão de detalhes durante a construção da lista é ativar o modo Preview no editor de planejamento da iteração. Na barra de ferramentas, clique no ícone óculos (veja a Figura 20); o editor se dividirá em dois para exibir lado a lado o plano da iteração e o item atualmente selecionado.

Figura 20. Visualizando os itens
Visualizando os itens

Visualização ampliada da Figura 20

Dica:
Para organizar e exibir os Epics e as Stories em uma ordem hierárquica na sua lista não processada, use um modo de visualização que apresente os itens de trabalho em uma visualização em árvore. O modo Pane no Trabalho exibe os itens em uma visualização em árvore, mas também é possível configurar concordemente outros modos.


Qual é o próximo passo

As partes subsequentes desta série abrangerão o planejamento e o gerenciamento do sprint (consulte "Outras informações nesta série"), além de detalhes do planejamento e da estimativa do software Agile.


Agradecimentos

Agradecemos a Dirk Baeumer, líder da equipe de planejamento do Jazz Agile, pela sua revisão técnica, e a David L. Schmidt, líder técnico da Tivoli Software Engineering, pela sua revisão geral, pelos comentários e pelo encorajamento.


Download

DescriçãoNomeTamanho
Rational Team Concert Scrum sample dataScrumSampleData.pdf54KB

Recursos

Aprender

Obter produtos e tecnologias

  • Obtenha os downloads e as atualizações do Jazz e do Rational Team Concert, e participe nas discussões no fórum em Jazz.net. (O registro gratuito é obrigatório.) Nesse site, também é possível inserir e examinar solicitações de melhoria e relatórios de erros.
  • Pratique a melhoria contínua usando a ferramenta IBM Rational Self-Check for Software Teams para dar suporte às reuniões de Reflections.
  • Faça download das versões de teste do software IBM Rational.
  • Faça download das versões de avaliação do produto IBM e tenha contato com as ferramentas de desenvolvimento de aplicativo e produtos de middleware do DB2®, Lotus®, Tivoli® e WebSphere®.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=446825
ArticleTitle=Gerenciamento de Projetos Scrum com o IBM Rational Team Concert Versão 2: Parte 1. Configure projetos, equipes e planos
publish-date=11122009