A flexibilidade é sem dúvida uma coisa boa, e o manifesto Agile faz sentido. Comparado à prática frágil chamada cascata, o Agile é visivelmente melhor. No entanto, na prática, abordagens flexíveis costumam causar danos profundos e, de fato, a dicotomia Agile / Waterfall é dificilmente apropriada aqui.

Vi quantas variantes do Agile chamadas Scrum realmente matam a empresa. Por "matar", não quero dizer "deterioração cultural", mas sim quando as ações da empresa caem quase 90% em dois anos.

O que é Agile?

O Agile surgiu de um ambiente de consultoria na Web que trouxe alguns benefícios: ao trabalhar com clientes exigentes que não sabem o que querem, geralmente é necessário escolher entre duas opções. Ou para derrotar o cliente: estabeleça expectativas, pagamento adequado para alterações e mantenha relações de igualdade, não de subordinação. Ou aceite o comportamento incorreto do cliente (como muitos designers precisam) e oriente o fluxo de trabalho em torno da disfunção do cliente.

Os programadores geralmente não funcionam muito bem com os clientes. Nós somos pessoas muito literais. Gostamos de sistemas com comportamento bem definido. Isso complica nossa interação com as humanidades, porque tendemos a aceitar cada pedido literalmente, em vez de descobrir o que eles realmente querem. No nível corporativo, os métodos ágeis (fora do ambiente de consultoria) vão além e sugerem que os engenheiros não são inteligentes o suficiente para entender o que seus "clientes" internos desejam. Isso significa que o trabalho é pulverizado em "histórias de usuários" e "iterações", que geralmente nos privam da satisfação com o trabalho realizado, bem como de qualquer esperança de uma visão de longo prazo de onde as coisas estão indo.

Em geral, geralmente são criados dois tipos de trabalho, dentro da empresa ou para o contratado. Em um nível alto, especialistas altamente qualificados são contratados. No fundo - todo o trabalho que eles não querem fazer é jogado para o lado. Obviamente, uma classe de consultores recebe respeito, enquanto a outra não. As empresas de consultoria mal gerenciadas geralmente acabam como rampas de lixo para trabalhos pouco qualificados. O Scrum parece ter sido criado para organizações em que o relacionamento com os clientes é tão ruim que os engenheiros precisam ser vigiados diariamente, porque se tornaram um tanque de sedimentação para o trabalho básico, inútil para uma carreira que ninguém quer fazer (e provavelmente esse não é um trabalho muito importante). , daí taxas baixas e respeito).

Transparência violenta

Existem muitas tendências no local de trabalho de TI que tornam uma carreira de programação extremamente pouco atraente, especialmente para pessoas criativas e inteligentes.

O exemplo mais notório são os escritórios de plano aberto. Eles não são produtivos. É difícil se concentrar neles. Eles são anti-intelectuais, pois as pessoas têm medo de serem pegos lendo livros (ou apenas pensando) no trabalho. Quando você faz as pessoas fingirem ser produtivas, elas realmente perdem a produtividade. Escritórios de plano aberto geralmente não são para produtividade. Esta é uma imagem corporativa. As startups financiadas por empreendimentos usam esses layouts para demonstrar aos investidores que o escritório parece ocupado. (Simplificando, um programador de plano aberto é mais valorizado como mobiliário de escritório do que pelo código que escreve). Por várias razões culturais, isso tornou a opção de plano aberto "legal" e "suja", e agora infecta o mundo corporativo como um todo.

É sabido que as pessoas criativas perdem sua criatividade se lhes for pedido que expliquem durante o trabalho. A mesma coisa com o software. Os programadores geralmente precisam trabalhar com transparência unilateral. Esses sistemas ágeis geralmente são mal utilizados e requerem transparência humilhante de operação, apesar da falta de reciprocidade. Em vez de trabalhar em projetos reais de longo prazo em que uma pessoa possa estar interessada, eles são reduzidos a trabalhar em "histórias de usuários" funcionais e atomizadas e muitas vezes são impedidos de trabalhar em melhorias que não estão relacionadas às necessidades imediatas e de curto prazo do negócio (geralmente de baixo para cima). Essa versão incorreta, porém comum, do Agile exclui o conceito de propriedade e considera os programadores como componentes idênticos e intercambiáveis.

