ti-enxame.com

Como você desenvolve software sem critérios de aceitação?

Como você desenvolve o software de forma colaborativa em uma equipe de 4 a 5 desenvolvedores sem critérios de aceitação, sem saber o que os testadores testarão e com várias (2-3) pessoas atuando como proprietárias do produto.

Tudo o que temos é uma "especificação" superficial com algumas capturas de tela e alguns pontos de bala.

Fomos informados de que será fácil, portanto, essas coisas não são necessárias.

Estou sem saber como proceder.

Informação adicional

Foi-nos dado um prazo final.

O cliente é interno, temos um proprietário do produto em teoria, mas pelo menos três pessoas testando o software podem falhar em um item de trabalho simplesmente porque não funciona como eles acham que deve funcionar e há pouca ou nenhuma transparência do que eles esperam ou não. o que eles estão realmente testando até que falhe.

o (s) proprietário (s) do produto não estão prontamente disponíveis para responder a perguntas ou fornecer feedback. Não há reuniões agendadas ou chamadas regulares com eles, e o feedback pode levar dias.

Entendo que não podemos ter uma especificação perfeita, mas pensei que seria 'normal' ter critérios de aceitação para as coisas em que estamos trabalhando em cada sprint.

68
user1450877

Um processo iterativo alcançará isso muito bem, sem especificações detalhadas.

Simplesmente crie um protótipo, solicite feedback do cliente, faça alterações com base no feedback e repita esse processo até que o aplicativo seja concluído.

Se o cliente é paciente o suficiente para fazê-lo dessa maneira é uma questão diferente. Alguns clientes e desenvolvedores realmente preferem esse processo; como o cliente está sempre ativo, ele (eventualmente) obterá exatamente o que deseja.

Não é preciso dizer que você não trabalha com um contrato de custo fixo ou tempo fixo dessa maneira.

129
Robert Harvey

Se o que você está dizendo é verdadeiro e a especificação não chega nem perto do suficiente para você começar (e você está sendo honesto nessa avaliação), recomendo esta abordagem:

  1. Leia os esboços e as especificações "esboçadas" que você recebeu.
  2. Escreva sua própria especificação em um nível apenas o suficiente para que você possa codificar. Você pode ter que fazer uma tonelada de palpites.
  3. Mostre suas especificações ao cliente para revisão. Observe as partes que elas gostam e obtenha mais informações sobre as partes em que elas acham que você errou.
  4. Repita as etapas 2 e 3 até que você e o cliente estejam sincronizados.
  5. Agora você tem uma especificação adequada.

Se o seu cliente estava certo quando disse "será fácil", esse exercício deve ser um pedaço de bolo.

Se o seu cliente estava errado e, de fato, existem todos os tipos de problemas e lacunas nos requisitos, o rascunho da especificação ilustrará rapidamente o problema e comunicará a eles que eles estavam errados (sem a necessidade de apontar o dedo ou argumentar), pois estar bem na frente deles e óbvio. Além disso, suas especificações servirão como uma ótima ferramenta de discussão para resolver essas ambiguidades e servirão como um registro das principais decisões conforme você as revisa com seus comentários.

57
John Wu

O proprietário do produto entregou a você um protótipo; entregá-lo de volta os melhores (até você terminar)

Parece que você recebeu um protótipo em papel para iniciar o projeto. Não é um começo terrível. Sugiro que você se comunique novamente com o proprietário da empresa no mesmo idioma , fornecendo protótipos com capacidade progressiva.

Seus protótipos devem começar com papel, passar para maquetes digitais e depois serem construídos com tecnologias "reais".

Treehouse tem um excelente guia para isso, que conclui:

O maravilhoso da prototipagem com uma estrutura é que o protótipo geralmente se torna o site real porque a estrutura e o estilo já estão em vigor. Não é necessário recriar o site do zero para usar a mesma estrutura.

Você também pode fornecer uma especificação formal, especialmente se continuar preocupado em ser responsabilizado por um resultado ruim. Mas você provavelmente obterá mais feedback dos protótipos.

Cumpra o seu prazo

Observe que seus esforços posteriores não serão "protótipos" clássicos como todos, pois não serão descartáveis ​​(ou partes deles não serão). A última iteração mais capaz que você completa antes do prazo final se tornar sua entrega.

Seu prazo é o requisito mais bem definido que você possui. Tenha algo completo e coerente que você possa entregar a tempo.

Colabore com seus testadores

