É tudo sobre o Agile - 2: Recursos de implementação do Agile

Continuamos com as nuances do desenvolvimento ágil que acontecem na prática. Como entender se o Agile é implementado corretamente, que prática é adequada para qual tarefa e setor, quem na empresa deve transferir o trabalho para o "Agile-rails"? Vasile Savunov, coach ágil ScrumTrek, continua compartilhando sua experiência com os editores do blog Mail.Ru Cloud Solutions .

Na última vez, Vasily falou sobre o que é Agile, quais metodologias ele inclui e quais estereótipos se formaram em torno dele. Agora vamos falar sobre sua implementação.

Sobre empresas ágeis

- Existem “preferências da indústria” em metodologias flexíveis?

Como o estudo Agile Russia , que realizamos pelo segundo ano consecutivo, mostra que o Scrum é usado principalmente no desenvolvimento de software, o Kanban em organizações financeiras e ambos no setor de telecomunicações.

Como uma pessoa que analisou diretamente os dados coletados e trabalhou com muitos dos entrevistados, acredito que esse estado de coisas se deve a duas razões:

• A taxa de mudança na TI é significativamente maior do que nas finanças. Portanto, é preferível o Scrum como uma abordagem que permite, devido a experimentos rápidos, controlar de forma flexível as prioridades e mudar a direção, dependendo das mudanças no ambiente externo e nas condições na entrada. As finanças são mais conservadoras.
• O custo de um erro nas finanças é muito maior do que no desenvolvimento de TI. Portanto, eles são um Kanban mais valioso, baseado na matemática, do que na experimentação, e permitindo mudanças pequenas, mas constantes, para melhorar o fluxo de trabalho como um todo.

Telecom Kanban também é adequado. Se apenas porque o vetor de desenvolvimento do setor é a digitalização. No entanto, poucas pessoas entendem exatamente como deve ser. Além disso, nas telecomunicações, a parte "rápida" do trabalho (desenvolvimento de software) é adjacente à parte "lenta" (suporte e desenvolvimento da infraestrutura de hardware). Portanto, juntamente com os experimentos realizados no Scrum, faz sentido acelerar evolutivamente os processos atuais usando o Kanban.


Práticas de desenvolvimento ágil adotadas em diversos setores. Os valores não são iguais a 100% porque mais de um item pode ser selecionado. Image / ScrumTrek

- E os desenvolvedores de dispositivos móveis? O Agile tem especificidades no desenvolvimento móvel?

Do meu ponto de vista, a principal dificuldade no desenvolvimento de aplicativos móveis é a identificação de requisitos de aplicativos, pois pode ser difícil identificar as partes interessadas. Essas dificuldades podem ser superadas usando o desenvolvimento do cliente para pesquisar as necessidades do cliente e o Scrum para testar rapidamente as hipóteses de produto.


Em geral, o Agile combina bem com o desenvolvimento móvel: requer uma reação rápida, envolvimento e trabalho coordenado de diferentes especialistas, a capacidade de fornecer rapidamente o resultado e, se necessário, alterá-lo.

Além do Scrum, aqui você pode usar diretamente o foco nas abordagens de desenvolvimento móvel. Por exemplo, o Mobile-D é baseado em XP, Crystal e RUP - as abordagens são bastante antigas e bem estabelecidas. A principal diferença entre o Mobile-D e o Scrum: a presença de fases claras e o foco principal no lado da engenharia do desenvolvimento de produtos. Enquanto o Scrum se concentra mais no gerenciamento e entrega de produtos, o Mobile-D se concentra no processo de fabricação e incorpora práticas XP que melhoram significativamente a qualidade do produto final. Ao mesmo tempo, a influência do RUP afeta, portanto, o processo é bastante formalizado.

Outra abordagem mais moderna para o desenvolvimento móvel é o SLeSS , combinando Scrum e Lean Six Sigma . Primeiro, ele implementa a configuração do fluxo de trabalho Scrum e depois aplica as abordagens Lean Six Sigma para o gerenciamento estatístico da qualidade. Parece-me que o SLeSS combina a flexibilidade necessária com os mecanismos de tomada de decisão informada com base em estatísticas.

