O que fazer com o "Desenvolvimento Orientado a Falhas"?

Em nossa loja, nos esforçamos para ser ágeis. E eu diria que estamos fazendo grandes progressos. Dito isto, alguns de nós descobrimos um padrão que começamos a chamar de "Desenvolvimento Orientado a Falhas".

O Desenvolvimento Orientado a Falhas pode basicamente ser descrito como um ciclo ágil de liberação / iteração, em que os bugs / recursos são guiados não por tarefas e histórias com critérios de aceitação, mas com defeitos inseridos no software de rastreamento de defeitos.

Nossa equipe tem um ótimo gerente de projetos que se esforça para obter os critérios de aceitação do (s) cliente (s), mas nem sempre é possível. Da minha cátedra de desenvolvimento, isso se deve ao fato de o cliente não saber exatamente o que deseja ou (e esse é o kicker) dois "campos" diferentes no escritório principal do cliente conflitam com o modo como uma história deve ser implementada. Acampamento Um vai vagamente ditam que as obras a função X como este , em seguida, acampamento B irá falhar devido não funcionando como que . Portanto, o termo "FDD". O processo é conduzido por "falhas".

Isso leva à minha pergunta: mais alguém encontrou isso e, em caso afirmativo, alguma dica / sugestão para lidar com isso?

Obviamente, tentamos fazer com que os campos A e B concordassem antes, mas todos sabem que nem sempre é esse o caso.

obrigado

Requisitos extremamente conflitantes não são incomuns no mundo corporativo. E esse é frequentemente o motivo dos projetos de automação de processos de negócios "falharem". Pode ser tão simples quanto "o manual de políticas e procedimentos diz para fazer X", enquanto as pessoas que realmente fazem o trabalho fazem Y. Fazer o software fazer Y significa que as pessoas que pagam pelo software insistirão que o software está com defeito em seus perspectiva. Fazer o software X significa que as pessoas que realmente realizam o trabalho não podem fazê-lo.

Normalmente, a maioria das empresas de desenvolvimento escolhe o que os gerentes dizem sobre o que os trabalhadores declaram, porque é assim que as contas são pagas. No mundo ideal, não há incompatibilidade de impedâncias entre políticas escritas e reais; no mundo real, grande parte do trabalho de escritório é informalmente particionado e não documentado.

O Acampamento A ditará fracamente que o Recurso X funcionará assim, e o Acampamento B falhará por não funcionar assim.

A incompatibilidade entre o CampA e o CampB é uma questão política e não de software. Resolver o problema envolverá conversar com as pessoas e obter um vencedor claro.

Um dos principais motivos para usar o desenvolvimento iterativo é porque você tem um grupo de clientes que não tem uma boa ideia do que deseja.

Isso não é falha. Muitos clientes simplesmente não têm uma idéia exata do que precisam até conseguir algo em suas mãos. É por isso que, pela primeira vez, o cliente vê que o sistema não deveria estar após todo o ajuste e acabamento terem sido feitos. Deixe-os vê-lo cedo e frequentemente.

Em outras palavras, se esse era o único problema, não há necessidade de entrar em pânico, a menos que você acabe em uma situação em que apenas tenha inúmeras tentativas.

O problema de desacordo entre o corpo do cliente é um problema do gerente de produto que não deve vazar para você. O máximo que você deve ver é a lista de pendências / tarefas / o que for. Obviamente, o gerente geral irá se desdobrar no campo do desenvolvimento, porque esse é o único lugar que eles podem, mas não deve afetá-lo.

Como ele é gerenciado dependerá muito de quem são o Campo A e o Campo B.

Se os campos A e B representarem dois altos, convide alguém que realmente usará o sistema para lhe dizer o que você precisa. Às vezes, você recebe ar rarefeito na área de gerenciamento, causando uma desconexão com a realidade. Alguém que é prático pode muitas vezes atravessar o idealismo e apontar o que é realmente necessário.

Por outro lado, se A e B são grupos de usuários, você usa a abordagem oposta de levar alguém da gerência a estabelecer a lei.

Em todos os casos, a perfeição é inimiga do suficientemente bom.

O que você descreve é ​​uma implementação incorreta típica do Agile. Você não aceita a mudança, você é seu escravo .

Você possui um proprietário do produto? Você pode conversar com eles conforme necessário? Você está fazendo uma revisão de sprint com os usuários? Os usuários estão envolvidos no processo (através do proprietário do produto) no planejamento do sprint? Você tem testadores na equipe principal?

Eu sugiro que você contrate um treinador Agile e / ou envie sua equipe para um treinamento.

Outra solução é parar de fazer o Agile.

