“Tudo é veneno, tudo é remédio; ambos são determinados pela dose ".
Paracelso
É costume contar a história do
Agile a partir de fevereiro de 2001, quando um documento bastante estranho nasceu - o
Agile Manifesto . Em geral, o texto do documento é composto por evidências filosóficas (por exemplo, "simplicidade - a arte de não fazer muito trabalho") e declarações controversas (por exemplo, "os melhores requisitos técnicos, design e arquitetura são obtidos de uma equipe auto-organizada"). Mas este documento é estranho, não tanto em seu conteúdo (você nunca sabe o que pode vir à mente em uma estação de esqui), mas na natureza épica das mudanças subseqüentes na indústria de desenvolvimento de software. No curto espaço de tempo, surgiram muitas técnicas que implementam a metodologia de desenvolvimento "flexível", que marcha solenemente ao redor do mundo, capturando as mentes dos contratantes e as bolsas dos clientes. Os adeptos apresentam esse movimento como uma espécie de pílula mágica que decide tudo. Chegou ao ponto de um
doador nobre, um programador honesto, já ter se tornado indecente em admitir envolvimento no desenvolvimento de software de acordo com a
orientação tradicional
da metodologia. Vamos tentar entender as causas e conseqüências do fenômeno, usando
Scrum como a manifestação mais comum do Agile.
Primeiro, vamos tentar entender o que realmente temos de novo no wrapper Agile em geral e no Scrum em particular.
Scrum no Egito antigo
Terei a liberdade de afirmar que uma metodologia flexível em geral, e a metodologia Scrum em particular, sempre existiram, embora não tenham sido chamadas. Eles não foram chamados, mas eram simplesmente a maneira mais natural e eficaz de conduzir seus projetos internos (a palavra-chave aqui é "interna").
Por exemplo, o antigo faraó egípcio planejava construir uma pirâmide e ... começou. Discutiu a idéia com os padres (partes interessadas) e designou seu mordomo para ser responsável pelo projeto (proprietário do produto). O funcionário encontrou um pedreiro competente (scrum master). O pedreiro contratou assistentes (equipe de scrum) e foram ao mercado de escravos e pontuaram escravos (ferramentas de trabalho: PC, servidor, software para desenvolvimento, etc.).
Desde que o faraó lhe ordenou um relatório mensal sobre o andamento da construção, o pedreiro (com assistentes) começou a realizar uma demonstração mensal da construção (demo) do mordomo. Durante o show, não apenas o que já foi feito (retrospectivo) foi discutido, mas também foi elaborado um plano para o próximo mês (sprint). Para não perder nada, o copeiro discutiu as histórias dos usuários com os padres por um mês e as escreveu em um pergaminho especial (lista de pendências), a partir do qual a lista de desejos entrou no plano para o próximo mês. Bem e assim por diante. Não sei como eram os adesivos, o quadro de scrum e os diagramas de burndown. Qualquer líder competente seleciona as ferramentas mais convenientes para gerenciar e monitorar o projeto. Os detalhes não são importantes aqui, o principal é que a técnica funcione.
I.e. Eu acho que todos os gerentes sempre usaram uma técnica flexível para criar seu produto interno (por seu próprio risco e risco) porque:
- competente o suficiente para projetar o resultado final;
- competente o suficiente para controlar o processo;
- ter poder suficiente sobre os participantes subordinados do processo;
- a proporção do termo, custo e qualidade do trabalho não é um dogma para eles e pode ser revisada, se necessário (uma vez que “ele é seu próprio mestre”);
- e mais importante, o resultado final e o processo para alcançá-lo estão nas mesmas mãos e buscam um interesse comercial.
Mas para o Cliente externo, nenhum dos itens desta lista é aplicável; portanto, para projetos externos (personalizados), uma técnica flexível nunca foi usada (as exceções apenas confirmam a regra). Afinal, as pessoas eram simples e intolerantes; por um flagrante excesso de prazos e estimativas, elas poderiam ter encurtado a cabeça.
Scrum hoje em dia
A única novidade do Scrum moderno é o fato de ser usado na implementação de projetos externos (personalizados). Tentar não ficar de fora desse lado da questão, porque puxar uma corda pode atrair a verdadeira motivação dos participantes do mercado. De fato, o manifesto ágil e todos os argumentos do Scrum são pura propaganda dos interesses do contratado, por uma questão de decência, velada sob a luta por todo o bem contra o mal. Essa é a genialidade da solução, que nos permite convencer o Cliente a sacrificar o resultado pelo bem do processo!
Então, o que muda se o proprietário do produto for um funcionário de outra empresa e não a sua? A principal diferença é que o resultado final e o processo de sua realização estão agora em lados diferentes da “barricada” e cada uma das partes busca apenas seu próprio interesse comercial. O resultado é importante para o cliente e o processo é importante para o contratante. Não pode ser de outra maneira - afinal, "nada pessoal, isso é apenas negócio".
O Agile é benéfico para os participantes do mercado de TI, pois oferece a oportunidade:
- ganhar dinheiro com o processo e não ser responsável pelo resultado;
- reduza o custo do pessoal de gerenciamento competente (eles são caros, mas você não precisa projetar nada agora e não precisa escrever TK, e o processo agora controla o proprietário do produto do cliente).
E, como isso é lucrativo, diante de nossos olhos, as equipes de programação com a espinha dorsal de profissionais altamente qualificados e preocupados com o sistema podem se transformar em fazendas de codificadores alugados da mão média.
Tente se colocar no lugar de uma pessoa que contrata uma equipe de construtores para consertar seu apartamento e tenta obter os termos e o custo dos consertos do líder da equipe e, em resposta, ele ouve:
- como somos pessoas criativas, trabalharemos "como está", mas você paga por cada hora de trabalho da equipe e materiais;
- não faremos um projeto e um plano comuns, descobriremos isso ao longo do caminho (se fizermos algo errado, refazeremos o processo pelo tempo que você pagou e materiais adicionais);
- mostraremos os resultados de nosso trabalho a cada duas semanas e falaremos sobre nossos problemas; juntos, planejaremos as próximas duas semanas.
É improvável que alguém concorde com essa oferta e os clientes dos funcionários de TI concordem! É isso que a propaganda vivificante faz!
Além de convencer os clientes a concordar com datas e custos imprevisíveis, eles também transferem toda a responsabilidade por falhas. Como regra, a qualificação do Cliente não permite formalizar requisitos para o resultado final e controlar profissionalmente o processo. Portanto, sempre pode ser confuso e distraído (na ausência de um TK geral) resolver muitos problemas secundários (que surgem mais frequentemente devido à falta de planejamento a longo prazo).
As conseqüências da adoração ágil
Você não acha que a qualidade dos produtos de software cai proporcionalmente à ampla distribuição do Agile no setor? De onde vem a qualidade se todo o processo é aprimorado, resolvendo os problemas da maneira mais simples e rápida possível? E pensar no futuro é oficialmente proibido pela metodologia!
Você não acha que os produtos de software estão se transformando cada vez mais em "colchas de retalhos" quando você fica surpreso ao perceber que diferentes seções do mesmo software parecem ser criadas por pessoas completamente diferentes? E mesmo em uma tela de programa, diferentes estilos de design, diferentes abordagens ergonômicas e diferentes algoritmos para o funcionamento de controles semelhantes podem se misturar. Mas não há Guia de Estilo e TK para o produto, portanto, quem estiver mais familiarizado fará isso! E a equipe de controle de qualidade, como todo mundo, é limitada pelos prazos de sprint.
Sobre o que é tudo isso?
De todas as opções acima, pode parecer que eu sou um fervoroso ódio ágil. Mas isso não é de todo! E não tentei ofender ninguém! Ele apenas tentou ilustrar com mais clareza as palavras do grande Paracelso divulgadas na epígrafe.
Uma metodologia flexível é bastante adequada para projetos internos de pequeno e médio porte. O tamanho do projeto é limitado apenas pela capacidade de um líder em particular de "não perder a floresta atrás das árvores", ou seja, a capacidade de ter em mente todos os detalhes e o resultado desejado sem sistematizá-lo “no papel”.
Uma metodologia flexível é limitada para projetos externos. Nesse caso, os mesmos requisitos se aplicam ao proprietário do produto do Cliente e ao gerente de projeto interno, ou seja, essa pessoa deve ser um profissional de TI real, e não uma secretária que exerce uma carga temporária em período parcial. Ele deve poder verificar as qualificações da equipe contratada e monitorar constantemente a qualidade do produto que está sendo desenvolvido. Além disso, o produto que está sendo desenvolvido deve permitir (no caso de força maior) a substituição da equipe de desenvolvimento. Somente neste caso, podemos esperar que não seja "insultuoso e doloroso por anos vividos sem rumo".
Como você pode ver, o Agile tem seu lugar ao sol, mas é muito limitado no campo do desenvolvimento de TI por contrato. O que fazer se o seu projeto não se enquadrar na categoria de Agile-apropriado?
Não lhe parece suspeito que uma metodologia flexível não tenha se enraizado em outro lugar que não seja o contrato de desenvolvimento de software? Bem, eles não fazem submarinos, aviões ou carros no Scrum. A sabedoria de nossos ancestrais nos ensina que nem mesmo uma casinha de cachorro normal pode ser montada sem um estágio de design (desenho a lápis com dimensões) e a preparação de um ToR (lista de materiais e ferramentas). Tudo o que você vê ao redor (do banquinho à nave espacial) foi criado de acordo com a boa e velha
"cachoeira" . Por que você não faz o mesmo? E lembre-se - tudo ficará bem!
PS
Tudo o que foi dito é baseado em minha considerável experiência pessoal (19 anos) no desenvolvimento de contratos por web, usando abordagens tradicionais (em cascata) e progressivas (Scrum). O motivo para escrever o artigo foi a angústia moral da contemplação do próximo "milagre da tecnologia hostil", reunido sob os convênios do grande Frankenstein para uma empresa ocidental respeitada.