Scrum é a pior opção, com a estupidez de "iterações" de duas semanas. Isso causa uma preocupação desnecessária sobre microflutuações no desempenho humano. Não há absolutamente nenhuma evidência de que essa abordagem realmente acelere ou melhore o desenvolvimento a longo prazo. Isso apenas deixa as pessoas nervosas. Muitos nos negócios acham que essa é uma boa abordagem, porque o trabalho está "indo mais rápido". Estou no setor de TI há dez anos, como gerente e como profissional. Isto não é verdade.

Falhas específicas do Agile e Scrum

1. Desenvolvimento orientado a negócios.

O Agile é frequentemente servido em comparação com uma "cachoeira". O que é uma cachoeira?

A abordagem Waterfall é realmente terrível. Nele, “o trabalho rola para baixo”, onde cada nível da hierarquia organizacional seleciona o que ele considera ser “material interessante” e o repassa. Os projetos são determinados pelos gerentes, a arquitetura é projetada pelos arquitetos, os prazos pessoais são definidos pelos gerentes intermediários, a implementação é realizada pelos cavalos de trabalho de nível superior (programadores) e, em seguida, as operações e os testes são transferidos para cavalos de nível inferior. Este é um esquema extremamente não funcional. Quando as pessoas sentem que todas as decisões importantes já foram tomadas, não têm motivação para trabalhar da melhor maneira possível.

A cachoeira reproduz o modelo social de uma organização disfuncional com uma certa hierarquia. Por sua vez, o Agile muitas vezes replica o modelo social de uma organização disfuncional sem uma hierarquia claramente definida.

Tenho opiniões contraditórias sobre cargos como "sênior" e "diretor", e assim por diante. Eles são importantes, e eu provavelmente não aceitarei uma posição abaixo do nível do diretor, mas odeio a importância deles. Se você olhar para o Scrum, ele priva especificamente os direitos dos engenheiros seniores e mais capazes, porque aqui eles são obrigados a aderir a processos estabelecidos (trabalhe apenas em tarefas criadas, 5 a 10 horas por semana em planadores). Esses processos são projetados para pessoas que começaram a programar há um mês.

Como um estado comunista fracassado que iguala as pessoas ao espalhar a pobreza, o Scrum, em sua forma mais pura, coloca todo o desenvolvimento no mesmo nível baixo: não claramente definido, mas claramente abaixo do nível dos empresários que têm poder total para decidir no que trabalhar.

O Agile, em sua implementação usual, aumenta a frequência do feedback, ainda não dando aos engenheiros qualquer poder real. Este é um acordo perdedor porque significa que é mais provável que os programadores sejam punidos ou punidos quando o trabalho demora mais do que deveria. Isso cria muita ansiedade e pressa, mas na verdade tem pouco a ver com o que realmente importa: criar ótimos produtos.

O Vale do Silício cometeu muitos erros, especialmente nos últimos cinco anos, mas fez algo certo. Incluindo introduziu o conceito de "engenharia" da empresa. Nem sempre é melhor para os engenheiros gerenciarem toda a empresa, mas quando os engenheiros gerenciam o desenvolvimento e estabelecem prioridades, todos ganham: os engenheiros ficam satisfeitos com o trabalho ao qual foram designados (ou, melhor ainda, são designados a eles mesmos), e os negócios obtêm uma qualidade de desenvolvimento muito mais alta.

Mas você tem uma "empresa comercial", tudo bem. Não contrate engenheiros na equipe, se precisar de talento. Você pode obter as melhores pessoas como consultores (a partir de US $ 200 por hora e aumentando acentuadamente a partir deste nível), mas não como funcionários em tempo integral de uma "empresa de negócios". Bons engenheiros querem trabalhar em empresas administradas por engenheiros, onde participarão do planejamento do trabalho sem ter que dar desculpas aos "mestres de scrum", "proprietários de produtos" e vários níveis de gerentes de humanidades.

Por fim, o Agile (conforme praticado) e o Waterfall são formas de desenvolvimento orientado aos negócios e, portanto, nenhum deles é adequado para o desenvolvimento de software de qualidade ou para motivar os funcionários.

2. A posição subordinada dos jovens.

Infelizmente, no desenvolvimento de software, uma cultura de subordinação jovem se desenvolveu com o conceito (extremamente errôneo) de programação como “brinquedos de homens jovens”, embora quase nenhum dos melhores engenheiros seja jovem e muitos dos melhores não sejam homens.

