A falta de requisitos funcionais é ágil?

Hoje em dia todo mundo quer ser ágil. Em todas as equipes com as quais trabalhei, o formato do ágil era diferente. Algumas coisas são comuns - como stand-ups diários ou planejamento, mas outras partes variam significativamente.

Na minha equipe atual, há um detalhe que acho perturbador. É falta de requisitos funcionais. Não apenas não há uma forma escrita de expectativa, mas também nas tarefas, é vagamente definido o que precisa ser feito.

O objetivo do projeto é reescrever o sistema antigo usando novas tecnologias. O sistema antigo também não possui documentação razoável. Com certeza, um atualizado não existe. A descrição dos requisitos dos proprietários das empresas é - vamos fazê-lo na nova implementação da mesma maneira que na anterior. Parece razoável, mas não é. O sistema antigo é uma espécie de código de espaguete, e extrair requisitos de negócios é caro. Parece que a situação afeta o planejamento de maneira negativa. Com certeza, é propenso a erros e bugs na nova implementação (omitindo alguns detalhes).

Portanto, estou pensando - é realmente ágil não ter requisitos de negócios em caso de reescrever o sistema antigo?

Se a falta de requisitos funcionais é ou não ágil, é uma receita para o desastre. Você não pode reconstruir um sistema quando não sabe como esse sistema funciona.

Você precisa informar ao proprietário da empresa que não tem idéia de como o sistema antigo funciona.

Sua melhor opção é trabalhar com o proprietário da empresa ou com alguns usuários experientes para entender os processos de negócios em jogo e desenvolver seus próprios testes de aceitação. Se você puder trabalhar com alguns usuários finais, poderá obter mais feedback sobre como o sistema antigo funciona.

Caso contrário, você precisará fazer alguns testes exploratórios em um ambiente de não produção para reunir seus próprios requisitos. Muitas vezes, quando o proprietário de uma empresa diz "faça com que ela funcione como a antiga", ele fica restrito no prazo e não pode ajudá-lo como o proprietário da empresa deveria. Você precisa da experiência de alguns usuários experientes ou de muitos testes manuais de sua parte para entender como o sistema antigo funciona.

Informe o proprietário da empresa que a falta de requisitos e a compreensão do sistema antigo aumentará bastante o tempo necessário para reconstruí-lo - o triplo do tempo ou mais. Diante do aumento do cronograma e dos custos, o proprietário da empresa fornecerá a experiência necessária para reunir os requisitos mais rapidamente ou decidirá que a reescrita não é economicamente viável no momento.

Você receberá um dos seguintes:

• Requisitos adequados e um ciclo de desenvolvimento mais rápido
• Hora de reunir requisitos e reconstruir o software
• Um novo projeto que não vai acabar sendo uma marca negra em sua carreira

O Agile não altera a necessidade de requisitos funcionais, mas geralmente altera a forma como você os reúne . A maneira não ágil é que alguém passe por um longo processo e, em seguida, forneça algum tipo de documento contendo todos os requisitos para o sistema.

A maneira ágil de reunir requisitos é trabalhar em conjunto para especificar os requisitos para um pequeno incremento do sistema, construí-lo, obter feedback e fazer o próximo incremento. Na sua situação em que você está tendo problemas para convencer os proprietários do negócio a iniciar o processo, eu começaria talvez meio dia explorando a parte do sistema antigo em que você deseja trabalhar a seguir e geraria uma lista de perguntas sobre os requisitos.

Em seguida, sente-se com os proprietários da empresa e faça as perguntas. Algumas perguntas serão fáceis para eles responderem, outras são mais fáceis para você, observando o código, e algumas são difíceis de responder de qualquer maneira. Divida as perguntas difíceis em pedaços cada vez menores até chegar a algo que possa ser respondido.

O objetivo é obter respostas suficientes das suas perguntas para criar algo, obter feedback e reiniciar o processo. Lembre-se, quanto menores as alterações e menor o ciclo de feedback, menor será o problema se você criar a coisa errada.

A captura de requisitos é uma parte essencial de qualquer projeto de software (bem-sucedido). Mas escrever uma especificação de requisitos não é.

• Uma abordagem centrada na documentação pode acabar como um jogo de sussurros chineses: um especialista no assunto expressa um requisito, um analista anota, um desenvolvedor tenta escrever algo que atenda à descrição do analista, o usuário final fica confuso porque o software não resolva o problema deles.

  Técnicas ágeis sugerem que os desenvolvedores devem reunir requisitos diretamente dos especialistas no assunto, geralmente os usuários finais. Existem várias técnicas para fazer isso, por exemplo, conversando sobre um exemplo de cenário com a PME. Os desenvolvedores são bons em identificar casos extremos e pedir à PME que esclareça como o software deve se comportar nesse caso extremos.

