Como o ágil pode ser aplicado a aplicativos que envolvem processamento complexo?

12

A maior parte da literatura sobre ágil parece ter tendência para aplicativos de negócios do tipo CRUD, nos quais o usuário está ciente do que está acontecendo nos bastidores. (Tudo bem, porque a maior parte do código que está sendo escrito provavelmente pertence a essa classe.)

Para esse tipo de aplicativo, o relacionamento entre as histórias do usuário (requisitos) e as tarefas de desenvolvimento é mais direto: basta dividir a história do usuário em algumas tarefas.

Mas há outro tipo de aplicativo em que a maior parte do código tem que lidar com processamento complexo que não é diretamente visível para o usuário. Exemplos seriam:

  • Compiladores
  • Sistemas de análise de imagem de carros autônomos
  • Sistemas de simulação de fluxo de fluido

Aqui pode ser realmente difícil relacionar tarefas e histórias de usuários. Existem técnicas para superar esse problema ou é apenas algo que temos que aceitar e tirar o melhor proveito dele?

Frank Puffer
fonte
6
Não é o menos votado, mas vou assumir que é porque a pergunta é baseada em uma premissa falsa. IMO sistemas complexos são ainda mais adequado para um desenvolvimento estilo Agile em virtude do fato de que eles são mais complexas. Quanto mais complexo o sistema, maior a probabilidade de ter requisitos emergentes. O Agile SwDev foi criado para lidar melhor com os requisitos emergentes.
precisa
4
@RubberDuck: "Eu assumo que é porque a pergunta é baseada em uma premissa falsa.": IMO, isso motivaria uma resposta na qual a falsa premissa é explicada, e não um voto negativo.
Giorgio
Se o uso entende a lógica ou não é totalmente irrelevante para o processo ágil. Cabe à equipe mapear uma história de usuário para uma implementação E estimar quanto tempo isso levará. Se for complicado e / ou muito trabalho, a equipe pode dividir a história em outras menores. O tipo de lógica não importa.
Martin Maat
2
"A maior parte da literatura sobre ágil parece ser tendenciosa para aplicativos de negócios do tipo CRUD" - e a maior parte da literatura sobre Java parece tendenciosa para imprimir a sequência de caracteres "Hello World" no console (ou computação alternativa do enésimo número de Fibonacci). Isso não significa que é a única coisa para a qual o Java é bom. O motivo é o mesmo nos dois casos: é difícil explicar exemplos realistas em um post ou tutorial do blog. [Nota: este é um comentário hiperbólico tentando ilustrar a base para a premissa falsa.]
Jörg W Mittag
1
O Agile não requer tarefas e histórias de usuários. Você pode usar qualquer forma de especificação que desejar. A questão toda é flexibilidade.
24717 Frank Hileman

Respostas:

9

Acabou sendo mais longo do que eu havia planejado (tinha começado como um comentário), mas espero que o comprimento / detalhes adicionados sejam úteis e você os encontre justificados.

O Agile não é específico para aplicativos CRUD

A maior parte da literatura sobre ágil parece ter tendência para aplicativos de negócios do tipo CRUD, nos quais o usuário está ciente do que está acontecendo nos bastidores. (Tudo bem, porque a maior parte do código que está sendo escrito provavelmente pertence a essa classe.)

Eu acho que isso ocorre porque é mais fácil criar exemplos fáceis de seguir desse tipo, não porque a metodologia é direcionada a esses tipos de sistemas. Se você criar um exemplo não tão fácil de seguir, corre o risco de ficar com o leitor preso ao tentar entender o exemplo quando seu argumento era ensinar ao leitor sobre conceitos ágeis.

Histórias de usuários! = Requisitos

Para esse tipo de aplicativo, o relacionamento entre as histórias do usuário (requisitos) e as tarefas de desenvolvimento é mais direto: basta dividir a história do usuário em algumas tarefas.

