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.

Um processo iterativo conseguirá 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 vai trabalhar com um contrato de custo fixo ou tempo fixo dessa maneira.

Se o que você está dizendo é verdade 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 suas próprias especificações em um nível que seja suficiente para você poder codificar. Você pode ter que fazer uma tonelada de palpites.
3. Mostre suas especificações ao cliente para revisão. Anote as partes que eles gostam e obtenha mais informações sobre as partes em que eles acham que você errou.
4. Repita as etapas 2 e 3 até você e o cliente estarem sincronizados.
5. Agora você tem uma especificação adequada.

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

Se seu cliente estava errado e, de fato, existem todos os tipos de problemas e lacunas nos requisitos, sua especificação preliminar 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.

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 de volta 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 há necessidade de 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 este processo solto é uma coisa nova para sua empresa, seus testadores são provavelmente ainda mais em uma perda do que você é, e pode estar olhando para você para 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 First Design

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

Familiarize-se com o design do primeiro teste e / ou o desenvolvimento orientado a testes e forneça orientações 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 o Bootstrap ou o Google Material Design são dois exemplos.

Comunicar, mas não incomodar

Sugiro enviar um e-mail ao proprietário do produto por dia. Envie 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

Estive envolvido muitos projetos para pessoas que não conheciam o termo "requisito". A maioria teve sucesso. Os proprietários do produto hands-off oferecem a possibilidade de criar ótimas soluções.

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

Um 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 seu 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 ;-))

" Não há reuniões agendadas regularmente ". Bem, por que você não começa 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.

Além disso, eu realmente recomendo que você mantenha um registro detalhado das decisões . 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.

Um projeto sem requisitos claros, liderança fraca, sem 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 cumprir o prazo é uma receita para o projeto falha.

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 mudança nos requisitos exige uma mudança na linha do tempo. Você não pode se comprometer a cumprir um prazo se não puder desenvolver uma linha do tempo e não poderá 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 poderá concordar com os proprietários do produto (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 somente se ) conheço os proprietários do produto o suficiente para confiar plenamente que os requisitos são realmente tão simples quanto eles dizem e as especificações que tenho sido desde que sejam auto-explicativas (caso contrário, agendar uma sessão de perguntas e respostas e documentá-la). Já estive em muitas situações em que a facilidade do ponto de vista das operações é incrivelmente difícildo 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 em um repositório de documentos", que, durante o teste de aceitação, se transforma em "Ah, esquecemos que alguns deles foram lidos de lado de maneira completamente inconsistente e alguns têm o tamanho de página errado definido e outros precisam dessas três páginas anexadas, e precisamos que todas exibam a mesma coisa. 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 que você documente todas as suposições e obtenha 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 se esquecerão disso quando você entregar um ótimo produto no 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.

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

Sente-se com o OP e elabore 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. Demonstre 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 entregue de forma colaborativa pequenas fatias verticais que são frequentemente demonstradas.

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

Passei vários trabalhos realizando projetos, como você descreveu. Desde que o OP saiba quais decisões de design você está tomando e por que você precisa tomá-las, você deve ficar bem. Se, por outro lado, eles não entenderem as decisões de design, será necessário pressioná-las para pelo menos um documento de teste de aceitação por escrito do usuário.

Você precisa de uma especificação detalhada e verificável antes de começar a escrever o código. Isso é um fato, e não há como contornar isso.

Se ninguém mais estiver disposto a escrever essa especificação, os desenvolvedores terão que escrevê-la. Então você obtém uma especificação incompleta. Você o transforma em uma especificação completa (o que significa "é isso que eu vou implementar, a menos que alguém me diga para não fazê-lo"). Você entrega essas especificações às partes interessadas e oferece a elas a chance de modificá-las. Apenas uma chance de modificar a especificação - não a excluindo, por exemplo, dizendo "Não gosto dessa maneira". Nesse ponto, é sua especificação ou eles podem fornecer uma especificação diferente, mas não removê-la.

Pode ser uma boa ideia obter uma rápida revisão de seus colegas que possam melhorar as especificações. Mas de qualquer maneira, você tem uma especificação, escreve o código de acordo, os testadores testam de acordo. E você fez seu trabalho: você tinha uma especificação e a implementou. Se a especificação não é o que o cliente deseja, isso é de responsabilidade do proprietário do produto ou do cliente que não se incomodou em escrever uma boa especificação.