Se esse processo frouxo é algo novo para sua empresa, seus testadores provavelmente estão mais perdidos do que você e podem estar procurando você para obter orientação. Você precisa dedicar parte do tempo deles no início do processo. Informe o chefe deles que você está tentando ajudá-los a fornecer um teste significativo sem receber critérios formais de aceitação.

Descubra se os testadores têm algo firme que precisam fornecer, como documentação de prova de teste, na qual você pode "voltar".

Tente Teste do primeiro design

Como você não possui requisitos formais, obter os casos de teste a serem desenvolvidos forneceria alguma estrutura.

Familiarize-se com Teste do primeiro design e/ou desenvolvimento orientado a testes e forneça orientação aos testadores sobre o processo, conforme necessário. Para um projeto rápido como esse, você não precisa se tornar especialista no processo. Mas o uso de uma metodologia comprovada refletirá bem em você e em seus testadores.

Atenha-se aos padrões, especialmente para a interface do usuário

Você não tem requisitos de aparência, mas tem um prazo. Use o trabalho de design de outra pessoa para minimizar o trabalho necessário para criar um artefato com aparência profissional.

Escolha uma interface do usuário padrão para o seu site e não a personalize, a menos/até que seja direcionado. Não sei para qual plataforma você está desenvolvendo, mas Bootstrap ou Google Material Design são dois exemplos.

Comunique-se, mas não incomode

Sugiro enviar um e-mail ao proprietário do produto por dia. Envie apenas mais do que isso se for uma emergência.

Se você tiver dúvidas, descreva como procederá se não receber orientação. Por exemplo:

Os usuários deste aplicativo precisarão acessá-lo com dispositivos móveis? No momento, estamos assumindo que este será um sistema somente para desktop/laptop.

Não entre em pânico

Participei de muitos projetos para pessoas que não conheciam o termo "requisito". A maioria teve sucesso. Os proprietários de produtos hands-off oferecem a você a liberdade de criar ótimas soluções.

Observe que era impossível agradar a alguns proprietários desses projetos e se esconderam atrás da desculpa de "Estou muito ocupado para ..." por sua incompetência. Mas a maioria ficou "encantada" com os resultados finais.

18
Tim Grant

m projeto é o ato de reduzir a incerteza até que a certeza seja alcançada:

  • Sempre há algum grau de incerteza no início. Às vezes é um pouco de ambiguidade nos requisitos. Às vezes, é muito superficial. Você terá que se exercitar como parte do trabalho.
  • O truque é reduzir iterativamente essa incerteza (combinando análise, design e implementação), refinando as histórias do usuário e implementando seu sistema.
  • Os casos/cenários de teste e os critérios de aceitação deverão ser esclarecidos da mesma maneira. Eles contribuirão para reduzir a incerteza sobre qualidade e correção (entre outros).
  • No final, é alcançada uma certeza suficiente: o cliente obtém um produto testado que atenda às suas necessidades e possa ser usado.

Esse é o princípio da elaboração progressiva: os requisitos, critérios e resultados serão elaborados passo a passo, assim como o entendimento do cliente sobre suas próprias expectativas e requisitos através do envolvimento no processo de desenvolvimento.

Isso é um problema?

Quanto mais esboçados os requisitos iniciais, maior a incerteza e maior o tempo necessário para executar as tarefas. Portanto, é apenas uma questão de quem fará o trabalho adicional e quem pagará pelos custos.

A resposta dessas duas perguntas deve estar no contrato. Ou será objeto de uma negociação. E o cliente deve aceitar um envolvimento adicional (o argumento principal será "lixo dentro, lixo fora", embora eu recomendo fortemente que você a apresente de uma maneira mais diplomática ;-))

10
Christophe

" Não há reuniões agendadas regularmente ". Bem, por que você não comece agendando reuniões regulares então? Só o fato de você ter vários proprietários de produtos garante que seu projeto NÃO será fácil, pois cada uma dessas pessoas terá requisitos conflitantes que DEVEM ser discutidos pessoalmente com todas as partes interessadas presentes.

Além disso, eu realmente, realmente, realmente recomendo que você mantenha um registro detalhado da decisão. No mínimo, você anota tudo o que alguém decidiu, com a data e uma lista de pessoas que estavam presentes quando a decisão foi tomada. Ainda melhor se você pode escrever por que algo foi decidido do jeito que era. Não importa se é um arquivo no seu PC, uma página no wiki da intranet ou um notebook na sua mesa. O log protege você e o projeto: quando um testador diz que algum item "falha", você pode apontar que foi decidido dessa maneira com essas pessoas, e não é problema seu, mas entre elas e os testadores. Se isso fizer com que as especificações sejam alteradas, tudo bem, mas neste momento elas não podem esperar cumprir qualquer prazo que tinham em mente - ou devem cortar o escopo em outro lugar.