Uma história de usuário não é a mesma que um requisito. É verdade que pode haver alguma sobreposição, dependendo de quão alto é o requisito, mas geralmente não é o mesmo. Tenho a impressão de que você está enfrentando a mesma armadilha que muitos de meus ex-gerentes caíram: pensando nas histórias de usuários simplesmente como sinônimos de "requisitos", que é semelhante a quando os usuários do SVN tentam fazer a transição para o Git, mas continuem pensando em termos de SVN. (Eles então enfrentam problemas devido às suposições iniciais ruins.)

IMHO, a principal diferença entre requisitos e histórias de usuários é que os requisitos especificam, em detalhes, como certos componentes do sistema devem se comportar; são especificações que incluem entradas, saídas, premissas / condições prévias, possíveis exceções levantadas etc. Eles se concentram no que o sistema faz.

OTOH, as histórias de usuários concentram-se no resultado esperado para o usuário final sem tentar criar uma especificação comportamental detalhada para os componentes do sistema. Eles se concentram na experiência esperada do usuário .

O que eu costumava fazer, e essa era uma prática adotada por minha equipe, era dividir as histórias dos usuários em tarefas. Suas tarefas podem ser tão específicas ou vagas quanto você queria / precisava delas, mas elas deveriam ser seus indicadores de progresso para o trabalho real realizado no sentido de levar a história a um estado concluído.

Exemplo

Lembro-me aproximadamente dos EUA em que trabalhei anos atrás, nos quais os usuários precisavam designar casos de teste para que todos na equipe estivessem cientes de quais TCs estavam trabalhando para evitar esforços duplicados; a interface do usuário era um aplicativo da web (interno). O usuário viu apenas um botão, mas a história foi dividida em várias tarefas que incluíam alguns detalhes técnicos de implementação etc.

Visibilidade do Usuário

Mas há outro tipo de aplicativo em que a maior parte do código tem que lidar com processamento complexo que não é diretamente visível para o usuário.

É possível torná-lo visível para o usuário de alguma forma?

Considere um GPS. Quando você perdeu a sua vez, não verá o processo real de recálculo da rota, mas o usuário recebe algum feedback útil (por exemplo, "Recalculando ...").

Os compiladores podem exibir avisos ou erros ou incluir novas configurações / opções na GUI para que os usuários vejam que algo novo foi adicionado. Eu acho que os usuários dos compiladores seriam programadores, certo? Eles não veriam o suporte a um novo padrão adicionado?

Embora o suporte a um novo padrão provavelmente esteja no nível do recurso e precise ser dividido em histórias do usuário, você se certificou de que, pelo menos em alguns casos, não está tentando usar histórias quando deveria usar os recursos ?

A análise de imagem em um carro pode ser formulada de maneira a permitir que o usuário saiba que as chances de acabar em um acidente de carro foram reduzidas. Por exemplo:

Como passageiro em um carro autônomo, preciso que a probabilidade de o veículo causar um acidente colidir com um objeto não reconhecido seja o mais próximo possível de zero, para que eu possa viajar com mais segurança.

Que os EUA capturam, em alto nível, coisas que você normalmente precisaria especificar usando uma combinação de requisitos funcionais e não funcionais - incluindo segurança, proteção etc.

No entanto, um requisito pode ser mais sobre o sistema; por exemplo:

A função abcno componente Adeve ter o valor do limite de tolerância diminuído no algoritmo de comparação de imagens para detectar melhor os objetos que se movem lentamente.

Para mim, isso seria facilmente uma tarefa na história do usuário que mencionei acima, intitulada algo como: Diminuir a tolerância na funçãoA.abc e incluir outros detalhes relevantes nela.

Para um sistema de simulação de fluidos, você pode até ter uma barra de progresso que fornece feedback sobre as tarefas em segundo plano que o sistema está executando, se isso faz sentido. (Sempre há uma maneira de informar o usuário sobre algo, embora você queira evitar spam.)

