Ao encerrarmos 2022, nós do DevOps.com queríamos destacar os artigos mais populares do ano. A seguir está o mais recente da nossa série dos Melhores de 2022.
Bem-vindo ao A visão de longo prazo– onde examinamos as notícias e as reduzimos ao essencial. Vamos malhar o que realmente importa.
Esta semana, algo um pouco diferente: estou dedicando toda a minha coluna ao Agile e ao Scrum. Eles estão ganhando cada vez mais uma má reputação, sendo associados aos piores aspectos da cultura tóxica no local de trabalho: Sexismo, racismo, esgotamento, microgerenciamento.
Análise: Maus trabalhadores culpam suas ferramentas
Embalar seus Post-Its? Ignorar suas histórias? Como sempre, a verdade é mais matizada: os métodos ágeis nem sempre são as melhores ferramentas para o trabalho. E quando são, Agile/Scrum exigem liderança forte e qualificada.
Qual é a história? Vamos começar com Ass. A crítica recente da Prof. Miriam Posner—“Agile e a longa crise do software”:
“Exercícios de vigilância”
Existem limites distintos para os tipos de criatividade que os trabalhadores se sentem autorizados a exercer sob o Agile. … Os desenvolvedores muitas vezes não conseguem avaliar as questões maiores. [And] essas questões maiores assumiram maior importância e urgência.
…
Agile pode ter desempenhado um papel na criação de uma cultura de trabalho que se revela cada vez mais tóxica para mulheres, pessoas de cor e membros de grupos minoritários de gênero. … Os autores do Manifesto Ágil eram … homens brancos que [had] não passavam muito tempo em locais de trabalho onde compunham a minoria. … Eliminar burocracia, hierarquia e documentação é ótimo, até que você seja a pessoa que precisa de regras para proteção.
…
O Manifesto Ágil pinta um quadro atraente. … O problema é que quase sempre é implementado em locais de trabalho dedicados aos resultados financeiros, não ao bem-estar dos trabalhadores, [such] como quando um gerente de projeto fica preso entre uma promessa a um cliente e as próprias prioridades dos desenvolvedores. … Além disso, os confrontos diários … tornaram-se, para alguns trabalhadores, exercícios de vigilância [with] pressão para que cada trabalhador justifique seu valor.
Tudo isso gerou opiniões fortes, como este de Xophmeister:
“Construir software complexo é um problema social”
Este é um ótimo resumo sobre como me sinto sobre “Agile”: é paternalista e indutor de ansiedade. O grau do qual é uma função das habilidades técnicas e sociais de … o PM, Scrum Master, o que quer que seja. … Existem líderes com fortes habilidades técnicas e alta inteligência emocional, mas são raros.
…
Da mesma forma, é por isso que também não acredito que um grupo totalmente igualitário de engenheiros funcionaria: … Inevitavelmente, um líder de fato surgirá. Na minha experiência, geralmente o mais alto, e não o mais eficaz. Construir software complexo é um problema social mais do que técnico.
E isto, de Kokuyo:
“Destruição do trem”
Estou deixando meu emprego atual como engenheiro de nuvem privada para um provedor de nuvem porque eles acharam uma boa ideia nos fazer trabalhar “Agile”. Claro, só somos planejáveis para 40-60% de nossa semana de trabalho, mas o problema é… planejar até 40% é bastante difícil quando os negócios diários interrompem praticamente qualquer plano que você tenha.
…
[It’s] levou a três esgotamentos em uma equipe de cerca de oito … duas pessoas saindo e mais duas por vir. … Eu fico lá assistindo o acidente de trem acontecendo e ninguém na administração fazendo nada sobre isso.
Sem contar isso, através da u/be-sc:
“Deixou de ser ágil para implementar o Agile”
Uma empresa que conheço costumava trabalhar de perto com seus clientes: … Portanto, não era grande coisa começar com requisitos falhos, porque eles podiam iterar rapidamente em direção a uma solução viável. No geral, era uma maneira bastante ágil de trabalhar – embora ninguém pensasse assim, era apenas a coisa natural a se fazer.
…
Então o mundo mudou e as coisas foram introduzidas em nome de se tornar Agile e praticar a melhoria contínua. Pense em coisas como SAFe ou SPICE. E SCRUM em cima disso, é claro. Como resultado, essas iterações rápidas e eficientes não são mais permitidas oficialmente. Tudo precisa ser planejado, documentado, rastreado, revisado, aprovado e documentado novamente. As reuniões precisam ser realizadas sobre tudo isso, é claro. E, oh, isso só parece uma cachoeira, mas totalmente não é.
…
A empresa deixou de ser ágil para implementar o Agile — e perdeu a agilidade.
Ah sim, Cachoeira com outro nome qualquer. Ou, como diz Jeremy Duvall, “Scrumfall”:
“Caos, código de baixa qualidade, custos excessivos”
A Igreja do Agile está sendo corrompida internamente por forças institucionais que [can’t] adaptar-se à humanidade radical [of] equipes colaborativas, auto-organizadas e multifuncionais. … Agile não deveria ser assim.
…
O Agile deve ser centrado nas pessoas, não nos processos. … Mas, em vez disso, muitas empresas priorizam o controle de seus recursos humanos de commodities. … As empresas vestiram-se com as roupas do Scrum, reivindicando a ideologia Agile enquanto reafirmam o microgerenciamento hierárquico do Waterfall. … Scrum ou Kanban adequadamente implementados [should] levar ao resultado desejado dentro de tempo e orçamento finitos.
…
Histórias como mini-cachoeiras [treat] o engenheiro como uma engrenagem na máquina de seu empregador… sem nenhuma compreensão do ofício, da criatividade e do pensamento crítico necessários para resolver problemas tão complexos. … O Scrumfall depende, em outras palavras, da equipe de produto … fornecendo uma especificação completa e perfeita antes do início do desenvolvimento. E depende da equipe de desenvolvimento… planejando uma implementação completa e perfeita antes que uma única linha de código seja escrita.
…
Os capatazes invasores da Cachoeira escondidos no Cavalo de Tróia do Scrum absolutamente ódio incerteza. No entanto, a incerteza não é um bug, mas um recurso do Agile. [But] essas cadeias de mini cascatas criam caos, códigos ruins e, ironicamente, custos excessivos e prazos perdidos.
Mas cuidado com o fanatismo. Preste atenção às sábias palavras de Parabéns:
“Qualquer coisa maior do que um desenvolvedor pode fazer em duas semanas é inviável”
Um dos problemas que as pessoas estão tendo é que muito se fala contra o Waterfall em vez de apenas a favor do Agile. … As pessoas enfatizam que tudo a ver com Waterfall é ruim e generalizam a partir de uma arquitetura grande, detalhada e inflexível, sem loops de feedback sendo ruim. [This is] repetido por pessoas treinadas para serem Scrum Masters ou alguma outra função gerencial ou administrativa que não sejam desenvolvedores.
…
Já me disseram que fechar uma história atrás da outra é uma cachoeira. Já me disseram que ter uma história de design é cascata. Disseram-me que os documentos de arquitetura que podem ser revisados… mas criados antes de todo o código estar pronto são cascata.
…
levado a sério [it] significa que qualquer coisa maior do que um desenvolvedor pode fazer em duas semanas é inviável. Isso geralmente acontece quando a equipe que está construindo o software não é considerada [as] partes interessadas.
O que aconteceu com “pessoas sobre processo”? Slicker fica real:
“Simplesmente não funciona assim”
A ética nunca fez parte dos métodos de desenvolvimento de software. Essas são decisões de negócios. Não é culpa do Agile ou do Waterfall. Um martelo é um martelo: você pode enfiar um prego na madeira ou espancar alguém.
…
No que diz respeito a dar autonomia aos engenheiros, vejo um enorme valor amplamente não reconhecido nisso. A Boeing, por exemplo, fazia ótimos produtos até que o estilo de gestão mudou para um modelo autoritário de cima para baixo. … Obviamente, qualidade, produtividade e inovação sofrem terrivelmente. (…) E tenho visto esse padrão em empresa após empresa.
…
Os engenheiros precisam de latitude para resolver problemas. Seu trabalho não é nada como uma linha de produção em uma fábrica. Simplesmente não funciona assim.
Como em outras esferas da vida, não há uma resposta única — e as nuances são essenciais. aqui está em/Sammy81:
“Você tem que planejar todo o projeto”
Tudo se resume a: O que você está desenvolvendo? Alguns produtos são adequados para Agile e outros não. Agile “puro” é melhor para um produto comercial. … Você tem um conjunto de recursos que prioriza e usa o máximo que pode antes de ficar sem tempo, conclua e tente vendê-lo.
…
Quando você tem um cliente que tem uma lista de requisitos nos quais eles insistem, … você não pode simplesmente fazer … sprints e ver até onde você chega. … Você tem que planejar todo o projeto, resultando em Agilefall.
Enquanto isso, Acho que todos podemos concordar que a culpa é do gerente de produto. Amirita, spaetzleesser?
Nunca vi um que pudesse realmente orientar um projeto do início ao fim. Eles não entendem a tecnologia o suficiente, ou não entendem o caso de negócios, ou não estão engajados o suficiente.
…
[Or,] assim que um gerente de produto tiver experiência suficiente para entender o negócio e a tecnologia, ele será promovido e você terá que lidar com um novato.
A moral da história:
A culpa não está em nossas estrelas, mas em nós mesmos
você tem lido A visão de longo prazo de Richie Jennings. Você pode contatá-lo em @RiCHi ou [email protected].
Imagem: Brad West (através da Unsplash; nivelado e recortado)