Baixo atrito Requisitos mínimos Colheita [fechado]

Question

Como pode a nossa equipa de reunir os requisitos do nosso "Product Owner" em um preço tão baixo atrito ainda utilizável de uma maneira possível?

Agora é aqui os guidelines- Não existem mensagens que não pode ser feito ou que a empresa precisa para tomar uma decisão que se preocupa com qualidade, yada yada. O produto Eu trabalho para um pequeno grupo que tem sido bem sucedida durante anos. Eu só quero ajudá-los a intensificar-se um entalhe.

Basicamente, eu estou em uma equipe de 6 ou 7 pessoa com um Product Owner. Ela faz um ótimo trabalho, mas é malabarismo alguns papéis diferentes (como eu acredito que é comum em extremamente pequenas equipes). Geralmente os requisitos são dadas em momentos esporádicos (convos e-mail, cara a discussões face, reuniões, etc). Eles nunca são inseridos em um sistema e às vezes isso resulta em características ausentes um lançamento ou a liberação ficando adiado já que todo mundo esqueceu sobre o recurso necessário.

Se você estiver em uma situação semelhante, mas você encontrou uma maneira de superar isso, eu adoraria ouvi-lo. Estou feliz em escrever código para ajudar a aliviar esta situação, mas ele não pode ser um web site que o Product Owner tem que ir para a fim de fazer nada. Ela é extremamente ocupado e precisamos de alguma maneira de trabalhar juntos como uma equipe, a fim de reunir estes requisitos.

Atualmente estou pensando em algo como isto: Desenvolvedores e membros da equipe de reunir os requisitos discutidos no rosto para reuniões presenciais e escrever algumas notas rápidas sobre os recursos discutidos em uma página wiki. proprietário do produto é notificado sempre que estas páginas são atualizados e torna-se então sua responsabilidade para garantir a precisão.

Pros: Nós vamos ter algum registro dos recursos. Contras: Os desenvolvedores estão assumindo a responsabilidade por algo que eles normalmente não faria. Eu estou bem com isso aqui. Eu acho que nesta situação de trabalho em equipe.

É claro que, uma vez que fazemos isso, então vamos ver que o proprietário do produto provavelmente não tem tempo suficiente para garantir a precisão característica. No final, ela está sobrecarregado e eu acho que esta mostra vai ajudar esse fato, mas eu só preciso ser capaz de chamar a atenção para isso primeiro.

Então, alguma sugestão?

P.S. seu tempo é extremamente limitada por isso é considerado razoável esperar que ela precisa digitar os requisitos após a discussão. Ela só tem tempo para discuti-los uma vez e seguir em frente.

Answer 1

Embora o conceito de "produto proprietário" é um littl ambígua para mim, eu acho que eu estou trabalhando em circunstâncias muito semelhantes: o cliente é extremamente buzy e sempre é um gargalo no desenvolvimento requisitos

.

Na superfície, o que tentamos fazer nesta situação é bastante óbvio e aparentemente simples: nós tentamos ter certeza de que o cliente está envolvido no modo "read-only / talk-only". escrita não. Leitura mínima. Principalmente falando.

O diabo, é claro, é nos detalhes. Então, aqui estão alguns detalhes sobre o nosso processo (em nenhuma ordem particular):

• Nós muitas vezes começam a partir de declarações problema gravação , que são as principais fontes de requisitos. Na verdade, às vezes, uma declaração do problema é tudo o que nós registramos inicialmente, apenas para se certificar de que não se perde.

  Nota: É importante distinguir declarações de problemas de requisitos. Embora a declaração do problema implica, por vezes, claramente alguma exigência, em uma única instrução geral problema pode render um monte de requisitos (cada um com sua própria gravidade e prioridade); Além disso, por vezes, uma determinada exigência meus definir uma solução (geralmente apenas um parcial) para vários problemas.

  Uma das principais razões de gravação de declarações de problemas ( e isso é muito relevante para a sua pergunta! ) é que semanticamente eles são um pouco "mais perto da pele do cliente" e mais estável do que os requisitos derivados eles. Eu acredito que essas declarações de problemas torná-lo muito mais fácil e mais rápido para colocar o cliente em contexto apropriado sempre que tem tempo para fornecer feedback para a equipe de desenvolvimento.

• Nós fazemos record todas os requisitos (e back-monitorá-los para declarações de problemas) , independentemente de quando é que vamos implementá-las. Prioridades governam a ordem em que os requisitos se implementado. Claro, eles também regulam a ordem em que as críticas requisitos inacabados.

  Nota: Um documento de gordura única contendo todos os requisitos é uma absoluta falta de nenhum Todos os requisitos são colocados em "banco de dados de rastreamento de problemas", juntamente com os relatórios de erros!. (A bug é apenas um caso especial de um problema em nosso livro.)