Ao mesmo tempo, o Guia Scrum não proíbe inicialmente a inclusão de outras abordagens e ferramentas no fluxo de trabalho do Scrum que possam ser úteis para o desenvolvimento de produtos. Portanto, todos os itens acima podem ser implementados na estrutura do Scrum "clássico".

- Quão flexíveis são as metodologias de modificação sob condições específicas?

Deve ser considerado separadamente Scrum e Kanban.

O Scrum é uma estrutura, ou seja, uma estrutura cujos elementos são necessários: eventos, funções e artefatos. Ninguém pode ser jogado fora. Mas não há requisitos estritos sobre como exatamente implementar esses elementos - faça como desejar. E o Scrum não proíbe adicionar novos elementos: reuniões, artefatos, funções que você precisa para trabalhar e ajudar a acelerar o processo.

Kanban é um conjunto de ferramentas e métricas. Ele não fornece configurações rigorosas sobre exatamente quais ferramentas e em que combinação usar, uma vez que foi projetado para uma longa mudança evolutiva no sistema existente. Mas, ao mesmo tempo, o sucesso do Kanban é determinado pela coleta de dados sobre o processo de trabalho e sua análise regular. Se isso não for feito, com o tempo, tudo desaparecerá e não haverá mais melhorias. Mas tudo bem: como Edward Deming disse, você não precisa mudar; a sobrevivência é voluntária.

- Quais são os erros típicos na adaptação que o Scrum cria para os negócios?

O principal erro na implementação de metodologias flexíveis é o uso de ferramentas sem entender por que elas devem ser usadas especificamente.

Por exemplo, em grandes organizações, ao implementar o Scrum, elas geralmente renomeam o gerente de projeto como o proprietário do produto e a equipe de projeto para a equipe Scrum e começam a exigir o resultado final em duas semanas. Mas isso não funciona, e por uma razão muito simples: as condições não são atendidas sob as quais o Scrum pode funcionar .

• Embora o gerente de projeto tenha sido apelidado de Dono do produto, ele não recebeu a autoridade necessária e, portanto, não tem o direito de formular uma visão do produto ou alterar as prioridades de implementação. Como antes, ele é forçado a coordenar todos os seus passos com a liderança e está preso na estrutura dos requisitos para o tempo e o volume do trabalho. Portanto, a velocidade da tomada de decisões permaneceu a mesma. Sem aceleração ou adaptação a mudanças de condições.
• Embora a equipe do projeto tenha sido chamada de equipe Scrum, as pessoas incluídas nela ainda podem ser listadas em cada departamento e se reportar diretamente aos gerentes de linha. Assim, cada membro da equipe faz primeiro o que seu gerente de linha, e não o Dono do Produto, lhe confiará. Como resultado, as tarefas do produto sempre terão prioridade mais baixa, o que significa que a velocidade de implementação do produto, para a qual a equipe do Scrum foi "montada", não aumentará.
• Muito provavelmente, como antes, os membros da equipe estarão ocupados em outros projetos. Enquanto o Scrum declara diretamente: os membros da equipe devem ser alocados à equipe do Scrum 100% do seu tempo de trabalho e lidar apenas com o produto que o Dono do Produto lidera. Se as pessoas são “divididas por porcentagens” entre projetos / produtos, elas alternam entre elas, o que reduzirá drasticamente o envolvimento e a eficiência do trabalho em cada projeto / produto específico.

Essa "implementação" inepta tem muitas consequências negativas, mas elas começam com uma tentativa de reproduzir a mecânica, mas não a essência do Scrum. Os principais erros na implementação do Scrum foram descritos em detalhes no meu relatório " Stop Signals for Agile " na conferência CodeFest 2017.

- Como avaliar como metodologias competitivamente flexíveis são implementadas na empresa?

Existe um teste Scrum Open , mas serve mais como teste de conhecimento teórico. O que acontece na prática, ele não permite entender. Dado que a base do Scrum é o trabalho em equipe, e sua prioridade é a velocidade de entrega do produto e o valor para o consumidor, as pesquisas 360 são mais apropriadas. Portanto, é mais confiável estabelecer o grau de maturidade da equipe e a satisfação do cliente.

Utilizamos nossa própria metodologia, que foi implementada no serviço ScrumTrek Diagnostic Tool . Ela trabalha assim. Uma equipe e partes interessadas externas fazem uma série de perguntas sobre como elas avaliam o nível de interação da equipe, planejando seu trabalho, o valor do resultado entregue ao cliente, a interação com outras equipes e assim por diante. Para cada parâmetro, a mediana das opiniões é calculada e um gráfico de pizza complexo é construído - Radar, que exibe a aparência de dentro da equipe e de fora.


