É tudo sobre o Agile 1: mitos populares da agenda

As metodologias de desenvolvimento ágil se enraizaram tanto na TI quanto na não TI, repletas de presságios, estereótipos, superstições e mitologia. Os editores do blog Mail.Ru Cloud Solutions decidiram conversar sobre essa mitologia com o treinador do Agile Vasily Savunov, do ScrumTrek.

Agile é uma filosofia de desenvolvimento ágil cujos fundamentos são descritos no Manifesto de desenvolvimento de software ágil . O conceito é baseado em quatro valores principais:

• pessoas e interação são mais importantes que processos e ferramentas;
• um produto de trabalho é mais importante do que documentação abrangente;
• a cooperação com o cliente é mais importante que o acordo do contrato;
• a prontidão para a mudança é mais importante do que seguir o plano original.

Os princípios da abordagem ágil transformaram o processo de desenvolvimento e ganharam respeito. O mundo moderno está acelerando muito - dezenas de novos serviços e soluções digitais aparecem todos os dias. O Agile permite que a empresa seja rápida o suficiente ao desenvolver novos produtos para acompanhar esse ritmo acelerado e dar aos usuários e clientes o que resolverá seus problemas o mais cedo possível.

Juntamente com a popularidade do Agile, veio sua interpretação formal. Analisaremos os mitos e estereótipos que nos impedem de ver a essência de uma abordagem flexível e de obter mais dela.

Mito 1. Agile é apenas TI

Não mais. Basta ver a lista de empresas em nome das quais os palestrantes da Agile Days e da Agile Business Conference falam: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Essas e muitas outras organizações que não estão relacionadas ao setor de TI usam com mais êxito as abordagens ágeis.

Mito 2. Agile - não para projetos de orçamento fixo

Dentro de um orçamento fixo, você pode trabalhar de maneira muito diferente. A questão é qual é o relacionamento entre o contratado e o cliente. Se você usa o Agile, precisa se concentrar no que resolve o problema do cliente. Em outras palavras, se no início o cliente e o contratado executam o planejamento juntos e identificam as principais prioridades do produto, nada os impede de determinar qual parte do produto, mais útil, pode ser implementada pelo contratado dentro de um orçamento limitado. E se você também estipular exibições regulares feitas para o cliente, é bem possível ajustar o processo em segmentos curtos e, consequentemente, ajustar os custos do projeto.

Mito 3. Agile - uma panacéia para negócios e desenvolvimento: implemente, deixe algo melhorar

Parece-me que esta é uma visão simplificada e muito prejudicial das coisas. Todos os casos e empresas são diferentes, e você precisa escolher a abordagem correta que ajudará nesse caso específico.

Definitivamente, o Agile não é necessário onde a chave do sucesso é seguir um algoritmo bem definido de ações. Por exemplo, no trabalho de um call center, onde, para um melhor serviço, os operadores devem conduzir uma conversa usando "scripts", ou seja, cenários de comunicação predefinidos. Não há campo para experimentação, e eles podem até ser prejudiciais aqui. Portanto, o Agile não é necessário nas atividades dos operadores de call center.



O Agile será prejudicial quando o custo de "processamento" ou "refinamento" do produto for colossal, ou mesmo envolver sacrifício humano. Digamos, durante a construção de uma usina nuclear, é óbvio que não podemos construir iterativamente - de forma incremental, como o Agile nos dita.

Mito 4. Scrum, Lean, Kanban não se cruzam.

Metodologias e ferramentas devem ser separadas. Metodologia é um algoritmo para criar um fluxo de trabalho. Ferramentas são aqueles "tijolos" usados ​​neste algoritmo.

Diferentes metodologias podem incluir as mesmas ferramentas, mas em um layout diferente. Você pode ver frequentemente como, ao implementar o Scrum, eles recorrem ao XP (programação extrema) ou às ferramentas Kanban. E isso é normal, pois todos eles atendem aos valores do Agile e permitem flexibilizar o fluxo de trabalho de criação do produto.

Se falamos sobre as abordagens específicas do Agile que agora são mais prevalentes, então isso é certamente Scrum e Kanban. Outros - FDD, XP, RUP e outros - saíram do palco ou raramente são usados ​​como um todo, mas ferramentas individuais de seu arsenal estão envolvidas na implementação do Scrum ou Kanban.

Mito 5. Scrum - como fazer um produto de forma rápida e barata.

Quanto ao "rápido", tudo é verdade, mas quanto ao "barato" - não. Julgue por si mesmo: você precisa formar uma equipe completa, destacando as competências necessárias nela 100%. Essas pessoas estarão ocupadas apenas com o desenvolvimento do produto que lhes foi confiado e nada mais, o que significa que elas terão que contratar esses especialistas ou "rasgá-las" de algum departamento. O mesmo se aplica à parte comercial: se você quiser, se não quiser, precisará alocar o proprietário do produto, que dedicará 50 a 80% do seu tempo apenas a essa equipe e seu produto.

Além disso, você precisará reuni-los todos, em uma sala, fornecer espaço próprio, acessórios para atividades em equipe e assim por diante. Além disso, você deve ter em mente que pelo menos oito horas por sprint serão gastas em comunicação, pois o Scrum envolve uma série de reuniões obrigatórias com duração de uma ou duas horas. Você terá que investir em qualquer caso, mas o ganho final em velocidade e qualidade que o Scrum fornece é muito grande.