• Nós sempre tentamos fazer o nosso melhor para minimizar o número de iterações necessário "finalize" cada requisito (ou um grupo de requisitos relacionados). Idealmente, o cliente deve ter que rever uma exigência apenas uma vez.

  Sempre que a primeira revisão acaba por ser insuficiente (acontece o tempo todo), e a exigência em questão é bastante complexa para exigir um monte de texto e / ou ilustrações, nós certifique-se de que o cliente não tem a tudo o que re-ler a partir do zero . Todo o importante alterações / adições / exclusões desde a versão reviwed anterior são destacados.

  Enquanto um problema ou uma exigência permanece em um estado inacabado, todas as questões em aberto (principalmente perguntas para o cliente) são incorporados no documento e destacada . Como resultado, sempre que o cliente tenha tempo para requisitos de revisão, ele não tem que chamar uma reunião e perguntas solicitar da equipe; em vez disso, o cliente pode abrir qualquer documento inacabado primeiro, ver exatamente o que se espera dele, e então decidir qual é a melhor maneira e no tempo (para ele) para resolver qualquer um dos problemas em aberto. Às vezes, os escolhe clientes para escrever um e-mail ou adicionar um comentário diretamente para o documento problema.

• Nós tentaremos nosso melhor para estabelecer e manter domínio oficial vocabulário (mesmo que fica espalhada por toda a documentação). Mais importante ainda, nós praticamente forçar o cliente a vara para que o vocabulário.

  Nota: Esta é uma das partes mais difíceis do processo, e tentativas de clientes para "rebelde" de vez em quando. No entanto, no final do dia todos concordam tchapéu é a única maneira de tornar as reuniões preciosos com o cliente o mais eficiente possível. Se você nunca participou de reuniões de uma hora em que 30 minutos eram gastos apenas para obter todos na mesma página (mais uma vez), eu tenho certeza que você gostaria de ter um vocabulário.

  NB:. Sempre que possível, quaisquer mudanças no vocabulário oficial se reflete no muito próxima versão do software

• Às vezes, um determinado problema pode ser resolvido de várias maneiras, e a escolha certa não é óbvio, sem consultar com o cliente. Isso significa que haverá um "menu de requisitos" para o cliente para escolher . Nós documentamos tais "menus", e não apenas a exigência finalmente escolhida.

  Isto pode parecer controverso e olhar como uma sobrecarga desnecessária. No entanto, esta abordagem poupa muito tempo, sempre que o cliente (geralmente algumas semanas ou meses abaixo da estrada) salta de repente com uma pergunta como "por que diabos nós fizemos desta forma e não dessa maneira?" Além disso, não é um negócio tão grande para esconder "ramos rejeitados" usando organização adequada / formatação da documentação de requisitos. Chato, mas factível. : -)

  Nota: Ao preparar "menus de requisitos", é muito importante não exagerar-los. Muitas opções ou muitos níveis de aninhamento escolha - e a próxima revisão pode exigir muito mais tempo do cliente do que realmente necessário. Escusado será dizer que o tempo gasto em ramos elaborados podem ser totalmente desperdiçado. Sim, é difícil encontrar algum equilíbrio aqui (depende muito da capacidade do cliente sempre-em-um-pressa para pensar dois ou mais passos em frente e fazê-lo rapidamente). Mas, o que eu posso dizer? Se você realmente quer fazer o seu trabalho bem, estou certo de que depois de algum tempo você vai encontrar o equilíbrio certo. : -)

• O nosso cliente é um cara "visual" muito. Portanto, sempre que discutimos quaisquer elementos de interface de usuário significativa, maquetes tela (ou até mesmo protótipos leves) muitas vezes são extremamente úteis. poupadores tempo real às vezes!

  Nota: Nós fazemos mockups de tela exclusivamente para o cliente, apenas para facilitar as discussões. Eles podem ser usados ??por desenvolvedores também, mas de nenhuma maneira que eles substituir especificações de interface do usuário! Mais frequentemente do que não, há alguns muito importantes detalhes da interface do usuário que são especificados por escrito (agora - principalmente para desenvolvedores).

• Estamos a sorte de ter um cliente com um fundo muito técnico. Por isso, não hesite em diagramas UML uso como ajuda discussão . Todos os tipos de diagramas UML -., Desde que ajuda ao cliente para entrar em contexto adequado mais rápido e ficar lá

  Estou a falar de diagramas UML de nível de exigências, é claro. Não sobre aqueles de nível de implementação. Acredito que as pessoas ainda não muito técnicos podem começar a cavar diagramas UML de nível de exigências mais cedo ou mais tarde; você apenas tem que ser paciente e saber o que colocar em um diagrama.

