Scrum? Qual SCRUM?
Pela primeira vez, a abordagem SCRUM (
scrum inglês “luta ao redor da bola”) foi descrita por Hirotaka Takeuchi e Ikujiro Nonaka, que observaram que equipes pequenas (5 a 9 pessoas), com equipes de diversos especialistas, fornecem melhores resultados. A descrição mais completa de SCRUM foi introduzida pela primeira vez em seu livro por Jeff Sutherland. O livro chama-se SCRUM. Jeff começou sua carreira como piloto militar. Durante a Guerra do Vietnã, ele completou mais de cem missões. Então Jeff se envolveu em ciência, mas o mundo se lembrará dele como um dos fundadores da SCRUM. O livro começa com uma história real da vida do FBI, que gastou milhões de dólares no desenvolvimento de um sistema automatizado projetado para pesquisar e rastrear criminosos. O problema era que, após o término do projeto, os contratados mostraram ao FBI um produto completamente inoperante. Isso significava apenas uma coisa - os contribuintes americanos desperdiçaram milhões. A situação parecia desesperadora até que a liderança do FBI se voltou para o então nascente método de gerenciamento de projetos SCRUM. Este método é descrito em idioma acessível no livro mencionado, que, aliás, foi traduzido para o russo. Além disso, o artigo discute os principais equívocos e mitos que podem afugentar os principais gerentes que decidiram implementar o SCRUM em seus projetos.
1. Controle total que mata a criatividade
Na SCRUM, a equipe do projeto, não a gerência, decide como atingir a meta de negócios. Esse método motiva e estimula uma abordagem criativa, em contraste com a gestão clássica, na qual delegados funcionários implementam ações específicas de baixo nível, e esses, por sua vez, nem sempre entendem por que isso é e como afetará o projeto como um todo. Assim, no SCRUM, o gerenciamento não controla as ações da equipe do projeto e, por sua vez, relata apenas os resultados no final de cada sprint (um período de tempo predefinido, por exemplo, 2 semanas). A transparência existe apenas entre os membros da equipe do projeto. Em que isso se manifesta? Primeiro de tudo, comícios diários em que cada membro da equipe do projeto conta o que fez ontem, o que fará hoje, que problemas teve. Esta prática não se destina a controlar a quantidade de trabalho realizado por cada funcionário. Comícios de pé são projetados para ajudar cada membro da equipe a remover obstáculos em seu trabalho e dedicar colegas aos seus planos, para que todos entendam para onde o projeto está se movendo hoje e tenham consciência de seu papel no desenvolvimento de produtos. Para o mesmo propósito, a propósito, um quadro comum do SCRUM com adesivos, que todos podem ver, e espaço aberto, que removem os obstáculos à livre comunicação entre os membros da equipe, servem.
2. O SCRUM priva os direitos dos engenheiros mais experientes, porque eles obedecem à decisão da equipe
O SCRUM cria um ambiente no qual a autoridade é adquirida não por títulos e posições, mas por habilidades e experiência. Um exemplo impressionante da situação inversa é a hierarquia das forças armadas, onde o poder se baseia na posição e na hierarquia. Um capitão pode ser muito mais talentoso e erudito que um coronel. Apesar disso, o capitão deve obedecer rigorosamente. Essa estrutura rígida é ideal para condições extremas, como hostilidades, nas quais as decisões devem ser tomadas rapidamente, e sua discussão leva ao atraso, o que leva à morte. SCRUM não cancelará títulos. Cada funcionário tem sua própria posição de acordo com sua matriz de experiência e competência. No entanto, no processo de discutir uma solução, o fator dominante é uma posição clara e razoável, apoiada na experiência pessoal do funcionário no campo em discussão, e não no seu título. Ao contrário do mito, o SCRUM dá poder exatamente àqueles membros da equipe que articulam claramente idéias sólidas. E como você sabe - quem pensa claramente, ele formula claramente.
3. O SCRUM visa valores de negócios de curto prazo, e não o desenvolvimento de longo prazo do projeto
Esse problema é, de fato, relevante. Felizmente, a pergunta "O que fazer?" há respostas Deveria começar com o fato de que, se o projeto não for longo, com uma duração não superior a seis meses, esse problema provavelmente não surgirá. Outra coisa é quando o software se desenvolve por 2-3 anos ou mais. Existem muitos artigos nos quais os autores expressam sua dor em relação a esses projetos. O exército de junho e o meio (sinergias, como você sabe, são caros e poucos em número) confiam seu trabalho com confiança, e o sprint do cliente obtém resultados brilhantes para o sprint SCRUM. Mas o problema é que, após 5 a 10 corridas, a adição de novos recursos se torna problemática e, quanto mais longe, mais difícil. Portanto, o SCRUM é bom, mas você precisa pensar em estratégia e arquitetura. Uma situação semelhante pode ser evitada. Primeiramente, pelo
menos um a dois engenheiros experientes possível trabalharão no projeto, que passarão por eles mesmos todas as confirmações no repositório durante a revisão do código. Em segundo lugar, dedicar muito tempo ao treinamento (pelo menos 3 horas por semana) para engenheiros juniores e médios em arquitetura de software, padrões de design e como isso é aplicado a um projeto existente. Tais aulas devem ser acompanhadas de prática e dever de casa mínimo para melhor aprendizado. Tarefas práticas podem ser incorporadas ao backlog dos sprints do projeto. Isso não afetará muito a lucratividade do projeto, mas acelerará o processo de crescimento dos funcionários e evitará possíveis problemas com a arquitetura de software. A realização de reuniões periódicas permitirá que as equipes do projeto aprendam umas com as outras, o que não prejudica a qualidade do software produzido.
4. O SCRUM impede que os engenheiros desenvolvam
O SCRUM assume que todas as decisões relacionadas à maneira de atingir as metas de negócios são delegadas à equipe. O proprietário do produto decide o que precisa ser feito e a equipe decide como. Daqui resulta que a equipe deve ser competente o suficiente para tomar decisões eficazes. Portanto, a pedra angular da metodologia SCRUM é o treinamento. É por isso que em todos os maiores bancos e terceirizados de TI é dada muita atenção ao desenvolvimento: treinamentos, seminários, cursos. O crescimento profissional dos funcionários é parte integrante da SCRUM. Devido ao fato de as equipes do SCRUM serem relativamente pequenas, os membros da equipe precisam dominar toda a pilha de tecnologia no projeto em que estão trabalhando. Ao final do projeto, o engenheiro recebe novas habilidades, o que aumenta seu valor no mercado de trabalho.
Subtotal
O SCRUM, como qualquer outro método de gerenciamento de projetos, possui características e rugosidade próprias que precisam ser conhecidas e levadas em consideração. Apesar disso, fornece o melhor resultado entre os métodos conhecidos hoje.
1. Jeff Sutherland // SCRUM 2017.