Radar ScrumTrek. Observamos a dispersão das classificações


Radar ScrumTrek. Nós olhamos para as medianas

O diagrama contém muitas informações úteis.

• As estimativas atômicas dos indivíduos e suas médias são interessantes em si mesmas e não são necessárias explicações aqui.
• A dispersão de notas em uma equipe é uma coisa interessante. Quando é muito grande, há motivos para concordar com o que entendemos como equipe por um ou outro aspecto do nosso trabalho. O que queremos dizer com "valor para o cliente", por exemplo? E quanto à "velocidade de entrega"? Um amplo spread indica que a equipe não formou uma única posição em vários problemas.

Um pequeno spread indica consenso e bom trabalho em equipe.

• As classificações são categorizadas. Você pode ver que está tudo bem com a cultura, mas a produtividade está diminuindo em alguns lugares. Está claro onde "cavar".
• A diferença entre a avaliação dentro e fora da equipe é um dos indicadores mais importantes, mostra as diferenças entre as expectativas dos clientes e outras partes interessadas da equipe e como a equipe se percebe. Agile é sobre a estreita interação entre os negócios e os que vendem o produto; portanto, essas discrepâncias são um excelente motivo para "verificar o relógio" entre essas duas áreas e concordar em como reestruturar a equipe.

Após a coleta dos dados, uma análise do gráfico é necessariamente realizada com o envolvimento de toda a equipe e partes interessadas. Tudo para mostrar a eles como o trabalho da equipe é apresentado sob diferentes ângulos e processar os resultados da análise em etapas concretas para melhorar o trabalho.

Sobre as equipes de implementação do Scrum

- De quem a empresa deve iniciar a implementação de metodologias ágeis de desenvolvimento?

A implementação do Scrum sempre vem de uma meta de negócios. Portanto, o cliente deve ser o primeiro a pensar em aceleração - interna ou externa. Então você precisa elaborar o conceito do produto para que ele possa ser feito iterativamente. E só então formar uma equipe. Scrum por uma questão de Scrum não funciona. Além disso, pode ser muito caro resolver problemas específicos.

Quem será o "guia ágil" na empresa é uma pergunta sem a única resposta certa. Vi o diretor técnico se tornar o "instigador" da mudança. Houve casos em que a iniciativa veio dos negócios e até vimos como essa iniciativa surgiu "de baixo". Tudo depende da energia e motivação da pessoa, se ele será capaz de incorporar sua visão de desenvolvimento usando abordagens flexíveis no contexto comercial do produto ou unidade.

Ideal quando a iniciativa vem da alta gerência. Os avanços nessa direção são perceptíveis no mercado russo.

- Quais novos papéis e funções surgem em uma organização ou equipe com a introdução de metodologias flexíveis? Quais deles são obrigatórios, quais são opcionais?

No caso do Scrum, esses são os papéis do mestre Scrum, proprietário do produto e equipe de desenvolvimento. Todos eles são obrigatórios. A equipe de desenvolvimento também é considerada uma "função", pois combina não apenas desenvolvedores, mas também todos que precisam que o produto apareça em princípio: analistas, designers e assim por diante.

O Scrum-master e o proprietário do produto podem ter assistentes que assumem parte de suas funções, enquanto a responsabilidade pelo resultado permanece com o Scrum-master ou o proprietário do produto.

O proprietário do produto geralmente é uma pessoa da empresa. Mas não necessariamente: digamos, se criarmos algum tipo de solução de engenharia para produção, esse papel poderá ser desempenhado pelo engenheiro-chefe. Por fim, essa é a pessoa que entende o melhor de tudo para qual consumidor estamos produzindo o produto, quais problemas ele resolve em primeiro lugar, como as prioridades devem ser construídas ao criá-lo. É muito importante que o proprietário do produto tenha autoridade para determinar independentemente a composição do produto com base em dados do mercado e do consumidor. Ele deveria ter o direito de dizer não às partes interessadas com quem ele interage. Isso é necessário para que as prioridades sejam acordadas e as decisões sejam tomadas prontamente.

