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

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

Basta criar um protótipo esboçado, solicitar feedback do cliente, fazer alterações com base no feedback e repetir 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; desde que o cliente é sempre hands-on, ele (eventualmente) terá exatamente o que ele quer.

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 está longe de ser boa o suficiente para você começar (e você está sendo honesto nessa avaliação), eu recomendo esta abordagem:

1. Leia os esboços e a especificação "esboçada" que você recebeu.
2. Escreva sua própria especificação para um nível que seja apenas o suficiente para você poder codificar. Você pode ter que fazer uma tonelada de palpites.
3. Mostre sua especificação ao cliente para revisão. Observe as partes que eles gostam e obtenha mais informações sobre as partes onde eles acham que você entendeu errado.
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", então este exercício deve ser fácil.

Se seu cliente estava errado e, de fato, existem vários tipos de lacunas e lacunas nos requisitos, sua especificação de rascunho ilustrará rapidamente o problema e comunicará a eles que estavam errados (sem você precisar apontar um dedo ou argumentar) desde que estará bem na frente deles e óbvio. Além disso, sua especificação servirá como uma excelente ferramenta de discussão para resolver essas ambiguidades e servirá como um registro das principais decisões à medida que você as rever com o feedback delas.

O product owner lhe entregou um protótipo; entregá-lo de volta os melhores (até que você é feito)

Parece que você recebeu um protótipo de papel para começar o projeto. Isso não é um começo terrível. Sugiro que você comunique-se com o proprietário da empresa no mesmo idioma , fornecendo protótipos progressivamente capazes.

Os seus protótipos devem começar com papel, passar para modelos digitais e depois construir com tecnologias “reais”.

Treehouse tem um excelente guia para isso, o que conclui:

The wonderful thing about prototyping with a framework is that the prototype often just becomes the real site because the structure and styling are already in place. There’s no need to recreate the site from scratch if it’s going to use the same framework.

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

Cumpra 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 e mais capaz iteração que você completa antes do prazo se torna sua entrega.

Seu prazo é o requisito mais bem definido que você tem. Tenha algo completo e coerente que você possa entregar no prazo.

Colabore com seus testadores

Se esse processo solto é uma novidade para sua empresa, seus testadores provavelmente têm mais prejuízos do que você e podem procurar por você para orientação. Você precisa gastar um pouco do seu tempo no início do processo. Deixe seu chefe saber 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".

Teste o Teste primeiro design

Como você não tem requisitos formais, fazer com que os casos de teste sejam desenvolvidos forneceria alguma estrutura.

Familiarize-se com o Teste o primeiro projeto e / ou testar o desenvolvimento orientado e fornecer orientações aos seus 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.

Siga os padrões, especialmente para a interface do usuário

Você não tem requisitos sobre aparência e comportamento, mas tem um prazo. Use o trabalho de design de outra pessoa para minimizar o trabalho que você precisa fazer para criar um artefato de aparência profissional.

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

Comunique-se, mas não importe

Sugiro enviar um email para o 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 você não receber orientação. Por exemplo:

Will the users of this app need to access it with mobile devices? Right now we are assuming this will be a desktop/laptop only system.

Não entre em pânico

Eu tenho envolvido muitos projetos para pessoas que não conheciam o termo "requisito". A maioria foi bem-sucedida. Os proprietários de produtos não-hands-on oferecem a latitude para criar ótimas soluções.

Note que alguns proprietários de projetos nesses projetos eram impossíveis de agradar e se esconderam 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 começo. Às vezes é um pouco de ambiguidade nos requisitos. Às vezes, são muito incompletos. Você terá que trabalhar como parte do trabalho.
• O truque é reduzir iterativamente essa incerteza (combinando análise, design e implementação), refinando as histórias do usuário & implementar o seu sistema.
• Casos / cenários de testes e critérios de aceitação terão que ser esclarecidos da mesma maneira. Eles contribuirão para reduzir a incerteza sobre qualidade e correção (entre outros).
• No final, uma certeza suficiente é alcançada: o cliente recebe um produto testado que atende às suas necessidades e pode 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 por meio de seu envolvimento no processo de desenvolvimento.

Isso é um problema?

O sketchier os requisitos iniciais, quanto maior a incerteza, e quanto maior o tempo necessário para executar as tarefas. Então é só 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á sujeito a uma negociação. E o cliente deve aceitar envolvimento adicional (o argumento principal será "lixo, lixo", embora eu recomende strongmente que você o apresente de maneira mais diplomática ;-))