Não conheço o suficiente sobre os domínios específicos que você mencionou para criar exemplos melhores e / ou mais realistas, mas se houver uma diferença aqui, você poderá usar diferentes maneiras de fornecer feedback ao usuário sobre algo menos visível que o sistema pode estar funcionando, ou seja, pode haver maneiras de tornar as coisas invisíveis um pouco mais visíveis. (Mesmo que tudo se resume a escrever um conjunto de notas de versão que documenta quanto mais rápido o desempenho do sistema é devido aos seus esforços, etc.)

Relação entre histórias e tarefas

Aqui pode ser realmente difícil relacionar tarefas e histórias de usuários.

Nossa abordagem foi manter as histórias dos usuários focadas no que era a solicitação, por que ela foi feita e no que as coisas precisavam ser verdadeiras para considerar os EUA "concluídos". O how sempre foi deixado de fora dos EUA e deixado para o (s) desenvolvedor (es).

O (s) desenvolvedor (es) dividiriam o problema descrito nos EUA em um conjunto de tarefas nas quais eles trabalhariam.

Estou dizendo isso como alguém que, na maioria das vezes, fez a programação no servidor de back-end, que provavelmente é tão "invisível" quanto possível para o usuário final.

Dependendo do que eu precisava fazer, às vezes eu usava o AJAX para mostrar uma animação / gif "carregando ..." simples, para que o usuário soubesse que precisava esperar um pouco para que algo mais fosse concluído, sem ter a impressão errada. Às vezes era tão simples assim. Uma tarefa para isso seria apropriada.

Paradigma, prática e experiência diferentes

Existem técnicas para superar esse problema ou é apenas algo que temos que aceitar e tirar o melhor proveito dele?

Além de aceitar a mudança de paradigma, praticar e acumular experiência, provavelmente não há muito mais a dizer. Eu sempre vi pessoas tentando usar atalhos durante o processo. Eu aconselho isso, especialmente se você está começando. À medida que obtém mais experiência, você pode permitir alguma flexibilidade, mas evite prejudicar a si mesmo.

Dada a sua redação anterior, você ainda pensa nas histórias como se fossem "requisitos renomeados", o que eu acho que é uma suposição falsa. Penso que este é um sintoma de uma questão mais profunda sobre as diferenças fundamentais entre abordagens ágeis e não-ágeis.

Em segundo lugar, acho que você deve aceitar que o ágil é uma mudança de paradigma em comparação à cascata, o que significa que, embora o processo tenha objetivos semelhantes, eles o fazem de maneiras muito diferentes. (Pense em SVN vs Git, se isso ajudar.)

Tente melhorar sua compreensão atual das diferenças conceituais entre requisitos e histórias de usuários e aceite que elas não são a mesma coisa.

Aprendendo com seus Sprints - Retrospectivas

O que não posso enfatizar o suficiente é a retrospectiva entre Scrum Master e Desenvolvedores no final de cada sprint. É nesse lugar que eles discutem coisas que "deram certo" ou "não deram certo" de maneira honesta / transparente, e que mudanças factíveis serão implementadas para o próximo sprint para abordar os pontos "não deram certo" .

Isso nos permitiu adaptar e até aprender com as experiências uns dos outros e, antes que percebêssemos, tínhamos melhorado significativamente conforme medido pela consistência geral da velocidade de nossa equipe.

