Padrão de Capacidade: Desenvolver um Incremento da Solução
Projetar, implementar, testar e integrar a solução para um requisito dentro de um contexto definido.
DescriçãoEstrutura de Decomposição de TrabalhoAlocação de EquipeUso de Produto de Trabalho
Objetivo
  • Para desenvolvedores: Para criar uma solução para o item de trabalho, o qual eles são responsáveis.
  • Para gerentes de projeto: Para ter uma forma, baseada em metas, de acompanhar o status do projeto.
Relacionamentos
Contexto
Descrição

Introdução

Execute esta atividade como uma forma de executar o planejamento e o desenvolvimento baseado em metas. O trabalho é selecionado pelos desenvolvedores e o progresso do trabalho é acompanhado com base nas metas alcançadas pelo uso do código fonte projetado, testado pelos desenvolvedores e integrado.

Contexto do que está sendo desenvolvido

Um contexto pode ser especificado quando um requisito é atribuído para ser desenvolvido, especificando assim o tamanho do requisito a ser desenvolvido em uma iteração. O desenvolvimento pode focar em uma camada (tal como a interface de usuário, a lógica de negócio ou o acesso à base de dados), em um componente, e assim por diante.

Independente de um contexto estar especificado ou não, a responsabilidade do desenvolvedor é de executar o design e a implementação deste requisito. O desenvolvedor também escreve e executa os testes de desenvolvedor para certificar-se que a implementação funciona como projetada, de forma unitária e integrada no código base.

Visão geral do fluxo de trabalho

Mudanças típicas exigem algum esforço para projetar a solução antes de passar para a implementação, mesmo que seja apenas um exercício mental que resulte em um produto de trabalho de curto prazo. O design para alterações triviais na implementação existente (por exemplo, para suportar algum requisito) pode ser auto-evidente no contexto da arquitetura e do design existentes.

Uma vez que a organização da solução técnica esteja evidente, defina os testes de desenvolvedor que irão verificar a implementação. Esta abordagem orientada a teste garante que as considerações de design têm de fato ocorrido antes da solução ser codificada. Os testes são executados na frente e, se falharem, define claramente os critérios para determinar se a implementação funciona como previsto.

Os testes que falham, conduzem a uma implementação da solução até a conclusão, na qual você executa os testes novamente. Este ciclo mais interno de implementação e teste de desenvolvedor é repetido até que os testes passem.

A execução dos testes sem falhas, não significa necessariamente que a solução seja de alta qualidade e adequada. É apropriado revisar o design neste ponto. Esse caminho é cíclico no processo, uma vez que qualquer alteração no design pode afetar os testes de desenvolvedor e a implementação.

Se os testes passarem o design da solução for adequado, existe mais um ciclo possível. É melhor manter os ciclos internos de design evolucionário, orientados a testes, os mais curtos possíveis. Elabore alguma solução de design, de pequena escala, para uma parte do item de trabalho, defina um ou dois testes para a implementação desta parte da solução, execute os testes com sucesso, verifique a qualidade, e então continue com a abordagem de testar-primeiro, até que esta parte do design esteja funcionando. Então, no ciclo mais externo da atividade, volte e projete uma outra parte do item de trabalho para se aproximar da conclusão.

Propriedades
Orientado a Eventos
Múltiplas OcorrênciasYes
Em Andamento
Opcional
PlanejadoYes
Repetível
Uso
Notas de Uso

Esta atividade ocorre várias vezes durante cada iteração. Normalmente, existe uma instância para cada item de trabalho planejado para a iteração. Quando instanciado em um plano de projeto, o padrão transforma-se em uma tarefa de desenvolvimento a ser escolhida por um ou mais desenvolvedores, e você deve alterar seu nome, incluindo o nome real do requisito. Opcionalmente, as palavras Incremento de Solução podem ser suprimidas, e o padrão pode ser instanciado da seguinte forma:

Desenvolver o nome_do_requisito (dentro do contexto nome_do_contexto)

Se um contexto for especificado, haverá uma instância deste padrão para cada requisito em cada contexto.

Exemplo

  1. Desenvolver o cenário 1 (dentro do contexto interface do usuário)
  2. Desenvolver cenário 1 (dentro do contexto lógica de negócio e acesso ao banco de dados)
  3. Desenvolver o cenário 2
  4. Desenvolver o requisito suplementar 1

Note que existem quatro instâncias deste padrão no exemplo acima:

  • As duas primeiras estão relacionadas ao mesmo requisito (cenário 1), mas em dois contextos diferentes.
  • As duas últimas estão relacionadas a requisitos diferentes e sem contexto especificado.