O problema com as iterações Agile (ou sprints) de duas semanas e as histórias de usuários é que não há estratégia de saída. Não há opção "Não precisaremos mais fazer isso quando chegarmos a [X]". Esse sistema deveria durar para sempre: comícios orientados para os negócios nunca desaparecerão. Arquitetura, P&D e desenvolvimento de produtos deixam o trabalho do programador porque não se encaixam em "histórias de usuários" atomizadas e sprints de duas semanas.

Como resultado, para programadores mais ou menos experientes, é desconfortável trabalhar dessa maneira, porque eles querem aceitar os tipos de projetos que são ignorados nessa estrutura, e é difícil justificar esses projetos em termos de valor comercial de curto prazo. A excelência técnica é importante, mas é muito difícil convencer as pessoas desse fato, se elas não quiserem ser convencidas.

Certa vez, trabalhei para uma empresa em que um gerente de produto disse que a diferença entre um engenheiro sênior e um engenheiro júnior é a capacidade de fornecer estimativas de tempo mais precisas. Bem, na verdade não. E é até insultuoso. Odeio avaliações porque elas geram políticas e, na verdade, não fazem o trabalho mais rápido ou melhor (na verdade, geralmente o oposto).

A pior parte das avaliações é que elas estimulam o desempenho do trabalho que pode ser avaliado. Isso faz com que os programadores dêem preferência a coisas simples de baixo nível que os negócios realmente não precisam (mesmo que os gerentes desajeitados de nível médio pensem de maneira diferente), mas é "seguro". Tudo o que realmente vale a pena fazer tem uma chance diferente de zero de falha e muitos parâmetros desconhecidos para uma estimativa razoável do prazo. O foco da Agile no valor comercial de curto prazo afasta as pessoas do trabalho que a empresa realmente precisa, para gerenciar a reputação de cada programador em tempo real.

Essa cultura sugere que a programação é infantil, da qual você precisa se livrar antes dos 35 anos. Eu não concordo com esta opinião. Na verdade, acho que esse é um pensamento ruim. Tenho mais de 30 anos e sinto que estou começando a programar bem. Assediar programadores seniores apenas por terem experiência suficiente para saber que esse processo flexível / scrum não tem nada a ver com ciência da computação e que não agrega valor é uma péssima idéia.

3. Abordagem de curto prazo, o que é estúpido e perigoso.

O Agile é destinado a empresas de consultoria secundária que não têm crédito suficiente para negociar com colegas em pé de igualdade e que enfrentam prazos apertados, e cada projeto do cliente é um risco existencial. Ele é dos forasteiros "marginais". Mas aqui está o problema: o Scrum é frequentemente implantado em grandes empresas e startups financiadas. Mas as pessoas vão a essas empresas porque não querem ser de fora . Eles querem segurança. É por isso que eles trabalham nessas empresas, em vez de criarem os seus próprios. Ninguém quer ficar para trás se não houver benefício pessoal significativo. Ágil em uma corporação significa dor e risco sem recompensa.

Quando cada projeto do cliente apresenta um risco reputacional sério ou existencial, o Agile pode ser a solução apropriada, pois o foco nas iterações de curto prazo é útil quando a empresa está em risco e pode desaparecer a longo prazo. O gerenciamento agressivo de projetos faz sentido em caso de emergência. Isso não faz sentido como um arranjo permanente; pelo menos não para programadores talentosos que têm opções menos estressantes e mais agradáveis.

Como parte do Agile, a dívida técnica aumenta e não é resolvida porque as pessoas de negócios que atribuem tarefas não verão o problema até que seja tarde demais ou pelo menos caro para corrigi-lo. Além disso, engenheiros individuais são recompensados ​​ou punidos apenas com base nos atuais "sprints" de duas semanas, ou seja, ninguém observa cinco "sprints" com antecedência. O Agile é apenas um “sprint” sem sentido e míope após o outro: sem progresso, sem melhorias, apenas ticket por ticket, por ticket.

As pessoas que concordam com o embaralhamento de tarefas sem sentido podem suportar, mas realmente bons engenheiros odeiam ir trabalhar na segunda-feira de manhã, sem saber o que trabalharão naquele dia.

4. Ele não tem nada a ver com a construção de uma carreira.

Histórias de usuários individuais não são boas para uma carreira de engenharia. Aos 30 anos, espera-se que você trabalhe no nível de todo o projeto e pelo menos esteja pronto para ir além desse nível em infraestrutura, arquitetura, pesquisa ou liderança.

