agile planning with microsoft team foundation server
Este tutorial explica como fazer o planejamento ágil usando o Microsoft TFS, que ajudará os gerentes de projeto a planejarem e rastrearem o trabalho em suas equipes:
Entre os vários artigos publicados em SoftwareTestingHelp.com sobre DevOps, vimos alguns bons artigos sobre DevOps do ponto de vista de Integração Contínua e Entrega Contínua usando Microsoft TFS, AWS e certamente ferramentas de código aberto como Ansible.
Um dos pré-requisitos para DevOps é um determinado processo forte como o AGILE, que traz agilidade para todo o processo SDLC, em que a área de foco é liberar o software em tempo hábil com ciclos de liberação mais curtos e feedback rápido. Portanto, o processo ágil se concentra principalmente na velocidade.
O que você aprenderá:
Planejamento ágil usando Microsoft TFS 2017
Antes de passar pelas diferentes seções deste artigo, seria bom conhecer alguns dos terminologias importantes usadas no Agile. Essas terminologias serão usadas ao longo deste artigo.
Pré-requisitos: Microsoft TFS 2017
Criar projeto de equipe TFS usando modelo de processo SCRUM
Começaremos primeiro criando um projeto de equipe TFS usando o modelo SCRUM, seguindo as etapas mencionadas abaixo.
Faça login no Microsoft TFS 2017 e clique em Novo projeto.
Insira um nome de projeto e selecione Scrum como o modelo. Clique em Crio.
Depois que o projeto for criado, adicione membros ao projeto clicando no + ícone.
Criar backlog do produto
Como você está ciente de que o Microsoft TFS é uma ferramenta ALM integrada que ajuda a criar Itens de Trabalho, fazer Planejamento de Projeto, criar Definições de Compilação e Definições de Versão com o recurso para realizar testes manuais.
Antes de qualquer planejamento Agile, precisamos começar definindo Corrida que é um prazo predefinido para o trabalho a ser feito. Clique em Configurações -> Trabalho e definir as sprints com datas de início e término.
Selecione o Sprint e defina as datas de início e término.
Aqui, estaremos nos concentrando na criação de itens de trabalho que farão parte integrante do planejamento ágil. Então, vamos começar criando o backlog do produto que contém uma lista priorizada de todos os recursos que farão parte do seu aplicativo ou produto.
O product owner mantém esse backlog e com a ajuda da equipe scrum, ele decide a viabilidade de trabalhar em um determinado sprint.
Para criar um product backlog do No menu da seção Trabalho, selecione Backlogs.
Clique em Novo, insira um Título para o item do backlog e clique em Adicionar .
O item do backlog do produto é adicionado ao backlog. Em um sentido teórico, você pode considerar o Item do Backlog do Produto como uma História de Usuário ou uma Solicitação de Mudança. Eles normalmente serão decompostos em várias tarefas de desenvolvedor e casos de teste.
pl sql para iniciantes com exemplos
Você também pode reordenar com base na prioridade. Basta arrastar e soltar os itens de trabalho acima ou abaixo.
Abra o item de trabalho e adicione o esforço. Aqui, o esforço pode ser de acordo com as necessidades do projeto de pontos da história ou dias ou horas. A estimativa de esforço seria adicionada assim que o item fosse decomposto em tarefas. Atribuir um proprietário na seção ‘Atribuído a’ e defina o ‘Estado’ como Aprovado para desenvolvimento. Clique em Salvar e fechar.
Em seguida, atribua o item ao Sprint 1 arrastando e soltando para o Sprint 1.
O caminho de iteração altera o item para Sprint1 conforme exibido na imagem abaixo.
Conforme movemos o item para Feito Estado, a velocidade que define o número total de pontos de história que a equipe scrum atinge em uma sprint é mostrada clicando no gráfico de velocidade superior direito.
Então, em resumo, podemos dizer que a equipe completou 8 story points no Sprint 1, conforme mostrado no gráfico de velocidade acima.
Planejamento de capacidade
Para cada Sprint, podemos definir o número de horas que cada membro estará trabalhando para o projeto atribuído. A visualização da capacidade de cada sprint define isso. Esta visualização também captura a atividade em que cada membro trabalha, como Design ou Desenvolvimento ou Relatórios, etc.
Clique no Sprint apropriado. Neste caso, abra Sprint 1 e vá para o Visão de capacidade . Atualize conforme mostrado abaixo.
Na imagem acima, como o usuário Dev1 trabalha apenas 4 horas por dia durante o período de sprint de 2 semanas, que é de 10 dias úteis. O Trabalho Atribuído a mostra que ele foi atribuído a uma tarefa que precisa de 8 horas para ser concluída de 40 horas para o período de sprint de 2 semanas. Isso é calculado como 4 (horas por dia) * 10 (2 semanas) = 40 horas.
Um cálculo semelhante é feito para o usuário Dev2.
Criação de tarefas
Como agora temos o Item do Backlog do Produto ou a História do Usuário definidos e também a capacidade planejada para cada usuário no projeto, podemos dividi-lo em tarefas de desenvolvedor. Na tela de trabalho, clique no Sprint 1 e, a seguir, clique no sinal + Adicionar Tarefa para o item do backlog do produto.
Atribua-o ao desenvolvedor e insira um valor em horas para o campo de trabalho restante. Clique em Salvar e Fechar.
A tarefa criada está vinculada ao Item do Backlog do Produto.
Aqui, o campo Trabalho restante é o número de horas restantes para concluir uma tarefa. Como no exemplo acima definimos o campo para 8 horas e digamos que o desenvolvedor ao final do dia tenha concluído apenas 2 horas de trabalho na tarefa, o campo da hora restante seria atualizado para 6. Você poderia fazer isso 0 quando não há mais trabalho, ou se há 1 hora ou menos de trabalho restante ou algo entre 0 e 1 hora.
A partir desse valor, o TFS pode criar um gráfico burndown para o sprint, que é uma das métricas muito úteis no Agile. O processo acima é para o modelo SCRUM e não tem o campo Estimativa Original no item de trabalho Tarefa.
Se o projeto de equipe TFS for configurado usando o modelo de processo Agile ou CMMI, haverá uma opção para inserir o campo Estimativa original.
Para adicionar o campo Estimativa Original ( Microsoft.VSTS.Scheduling.OriginalEstimate ) no tipo de item de trabalho Tarefa usando o modelo de processo SCRUM, ele deve ser adicionado como um campo personalizado. Você pode usar o witadmin exportwitd , que é uma opção de linha de comando. Adicione o campo no arquivo XML exportado e importe-o de volta para o projeto de equipe.
Sprints Futuros
O Item do Backlog do Produto ou a História do Usuário também podem ser planejados para o futuro arrastando e soltando o item em qualquer outro sprint futuro.
Usando o Taskboard
Uma vez que o Plano de Sprint está em vigor, podemos agora visualizar o progresso de cada Tarefa na visualização do Painel de Tarefas. Portanto, o painel de tarefas fornece um fluxo visual das tarefas e seu status. Portanto, durante cada reunião do scrum, você pode verificar o status de cada tarefa atribuída aos membros.
Você também pode ver o resumo do total de trabalho restante a ser concluído.
como abrir um arquivo apk no android
É muito importante monitorar o status e o progresso e pode ser feito por meio do quadro de tarefas. Clique no Vista do tabuleiro para o Sprint.
Este quadro é uma visão muito útil e pode ser usado para fins de relatório durante a reunião diária.
para) Se os desenvolvedores com tarefas atribuídas começaram a trabalhar nas tarefas, você pode mover as tarefas de Façam estado para Em andamento estado simplesmente arrastando e soltando o recurso.
b) Altere as horas de trabalho restantes da tarefa para um usuário Dev2 de 8 para 5 horas restantes. As horas da tarefa em andamento serão então atualizadas de acordo.
c) O gráfico burndown, clicando no canto superior direito, é atualizado automaticamente.
d) Agora feche a tarefa atribuída ao Dev2 arrastando e soltando a tarefa para Feito Estado. As horas de trabalho restantes para esta tarefa são diminuídas automaticamente para 0 e o gráfico burndown também é atualizado.
Revisão e retrospectiva da sprint
Bem, o trabalho está feito agora e o prazo de sprint acabou. A equipe acha que agora é hora de relaxar ou fazer uma pausa? Absolutamente um grande NÃO. Agora é hora de discutir a parte muito importante do ciclo de vida do SCRUM, que é a revisão e a retrospectiva.
A revisão do Sprint concentra-se nas entregas, analisa os itens da lista de pendências do produto CONCLUÍDO e fornece uma demonstração aos clientes. Além disso, é muito importante discutir quais itens do backlog do produto não foram feitos e por que, e o mais importante, coletar feedback dos clientes e planejá-los para sprints futuros. A revisão do sprint normalmente é feita entre o proprietário do produto, a equipe de desenvolvimento e os clientes.
A retrospectiva da Sprint enfoca os aspectos do processo, como o que deu certo e o que não deu? Portanto, você também precisará obter feedback sobre o processo e as pessoas. Como este é um aspecto muito importante do ciclo de vida Agile, você pode aprender mais sobre retrospectivas.
Portanto, é muito possível que haja trabalho inacabado em cada sprint. Neste cenário, mova os PBIs / Tarefas para o Backlog do Produto ou para o próximo Sprint que o Dono do Produto decidir.
Mas, por enquanto, onde armazenamos as análises e retrospectivas? Você pode salvá-los como parte da discussão do item de trabalho ou criar um novo item de trabalho para conter pontos de ação retrospectivos e feedback.
Conclusão
Vimos neste artigo como o Microsoft Team Foundation Server como uma ferramenta ALM fornece uma maneira rápida e organizada de começar a trabalhar em seu aplicativo seguindo o processo Agile Scrum.
Precisamos garantir que todas as equipes que seguem o processo Agile SCRUM precisem definir e criar os seguintes aspectos para planejar e gerenciar adequadamente o trabalho de suas equipes.
- Use o modelo de processo SCRUM apropriado no Microsoft TFS
- Criar backlogs de produtos
- Especificando o cronograma de Sprint e a capacidade da equipe
- Selecionando itens para sprint backlog
- Decompondo PBIs ou histórias de usuários em tarefas
- Use gráficos Burndown para monitorar o progresso
- Muito importante usar o Taskboard para monitorar o progresso
- Por último, conduza uma revisão de sprint eficaz e retrospectiva
Leitura recomendada
- Como ser um bom mentor, treinador e um verdadeiro defensor de equipe em um mundo de testes ágeis? - A inspiração
- Terminologia Agile e Scrum: Um Glossário para Conceitos Agile / Scrum
- Como tornar o processo de estimativa ágil fácil com o Planning Poker
- Princípios de teste modernos para metodologia ágil em testes
- Times Scrum Auto-Suficientes: Como Criar uma Equipe Auto-Suficiente?
- Reuniões Retrospectivas do Agile - Por que é necessário e algumas maneiras divertidas de conduzi-lo
- 4 etapas para desenvolver a mentalidade de teste ágil para uma transição bem-sucedida para o processo ágil
- Formato do exame ISTQB Foundation e diretrizes para resolver documentos