- Programar hoje em dia é muito mais estressante do que nos anos 90 e no começo dos anos 2000
- Naquela época, as coisas só ficavam caóticas perto dos prazos, e no restante do tempo era relativamente tranquilo
- O autor refletiu sobre por que o estresse aumentou nas últimas décadas
- Não é por causa da concorrência, das mudanças do mercado ou de prazos rígidos, mas por causa do modelo de trabalho com sprints
1. Sprints não param
- Sprints são prazos contínuos que nunca terminam
- O modelo waterfall era alinhado a prazos e eventos reais
- Sprints são prazos artificiais, sem pausas naturais
- Estresse de curto prazo pode até fazer bem à saúde, mas estresse de longo prazo faz mal ao corpo
2. Sprints não são voluntárias
- É diferente de uma equipe decidir voluntariamente publicar código a cada duas semanas
- Todos os aspectos da sprint são regulamentados
- A autonomia tem um papel importante na experiência de trabalho
- Trabalho imposto gera estresse e desconforto
3. Sprints ignoram atividades de suporte importantes
- Sprints não oferecem tempo para preparar a próxima tarefa
- É preciso tempo de preparação para conseguir executar o trabalho
- Sprints tentam separar preparação e execução, mas isso gera estresse
Scrumban: o retrato real (e pior)
- A maioria das implementações de Scrum é uma mistura de waterfall com Scrum
- Grandes prazos estão sempre presentes em segundo plano
- Quando os grandes prazos se aproximam, o Scrum é interrompido e o estresse aumenta
Conclusão
- Nas sprints não há descanso, falta autonomia e falta tempo de preparação
- Desenvolvedores precisam ser capazes de controlar seu trabalho e seu processo
- Para isso, é preciso esforço, como construir organizações éticas ou migrar para o trabalho freelancer
Resumo do GN⁺
- Este texto explica por que o método Scrum causa estresse contínuo nos desenvolvedores
- Os principais motivos são os prazos contínuos das sprints, a falta de autonomia e a falta de tempo de preparação
- É preciso permitir que desenvolvedores controlem sua forma de trabalhar
- Outro método com função semelhante é o Kanban
8 comentários
Mesmo ao executar projetos como os de SI e do setor público, ficam empurrando sem parar em phase 1, 2, 3... desse jeito. E em cada phase individual ainda acontecem mudanças enormes de novo. Assim, jamais dá para alcançar o propósito original do scrum, que é desenvolver com sucesso. No fim, no meio desse caos e dessa atmosfera desorganizada e frenética, só os desenvolvedores acabam se desgastando até o limite.
Sou PM em atividade.
Nos casos de ágil/Scrum que senti que funcionaram bem, quando um sprint principal terminava, fazíamos uma retrospectiva e recebíamos um tempo de descanso. Tanto a equipe de desenvolvimento quanto a de planejamento tinham um momento para respirar antes de preparar a próxima etapa.
Nas formas de trabalho que, como no texto, eu sentia que não funcionavam da mesma maneira, o estresse aumentava porque, sob prazos impostos em waterfall, o time de produto ainda tentava operar Scrum internamente ao mesmo tempo. E, como o prazo em si não podia ser alterado, passávamos correndo toda semana sem tempo para descansar nem fazer retrospectiva, dando a sensação de uma corrida sem fim.
Pelo que eu entendo, a intenção do waterfall é identificar os requisitos o mais cedo possível e, como há dependências entre as etapas de design, implementação e testes, fazer o trabalho em sequência. Já a intenção do ágil e dos sprints é pegar trabalhos grandes demais para serem totalmente projetados ou implementados de antemão no modelo waterfall e quebrá-los em partes menores para tentar avançar assim. Acho que ambos têm vantagens e desvantagens, e que, em vez de seguir uma metodologia de forma dogmática, talvez baste escolher apenas o que for necessário de acordo com a situação. Como o texto defende, também precisa haver descanso, além de tempo de preparação para revisões técnicas ou para criar protótipos. Independentemente de quem decida a ordem das tarefas, se essa pessoa entender os fatores de impedimento e definir as prioridades de acordo com o fluxo real do trabalho, fico pensando se a existência ou não de autonomia do desenvolvedor faz tanta diferença.
Será que esse tipo de texto aparece em blogs estrangeiros porque, lá fora, muitos gerentes sem nenhuma experiência em desenvolvimento são formados para aplicar cegamente os procedimentos das metodologias de desenvolvimento? Dá até a sensação de estar vendo o conflito, tão comum por aqui, entre planejadores que não conhecem em nada a prática real e os desenvolvedores.
Seguindo o fluxo real do trabalho, quem provavelmente consegue definir melhor as prioridades é o próprio desenvolvedor; por isso, considero que a própria abordagem de tirar essa autonomia e delegá-la a outra pessoa acaba, na verdade, causando uma separação entre a prática e o planejamento da equipe.
Se gestão em si também é uma área especializada, então, mesmo que seja um gerente sem experiência em desenvolvimento, quando ele se depara com um momento em que a gestão dos recursos de desenvolvimento não está funcionando bem, acredito que a resposta para essa situação é que o gerente deve se adaptar ou reagir. No entanto, já vi muitas vezes essa responsabilidade ser transferida para os contribuintes individuais...
A responsabilidade final é do gerente, certo? Mas parece que na prática não é bem assim. É como um CEO que só sabe administrar, não entende nada do negócio da empresa e às vezes acaba levando a empresa à ruína.
Tem PM demais que só fica no pingue-pongue 😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭
Opiniões do Hacker News
Citando Rich Hickey, programadores resolvem problemas não como corredores de curta distância, mas como se um tiro de largada fosse dado a cada 100 jardas para iniciar um novo sprint
Passei a odiar processos de software. Se o tamanho da equipe for definido de forma adequada e os desenvolvedores receberem autonomia para atingir os objetivos, eles conseguem entregar bem sem o fluxo de produtividade imposto pela gestão. Agile e afins existem para que gerentes justifiquem seus salários
Fico me perguntando o que significa dizer que "sprints não são voluntários". A equipe escolhe as características do sprint, não é algo atribuído aleatoriamente. É uma colaboração entre liderança, membros da equipe e partes interessadas de fora da equipe. Gostaria que explicassem por que o Scrum seria rígido demais
Desde que o Scrum surgiu, achei que não fazia sentido desenvolvedores ficarem em sprint o tempo todo. Sprint é algo curto e rápido, e depois disso é preciso descansar. Transformar todo o trabalho em sprint é loucura
Muitas vezes o Scrum acaba virando um "Scrumfall" ainda pior. No começo, o Scrum foi usado para facilitar a comunicação de equipes remotas, mas aos poucos virou algo guiado por metas de marketing e sprints estressantes. O esgotamento dos desenvolvedores fica evidente
No começo dos anos 2000, equipes de engenharia trabalhavam por conta própria sem gerentes de projeto. O software não era tão interconectado quanto hoje e os ciclos de deploy eram mais longos. Agora, com CI/CD e deploy contínuo, tudo anda rápido. SCRUM gera estresse
A maioria das conversas pode ser resumida em "no meu trabalho o Scrum é ruim por causa de X, Y, Z" e "isso não é Scrum ideal"
Desenvolvo software há 40 anos e, seja qual for o método, é preciso dividir o trabalho e mostrar que os objetivos foram alcançados. Em equipes pequenas, com codebases simples, Kanban pode bastar, mas em equipes grandes ou soluções complexas é necessário reportar
Não usamos Agile, Scrum, standups etc. Fazemos uma reunião semanal para redefinir prioridades e acompanhamos o progresso por um sistema de tickets. Isso permite que os desenvolvedores trabalhem com autonomia. É preciso dedicar mais tempo a programar do que a reuniões ou relatórios TPS
Depois de trabalhar em 8 empresas, a abordagem Shape Up da Basecamp foi a que mais deu certo. O importante é perguntar "quanto tempo vamos investir", e não "quantos dias vai levar". O Shape Up oferece um período de respiro entre ciclos de 6 semanas e entrega produtos bem-sucedidos de forma consistente