Conceito: Equilibrar as prioridades concorrentes para maximizar o benefício aos Stakeholders |  |
Desenvolver uma solução que maximize os benefícios ao stakeholder e cumpra com as restrições impostas ao projeto.
Relacionamentos
Elementos Relacionados | A Família OpenUP Fase de Concepção Fase de Elaboração Priorizando Itens de Trabalho
Descrição Principal
# Introdução Raramente os sistemas farão tudo para todas as pessoas. Mas quando tentamos fazer isso, criamos um sistema inchado e caro. Para atingir o sucesso, os Stakeholders e os participantes do projeto devem convergir para um claro entendimento e concordar com estes três fatores: Problema a ser resolvido Restrições impostas à equipe de desenvolvimento (custo, cronograma, recursos, regulamentos, etc.) Restrições impostas à solução O desafio de todos os participantes do projeto é criar uma solução que maximize o valor entregue aos Stakeholders, mesmo que sujeita a restrições. O equilíbrio está em fazer uma análise crítica do custo-benefício entre as características desejadas e as decisões de projeto subseqüentes que definem a arquitetura do sistema. Descobrir o ponto de equilíbrio é desafiador, evasivo e progressivo, porque o ponto de equilíbrio é dinâmico. Quando os sistemas evoluem, as necessidades dos Stakeholders mudam, aparecem novas oportunidades, os riscos são resolvidos, novos riscos aparecem e a equipe de desenvolvimento descobre novas realidades sobre o sistema. Mudanças surgem em todo o ciclo de desenvolvimento. Os Stakeholders e os membros da equipe devem estar preparados para reavaliar seus compromissos, reduzir expectativas e ajustar o planejamento conforme a evolução do sistema. # Práticas ## Conheça a sua audiência Você não terá como realizar compensações com eficiência se você não souber quem são os Stakeholders e o que eles realmente querem. Conheça seus Stakeholders. Melhor ainda, trabalhe junto com eles e assegure-se que você tenha entendido as suas necessidades. Comece identificando todos os Stakeholders e então mantenha uma comunicação e colaboração aberta e freqüente entre eles e a equipe de desenvolvimento. ## Separe o problema da solução Com freqüência nos precipitamos ao apresentar uma solução sem a devida compreensão do problema. A final de contas, nós aprendemos a solucionar problemas e não a definir problemas, isso é fácil. No entanto, essa forma de pensar limita o seu entendimento do problema, impõe restrições artificiais e dificulta a análise equilibrada, ou mesmo o conhecimento de quais são as alternativas existentes. Assegure-se de ter entendido o problema antes de definir a solução. Ao separar claramente o problema (o que os clientes necessitam) da solução (o que o sistema deve fazer), nos ajuda a manter o foco apropriado e facilita acomodar as formas alternativas de resolver o problema. ## Crie um entendimento compartilhado do domínio Especialistas de domínio normalmente possuem limitações técnicas; desenvolvedores, arquitetos e testadores normalmente possuem limitações de domínio; e revisores e outros Stakeholders normalmente possuem limitações de tempo para acompanhar o projeto e aprender sobre o domínio do problema. Como resultado, as pessoas possuem, normalmente, um entendimento pobre ou inconsistente do domínio do problema, o que provoca problemas de comunicação e eleva as chances de entregar algo de pouquíssimo valor aos Stakeholders. Aumente e compartilhe o entendimento de todos sobre o domínio. Um entendimento conciso e compartilhado do domínio do problema melhora a comunicação e a efetividade do projeto. Comece definindo o problema no documento de Visão. Na medida em que você adquirir novos conhecimentos, capture os principais conceitos e terminologias do domínio no Glossário para assegurar um uso compartilhado consistente da linguagem do domínio. ## Use os cenários e os casos de uso para capturar os requisitos Muitas empresas ainda documentam requisitos como uma lista de declarações, que são algumas vezes chamadas de "lista de desejos". Para os Stakeholders, essas listas são normalmente difíceis de entender porque elas precisam que o usuário final leia e traduza mentalmente a lista em uma visualização de como os requisitos irão interagir no sistema. Use os cenários e os casos de uso para capturar os requisitos funcionais de forma que facilite a compreensão dos Stakeholders. Os requisitos não-funcionais, tais como desempenho, estabilidade ou usabilidade são importantes e podem ser documentados como Requisitos Suplementares, usando as técnicas tradicionais. ## Estabeleça e mantenha um acordo sobre prioridades Tomar decisões erradas sobre o que desenvolver depois pode resultar em desperdício de esforço, em liberação de capacidades que nunca serão usadas ou na identificação de problemas tardiamente no projeto (resultando em atrasos e até no fracasso do projeto). Priorize os requisitos para implementação trabalhando regulamente com os Stakeholders durante a evolução do produto. Faça escolhas que agreguem valor e reduzam os riscos, enquanto se constrói um sistema que possa evoluir. ## Faça compensações para maximizar o valor A análise de custo-benefício não pode ser realizada independentemente da arquitetura. Os requisitos estabelecem os benefícios do sistema para o Stakeholder, enquanto a arquitetura estabelece o custo. O custo de um benefício pode influenciar no valor do benefício percebido pelo Stakeholder. Trabalhe com os Stakeholders e com os membros da equipe para priorizar os requisitos e desenvolver arquiteturas candidatas para implementar estas soluções. Use as arquiteturas candidatas para avaliar o custo dos benefícios. Soluções candidatas são consideradas num nível elevado durante a determinação da viabilidade arquitetural. Diferentes perspectivas arquiteturais podem resultar em diferentes estimativas de custo versus benefícios. A arquitetura candidata que forneça a maior cobertura no menor custo é selecionada para o desenvolvimento futuro. ## Gerencie o escopo As mudanças são inevitáveis. Embora as mudanças apresentem oportunidades para elevar o valor para o stakeholder, mudanças irrestritas resultarão num sistema inchado e deficiente e não atende às necessidades do Stakeholder. Gerencie as mudanças mantendo a concordância dos Stakeholders. Os processos modernos sempre gerenciam mudanças, adaptando-se continuamente às mudanças ocorridas no ambiente e às necessidades dos Stakeholders, avaliando o impacto das mudanças, fazendo análise das alternativas, e re-priorizando o trabalho. As expectativas dos Stakeholders e dos desenvolvedores devem ser realísticas e alinhadas no ciclo de vida de desenvolvimento. ## Saiba quando parar Excesso de engenharia para construir sistemas não só desperdiça recursos, como também eleva a complexidade do sistema. Pare de desenvolver o sistema quando a qualidade desejada for atingida. Lembre-se que "A qualidade é a compatibilidade com os requisitos" [CRO79]. É isto que dá um sentido de término na prática. Separe o problema da solução, assegurando que a solução realmente resolva o problema. Depois que os requisitos críticos forem implementados e validados, o sistema estará pronto para a aceitação dos Stakeholders.
Este programa e o material que o acompanha são disponibilizados sob a Eclipse Public License v1.0 que acompanha esta distribuição. Direitos Autorais do OpenUP.