Scrum-master é uma pessoa cuja tarefa é criar uma equipe forte, unida, responsável e idealmente auto-organizada. O importante não é um líder de equipe , ou seja, não é um líder. O Scrum-master não tem permissão para orientar ou intervir diretamente no desenvolvimento do produto. Ele é o organizador, facilitador, treinador e praticante do Agile. Na minha experiência, os melhores mestres de Scrum vêm de gerentes de projeto - desde que tenham sido treinados e conseguiram passar de um formato de diretiva para um de coaching.


Falando em estilo de comunicação de coaching. Há também um treinador ágil . Sua tarefa é configurar o fluxo de trabalho, educar as pessoas e fornecer ferramentas para as atividades diárias no Agile. Incluindo ferramentas de resolução de conflitos. Tudo o resto está além do seu alcance. Idealmente, um coach Agile deve configurar uma equipe ou departamento para que tudo funcione por si só e não seja necessário um coach Agile.

O período de transição está sempre associado ao desconforto. O treinador ágil foi projetado para ajudar a equipe a passar por esse período com atrito mínimo e desenvolver novos métodos de trabalho convenientes e eficazes.

Ao escalar, funções adicionais podem ser introduzidas, como descrito, por exemplo, na estrutura do SAFe , mas ainda são baseadas nos termos de referência e nos princípios de trabalho do Scrum-master ou do proprietário do produto: os níveis de hierarquia relacionados ao produto simplesmente aparecem.


- Como são diferenciadas as funções do proprietário do produto e do Scrum-master "em um mundo ideal"?

De um lado da escala, estão os interesses dos negócios que o proprietário do produto representa, por outro, a vitalidade e a eficácia da equipe pela qual o Scrum master é responsável. Para que a equipe alcance resultados rapidamente, o sistema deve estar em equilíbrio. Se o proprietário do produto "aperta", a equipe trabalha noites e fins de semana e, em breve, enfrentará um punhado de pessoas desmotivadas e não envolvidas, em vez de uma equipe bem coordenada. Se o Scrum-master puxar o cobertor sobre si mesmo, o desenvolvimento não será instável, nem superficial, com disputas constantes e muito mais tempo do que o necessário.


- Quais metodologias e modelos gerenciais valem a pena dominar para aqueles que vão assumir uma das funções descritas anteriormente?

Em termos de competências de negócios, tudo é "de acordo com os clássicos", como na gerência comum, exceto pela necessidade de determinar prioridades por etapas e interagir mais estreitamente com a equipe.

O proprietário do produto deve aprender Lean Startup, desenvolvimento de clientes e outras abordagens modernas para criar produtos.

Para o Scrum-master, a gama de competências é maior: facilitação, gerenciamento de conflitos, dinâmica de grupo, coaching e, é claro, prática ágil. Pelo contrário, essas são habilidades do campo da psicologia; portanto, sua falta é sentida ao treinar gerentes.

- A propriedade coletiva do código realmente reduz a dependência da empresa em desenvolvedores "estrela"? A motivação deles está caindo?

A propriedade do código coletivo é viável sem metodologias flexíveis. Chega de acordos de revisão de código e outras regras formais, e os desenvolvedores podem agir atomicamente.

Muitas vezes, a própria empresa provoca o comportamento "estelar" dos engenheiros: à primeira vista, é mais lucrativo contratar um super especialista e confiar-lhe toda uma direção com total responsabilidade pelo resultado do que reunir uma equipe de camponeses médios, reduzir sistematicamente os riscos devido a erros e aumentar seu profissionalismo.

Este é um dilema: sucesso a curto ou longo prazo. Parece que contratar uma "estrela" é bom para os negócios. Mas o que acontecerá em três anos, cinco, sete anos após a entrada de um profissional na empresa? Ele se tornará indispensável. E com pelo menos três consequências negativas.

Em primeiro lugar, essa pessoa quase não tem tempo livre e a empresa, em geral, não se importa. Sua lógica: "Não pagamos um salário enorme para que você possa descansar". Chegando a uma situação semelhante, as pessoas rapidamente se esgotam, caem no cinismo e tentam obter o máximo de benefícios de sua posição.

-, . , , , . : , , , , . , .

-, «» . , : , «», «» . : , , .

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

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

Mail.Ru Cloud Solutions .