O Sprint inclui 4 reuniões obrigatórias: planejamento, implementação, liberação, revisão do sprint com uma retrospectiva. Além disso, são realizadas diariamente reuniões de curta duração (reuniões em pé), nas quais os membros da equipe “verificam o relógio” em um único formato e coordenam suas ações. Você não pode adicionar novas tarefas ao sprint aberto - isso acostuma a equipe a planejar e garantir a ocorrência de caos gerencial.

Mito 6. Kanban é um quadro com tarefas postadas neles.

Nem um pouco! Os conselhos são apenas o primeiro e mais fácil passo no Kanban. Mas o assunto não se limita a eles . No coração de Kanban está um aparato matemático complexo, baseado em dados estatísticos. Portanto, equiparar Kanban a pranchas significa não olhar além de sua fachada.

Em poucas palavras, o ponto principal do Kanban é:

• Torne o fluxo de trabalho atual transparente e cubra todos os estágios - desde a ocorrência da tarefa na cabeça do negócio até a implementação e o envio do produto ao consumidor.
• Gerencie seu fluxo de trabalho identificando perdas de tempo e eliminando-as. Assim, tornamos nosso fluxo de trabalho previsível.
• Tome decisões de gerenciamento com base em métricas, não sentimentos.

Mito 7. Scrum e Kanban podem ser plantados em qualquer projeto e empresa.

Eu não gosto da palavra "plantio", afinal, o Agile é sobre trabalhar com pessoas. Seria mais correto falar sobre "incutir" uma nova filosofia de pensamento na equipe.

Ao mesmo tempo, os algoritmos de enxerto Scrum e Kanban são diferentes.

A taxa de sucesso do uso do Scrum depende da cultura corporativa dominante da empresa. Em uma estrutura hierárquica rígida, onde todos precisam de um pedaço de papel, nenhum esforço para "crescer" o Scrum será bem-sucedido sem o apoio da alta gerência. Teremos que construir uma nova estrutura paralela com base em uma abordagem de equipe. Uma espécie de "reserva Ágil", que protegerá um dos gerentes do mais alto escalão. Em tais condições, é possível mostrar um resultado rápido em três a quatro meses. Mas haverá uma tarefa mais difícil pela frente - espalhar essa cultura por toda a organização. Quanto isso vai durar é extremamente difícil de avaliar. Mas, na minha experiência, se a nova abordagem cobre 30% da empresa, ela começa a se espalhar e não precisa mais de proteção.

A implementação do Scrum geralmente requer grandes mudanças, tanto na estrutura da organização quanto na contratação de prestadores de serviços (você precisa de um contrato de tempo e material ) e no orçamento (orçamento faseado) e tudo mais.



O Kanban não exige uma mudança tão radical. Ele oferece: "Comece com o que é e comece a melhorá-lo evolutivamente". A taxa de mudança será significativamente menor do que no Scrum, mas todas as mudanças serão baseadas em estatísticas e terão uma justificativa clara.

Mito 8. O Scrum é projetado apenas para projetos feitos a partir do zero.

Existem casos diferentes, não existe uma regra rígida de que o Scrum seja destinado apenas ao desenvolvimento do zero. Transferir projetos existentes para o Scrum não é apenas possível, mas geralmente apropriado. Tudo depende da vontade de artistas e clientes de reestruturar seu trabalho para acelerar o desenvolvimento. Se eles estiverem prontos, tudo é realizável.

Por exemplo, um dos criadores de Scrum, Jeff Sutherland, em seu livro Scrum: A arte de fazer o trabalho duas vezes na metade do tempo, falou sobre como ele usou o Scrum para desenvolver um sistema de contabilidade automatizado do FBI. Quando ele assumiu o projeto, o desenvolvimento continuou pelo quarto ano, nenhuma função foi trazida para o lançamento e o projeto não era visível nem no final nem no limite. Jeff foi capaz de acelerar radicalmente o desenvolvimento e torná-lo transparente para os clientes. Seis meses depois, a primeira versão de trabalho do produto foi lançada e, em dois anos, o desenvolvimento foi concluído com êxito.

Mito 9. Ao introduzir metodologias flexíveis, os conflitos com representantes da hierarquia tradicional são inevitáveis

Se tudo for feito corretamente - para separar a equipe da hierarquia tradicional, forneça o orçamento ao proprietário do produto e contrate um Scrum-master verdadeiramente qualificado, não haverá conflitos. Mas isso nem sempre acontece. Muitas vezes, é impossível combinar essas duas estruturas; portanto, existe apenas uma saída: construir uma nova estrutura, afiada para a rápida tomada de decisões e implementação do produto.

E sobre quem é um Scrum-master, você aprenderá na próxima série. Aguarde na segunda parte da história de Vasily sobre a implementação de metodologias flexíveis de desenvolvimento: dificuldades, benefícios, armadilhas e bombas-relógio.

UPD E aqui está a continuação: É tudo sobre o Agile - 2: recursos da implementação do desenvolvimento ágil

Não há tempo para explicar, o material foi preparado com desinteresse e amor pela equipe do Mail.Ru Cloud Solutions .