code_dredd
fonte
"Histórias de usuários! = Requisitos": não quis dizer que os dois são sinônimos. Nem todo requisito é uma história de usuário. Mas acho que todas as histórias de usuários são requisitos. Eu vejo os requisitos como uma estrutura hierárquica em que as histórias de usuários são um nível específico de detalhe. Você concordaria?
24817 Frank Puffer
@FrankPuffer Eu acho que visualizar histórias de usuários como se elas fossem um nível diferente em uma hierarquia de requisitos é basicamente misturar conceitos diferentes. No lado ágil, uma hierarquia se parece mais com: Temas >> Épicas >> Recursos >> Histórias de usuários >> Tarefas . Os requisitos geralmente são divididos em requisitos funcionais e não funcionais na abordagem mais tradicional da Waterfall, mas não encontrei uma hierarquia real; Dito isto, não ficaria surpreso se alguém dividisse recursivamente um requisito em "sub-requisitos" menores. De qualquer forma, você está misturando diferentes conceitos.
code_dredd
Sistemas de gerenciamento de requisitos como o PTC Integrity tratam os requisitos como uma hierarquia. Isso pode ser uma vantagem ao mapear requisitos para um documento de especificação.
Frank Puffer
@FrankPuffer Sim, é por isso que eu disse que não ficaria surpreso. Dito isto, gostaria de saber que minha resposta esclareceu alguma coisa para você. A analogia entre SVN e Git foi útil? (Ele assume que você está familiarizado com ambos os sistemas, o que parecia razoável num contexto de desenvolvimento de software.)
code_dredd
Ok, eu interpretei mal o "não" como "faria". E sim, acho sua resposta muito útil e provavelmente a aceitarei. Provavelmente, só preciso de um tempo para me acostumar com a ideia de não considerar as histórias de usuários como requisitos.
Frank soprador
4

Os princípios ágeis certamente podem ser aplicados nesses casos. Quão?

  • Compiladores podem ter novos recursos de idioma adicionados posteriormente em histórias de usuários separadas
  • Os sistemas de análise de imagem podem ter novos recursos adicionados como diferentes classificações de imagem
  • Os sistemas de simulação de fluxo de fluido podem levar em consideração diferentes aspectos do modelo em suas simulações

Você não precisa comer o elefante inteiro de uma só vez. O Agile apenas pede que você mostre que limpou o prato antes da próxima porção de elefante.

candied_orange
fonte
Ainda acho que permanecerão uma ou mais histórias de usuários que exigem muitas das chamadas funcionalidades básicas. Eles geralmente não se encaixam em um único sprint. Como isso deve ser tratado?
Frank soprador
1
Você mede o sucesso com aplicativos executáveis ​​que os clientes podem testar, ver ou tocar. Se for esse o caso, dê a eles um brinquedo que gere o sentido de progresso dessa maneira. Por exemplo, você provavelmente não pode liberar um carro autônomo no primeiro sprint, mas pode fazer uma demonstração de como seu algo reconhece as pessoas. Mais tarde, como reconecta sinais e animais. Mais tarde, como Ele mede distâncias, tamanhos, etc ... O carro autônomo está muito, muito longe em um sprint remoto que quem sabe se isso acontecerá.
23417 Laiv
2
@ Laiv: Isso seria bom, mas não tenho certeza se funciona. Em resumo, após os primeiros sprints, o software não poderá fazer nada com o qual o cliente possa se relacionar. Você terá progresso técnico, mas será difícil, se não impossível, comunicá-lo ao cliente.
31817 Frank Puffer
2
Por quê? Porque foi escrito no Stone por alguém estranho ao seu projeto? Eu espero que o Agile se adapte às minhas necessidades, e não o contrário. Se eu disser que posso ensiná-lo a andar de skate em 4 semanas e, uma vez no dia 5, você ainda não conseguirá ficar de pé, isso significa que você não está aprendendo a andar de skate? Ou apenas que vai demorar um pouco mais? O manifesto ágil não foi escrito em pedra, nem as regras do Scrum são os Mandamentos de Tendência.
LAIV
2
O objetivo dos sprints é tornar seu cliente parte de suas iterações. Para se comunicar com eles usando o código entregue. Não planos e promessas. Exige que você se concentre em resolver o problema. Não exige que a primeira coisa que você entregue seja gravada em pedra. Exige que você prove que vale a pena pagar cada corrida.
23717 Candied_orange
1

Descobri que as pessoas que aderem estritamente às histórias de usuários apenas se envolvem em um exercício muito bobo de apresentar maneiras absurdas pelas quais as mudanças técnicas de back-end afetam o usuário (sem o conhecimento do usuário, é claro, porque são apenas ingênuas usuário e você está falando sobre alterações complexas em sua linha de análise de dados ou algo desse tipo) ou elas terão uma perda total para "como podemos organizar esse trabalho!?!"