Um projeto sem requisitos claros, liderança frouxa, 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 atender a sua prazo final é uma receita para o fracasso do projeto.

O desenvolvimento iterativo não é uma má sugestão, mas requer uma cooperação próxima entre os proprietários do produto e os desenvolvedores. Tente convencer alguém a dizer: "Sabemos que teremos perguntas. Quem pode estar regularmente disponível para garantir que as respostas sejam respondidas para que a entrega do projeto não seja atrasada?" Agende horários regulares com alguém para revisar o progresso e remover impedimentos. Se eles não mostram, ou se recusam, então faça o acompanhamento com correspondências escritas educadas e atrasos ou não respostas de documentos. Se os proprietários do produto não puderem estar disponíveis, peça que forneçam um representante que possa ser.

Além disso, outra marca registrada do desenvolvimento iterativo é que uma mudança nos requisitos exige uma mudança na linha do tempo. Você não pode comprometer-se a cumprir um prazo se não puder desenvolver uma linha do tempo e você não pode desenvolver uma linha do tempo se não tiver uma boa ideia do que precisa ser feito. Em vez de solicitar dogmaticamente uma especificação, revise a especificação atual, documente todas as perguntas que você ou a equipe tiver sobre como ela deve funcionar, programe o tempo com os proprietários do produto para discuti-lo e documente as respostas. Quando tiver terminado, você terá suas especificações com base em suas decisões, com as quais você poderá fazer com que os proprietários do produto concordem (por escrito). O objetivo de uma especificação é remover a ambigüidade e criar um DoD, que é exatamente o que uma sessão de perguntas e respostas poderia fornecer. Se houver oposição a uma especificação, não chame isso de especificação.

Não acredite em ninguém quando ele lhe disser que será fácil . Às vezes é tão simples quanto parece, e eu posso acreditar nisso if (e somente if ) eu conheço bem os proprietários do produto para confiar plenamente que os requisitos realmente são tão simples como eles dizem que são, e as especificações que foram fornecidas são auto-explicativas (se não, eu agendar uma sessão Q & A e documentá-lo). Eu estive em muitas situações onde fácil do ponto de vista de operações é incrivelmente difícil do ponto de vista do desenvolvimento, ou você acha que está totalmente pronto e ouve as palavras de desespero ( "Ah, a propósito, nos 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 "Oh, esquecemos que alguns deles foram lidos lateralmente de uma maneira completamente inconsistente, e alguns têm o tamanho errado da página definido, e alguns precisam dessas três páginas anexadas, e precisamos que todos eles exibam o mesmo. Isso é realmente fácil de corrigir, certo? ".

" Não há reuniões agendadas regulares ". Bem, por que você não começa agendando reuniões regulares ? O fato de você ter vários proprietários de produtos garante que seu projeto NÃO será fácil, pois cada um desses clientes terá requisitos conflitantes que DEVEM ser discutidos pessoalmente com todas as partes interessadas presentes.

Além disso, eu realmente recomendo que você mantenha um registro detalhado de 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. Melhor ainda se você puder escrever porque algo foi decidido do jeito que foi. Não importa se é um arquivo em seu PC, uma página no seu wiki de intranet ou um caderno em 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 levar as especificações a serem modificadas, tudo bem, mas, neste momento, elas não podem esperar cumprir qualquer prazo que tivessem em mente - ou devem cortar o escopo em algum outro lugar.

Sem uma especificação, você tem trabalho em equipe. Seja ágil.

Especifique e distribua colaborativamente pequenas fatias verticais que são frequentemente demonstradas.

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

Eu gastei vários trabalhos fazendo projetos exatamente como você descreveu. Contanto que o PO saiba quais decisões de design você está fazendo e por que você tem que fazê-las, você deve estar bem. Se, por outro lado, eles não entenderem as decisões de design, será necessário pressioná-los por pelo menos um documento de teste de aceitação do usuário por escrito.

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 fugir disso.

Se ninguém mais estiver disposto a escrever essa especificação, os desenvolvedores precisam escrevê-la. Então você recebe uma especificação incompleta. Você o transforma em uma especificação completa (o que significa "isso é o que eu vou implementar a menos que alguém me diga para não"). Você entrega essa especificação para as partes interessadas e dá a elas a chance de modificar a especificação. Apenas uma chance para modificar a especificação - não a impondo, por exemplo, dizendo "Eu não gosto desse jeito". Nesse ponto, é sua especificação, ou eles podem fornecer uma especificação diferente, mas não remover a especificação.

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