Como a prototipagem rápida se encaixa em uma metodologia ágil?

Eu trabalho para uma grande empresa, que determina o uso de processos ágeis. Por exemplo, para nossos projetos, usamos serviços baseados em nuvem especificamente direcionados ao gerenciamento do desenvolvimento ágil.

O grupo de engenharia específico em que trabalho não desenvolve software tradicionalmente (em vez disso, ajudamos a direcionar projetos de um ponto de vista muito mais abrangente), mas isso está mudando. Temos uma ampla gama de projetos de software futuros / planejados que são principalmente centrados em dados - por exemplo, faremos monitoramento, coleta, agregação e alguns relatórios de dados. Outras tarefas envolvem automação com hardware especializado e vários tipos de arquiteturas de cliente / servidor (multicamadas). Devo ajudar no processo de contratação de várias pessoas e na formulação de muitos de nossos planos para avançar.

Minha pergunta é se a prototipagem rápida (código descartável) se encaixa ou não em uma filosofia ágil. Por exemplo, eu amo o Python e sua grande variedade de pacotes. Vejo a possibilidade de implementar muitas de nossas idéias muito rapidamente com um fluxo de trabalho baseado em Python. No entanto, acho que haverá muitas percepções de que o Python não é de "qualidade corporativa" e muito desse trabalho precisaria ser reescrito em Java ou talvez C ++.

No entanto, a criação dos protótipos do Python nos daria muito dinheiro para nos permitir entregar rapidamente resultados reais.

Você conseguiu incorporar a prototipagem rápida - espero que em Python - em um sólido fluxo de trabalho ágil em um ambiente corporativo?

O conceito de "prototipagem", como pretendido no RAD , é um pouco estranho ao desenvolvimento ágil. Isso não significa que não pode ser feito, mas é incomum.

Existem diferentes casos que precisam ser explorados:

1. O protótipo é uma "concha vazia", ​​uma simulação ou demonstração, criada para dar uma idéia de como seria um produto? Certamente, você pode fazer isso com uma ou mais histórias - no entanto, você está criando algo com sua própria imaginação, não criando um produto com feedback real. As pessoas não avaliam uma demonstração como avaliam um produto. Por exemplo, veja o feedback sobre o protótipo da barra superior versus a implementação real da barra superior .

2. O protótipo é algo que precisa ser construído para entender melhor o espaço do problema? Em seguida, deve ser coberto como um pico , e apenas seus resultados são mantidos (o código-fonte é transitório).

3. O protótipo é uma versão 0.x? Um produto minimamente viável ? Em seguida, use o processo ágil de sua escolha. Se você precisar recriá-lo em outro idioma, provavelmente será melhor se tratar um produto diferente. Observe que às vezes isso é tratado como uma maneira de criar um atalho para escrever uma especificação ("deve fazer o mesmo que o protótipo!"). Essa é uma maneira muito ruim de documentar um produto, mas isso provavelmente é melhor explicado como uma pergunta e resposta separadas :-)

A prototipagem rápida (ou seja, desenvolvimento iterativo e incremental) não é o ponto principal do Agile?

Parece que você está tendo problemas com "percepção é realidade" em sua organização. Convém lembrar a todos que Agile não significa "descartar todos os planos", assim como Desenvolvimento Orientado a Testes significa "descartar toda a arquitetura".

E Python não é (se alguma vez foi) uma linguagem de brinquedo. A NASA e seus contratados usam Python , e se é bom o suficiente para eles, é bom o suficiente para mim.

Existe uma prática bastante estabelecida na Programação extrema chamada Spike . Isso significa que é um código descartável. Não há nada de especial nisso. É apenas um Sprint no qual o resultado esperado é o conhecimento sobre o código descartável.

O link acima tem informações suficientes sobre as boas práticas, armadilhas dos picos.

Seu caso específico de uso parece um bom exemplo: pode ser útil projetar a interface, validar o utilitário e mostrá-lo a alguns usuários.

Você jogará fora o código e não o colocará em produção (deixe isso perfeitamente claro para TODOS), portanto, ser ágil ou não realmente não importa. Quaisquer práticas ágeis são puramente opcionais para protótipos: sprints, queimaduras, testes, programação em pares ou qualquer outra coisa que você planeja usar.

Se você estiver criando principalmente modelos funcionais no Python para ajudar os proprietários de produtos e outros tomadores de decisão a conceituar o projeto, não precisa estar pronto para a empresa. No entanto, se você estiver criando provas de conceito ou tentando ver se consegue lidar com determinados níveis de desempenho, provavelmente deve seguir a linguagem de produção. Isso não significa que você não pode experimentá-lo em Python.

Independentemente disso, você jogará fora o código, mas tenha o conhecimento de poder fazer isso funcionar junto com uma melhor noção do que os proprietários desejam. Agora você pode usar qualquer método que desejar.

Eu acrescentaria que os protótipos são cruciais para o aprendizado e também no espírito do Agile. Se o protótipo permitir que você aprenda, especialmente em ciclos de feedback mais rápidos, tente. Trata-se de maximizar o aprendizado e compartilhar aprendizados com a equipe.

Em termos de aprendizado, eu acrescentaria que a prototipagem leva você a aprender mais rápido. Dessa forma, você pode validar se as pessoas se preocupam com o problema que você está tentando resolver - e se a solução que você tem em mente é exatamente o que elas estão procurando - sem perder muito tempo criando uma solução completa que pode , no final, não resolva um problema suficientemente doloroso ou não o resolva da maneira correta.

O verdadeiro espírito do Agile é sobre interação e comunicação. Eu diria que se o protótipo funcionar bem como uma ferramenta para ajudar na comunicação, não há nada errado em usá-lo no mundo Agile. Em nossa equipe (praticamos o Agile por mais de 5 anos), o usamos de tempos em tempos. E há alguns benefícios que posso ver disso

1) Auxiliar a comunicação

2) Coloque os usuários em entrevistas de solução e obtenha feedback antecipado

Embargo:

A comunicação direta entre o UX e os engenheiros NUNCA deve ser substituída por nenhum artefato de prototipagem. Se possível, o emparelhamento com o engenheiro funciona muito melhor do que a comunicação através de um mediador (protótipo).

Outros já mencionaram o objetivo de aprendizado dos picos. O que está faltando é o princípio ágil subjacente, que é rápido .

Um dos pilares do desenvolvimento ágil é reconhecer as partes difíceis e procurar provas de conceitos, ver se você consegue fazer isso. A maneira clássica de trabalhar todas as tarefas em uma ordem "lógica" pode se tornar muito cara se você achar que não pode fazer algo no final do projeto. Tudo o que foi feito até agora pode ser um desperdício.

Se precisar terminar assim, você quer saber o mais rápido possível. Em seguida, as partes interessadas podem optar por parar de gastar dinheiro enquanto ainda não há muito gasto e aceitar o que desejam não é viável ou tentar uma abordagem radicalmente diferente do problema que terá uma nova chance de sucesso. Se seus protótipos estão servindo a esse propósito, eles são realmente mais ágeis.