8
ZeroOne

Um projeto sem requisitos claros, liderança solta, nenhuma definição de feito (DoD), ninguém disposto a prestar contas para garantir que você tenha as informações necessárias para realizar seu trabalho em tempo hábil e se reunir o prazo é uma receita para o fracasso do projeto.

O desenvolvimento iterativo não é uma má sugestão, mas requer uma cooperação estreita entre os proprietários do produto e os desenvolvedores. Tente convencer alguém a dizer: "Sabemos que teremos perguntas. Quem pode estar disponível regularmente para garantir que as respostas sejam respondidas, para que a entrega do projeto não seja adiada?" Programe horários regulares com alguém para revisar o progresso e remover impedimentos. Se eles não aparecerem ou recusarem, faça o seguimento com correspondência escrita educada e atrasos ou não respostas no documento. Se os proprietários do produto não estiverem disponíveis, peça que forneçam um representante que possa estar.

Além disso, outra característica do desenvolvimento iterativo é que uma alteração nos requisitos exige uma alteração na linha do tempo. Você não pode se comprometer a cumprir um prazo se não pode desenvolver uma linha do tempo e você não pode desenvolver uma linha do tempo se não tiver uma boa idéia do que precisa ser feito. Em vez de pedir dogmaticamente uma especificação, revise a especificação atual, documente qualquer pergunta que você ou a equipe tenha sobre como ela deve funcionar, agende um horário com os proprietários do produto para discuti-la e documente as respostas. Quando terminar, você terá suas especificações baseadas nas decisões deles, com as quais os proprietários do produto poderão concordar (por escrito). O objetivo de uma especificação é remover a ambiguidade e criar um Departamento de Defesa, que é exatamente o que uma sessão de perguntas e respostas pode oferecer. Se houver oposição a uma especificação, não a chame de especificação.

Não acredite em ninguém quando eles lhe disserem que será fácil . Às vezes, é realmente tão simples quanto parece, e eu posso acreditar nisso se (e apenas se) Conheço os proprietários do produto o suficiente para confiar plenamente que os requisitos realmente são por mais simples que sejam, e as especificações que forneci são auto-explicativas (caso contrário, agendamento de uma sessão de perguntas e respostas e a documento). Já estive em muitas situações em que fácil do ponto de vista das operações é incrivelmente difícil do ponto de vista do desenvolvimento, ou você pensa que está totalmente pronto e ouve as palavras de desespero ("Ah, a propósito, esquecemos ..."). Exemplo ... "Tudo o que você precisa fazer é ler esses arquivos PDF de um repositório de documentos") que, durante o teste de aceitação, se transforma em "Ah, esquecemos que alguns deles foram lidos de maneira completamente inconsistente, e alguns têm o tamanho de página errado definido, e alguns precisam dessas três páginas anexadas, e precisamos que todos exibam o mesmo. Isso é realmente fácil de corrigir, certo? ".

O ponto é que pode ser realmente fácil e uma reunião rápida pode confirmar isso, permitindo documentar todas as suposições e obter confirmação de que elas são precisas e corretas. Eu recomendo levantar-se para remover os impedimentos que você precisa para escrever um código de trabalho que atenda às expectativas deles, porque, independentemente de você pisar no pé, alguém provavelmente ficará infeliz no final. Se você persistir em obter respostas às perguntas e irritar alguém, elas esquecerão quando você entregar um ótimo produto dentro do prazo e que atenda aos requisitos. Se você não conseguir esclarecimentos e não entregar, ninguém se lembrará de que eles disseram para você não os incomodar.

8
DVK

Sem uma especificação, você tem trabalho em equipe. Agile.

Sente-se com o OP e elabore uma/algumas pequenas histórias iniciais. "Nós vamos entregar apenas esta tela, com apenas este botão que vai 'bing!'". Aceite alguns ACs. Entregue a história. Demonstrar a história. Acontece que os botões devem estar vermelhos. Crie um bug ou uma nova história. Entregue os botões que tocam bong e bang. E assim por diante.

Especifique e forneça colaborativamente pequenas fatias verticais que são frequentemente demonstradas.

Se o cliente não trabalhar com você dessa maneira, procure uma saída.

3
Grimm The Opiner