Os princípios ágeis se sustentam?

Charles Lambdin Blocked Unblock Seguir Seguindo 28 de novembro de 2018

O último post gerou muito feedback. A maioria foi positiva. Alguns foram negativos. Isso levou a algumas trocas interessantes online que levantam uma questão importante: o que exatamente é “ágil”? Aparentemente, é simples. Disseram-me, mais de uma vez na semana passada, que o Agile é apenas um conjunto de princípios, e qualquer coisa que se alinhe aos princípios é Ágil.

Então, dito de outra maneira: Qualquer coisa que não esteja em desacordo com os princípios ágeis pode ser reivindicada como sendo ágil?

Isso não parece muito útil. Tome algum novo conjunto de práticas. Se os princípios do Agile não revelassem, apontassem para ou prescrevessem essas novas práticas de maneira significativa, mas apenas "se alinhasse" com eles, como isso é importante? (É como um candidato ser aprovado por um político? Cheira a marketing, ou uma guerra de territórios.) Por que então manter referindo-se a Agile, dando-lhe preferência sobre tantas outras ideias? É uma obsessão bizarra. À medida que as organizações digitais – por necessidade – continuam a evoluir além de uma mentalidade de fábrica do século 19, apelidar tudo de “Ágil” em retrospecto é enganoso . Verdade seja dita, Agile pode não ter ajudado muito com essa evolução. Na prática, o Agile perdeu muito para o Scrum, que manteve o foco no custo e na otimização local, reforçando uma mentalidade incrementalista de "fábrica de recursos".

(Como argumentei na última vez, acho que muitos na comunidade de produtos estão passando por essa obsessão. Equipes de produtos mais jovens não parecem se identificar como "fazendo Agile". Elas estão apenas fazendo o trabalho do produto . Parece que é principalmente pessoas mais velhas tentando afirmar que tudo é Agile. Talvez não seja coincidência que tantas trocas com os Agilistas acabem me lembrando Horace Nebbercracker no filme Monster House. )

Que alguns (bastante veementemente) insistem que Agile é a caixa em que tudo deve caber é simplesmente estranho. Agile não é apenas uma das muitas coisas? Aparentemente não. Foi-me dito esta semana que o Lean em si é “Agile thinking” (mesmo que anteceda o Manifesto por meio século), e que o DevOps é apenas Agile também.

Tudo bem, eu digo, se tudo deve estar ligado aos “princípios ágeis”, então é melhor que esses sejam alguns bons princípios. Quero dizer, depois de um tempo, os Agilistas começam a soar como os seguidores de Sydney Banks – “É tudo sobre OS PRINCÍPIOS…”. Então, esses princípios devem ser realmente importantes, bem abrangentes. Se não os levarmos a sério hoje, nós convidamos o fracasso, certo? Isso pelo menos não pressupõe os princípios que todos sustentam hoje? Parece, mais por que todo o tumulto?

Mas eles realmente aguentam hoje? Bem, vamos apenas ver. Pode ter sido um tempo desde que você leu através deles.

Os 12 princípios ágeis

1. Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.

Quem é o “cliente”? Eu vi pessoas afirmando que é basicamente “todo mundo impactado pelo seu trabalho”. Essa é uma história revisionista. Como Melissa Perri observou, os co-autores do Manifesto estavam falando sobre as partes interessadas nos negócios, o que é provável porque o Manifesto ainda está se concentrando em “requisitos”. Agora, use a palavra “valioso”. Valioso para quem? Como assinala Mark Schwartz, o pressuposto oculto é que o negócio sabe o que será de valor (uma suposição bastante comum). Mais uma pergunta: como você normalmente satisfaz as partes interessadas nos negócios? Resposta: Perguntando-lhes o que eles querem… e é por isso que a maioria dos recursos é raramente ou nunca usada e 60–90% do que construímos é desperdício.

2. Bem-vindo mudanças nos requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam as mudanças para a vantagem competitiva do cliente.

Requisitos não são uma boa maneira de se comunicar, ponto final. Isso destaca que o Agile ainda está focado na produção, não nos resultados. Um "resultado" é a mudança concreta de comportamento que você está tentando alcançar para criar valor comercial. É o comportamento dos usuários que você normalmente espera mudar, não os stakeholders das empresas. (Em quem, então, você deve gastar a maior parte do tempo aprendendo?) Concentrar-se nos resultados faz com que você perceba que sua saída é apenas uma ferramenta para testar suas suposições. Como Jeff Patton coloca, você não deveria estar tentando maximizar a produção – você deveria estar tentando maximizar os resultados por saída mínima . É assim que você aumenta o "valor".

3. Forneça software de trabalho com frequência, de algumas semanas a alguns meses, com preferência para a escala de tempo mais curta.

Claro, encolha seus malditos lotes já. Mas perceber o que você realmente está fazendo é avaliar as premissas sobre qual saída atingirá os resultados e quais resultados produzirão impacto nos negócios. Não importa se você está tendo o tipo certo de conversa com os usuários, fazendo com que eles mostrem seu fluxo de trabalho atual, esboçando uma ideia, fazendo uma rápida prototipagem participativa ou apenas codificando softwares, tudo isso é apenas um nível de verificação contínua . E por que o foco no software? É irônico quando as equipes Agile dizem que não precisam aprender sobre o trabalho de descoberta porque já estão “inspecionando e adaptando”. Como Alan Cooper aponta, a maioria das equipes Agile mantém a maior parte do código, o que significa que eles não estão realmente inspecionando e adaptando qualquer coisa. Eles estão apenas dividindo seu trabalho em caixas de tempo, e isso não é a mesma coisa.

4. Empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.

Não. Pessoas de negócios devem ser mantidas no circuito. Desenvolvedores e usuários finais devem trabalhar juntos diariamente. Eu vi pessoas apontarem para o XP e dizer: “Isso é o que o Agile quis dizer”. Talvez, mas não é isso que os princípios dizem! O XP tinha muita bondade real (ignorando que muitas pessoas realmente odeiam a programação em pares). De fato, introduziu muitos conceitos que agora fazem parte do movimento DevOps. Com isso dito, enfatizando o pragmatismo e o progresso sobre o idealismo, talvez seja hora de admitir que o Agile perdeu para o Scrum . Como Patton argumenta, a Scrum tem um intermediário, o “PO”, sendo o “cliente”, consagrando o antipadrão de fornecedor-cliente e, normalmente, removendo ainda mais os desenvolvedores de seus usuários reais.

5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para realizar o trabalho.

Não. Os projetos de construção reforçam a prática de dividir equipes continuamente e mover pessoas desnecessariamente. Parabéns por chamar a atenção para a necessidade de confiar nas equipes para realizar o trabalho. Um monte de calorias desnecessárias queimados em torno de prazos e estimativas de tempo e "dimensionamento" resume-se a não confiar realmente em suas equipes.

6. O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa cara-a-cara.

Eu vi dados (de Larry Maccherone) mostrando que equipes distribuídas (no mesmo geo) fazem mais trabalho do que equipes colocadas. Isso certamente gelou com a minha experiência. Além disso, quando os membros da equipe são colocados uns com os outros, mas não com os usuários reais, isso é um problema maior . Observe também que a colaboração diária F2F também exige que todos entrem no escritório todos os dias. Isso levanta a questão de pesquisas mais recentes mostrando que as pessoas que trabalham em casa têm maior satisfação no trabalho e realizam mais trabalho real. Como Jason Fried pergunta, o que você faz quando realmente precisa fazer algo? A maioria das pessoas não entra no escritório, onde pode ser difícil se concentrar e você é constantemente interrompido.

7. O software de trabalho é a principal medida de progresso.

Se é isso que você pensa, tomando emprestado o termo de John Cutler, você é uma “fábrica de recursos”. Alcançar os resultados é a principal medida do progresso. Se você constrói alguma coisa e sua medida de resultado alvo não se move na direção certa, você não está "pronto". Quem se importa com o software que você entregou? Observe também que este princípio pressupõe que você está sempre alcançando resultados construindo software . Isso também é falso. Às vezes, você precisa reprojetar o fluxo de trabalho subjacente. Às vezes você precisa mudar uma política. Às vezes você precisa convencer as partes interessadas de que algumas de suas suposições são falsas.

8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Esse princípio promove o desenvolvimento sustentável, que eu concordaria com 100%. Vale notar, no entanto, que o Agile na prática tende a manter o foco na produção e na eficiência da equipe. Agile foi parcialmente morto pelo conceito de “velocidade”, que, eu sei, tecnicamente não faz parte do Scrum. Ainda assim, aconteceu. Em vez de fluxo de valor através do sistema, Agile manteve o foco no fluxo de trabalho através de equipes de desenvolvimento. A saída não é apenas a coisa errada para se concentrar, mas fazê-lo provavelmente não "promove o desenvolvimento sustentável".

9. A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.

O que é “bom design?” Eles significam “código limpo”? Porque, você sabe, a maioria das equipes ágeis relutam em trabalhar com designers. (Eles seguram os dedos indicadores em forma de cruz e começam a resmungar sobre “BDUF” enquanto escrevem código que ninguém vai usar.) Isso é o que Gabrielle Benefield quis dizer quando disse Agile se tornou um exercício em “construir o coisas erradas mais claras. ”

10. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.

Dos 12 princípios ágeis, este é provavelmente o único que eu manteria como é. Toda vez que você diz "Sim" para alguma coisa, seja uma solicitação de uma parte interessada, representante do cliente ou grupo de usuários, você está dizendo "Não" para muitas outras opções. A verdadeira questão é como você fica melhor em descobrir as coisas certas para construir? Não se trata de fazer mais apostas mais rapidamente, mas de fazer apostas mais inteligentes , e as melhores respostas para como fazer isso não estão incorporadas no Manifesto ou nos princípios.

11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.

Os melhores requisitos? Oy vey As melhores arquiteturas? As equipes ágeis tendem a determinar a arquitetura? Não na minha experiência. Os melhores desenhos? Esses surgem por descoberta contínua com os usuários, não algo que os princípios enfatizam (ou mesmo mencionam). Além disso, uma equipe significativamente auto-organizada assume que ela já possui todas as habilidades multifuncionais e de pilha completa de que precisa para se auto-organizar em primeiro lugar . O problema com essa suposição é que o Agile se concentra apenas na entrega. Assim, uma equipe Agile auto-organizada – uma boa equipe de produto completa.

12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficiente, depois ajusta e ajusta seu comportamento de acordo.

Bom, mas por que a intervalos regulares? Por que não continuamente? Continue.

Conclusão

Então … os princípios do Ágil se sustentam?

Bem, o que você acha? Seja honesto.