Planejar um projeto (CMMI)
O resultado desejado do planejamento de um projeto é um plano que inclui um escopo, uma agenda, um orçamento, um plano de gerenciamento de riscos e um compromisso e uma aprovação de todos os participantes. Com um plano de projeto combinado, você deseja dar prosseguimento a análise, criação, desenvolvimento, teste e, eventualmente, entrega.
Você pode reduzir o risco usando um método de desenvolvimento iterativo. As iterações permitem que você demonstre um produto funcionando parcialmente antes do final de cada iteração e atue em comentários da demonstração Portanto, o plano fornece uma forma geral e está sujeito à revisão e ao refinamento antes do início de cada iteração.
Coletando e modelando os requisitos
Essa atividade é sobre discutir o que o sistema deve fazer, com participantes da empresa, usuários em potencial e especialistas no assunto. É importante compreender o contexto de negócios. Se for solicitado que você escreva um aplicativo para agentes de polícia, ele ajudará você a entender seus jargões, procedimentos, e regras.
Os modelos UML são uma ferramenta útil para expressar e pensar sobre relações complexas. Você pode desenhá-los em Visual Studio e vinculá-los a outros documentos e a itens de trabalho Team Foundation. Para obter mais informações, consulte Requisitos de usuário da modelagem.
Atualize e refine o modelo de requisitos em todo o projeto. Conforme cada iteração se aproxima, adicione mais detalhes aos aspectos de modelo que são relevantes para essa iteração. No modelo, você pode derivar testes de verificação.
Para obter mais informações, consulte Requisitos de desenvolvimento e Desenvolvendo testes a partir de um modelo.
Criando requisitos incrementais de produto
Os requisitos, conforme você os coletou de seus clientes, não são diretamente apropriados para a finalidade de programar o desenvolvimento incremental. Por exemplo, para esclarecer o procedimento quando um usuário compra algo de um site, você pode escrever uma série detalhada de etapas: o cliente consulta o catálogo, adiciona o item ao carrinho de compras, faz o check-out do carrinho de compras, fornece o endereço, e realiza o pagamento; o depósito programa a entrega; e assim por diante. Essas etapas, ou um diagrama equivalente de atividade, não são requisitos incrementais.
Em vez disso, o primeiro incremento do seu sistema pode oferecer somente um item à venda, entregá-lo a apenas um endereço, e executar apenas uma transação de teste com o serviço de pagamento. O segundo incremento pode fornecer um catálogo que consiste em uma lista simples. Incrementos posteriores podem adicionar a opção de papel de embrulho, de compra ou de solicitar catálogos que são fornecidos por fornecedores diferentes. Alguns incrementos podem ser sobre a qualidade do serviço, como a capacidade de manipular 1.000 clientes em vez de apenas um.
Em outras palavras, os incrementos recentes devem exercitar os principais casos de uso ponto-a-ponto e gradualmente adicionar funcionalidade.
Se você trabalha com um produto existente, o princípio é o mesmo, mas você parte da funcionalidade existente. Se você não estiver familiarizado com seu design interno, o custo das atualizações pode ser difícil de estimar. Vale ser liberal com suas classificações para as alterações anteriores.
Para obter mais informações, consulte Requisitos de desenvolvimento.
Inserindo e editando requisitos de produto
Registre os requisitos incrementais do produto como itens de trabalho do requisito no Team Foundation e defina o tipo de requisitos como Recurso. Você pode criar requisitos de retorno usando o TWA ou o Team Explorer. Se houver vários itens de trabalho que você deseja criar ao mesmo tempo, você pode usar o Excel.
Estimando requisitos do produto
A equipe de desenvolvimento deve estimar o trabalho que é necessário para desenvolver cada requisito do produto. A estimativa deve ser inserida em horas, no campo Estimativa original do item de trabalho.
No início do projeto, é necessário somente uma avaliação superficial.
Interrompa grandes requisitos de produto em menores. O ideal é que cada requisito do produto use apenas alguns dias de tempo de desenvolvimento.
Atribuindo requisitos do produto para iterações
Os representantes dos participantes de negócios e a equipe de desenvolvimento devem trabalhar juntos para atribuir requisitos de produtos a iterações. Normalmente, você faz isso em uma reunião, onde você compartilha ou projeta a exibição do Office Excel da consulta de Requisitos de Produto.
A atribuição é concluída usando as seguintes informações:
A prioridade do requisito. Consulte as notas na próxima subseção.
O custo estimado. Dado o número de membros da equipe e o comprimento da iteração, cada iteração tem apenas um número fixo de horas que estão disponíveis para desenvolvimento. Além disso, um número significativo dessas horas será usado para o planejamento de iteração e outras tarefas que não envolvem diretamente o desenvolvimento.
Dependências entre os requisitos do produto. Em uma série incremental de requisitos, os requisitos mais simples devem ser abordados antes dos aprimoramentos na mesma área.
Você pode definir o requisito em um item de trabalho especificando uma variedade de informações, como as ilustrações mostram:
.png "Formulário de item de trabalho de requisito")
Algumas diretrizes sobre priorização
Muitos esquemas detalhados existem para a priorização. Examinaremos alguns desses nós quando considerarmos planejamento de iteração. Por enquanto, a nível de projeto, incluímos algumas diretrizes que podem ser úteis para ajudar a gerenciar o risco e otimizar o valor adicionado.
Priorize os cenários mínimos completos.
Visa obter um cenário completo simples desde o início do projeto, como possível. Posteriormente, adicione mais recursos às diferentes partes do cenário. Essa prática garante que as funções da entidade de segurança da plataforma e as ideias da entidade de segurança nos requisitos sejam testadas antecipadamente.
Por outro lado, não divida a agenda de acordo com a arquitetura. Uma agenda que conclui o banco de dado, a lógica comercial e, em seguida, a interface do usuário provavelmente precisará de muito retrabalho de integração das partes no final. Da mesma forma, uma separação horizontal como {componente de venda; componente de armazenamento; componente de pagamento} não é recomendada. Provavelmente geraria um sistema maravilhoso para vender na Web, mas execute-o fora de tempo antes do negócio ter meios de obter dinheiro de seus clientes. Os componentes completos só poderão ser agendados para iterações posteriores se elas forem realmente suplementos opcionais.
Priorize o risco técnico.
Se um cenário inclui um elemento tecnicamente arriscado, desenvolva-o no início da agenda. Use uma abordagem de "falha antecipada" para o risco. Se algo não puder ser feito, convém saber disso no início do projeto para que possa ser cancelado ou substituído por uma abordagem alternativa. Então, priorize os requisitos tecnicamente arriscados nas iterações iniciais.
Priorize a redução de incerteza.
Os participantes de negócios não terão certeza quanto a alguns requisitos. É difícil prever qual comportamento do produto funcionará melhor no contexto de negócios. Priorize o trabalho suscetível de reduzir as incertezas. Muitas vezes, isso pode ser atingido ao desenvolver uma versão mais simples do cenário com a qual os usuários podem fazer experiências. Adia o cenário completo para uma iteração posterior, na qual os resultados dessas experiências poderão ser considerados.
Priorize os requisitos altamente importantes.
Se possível, tente estabelecer uma função de oportunidade de custo de atraso para cada cenário. Use esses para determinar os requisitos que potencialmente podem transferir mais valor para clientes, de maneira mais rápida. Priorize esses requisitos em iterações anteriores. Isso pode dar a opção de liberar um produto parcial antecipadamente
Agrupe os cenários que são comuns a várias pessoas.
Se você tiver cenários que têm o utilitário para duas ou mais pessoas, agrupe esses juntos. Classifique-os pelo número de pessoas que exigem o cenário. Priorize os cenários que se aplicam a um número maior de pessoas em iterações iniciais.
Classifique pessoas.
As pessoas representam os segmentos de mercado ou grupos de usuários. As pessoas ou proprietários comerciais de marketing devem ser capazes de articular a prioridade de tais segmentos ou grupos com base no utilitário a ser enviado ou no valor do segmento. Se os segmentos ou grupos de usuários puderem ser classificados por prioridade, mostre isso listando as pessoas de cada segmento por classificação. Identifique os cenários para as pessoas com classificação mais alta, e priorize esses nas iterações anteriores na agenda.
Em geral, desejamos priorizar a redução de risco devido à possibilidade de falha. Desejamos priorizar a funcionalidade comum porque é provável que seja necessário ou não alterar. Desejamos priorizar requisitos mais importantes. Queremos ativar a opção para a versão anterior do produto a um subconjunto de personas priorizando todos os cenários que são necessários para atender as necessidades de qualquer uma persona.
Planejando testes
A estimativa de trabalho para cada requisito deve incluir o esforço que é necessário para testar o requisito, manualmente ou criando um teste automatizado.
Antes de ser considerado como concluída, cada requisito do produto deve ser vinculado a um conjunto de itens de trabalho de caso de teste que, juntos, demonstram se o requisito foi atendido e se os testes devem passar.
Quando você cria ou revisa os requisitos do produto, o plano de teste correspondente deve ser atualizado.
Revisando os requisitos do produto
Visite esta atividade novamente antes de cada iteração para considerar os requisitos revisados e novos, as prioridades revisadas e as estimativas revisadas. Haverá mais revisões nas primeiras iterações.
Depois das primeiras iterações, os membros da equipe de desenvolvimento ficarão mais seguros sobre as estimativas. Eles devem passar pelas estimativas da próxima ou duas próximas iterações e revisar os campos Estimativas Originais dos requisitos que foram atribuídos a essas iterações.