Watch azure boards : gerenciamento de projetos com azure devops

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Índice Show

Processo de gerenciamento de projetos no Azure Boards
Neste artigo
Implementar o desenvolvimento iterativo
Ciclos maiores e menores
Projetos grandes
Artigos relacionados
O que é o Azure Boards?
Para que serve o Azure DevOps?
Quais modelos de processo disponíveis no Azure DevOps?
Qual nome do template de processo do Azure DevOps usado na prática?

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

Processo de gerenciamento de projetos no Azure Boards

Artigo
11/17/2022
4 minutos para o fim da leitura

Neste artigo

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Você pode usar a seção Gerenciamento de Projetos da orientação de aprimoramento do processo DE CMMI (MSF for Capability Maturity Model Integration) para entender melhor como gerenciar, planejar e coordenar o desenvolvimento e a manutenção de produtos de software. Para obter mais informações sobre o CMMI, consulte Background to CMMI.

O agrupamento de gerenciamento de projetos de áreas de processo no CMMI inclui Planejamento de Projetos, Monitoramento e Controle de Projetos, Gerenciamento de Contratos de Fornecedores, Gerenciamento Integrado de Projetos, Gerenciamento de Riscos e Gerenciamento Quantitativo de Projetos. Todos, exceto o Gerenciamento Quantitativo de Projetos, fazem parte dos níveis de modelo 2 ou 3. O Gerenciamento Quantitativo de Projetos é uma atividade de nível de modelo 4 que reflete como as organizações de alta maturidade usam dados quantitativos, estatisticamente defensivos e imparciales para tomar decisões de gerenciamento e direcionar projetos para um resultado bem-sucedido e previsível.

As atividades de gerenciamento de projetos representam custos econômicos em atividades de engenharia com valor agregado. Essas atividades são necessárias e importantes para gerenciar riscos, coordenar esforços de engenharia bem-sucedidos e definir as expectativas do cliente adequadamente. No entanto, você deve minimizar o esforço usado nessas atividades. "Pouco e muitas vezes" é um bom mantra. Lotes menores reduzem os custos de complexidade e coordenação. Ao definir e personalizar sua definição de processo, você deve ter em mente que suas atividades de gerenciamento de projeto devem ser o mínimo possível e, ao mesmo tempo, satisfazer o perfil de risco do seu projeto.

Implementar o desenvolvimento iterativo

O Team Foundation junto com o modelo de processo MSF para CMMI dá suporte ao trabalho iterativo. O desenvolvimento iterativo gerencia o risco fornecendo software demonstrado e testado em intervalos definidos em todo o projeto.

A agenda do projeto é organizada em uma série de iterações que normalmente têm de quatro a seis semanas de duração. Cada iteração termina com uma demonstração de software utilizável e testado. Para agendar sprints, consulte Agendar sprints.

O plano de projeto indica quais requisitos de recurso serão desenvolvidos em cada iteração. O plano de projeto é desenvolvido na Iteração 0 e revisado no início de cada iteração. Para criar e exibir o plano de projeto, consulte Criar lista de pendências.
Cada plano de iteração indica quais tarefas serão executadas durante essa iteração. A maioria das tarefas é o trabalho de desenvolvimento e teste que atende aos requisitos de recurso nessa iteração. O plano de iteração pode ser exibido por meio da página de pendências de sprint.
O trabalho iterativo não gerencia automaticamente os riscos. Para minimizar riscos, você deve organizar o plano de projeto em incrementos. As iterações iniciais devem fornecer uma "fatia fina de ponta a ponta", ou seja, uma versão mínima dos comportamentos mais importantes do produto. Iterações posteriores adicionam mais funcionalidade.
Por outro lado, seria muito menos útil agendar a parte de vendas de um site de compras para o primeiro terço do projeto, o sistema de armazéns no segundo terço e o sistema de pagamentos no último terço. Essa agenda correria o risco de produzir um site de vendas atraente e rico em recursos que não tem meios para a empresa receber dinheiro de seus clientes. É iterativo sem ser incremental.
O desenvolvimento incremental tem os seguintes benefícios:
Atende aos requisitos verdadeiros. Os stakeholders têm a oportunidade de experimentar o produto, o que sempre resulta em melhorias em seus requisitos declarados.
Ajusta a arquitetura. Permite que a equipe de desenvolvimento descubra e resolva as dificuldades que ocorrem com sua plataforma ou possíveis melhorias em seu design.
Garante resultados. Os stakeholders sabem que, mesmo que os recursos do projeto sejam cortados parcialmente, as despesas até o momento não foram desperdiçadas. O mesmo acontece se as estimativas de desenvolvimento se mostrarem otimistas e você deve descartar os recursos menos importantes.
Para obter mais informações sobre como expressar os requisitos de forma apropriada para desenvolvimento incremental, consulte Desenvolver requisitos.

Ciclos maiores e menores

O projeto e a iteração não são os únicos aspectos cíclicos do desenvolvimento de software. Por exemplo, em uma iteração, os membros da equipe iniciam e completam tarefas e verificam o código. O sistema de build cria o produto de forma contínua ou noturna. A equipe realiza uma breve revisão diária do progresso nas tarefas de iteração.

Projetos grandes

Um projeto no qual uma equipe trabalha por meio de uma série de iterações pode fazer parte de um projeto ou programa maior. Um projeto grande tem várias equipes que trabalham em paralelo. Cada equipe normalmente tem de quatro a 16 pessoas.

Abra um branch de controle de versão separado para cada equipe. Cada equipe deve se integrar ao branch principal no final de cada iteração. Para obter mais informações, consulte Usar branches.

Reserve o branch principal para integração e testes. O computador de build deve executar um conjunto completo de testes após uma integração.

Atribua uma área a cada equipe para que seus itens de trabalho possam ser facilmente separados dos outros. Para obter mais informações, consulte Personalizar caminhos de área e iteração.

As equipes podem compartilhar uma série de integrações, mas o compartilhamento nem sempre é necessário. Se as equipes não sincronizarem as integrações, cada equipe deverá ter seu próprio prefixo para seus nomes de iteração.