Obviamente, o custo de tal processo depende muito da capacidade de análise e escrita da equipe, e, claro, sobre as ferramentas que você tem à sua disposição. E eu devo admitir que, no nosso caso, este processo parece ser muito caro e lento. Mas, tendo em conta a baixa taxa de erros e baixa taxa de "vapor características" ... Eu acho que, no longo prazo, temos muito bom retorno.

FWIW: De acordo com boa classificação de produtos de software de Joel , este projecto é um "interna " 1. Assim, podemos dar ao luxo de ser tão ágil como o nosso cliente pode manipular. : -)

Answer 2

"membros desenvolvedores e equipe de reunir os requisitos discutidos no rosto para reuniões presenciais e escrever algumas notas rápidas"

Comece com isso. Se você não está tomando notas, basta fazer uma pequena mudança. Tomar notas. Mais tarde, você pode publicá-las para um wiki ou criar um backlog recurso ou começar a usar Scrum ou bugzilla ou algo assim.

Em primeiro lugar, no entanto, fazer pequenas mudanças. Escrever coisas para baixo soa como algo que você não está fazendo, então, basta fazer isso e ver o que melhora e que você pode fazer em seguida. Seja Agile. Trabalho de forma incremental.

Answer 3

Você pode querer ter cuidado com o hipopótamo na sala. Parecer da pessoa mais alto pago nem sempre é uma boa. Nós tendem a se concentrar mais no fornecimento de excelentes ferramentas e suporte para os desenvolvedores. Essas coisas, bem feito, tirar um pouco da trabalheira de desenvolvimento, de modo que se torna mais rápido e mais divertido. Desenvolvedores são, então, mais flexível em termos de sua carga de trabalho, e mais passíveis de mudanças de última hora.

One-Click testes e implantação são um par de bons para começar; garantir que cada desenvolvedor pode executar a sua própria pilha de software em poucos segundos e experimentar ideias diretamente. Desenvolvedores são então capazes de fazer revisões rapidamente ou correr por caminhos secundários que achar interessante, e esses caminhos são muitas vezes os mais bem sucedidos. E por sucesso quero dizer medido o sucesso com base em métricas reais recolhidos direito no sistema e fez prontamente disponível para todos os interessados. O proprietário então é capaz de definir as métricas que eles provavelmente se preocupam, em vez das exigências, que ou não se preocupam ou não tem experiência na definição.

Claro que depende do proprietário e sua situação particular, mas descobrimos que as métricas são mais fáceis de discutir do que os requisitos, e que os desenvolvedores são muito bons em interpretá-los também. Um problema típico pode ser que os clientes parecem gastar muito tempo enchendo seus carrinhos de compras, mas não ir para check-out.

1) A exigência de marketing poderia ser a de tornar o botão de pagamento maior e mais vermelho. 2) A exigência do CEO poderia ser a de levar o cliente direto para o check-out, como o CEO sempre apenas compra um item de cada vez de qualquer maneira. 3) exigência do designer de interface do usuário pode ser colocar um segundo botão de pagamento no topo do carro, bem como o existente na parte inferior. 4) A exigência do desenvolvedor pode ser algum Widget 2.0 AJAX Web que segue o ponteiro do mouse ao redor da tela. Quem está certo?

Quem se importa ... o cliente provavelmente viu o ridículo custo de entrega e fugiu. Mas redefinir o problema como uma métrica, em vez de um requisito, e de repente o desenvolvedor torna-se interessado. O desenvolvedor não tem que fazer 10 voltas com o CMO do que tom de vermelho o botão deve ser. Ele pode jogar com a sua coisa Web 2.0 durante toda a semana, e depois apressar os outros 3 soluções na segunda-feira de manhã. Cada um é distribuído ao vivo por 48 horas ea taxa de carrinho-de-checkout é medido e relatado imediatamente. Nada disso faz alguma diferença, mas o desenvolvedor tem que fazer o seu trabalho e as mudanças de visita É foco para os produtos de baixa qualidade que vendem e o preço que avaliar no momento da entrega.

Bem, ok, então o exemplo é planejado. Há um monte de trabalho lá para se certificar de que o projeto é pequeno, a equipe é experiente, implantação quente é simples, reversão instantânea é fornecido, e que todo mundo a bordo. O que queríamos para chegar a um estado onde todo o potencial do desenvolvedor não é desperdiçado, é por isso que eles estão envolvidos não apenas desde o início, mas também no sucesso. Comece com uma questão como o número de cliques durante o registo é muito alto, executá-lo através de uma comissão de design, e descobrimos que o número de cliques realmente subiu na especificação do projeto. Que foi a experiência de qualquer maneira. Mas deixar o desenvolvedor alguma liberdade para apenas reduzir o número de cliques e você pode realmente acabar com uma solução patenteada, como fizemos. Não que os cuidados desenvolvedor sobre patentes, mas teve o mérito - e não cliques!