Se eles praticam pingue-pongue (A diz x, B rejeita, diz y, A rejeita e volta para x), seus leads (PO ou o que você tem) precisam bater neles para se decidirem .

Tudo bem se o primeiro passo não atender às necessidades deles (o objetivo é fornecer a eles algo para olhar), mas se eles ficarem lá e se movimentarem nas iterações subseqüentes, você nunca terminará.

O problema aqui não parece ser "saberei quando o vir". Os wireframes podem ajudar (até certo ponto) com esse problema específico.

O problema aqui é, parece-me, as duas facções concorrentes dentro do seu cliente. O ideal é que os campos A e B tenham uma visão compartilhada negociada que eles possam apresentar a você.

Talvez eles possam ser forçados à mesa por você, explicando quanto custa os combates, enquanto refaz novamente o que A pediu B (ou vice-versa).

Manter anotações detalhadas do seu tempo gasto ajudaria aqui. (Meu trabalho criou um aplicativo de rastreamento de tempo leve: fácil de usar e fácil de gerar relatórios e relata o tempo em partes de 15 minutos. É fácil dizer "eu passei n horas no recurso X".)

Isso significa que você corre o risco de incomodar o cliente ou parecer mal, não importa o que faça, pois o que você faz para B pode perturbar A (ou, novamente, vice-versa).

Espero que você possa encontrar um campeão no cliente que possa cuidar das lutas internas para você.

A meu ver, o problema só pode ser efetivamente resolvido em um local, na loja do cliente, o que será difícil.

Você está mencionando que está se esforçando para ser ágil, então eu o considerarei da perspectiva do scrum, que é o processo ágil que eu conheço melhor.

De acordo com o scrum, você tem uma função específica, o proprietário do produto, responsável por priorizar as histórias / bugs / lançamentos do usuário, etc. Isso idealmente deve ser apenas uma pessoa. Se houver muitas partes interessadas com visões diferentes sobre o mesmo software, é de responsabilidade do proprietário do produto que o produto satisfaça todas as partes interessadas.

Parece-me que seu gerente de projeto tem esse papel. Mas como ele é chamado gerente de projeto e não proprietário de produto, sou levado a acreditar que ele também está sobrecarregado com outras tarefas (tarefas de gerenciamento tradicionais e não ágeis?) E não tem tempo suficiente para prosseguir com a tarefa. função de proprietário do produto.

Portanto, acredito que você precisa de uma pessoa com a responsabilidade de coordenar as necessidades entre as diferentes equipes do cliente, garantindo que os requisitos / histórias de usuários entregues aos desenvolvedores sejam verificados pelas duas equipes no cliente. O exercício dessa função pode ser facilmente um trabalho em período integral, especialmente com o cliente que você possui.

O que seria realmente ideal é transferir essa responsabilidade para o cliente, para que um dos funcionários de seu cliente tenha a função de proprietário do produto. Enquanto o cliente não tiver essa função, ele não estará comprometido em resolver suas próprias divergências internas, e eles decidem resolver isso, o que você provavelmente não será capaz. E é por isso que acredito que a única solução eficaz é dar ao cliente essa responsabilidade.

Mas, considerando que você já iniciou uma colaboração, acredito que será difícil implementar essa mudança.

Para que seu software seja aceito pelo cliente, ele deve atender aos requisitos definidos pelo cliente de acordo com os critérios de aceitação.

Você tem um conjunto de requisitos do usuário na forma de histórias e critérios de aceitação, mas partes da organização do cliente têm interpretações diferentes das histórias do usuário, levando à ambiguidade.

Você pode sair dessa situação descrevendo o design funcional e as regras de negócios implementadas e assinando-as pelo cliente. Estes serão, então, o que é testado durante a aceitação. Isso deve ser acordado previamente pelo cliente para evitar discussões sobre o significado de toda a documentação posteriormente.

Contanto que seu grupo não possa descrever o software que você está construindo de forma que ambos os grupos concordem com ele, você ainda estará na fase de análise de requisitos do projeto.

Seu gerente de projeto pode / deve oferecer consultoria paga como parte do projeto para resolver a ambiguidade nos requisitos funcionais.

Acho que todos vimos o caso em que obtemos requisitos detalhados do usuário, implementamos e depois ouvimos o usuário "Espere, isso não vai funcionar para mim", uma vez implementado.

Uma coisa que ajudaria é fazer uma forma de controle de qualidade dos requisitos, fornecendo ao usuário exemplos detalhados com o comportamento esperado do sistema. Por exemplo, você pode dizer: "Aqui está um exemplo de caso. Se implementarmos X, Y será o resultado e Z uma das consequências". Dessa forma, você pode obter "Espere, isso não vai funcionar" antes de escrever o código em vez de depois.