Eu acho que a solução óbvia é ser mais pragmático. Se o trabalho for de natureza muito técnica e não tiver um impacto particularmente perceptível sobre o usuário, não perca o sono tentando explicar como ele funciona. Basta escolher uma maneira óbvia e simples de beneficiar os usuários e, em seguida, orientar a história em torno dos detalhes necessários para que os desenvolvedores façam seu trabalho. Acho incrivelmente frustrante quando um OP insiste em não ter informações técnicas na história quando é absolutamente necessário. Não é apenas uma visão holística sobre o que esse artefato (a história) realmente é. Como eles acham que existe apenas para eles, na maioria dos casos também é importante para os engenheiros.

Para a maioria dessas tarefas técnicas, há poucas frutas pendentes em relação ao impacto do usuário, se isso está melhorando a eficiência, de modo que as entregas futuras serão mais rápidas, melhorando o desempenho, a confiabilidade etc. Eles não são realmente o que as pessoas pensam quando pensam em 'histórias de usuários', mas se a empresa quer entender por que você comprometeria uma dívida técnica ou algo nesse sentido, essas explicações geralmente são as mais simples de fornecer.

Não deixe que um scrumnazi torne sua vida mais difícil, simplesmente porque eles são muito quadrados para se adaptar. Ser adaptável é um conceito central de agilidade, afinal. A aderência estrita ao Scrum ou ao Agile geralmente voa na cara ou no pragmatismo e na praticidade (o que realmente funciona melhor).

evanmcdonnal
fonte
Sou a favor de ser flexível, mas, francamente, o usuário não se importa particularmente com os detalhes técnicos, desde que suas histórias sejam satisfeitas. Você não precisa ser "estritamente ágil" para ter bons requisitos; e por bons requisitos, quero dizer requisitos que são acompanhados por um teste de aceitação que prova inequivocamente que o requisito foi atendido. As pessoas que estão "se envolvendo em exercícios muito bobos" obviamente estão fazendo algo errado, mas isso não significa que estejam seguindo alguma noção de "rigoroso scrum".
22417 Robert
@RobertHarvey Concordo que os detalhes técnicos são irrelevantes para o usuário, mas o que quero dizer é que os artefatos que contêm histórias de usuários têm um propósito mais amplo do que apenas comunicar como as coisas funcionam para o usuário (ou pelo menos deveriam). Como aplicar os requisitos relacionados à arquitetura, extensibilidade, desempenho e assim por diante, se eles escrevem histórias puramente de usuários? Adotar uma abordagem pura da 'história do usuário' incentiva os desenvolvedores a escrever código de baixa qualidade. E não são usuários que leem as 'histórias de usuários', são devs e qa, é tolice excluir deliberadamente informações relevantes por serem técnicas.
precisa saber é o seguinte
0

Acho que o problema é dar às histórias dos usuários um significado que elas não têm. Scrum usa o termo PBI, ou Product Backlog Item, que eu acho infinitamente melhor. PBIS vai muitas vezes seguem um formato de história de usuário, por exemplo, você pode ter um PBI como "Assinantes deve ser capaz de ver os seus detalhes da assinatura", mas você também poderia muito facilmente ter um PBI como "Criar um procedimento armazenado para obter detalhes de assinantes "

Histórias de usuários são uma ferramenta . Eles ajudam a formar descrições e requisitos de recursos com base em colocar-se no lugar de um usuário. Mas, assim como uma chave inglesa é inútil quando você precisa colocar uma foto, há momentos em que você pode não precisar de uma história de usuário.

