Atividades de iteração
No MSF for CMMI Process Improvement, você planeja um projeto como uma série de iterações. Cada iteração tem normalmente de quatro a seis semanas de duração, período em que a equipe de desenvolvimento implementa um conjunto especificado de requisitos.
No início de uma iteração
O planejamento de iteração ocorre antes ou no início de cada iteração. Inclui as seguintes tarefas:
Revisar os requisitos atribuídos à iteração e defini-los com mais detalhes.
Criar itens de trabalho de tarefas para o trabalho que deve ser executado para implementar e testar cada requisito. Vincular as tarefas ao item de trabalho de requisito usando o tipo de link pai.
Definir o campo Estimativa Original de cada tarefa. Dividir as tarefas que possuem estimativas mais longas que alguns dias.
Comparar as estimativas com o tempo que está disponível para a iteração. Se o total estimado for muito longo, simplifique alguns dos requisitos ou adie-os para iterações posteriores.
Para obter mais informações, consulte Planejar uma iteração (CMMI).
Durante uma iteração
Execução das tarefas
Os membros da equipe iniciam e concluem as tarefas, gravando esses eventos em itens de trabalho. A conclusão de uma tarefa pode incluir o check-in do código de programa e outros artefatos. Cada tarefa deve durar não mais que alguns dias; as tarefas principais são divididas durante o planejamento de iteração. Para obter mais informações, consulte Escrever novo código para uma história de usuário.
Se um membro da equipe encontrar qualquer obstáculo para seu trabalho que não pode ser resolvido imediatamente, ele deverá registrar um item de trabalho de problema.
Testes
Os testes manuais ou automáticos devem ser desenvolvidos, e os casos de teste devem ser vinculados aos requisitos do produto. Um requisito do produto não pode ser considerado concluído até que o item de trabalho seja vinculado aos casos de teste que passam e demonstram que estão funcionando.
O trabalho de desenvolvimento para os testes deve ser incluído nas tarefas que são vinculadas ao requisito do produto.
Compilações sem interrupção e noturnas
O sistema de compilação compila o produto a partir das atualizações recentemente submetidas a check-in e executa testes automatizados. Você pode definir testes de entidade de segurança para execução contínua, bem como definir um conjunto completo para execução todas as noites. Essa prática ajuda a garantir que vários incrementos não criem um acúmulo de bugs. Para obter mais informações, consulte Configurar e gerenciar seu sistema de compilação.
Reunião breve
A equipe toda conduz uma breve revisão diária do andamento das tarefas da iteração. Os membros da equipe podem usar o painel de tarefas ou projetar o Painel de Andamento no mural, compartilhá-lo usando o Office Live Meeting ou ambos.
Cada membro da equipe relata rapidamente o progresso recente, o trabalho disponível para o dia e todos os problemas de bloqueio.
O gerente de projetos ou o líder da equipe relata o progresso na resolução de problemas. Para obter mais informações, consulte Gerenciar problemas (CMMI).
A contagem de bugs é examinada. Os bugs devem ter prioridade sobre os novos desenvolvimentos. Tente manter a contagem de bugs baixa ao longo do projeto. Se o número de bugs aumentar, conversem sobre as causas e o impacto possível sobre o trabalho de desenvolvimento.
A taxa de burndown é examinada.
Ajustes de escopo
O gráfico de burndown pode indicar que as tarefas não serão concluídas até o final da iteração. Nesse caso, o gerente de projetos ou o líder da equipe inicia uma discussão sobre como os requisitos podem ser simplificados de modo que as tarefas possam ser cortadas. Para obter mais informações, consulte Relatório de Burndown e Taxa de Gravação.
Os requisitos e os testes correspondentes são ajustados. Um novo recurso do requisito é colocado no plano de projeto para a funcionalidade ausente. Na revisão do plano de projeto que acontece no final da iteração, o recurso pode ser atribuído a uma iteração ou um corte futuros.
As solicitações de alteração e os riscos não são considerados durante uma iteração.
Triagem
Alguns membros da equipe (geralmente não a equipe toda) reúnem-se regularmente para revisar bugs. Cada membro da equipe deve registrar um bug ao descobrir um defeito. Um bug registrado começa no estado proposto, e a finalidade da reunião de triagem é decidir se ele será corrigido, adiado para uma iteração posterior ou rejeitado.
Para obter mais informações, consulte Acompanhar bugs.
No final de uma iteração
Verificação
Os requisitos serão considerados concluídos somente se os testes associados forem aprovados. Para obter mais informações, consulte Verificar requisitos.
Retrospectiva
O aprimoramento do processo é uma importante meta do CMMI.
Uma retrospectiva de iteração reflete o que foi satisfatório ou não na iteração e considera aperfeiçoamentos no processo e nas ferramentas usadas pela equipe. Está disponível na Web um volume significativo de material sobre retrospectivas.
Os membros da equipe devem evitar qualquer atribuição de culpa. Tente melhorar o processo para que os erros cometidos por indivíduos tenham menos probabilidade de terem um efeito.
Quando você introduz uma alteração no processo, verifique se a equipe concorda com as seguintes decisões:
Como vocês saberão que essa foi uma melhoria.
Quando vocês farão essa avaliação.
O que vocês farão em razão disso.
Integração
Se esse projeto for parte de um programa maior, cada equipe realiza seu trabalho em uma ramificação do sistema de controle de versão. A ramificação principal é reservada para integração do trabalho das equipes. No final de uma iteração, a equipe pode executar uma integração com a ramificação principal. Para obter mais informações, consulte Usar ramificações para isolar riscos no Controle de versão do Team Foundation.
A integração consiste em duas etapas:
Uma integração de encaminhamento, para mesclar o código mais recente de ramificação principal na ramificação de projeto local. Depois de executar a mesclagem, testes automáticos e manuais são executados. Isso criará alguns defeitos. Os defeitos são corrigidos em alta prioridade.
Uma integração inversa. O código da ramificação local é mesclado na ramificação principal, e a compilação e o conjunto completo de testes na ramificação principal são executados. As alterações serão revertidas se ocorrer algum erro. A introdução de erros na ramificação principal não é aprovada. Se nenhum erro ocorrer, a integração será declarada concluída.
Recomendamos que você execute uma integração no final da cada iteração. Se você adiá-la, a lista de bugs a serem corrigidos após a integração de avanço será maior. Se demorar muito para corrigir os bugs, a ramificação principal terá o novo material, e você terá de executar outra integração de avanço.
Preparando-se para a próxima iteração
Mais para frente ou no fim de uma iteração, várias atividades de gerenciamento do projeto são executadas. Elas incluem examinar os riscos e o plano em relação às solicitações de alteração e estimativas de desenvolvimento alteradas.
Para obter mais informações, consulte Atividades de projeto.