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

12

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?

BobIsNotMyName
fonte
3
Escrever código de descarte é uma coisa perigosa a se fazer. Se funcionar, então por que a empresa se importa com isso? "Jogue fora". Isso sempre acontece, a menos que você não mostre a eles. Nunca comprometo a qualidade do meu código, mesmo quando inseri hackathons. Eu poderia colocar o truque estranho aqui e ali - mas nada que seria "jogar fora". Ao prototipar, concentre-se nas histórias que fazem uma boa demonstração.
precisa
3
"grande empresa, que dita o uso de ágil" - a divertida mistura de palavras "dita" e "ágil" de alguma forma me lembrou o Manifesto Ágil Semi-Arsed . Indivíduos e interações sobre processos e ferramentas ... e nós temos processos obrigatórios e ferramentas para controlar como aqueles indivíduos (nós preferimos o termo 'recursos') interagem
mosquito

Respostas:

11

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 :-)

Sklivvz
fonte
Na minha opinião, esta é a pior resposta até agora, estou tendo dificuldade para entender de onde vieram todos esses votos positivos. A criação de protótipos para obter feedback antecipado não é incomum, é nativa do desenvolvimento ágil.
Martin Maat
@MartinMaat Por "protótipo", você quer dizer "uma versão inicial do produto entregue ao cliente que evolui gradualmente no produto de forma iterativa"? Nesse caso, é claro, você está certo que é nativo o modo como o ágil funciona e os três pontos que explico explicam exatamente como. Não é isso que as pessoas pretendem com essa palavra.
Sklivvz
8

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.

Robert Harvey
fonte
Concordo, Python não é uma linguagem de brinquedo ... No entanto, muitas das organizações da minha empresa usam Java extensivamente, e precisaremos fazer interface com seu código, e, portanto, é um requisito atrair pessoas com um forte background Java . Além disso, não é tanto a percepção das pessoas que entendem o software que é uma preocupação - é a percepção das pessoas que não o entendem. Essas são as pessoas que querem um nome que já ouviram antes, e esse nome é "Java" ... Eu adoraria que construíssemos uma equipe comprometida com o Python como linguagem principal, mas isso será difícil.
BobIsNotMyName 16/11
1
Mesmo que você protótipo no Python e reescreva parte ou tudo em Java, isso não é necessariamente uma coisa ruim (o python não tem o perfil de desempenho que alguns aplicativos precisam). Ter "ouvido" uma língua não é exatamente um endosso de toque. Dada a escolha, eu pessoalmente escolheria outra linguagem além do Java, mas outras forças frequentemente determinam a escolha da linguagem.
Robert Harvey
@ Robert Harvey: "A prototipagem rápida (ou seja, desenvolvimento iterativo e incremental) não é o ponto principal do Agile?": Até onde eu entendo, a prototipagem rápida significa criar um protótipo rápido e descartável e, depois do cliente aprovou, para construir um produto real (com design adequado, etc.). No ágil, você tem um compromisso entre os dois: você sempre tem um protótipo que é tecnicamente "bom o suficiente" (provavelmente não tão bom quanto um sistema que foi projetado antecipadamente, mas bom o suficiente para produção), para que possa ser entregue como um produto assim que o cliente estiver satisfeito com ele.
Giorgio
1
@Giorgio: Tudo bem, mas os clientes não sabem o que querem até que você mostre a eles e dizem "não, não é isso que eu quero, quero isso. " Se você faz isso em código ou em um pedaço de papel não faz diferença para mim, desde que identifique o que o cliente deseja.
Robert Harvey
2

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.

Borjab
fonte
1

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.

JeffO
fonte
1

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.

Melissa
fonte
0

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.

Ethan Teng
fonte
0

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).

Huimin
fonte
0

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.

Martin Maat
fonte