Dito isto, muitas equipes realmente jogam rápido e frouxamente com a parte "usuário". Eles podem ter "histórias de usuário" como "Como desenvolvedor, preciso poder chamar um procedimento armazenado para obter detalhes do assinante", essencialmente uma "história de desenvolvedor" por assim dizer. Essa é uma opção igualmente válida, mas pessoalmente, digo que, desde que você possa descrever o que precisa ser feito e criar um conjunto de critérios de aceitação, dificilmente importa se você tem uma história real do usuário ou não.

Chris Pratt
fonte
1
Não concordo com isso, exceto em casos muito estranhos e raros. No Scrum, o HOW é da competência da equipe de desenvolvimento, não do proprietário do produto. No entanto, o proprietário do produto deve ser responsável pelos PBIs. Portanto, um PBI como "criar um procedimento armazenado" retira da equipe de desenvolvimento o direito de escolher o COMO. Os PBIs, com ou sem história de usuário, devem explicar qual é o valor comercial do PBI. Criar um procedimento armazenado não é sobre valor comercial, é sobre detalhes de implementação.
RibaldEddie
Essa não é a questão. Aquilo foi apenas um exemplo. Você pode simplesmente mudar o "procedimento armazenado" para algo genérico como "um caminho". O ponto é que não precisa necessariamente ser uma história de usuário.
31517 Chris Pratt
todo o objetivo de um exemplo é ser um exemplo. Se o seu exemplo "não é o ponto", então qual é o ponto do exemplo?
RibaldEddie
-3

Esses tipos de aplicativos são exatamente aqueles em que diferentes conhecimentos estão presentes e se desenvolverão ainda mais. Os membros da equipe terão devido a diferentes níveis de educação, diferentes projetos de hobby e diferentes experiências de trabalho anteriores, diferentes habilidades. Além disso, se alguém desenvolve um pedaço de código específico, pode-se esperar que o desenvolvedor seja quem conhece melhor o código. Portanto, pode fazer sentido atribuir tarefas de desenvolvimento adicionais que envolvam o mesmo trecho de código ao mesmo desenvolvedor.

No processo ágil mais popular, Scrum, há um planejamento de pôquer em que cada tarefa recebe um nível de dificuldade. O nível de dificuldade não depende da pessoa que está realizando essa tarefa de acordo com o processo. Depois, durante o sprint, as pessoas são consideradas homogêneas, de modo que se espera que cada pessoa possa escolher cada tarefa e implementá-la. Em projetos simples como CRUD, essa suposição é válida. Mas em projetos muito complexos e difíceis, certamente não.

Eu não usaria um processo ágil para esse tipo de projeto. Sua melhor opção é evitar qualquer processo formal e usar apenas um bom gerenciamento de projetos. Ao decidir quem implementa um recurso específico, considere quem possui as melhores habilidades necessárias para esse recurso e o melhor conhecimento do código existente. Nenhum processo é necessário para isso. Provavelmente, você deseja escrever bons documentos de design para todos os recursos e mantê-los atualizados. Observe que não estou promovendo um modelo em cascata aqui: os documentos de design nem todos serão gravados no início do projeto; em vez disso, você escreverá novos documentos de design conforme novos recursos forem necessários.

juhist
fonte
5
Não está realmente relacionado à minha pergunta, mas sempre deixar que alguém com as melhores habilidades implemente um recurso pode ser perigoso. Isso dificulta a disseminação do conhecimento dentro da equipe. Se a manutenção for necessária e o especialista deixar a equipe ou estiver temporariamente indisponível, você estará com problemas.
31817 Frank Puffer
@FrankPuffer Para alguns dos tipos de sistemas listados, por exemplo, carros autônomos, se o especialista sair da equipe, você está com problemas. Período. Embora provavelmente não seja o caso de a codificação ser centralizada, também é completamente irracional assumir uma "disseminação de conhecimento" adequada para permitir a substituição do especialista em qualquer escala de tempo razoavelmente curta. São pessoas que passaram mais de uma década pesquisando o problema e presumivelmente estão perto do topo de seu campo. Você provavelmente precisará de várias pessoas com diferentes habilidades. Tais projetos são inerentemente arriscados.
Derek Elkins saiu de SE