• Em vez de reunir todos os requisitos antecipadamente (e, portanto, arriscar grandes mal-entendidos), as equipes ágeis provavelmente começarão com uma pequena fatia de requisitos, criarão um protótipo e o usarão para obter feedback para a próxima iteração.

• À medida que o entendimento dos requisitos muda com o tempo, uma especificação de requisitos estáticos fica desatualizada. Como isto pode ser evitado?

  Expressando requisitos como testes executáveis. Acontece que “especificação legível” e “testes executáveis” não são conceitos exclusivos, mas podem acabar sendo o mesmo documento. Por exemplo, pepino e outras idéias fora do espaço do BDD podem ser muito úteis aqui.

No caso de você reescrever um sistema antigo, o sistema original pode ser uma excelente fonte de requisitos. Mas quais aspectos são relevantes? Seus recursos de nicho estão sendo usados? Quais erros devem ser reimplementados para compatibilidade? Geralmente, não há solução alternativa para conversar com os usuários finais.

Ter um sistema em funcionamento também pode ser muito útil para testar o novo software, mas isso não está relacionado a nenhuma preocupação de agilidade.

Observe que projetos de escopo fixo e tempo fixo com prazos iminentes são a antítese do ágil. A abordagem ágil normal é escolher uma faixa de funcionalidade e primeiro entregá-la, depois iterar. As coisas mais importantes são feitas primeiro, as menos importantes depois (ou nunca). Se tudo é importante e DEVE ser feito o mais rápido possível, nada é importante e é improvável que o projeto entregue algo.

Na sua situação, a falta de requisitos não é um recurso ágil, mas mais um caso médio de disfunção organizacional. Se você deseja que o projeto seja bem-sucedido, precisará encontrar uma maneira de solucionar essa disfunção. Por exemplo, peça ao proprietário da empresa que não escreva um documento completo de requisitos, mas tente marcar uma reunião em que explique seus requisitos para o recurso mais importante. Você pode olhar para o sistema antigo para obter detalhes. Em seguida, implemente esse recurso e itere.

Aqui está como fizemos. Conversamos com os proprietários. Conversamos com os gerentes. Conversamos com os usuários que estão fazendo o trabalho. O que descobrimos sentados à mesa de um usuário e assistindo (e fazendo perguntas) foi incrivelmente útil. Os gerentes sabiam com quais usuários deveríamos nos sentar.

Descobrimos que algumas partes do sistema funcionavam muito bem e poderíamos escrever facilmente requisitos suficientes para iniciar o design, a codificação e os casos de teste e assim por diante, mas outras partes tinham algumas soluções desagradáveis ​​que os usuários no chão estavam usando, que os gerentes e os proprietários não tinham conhecimento. Para essas partes do sistema antigo, voltamos aos negócios e conversamos um pouco sobre o fluxo de trabalho e os processos antes de podermos definir quais deveriam ser as tarefas menores e, assim, dividi-las nas unidades que nosso método ágil desejava.

Portanto, embora o Agile pudesse decolar rapidamente em algumas partes do sistema, outros precisavam pensar e documentar um pouco mais antes de começarmos.

Reunindo requisitos em uma estrutura Agile e ninguém mencionou Histórias de Usuários? Uma história de usuário é essencialmente uma definição de alto nível do que o software deve ser capaz de fazer. Normalmente, qualquer feedback ou solicitação proveniente da empresa ou do usuário final pode ser gravado como uma história do usuário. ... Você pode pensar nos critérios de aceitação como os requisitos funcionais que suportam uma história de usuário.

Essa pergunta sugere o que deu errado com o movimento ágil. Não é culpa da pessoa fazer a pergunta; Caio nessa armadilha o tempo todo porque anos de vida corporativa me treinaram.

A armadilha da qual estou falando é pensar que há uma maneira Agile prescrita e correta de fazer as coisas. Isso pode ser porque as pessoas pensam que o Agile existe. Você não pode fazer Agile mais do que você pode fazer Pragmatic.

Não ter "especificações funcionais" ou o que seja, parece preocupante, mas pode não ser. Quantos detalhes você precisa para começar? Segurança e desempenho são os óbvios, que são conhecidos de antemão e se aplicam por todo o caminho. Caso contrário, é um mecanismo de preço de opções ou um aplicativo de relógio?

Haverá liberação contínua, discussão, aprendizado, retorno e alteração do software? Você está construindo macio mercadoria ou hardware?

Os desenvolvedores que trabalham em um processo em cascata geralmente não se envolvem até um estágio posterior, o que é um problema. Envolvê-los mais cedo ou desde o início significa que eles estão cientes de que as coisas não são claras, indefinidas e incompletas, o que parece incomodar os desenvolvedores de longa data, quando na verdade parte do trabalho deles é fazer perguntas, como "quais são as requisitos funcionais para essa coisa que vamos construir? "

Identificar falhas no plano não é encontrar falhas, é apenas desenvolvimento de software.

Por esse motivo, adoro a resposta de Guy.