Em caso de emergência, seja uma consulta que busque tranquilizar um cliente importante ou uma "sala de guerra" corporativa, pensamentos sobre um currículo podem esperar. Poucas pessoas desistem de algumas semanas de trabalho desagradável ou outro que não esteja relacionado ao desenvolvimento de carreira, se for realmente importante para a empresa. A importância do trabalho é prioridade aqui. Se você pode dizer, “sentei-me na sede e conversei com o CEO por 20 minutos por dia”, o que justifica fazer um trabalho idiota.

Mas, se não houver emergência, os programadores esperam que suas carreiras sejam levadas a sério. Caso contrário, eles sairão. "Eu estava no time Scrum" significa que você é um saco de pancadas. Uma coisa é fazer um trabalho idiota, porque o CEO reconheceu que uma tarefa desagradável agregará milhões de dólares em valor (e ele a recompensará de acordo). Mas se você simplesmente tiver atribuído “histórias de usuário” e tickets Jira, será considerado um perdedor.

5. O objetivo é determinar taxas baixas, mas o nível de resultados positivos falsos é inaceitavelmente alto.

O Scrum é proposto como uma boa maneira de identificar "funcionários atrasados". O problema é que ele cria programadores mais ineficazes do que revela. Este é um sistema de rastreamento total no qual engenheiros individuais mostram em detalhes o andamento de seu trabalho, com uma avaliação da produtividade.

Em um debate sobre liberdades civis, um erro comum é frequentemente mencionado: o argumento "nada a esconder". Algumas pessoas gostam de argumentar que invadir a privacidade, por exemplo, pelas forças da lei, não é um problema, porque elas mesmas não são criminosas. Essas pessoas sentem falta de algumas coisas importantes. Por exemplo, essas leis estão mudando. Pergunte a qualquer um que era judeu na Europa Central nos anos 30. Mesmo para pessoas respeitáveis, o estado de vigilância é um estado de ansiedade.

O fato da observação muda a maneira como as pessoas trabalham. Em áreas criativas, dói. É quase impossível trabalhar de forma criativa se você precisar informar sobre o trabalho todos os dias.

Outro tópico vem à mente: sensibilidade ao status . Os programadores gostam de fingir que superaram vários milhões de anos de evolução de primatas relacionados ao status social, mas o fato é que o status social é importante e não é embaraçoso admitir esse fato. Pessoas idosas, mulheres, minorias raciais e pessoas com deficiência são geralmente sensíveis ao status do local de trabalho, porque é uma questão de sobrevivência para elas. O monitoramento constante do trabalho indica falta de confiança e baixo status social, e os mais sensíveis ao status (mesmo que sejam os melhores funcionários) são os primeiros a sofrer com o aumento do monitoramento. Se eles sentem que não são confiáveis ​​(e o que mais é transmitido pela cultura, onde cada elemento do trabalho deve ser aprovado?), Eles rapidamente perdem a motivação.

Agile e especialmente Scrum são vulneráveis ​​ao erro "nada a esconder". Se você não é um “mau trabalhador”, você não é contra a asa-delta diária, certo? As únicas pessoas que se opõem aos relatórios diários de seu trabalho em termos de valor comercial de curto prazo são os "mocassins" que querem roubar dinheiro da empresa, certo? Bem, não. Obviamente não.

Uma cultura de transparência violenta é projetada para os mais insensíveis ao status: jovens, geralmente brancos ou asiáticos, homens privilegiados que nunca foram pressionados no trabalho. Para aqueles que pensam que RH e gerência são uma perda de tempo, e o funcionário deve simplesmente engolir humilhações e insultos.

Geralmente, os melhores funcionários sofrem com a implementação do Agile / Scrum, porque a pesquisa e o desenvolvimento são efetivamente eliminados. Obsessão por "iterações" ou sprints de curto prazo significa a incapacidade de tentar algo novo e arriscado.

A verdade sobre os funcionários atrasados ​​é que você pode identificá-los sem Agile. As pessoas sabem quem são. A razão pela qual algumas equipes estão cheias de sapatos, pessoas incompetentes ou tóxicas é porque ninguém faz nada com elas. Esse é um problema de gerenciamento no nível da equipe, não no nível do fluxo de trabalho.

6. O efeito bêbado.

Parece que o gerenciamento agressivo pode tornar algumas pessoas um pouco incompetentes capazes de trabalhar. Eu chamo isso de efeito bêbado: quando as meninas ficam mais ou menos em forma, mas muito fofas, não querem mais ter nada a ver com você. — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .