Quero falar sobre minha experiência em acelerar a automação em uma equipe de programadores e sobre quais técnicas colocamos em prática e o que resultou disso.
Condições iniciais
Realizamos nosso experimento para acelerar o trabalho dos programadores nas seguintes condições:
- era uma empresa de manufatura distribuída geograficamente;
- 4 programadores 1C e eu, seu líder, participamos do experimento;
- somos programadores em tempo integral que suportam configurações complexas;
- ficamos entediados e decidimos nos desenvolver.
Primeiro de tudo, o desejo de desenvolver surgiu depois que chamamos a atenção de um livro de Jeff Sutherland sobre Scrum. Você provavelmente já sabe muito sobre essa técnica, então não vou insistir nela. A parte principal do artigo não será sobre Scrum.
Então, quando lemos este livro, descobrimos que há um dilema, que é a tradução incorreta do nome do livro. O nome em inglês sugere que o Scrum acelera quatro vezes: "A arte de fazer o dobro do trabalho na metade do tempo".
E na tradução para o russo, afirma-se que o Scrum é um método revolucionário de gerenciamento de projetos. Quando os gerentes de TI estão preparados para as entrevistas, eles geralmente são instruídos - preste atenção no que a pessoa está se concentrando - nos processos ou nos resultados. A tradução para o russo se concentra no processo .
Por que estou falando sobre isso com tanta confiança? Vi dezenas de pessoas que usavam o Scrum ao vivo. A maioria deles acabou de iniciar o processo Scrum e, quando você pergunta: "O que você mudou?" - eles dizem: "Nós nos tornamos transparentes, interessantes, divertidos". Mas quando você está interessado em saber como os resultados mudaram, se a velocidade de desenvolvimento aumentou, se você começou a entregar projetos mais rapidamente, verifica-se que eles não sabem disso, porque não mediram a eficácia .
Então, lemos este livro e lançamos o clássico Scrum com todos os principais estágios do processo de negócios (eles são mostrados na figura).
Mencionarei o método de medição (ele aparecerá em todo o relatório). A maneira tradicional de medir no Scrum é o planejamento de pôquer . Consiste no seguinte: para cada tarefa, a equipe (ou os de seus participantes que entendem algo nessa tarefa) recebe uma pontuação de 1, 2, 3, 5, 8 e até 34 (números da série Fibonacci). De acordo com a totalidade das estimativas, a média é calculada. A tarefa é considerada concluída quando foi aceita pelo cliente.
Primeiros resultados
O que a introdução do clássico Scrum nos deu? Antes dele, a produção média diária por pessoa era de 4,2 pontos e, com sua introdução, o indicador subiu para 7,73 pontos . Aconteceu que nossa produtividade dobrou.
Todo mundo gostou, contamos a colegas de outros departamentos sobre o assunto, toda a empresa se interessou, todo mundo começou a implementar o Scrum em casa.
Mas nada aconteceu, porque todo mundo foi levado por um fetiche - eles compraram pranchas de cortiça, colaram adesivos e se limitaram a isso. Até o proprietário, que também estava interessado em Scrum, vasculhava os funcionários: ele foi ao quadro de cortiça, tirou uma foto dele, depois voltou uma semana depois e tirou uma foto novamente - o quadro não mudou.
Eu queria mais
Duas vezes a melhoria de desempenho nos pareceu entediante. Então comecei a ler o livro novamente. Nas páginas 54-55, alguns shuhari notaram. Estava escrito no livro que este é um princípio do Aikido que dizia - primeiro faça tudo de acordo com as regras (syu), depois comece a improvisar (ha), e só então separe e faça sua própria técnica (ri) .
Curiosamente, no conhecido Guia Scrum, esse princípio foi descartado e apenas "syu" permaneceu no "shuhari".
E nós decidimos ir até o fim.
O algoritmo básico de aceleração recomendado no livro de Jeff Sutherland é o ciclo de Deming . Em palavras simples, ele pode ser formulado da seguinte forma: você observa como seu pessoal trabalha, percebe onde eles são estúpidos, onde há um atraso, cria algum tipo de mudança, implementa e observa o que aconteceu. Se melhorar, mais rápido - você deixa a mudança. Se piorar - remova a alteração. O principal é fazê-lo rapidamente.
A propósito, a Teoria das Restrições da Goldratt Systems diz sobre a mesma coisa, apenas se concentra na outra. Ela diz - encontre o link mais estreito do seu sistema, expanda-o ou remova-o. Então repita novamente.
O objetivo de um e de outro é tornar possível obter o resultado o mais rápido possível em todo o ciclo de produção. A mesma idéia, aliás, foi expressa pelo desenvolvedor do Toyota Production System - o objetivo do sistema de produção é garantir que o dinheiro do cliente chegue o mais rápido possível.
O papel do observador para o fluxo de trabalho é desempenhado pelo Scrum-master. Podemos dizer que este é um treinador. Quando você lê a experiência de seus colegas do Scrum, eles percebem os mestres do Scrum como defensores e dizem que o mestre do Scrum deve remover obstáculos , afastar algumas pessoas, ajudar em alguma coisa.
No entanto, tenho certeza de que o Scrum-master é um observador e instrutor que ensina seu pessoal a trabalhar mais rápido, olha para onde eles são burros, ajuda, solicita, procura por algo novo, tenta combinações diferentes. Como um treinador de futebol.
Equipe de experimentos.
Para entender o contexto em que nosso experimento ocorreu, precisamos apresentar uma equipe. Se eu lhe disser que havia dois Stas, Oleg e Igor, isso não lhe dirá nada, porque ninguém conhece essas pessoas. Você, mais ou menos, me conhece apenas.
Portanto, em vez de dois Stasov, Oleg e Igor, a equipe apresentará personagens que todos conhecem e que são tão semelhantes quanto possível às pessoas reais:
- O coelho é inteligente, silencioso, silencioso.
- Leitão é o mais novo, o mais rápido, o mais curioso.
- O burro é o mais deprimido, e ele é assim na vida.
- E a coruja ... Na verdade, o livro original não era uma coruja, mas uma coruja de águia, masculina. Então a equipe tinha uma coruja de águia.
O próximo passo é a improvisação.
No primeiro dia, quando decidimos mudar tudo, nós:
- Jogou fora Scrum-board e adesivos. O Scrum-board foi substituído por um sistema de informação baseado em 1C: Gerenciamento de documentos;
- Os adesivos foram substituídos por tarefas neste sistema de informação;
- Pôquer esquerdo e medição de velocidade;
- Removidas reuniões diárias, retrospectivas, projetos (em geral, como uma entidade) - deixaram apenas uma certa classificação de tarefas por tópico;
- Adicionado monitoramento constante de tempo de inatividade, perdas;
- E eles adicionaram uma constante mudança de processo.
No total , durante esse experimento, que durou cerca de um ano conosco, encontramos cerca de 40 aceleradores . Tentei agrupar esses 40 aceleradores e agora vou contar rapidamente como cada um deles influenciou o fluxo de trabalho.
Só para mencionar de onde vieram esses aceleradores. Não há nada de novo aqui. Eu mesmo inventei alguns princípios, alguns dos meus colegas criaram algo, lemos algo nos livros. Por exemplo, quando em um livro é recomendável agir dessa maneira para resolver esse problema, você precisa fazer uma tentativa. Se isso acontecer, deixe-o. Se não há sentido, jogamos fora.
Zero change
Então, a primeira coisa que começou a repensar o processo é o livro “Code of Samurai” . Eu recomendo que todos leiam, comprem e mantenham em casa. Como foi escrito há 500 anos, e já há 500 anos, as pessoas sabiam como gerenciar, como obedecer, como desenvolver e como melhorar.
A atenção do personagem, a quem chamo de Leitão, no "Código Samurai" foi atraída por essas duas frases. Ele viu isso:
- A decisão deve ser tomada muito rapidamente - em sete respirações;
- E se você não tomar uma decisão rapidamente, o resultado será desastroso.
Piglet ficou tão empolgado com essa idéia que, se não pudesse tomar uma decisão em sete respirações, recusou. Uma vez eu até perdi uma bebida divertida.
Tornou-se interessante para mim, reli este livro novamente e notei que aproximadamente a cada 10 páginas diz: para tomar decisões rapidamente, você precisa pensar com antecedência como vai agir em uma determinada situação.
Como é isso?
É como uma estratégia quando você tem regras para tomar decisões .
Qual é a estratégia mais comum em nosso país? Quando você pergunta a alguém: “Qual é a estratégia da sua empresa?”, Eles mostram um longo “calçado”, que diz o que eles farão este ano - quais são os planos, orçamentos, tarefas da empresa, como crescerão em vendas etc. .d.
Esta definição não é próxima de mim, não é adequada para meus propósitos.
Portanto, deixamos para nós apenas a segunda definição e começamos a perceber a estratégia apenas como um conjunto de regras para a tomada de decisões .
Dessa forma, a mudança zero que introduzimos em nosso processo Scrum foi que, em nossa equipe , tentando novas técnicas de aceleração, formulamos princípios para eles , nomeamos (para facilitar a lembrança e a discussão) e os utilizamos ainda mais em nosso trabalho. . Esses princípios são os portadores de todo o resto.
O principal segredo das melhorias
O próximo princípio fundamental a que chegamos é "o principal segredo da melhoria" .
Você quer, acredite, você quer - não, mas criamos o "principal segredo das melhorias", cuja eficácia já vimos muitas vezes.
Ele pode ser formulado da seguinte forma: 75% dos problemas nas mudanças surgem devido ao fato de as pessoas não trabalharem conforme as instruções.
Por que isso está acontecendo? O fato é que as pessoas que estão tentando implementar mudanças (por exemplo, Scrum) vêm e dizem a seus subordinados: "Agora você está trabalhando de uma nova maneira". E então eles simplesmente vão embora. E quando retornam em uma semana ou duas, vêem que não há resultados. E no final, esses "trapaceiros" decidem que o Scrum não está funcionando e o excluem permanentemente da memória e do conjunto de ferramentas. O mesmo acontece com todos os outros métodos. Vi isso inúmeras vezes na minha empresa, e eles constantemente tentavam me convencer de que algo (algum tipo de mudança) não estava funcionando.
Portanto, formamos os princípios básicos da mudança - para que as mudanças ocorram, elas devem ser aplicadas . Se decidirmos que não temos suporte técnico hoje - só queremos ver o que acontecerá sem o suporte técnico - não haverá suporte técnico e nada mais.
Essa é provavelmente a coisa mais importante na qual nosso sucesso se baseou - no fato de que os caras que trabalharam comigo aceitaram essas regras. Eles não me pediram ordens, instruções, mudanças de pessoal ou permutações. Acabamos de concordar e fizemos juntos. Como resultado, em um dia pudemos verificar a operação de alguns métodos, práticas etc.
Sempre havia muitos gerentes legais por aí. Eu mesmo uma vez quis me tornar um.
Quem é um gerente legal? É ele quem acredita que é necessário definir uma tarefa, nomear o prazo e, quando o prazo termina e a tarefa não é concluída, o executivo é o culpado. Isso não é meu, mas a expressão deles. Eles dizem o seguinte: Scrum é uma porcaria, você precisa definir tarefas e secar quando elas não cumprem os prazos.
Mas decidimos por nós mesmos que os prazos são maus . Porque
- Primeiro, quando você tem um pool de tarefas, por exemplo, 150, e define um prazo para cada um deles, é necessário recalcular essas datas todos os dias, porque elas "flutuam" o tempo todo. Como resultado, uma quantidade enorme de tempo é gasta na administração;
- Em segundo lugar, devido ao fato de que as datas “flutuam” o tempo todo, elas estão sempre incorretas ;
- Além disso, o grau em que uma pessoa cai no tempo não significa nada . É que uma pessoa, por um período, pode ter uma tarefa;
- E para que eles são necessários? Se você mexe muito, mas na verdade o tempo está sempre errado? O tempo é apenas um fetiche;
- Decidimos por nós mesmos que o gerenciamento de tempo é uma "abordagem feminina" no gerenciamento .
O último ponto deve ser esclarecido separadamente. Peço imediatamente às mulheres que não se ofendam, especialmente porque essa abordagem agora é ainda mais comum nos homens. Essa metáfora foi inventada para explicar de alguma maneira as ações de alguns gerentes.
Uma analogia da vida: imagine que uma mulher pede a um homem que dê um tapinha e lhe dá 5 dias para fazê-lo. O que acontecerá todos esses cinco dias? Um homem fará seus próprios negócios e uma mulher lembrará? Não, não vai. Ela vem todos os dias e assiste silenciosamente - reparada ou não. E aí chega o quinto dia, a mulher aparece, olha - não consertou. Esperando de manhã e de manhã ...
E o mais importante, para uma mulher, este é um resultado positivo . Porque Porque depois disso você pode fazer assim:
Agora, faça uma analogia com os gerentes difíceis que definem a tarefa para que a pessoa não a conclua no prazo e, em seguida, ela possa ser explodida . Parece-me que isso é algum tipo de sadismo. Eles se divertem muito e acreditam que isso é trabalho , e para isso você precisa pagar de 300 a 500 mil rublos por mês.
Não somos assim, portanto, formulamos para nós mesmos o princípio de que um termo é necessário apenas quando nada precisa ser feito depois dele . Por exemplo, o prazo final para a geração de relatórios. Depois disso, você não poderá mais executar a tarefa, porque a penalidade para relatórios atrasados, ao que parece, é de cerca de 20% da receita?
Objetivos
Certamente todo mundo viu seus subordinados nesse estado.
Você vem para o trabalho - e seu funcionário fica assim.
Ou assim.
O que fazer com isso? Eu costumava fazer isso:
Como resultado, ele foi francamente enviado várias vezes, uma vez que levou uma pessoa a desmaiar, e isso não conta as lágrimas derramadas - homens e mulheres. Nojento, ainda envergonhado.
Uma pessoa que está constantemente gritando se transforma em uma merda. Embora seja mais correto dizer que o idiota foi quem o fez assim.
Por que essa condição é ruim? Se você gritar constantemente com uma pessoa, não verá mais as lágrimas dele, o que significa que você não saberá que ela está sentada e não faz nada . Porque uma pessoa em depressão não faz nada . Por eficiência, é uma perda enorme. Se uma pessoa ficar deprimida pela manhã, ele passará o dia todo navegando na Internet, abrir o configurador e alternar rapidamente. Ainda assim, os programadores estão sentados ao lado do monitor, certo?
Portanto, é melhor não gritar com as pessoas. É necessário analisar a situação, e pode acontecer que a pessoa não tenha motivação comum . Mas uma pessoa não tem motivação porque não tem objetivo . Ele veio trabalhar e não sabe o porquê. E se ele também recebeu algum tipo de negatividade em casa, por exemplo, porque não alcançou nenhum objetivo em casa (sua esposa quer ir de férias às Maldivas, mas ele não pode fornecer isso), ele vem trabalhar apenas para se sentar . Porque como atingir a meta, ele não sabe . Ou talvez ele não tenha propósito.
Portanto, formulamos para nós mesmos o princípio de que precisamos falar sobre objetivos . Primeiro, sentamos um de cada vez, conversamos, depois nos reunimos, discutimos.
Como resultado, conseguimos obter uma certa meta "média" - uma para todos .
Esse "objetivo médio" era assim - trabalhar para o futuro empregador . Essa redação tem muitos significados (bem, parece-me). Vou mencionar apenas dois:
- Em primeiro lugar, o objetivo do programador não está relacionado ao trabalho atual da organização atual. Porque as pessoas que se apegam à organização atual quando saem recebem um grande golpe em sua importância. Afinal, o que era importante aqui, ninguém precisa de lá .
- Em segundo lugar, o que significa “trabalhar para o futuro empregador”? Isso significa obter a experiência mais abstrata que será útil para a maioria dos futuros empregadores.
Esse é o objetivo que formulamos para as crianças, e isso teve um efeito muito positivo sobre elas.
Algumas palavras sobre “personalização imediata” é uma maneira puramente técnica de acelerar o trabalho.
A imagem mostra uma lista incompleta desses aceleradores. Estas são soluções abstratas que resolvem certas classes de problemas muito rapidamente . O exemplo mais comum é a validação de dados. Em vez de sempre que o usuário deseja proibir algo enquanto segura um documento, escreve código por 30 minutos, fazemos uma verificação em três minutos sem iniciar o configurador. Só isso.
Depois de adicionar o "Objetivo médio" e "Personalização em tempo real", obtemos o "Kit de dispensa". O que é isso Este é apenas o conjunto de conhecimentos, experiências e idéias que uma pessoa, deixando a empresa, leva consigo .
Para cada membro da equipe, fizemos uma lista bastante ampla do que precisamos estudar, do que precisamos tentar, do que precisamos entender, para que, quando deixarmos a empresa, isso possa ser aplicado a um novo emprego.
As prioridades são uma coisa insanamente importante.
Na minha vida, tentei muitas opções diferentes para atribuir prioridades às tarefas - na medida em que usei o modelo de desenvolvimento vetorial inovador de uma empresa a partir de uma tese de doutorado em economia.
Mas a prática mostrou que a eficiência é simples. Portanto, no final, para definir prioridades, escolhi a matriz Eisenhower usual . Todo mundo conhece essa ferramenta - quando todas as tarefas são divididas em quatro quadrados.
Nos princípios da equipe, isso se refletiu da seguinte forma:
- Urgência / Importância é colocada pelo (s) gerente (s);
- O funcionário não tem opção de ordem de execução;
- Para Nefig.
Por que o funcionário não tem uma opção de ordem de execução? Porque a capacidade de escolher uma tarefa para o programador é um mal terrível para a eficiência . Ele pode escolher uma tarefa o dia inteiro. O que é um dia? Isso é 20% da semana. É isso aí, o dia passou. Ele não escolhe apenas uma tarefa, ele pode acessar o configurador, ver como é resolvido, quais são as armadilhas e, em seguida, ficará assustado e mudará de ideia sobre isso. E assim acontece o dia todo, e talvez mais.
E os dois maiores males para a eficiência são quando uma pessoa está assustada e quando ela não entende .
Assustador - é quando uma pessoa se senta e ele:
- Assustador perguntar;
- É terrível cometer um erro;
- É assustador distrair colegas para perguntar algo;
- , .
, . , – , – ?
, , . , . . ?
, .
, metadata.js.
, , 20 . , , – , – . .
, . , .
, . . , . , , .
, ? , , , .
- , , , . ? : « , ». , . - – . , : «, , ». , , , , . , , .
, ? – , . :
- .
- « ». , – . , , – . – , , .
- - – - . , - , – . , : «, , , , , ». , – 30 .
- – . : , , , . , . : , . : «, , » – . - - .
, , . – – , , .. , .
– , ? . , , , , .
. 30 % . :
, … , , . , , , . , . .
– .
, , . . , — , . , , – , . – . , . , . – . , , , .
, , .
… , « ». .
, ? . :
, , , . , - , .
, , .. , – . – , , , . « », .
, . . , – , - . , , , , – , , , , – -, .
, , , , . , – , , , -, , , . , . , .
. , , , . , . , . , , . .
Caiu para eles, no departamento de compras, Piglet. Eu digo - há quanto tempo você reclama que não tem automação? Aqui está o Leitão à sua disposição completa. O pouso foi com intenção maliciosa, porque Piglet é um cara alegre e charmoso, e as garotas realmente gostam dele (a maioria delas está no departamento de compras).
Por uma semana, ele simplesmente ficou sentado com eles - essa era a tarefa do centro: sentar e assistir. Eu assisti, vim e disse - eles funcionam 3% do tempo. Eles trabalham - no sentido de comprar, procurar fornecedores, fazer pedidos, ou seja, desempenhar sua função principal. O resto do tempo eles estão envolvidos em algum tipo de processo, burocrático e outras bobagens.
Naturalmente, não falamos aos compradores sobre isso, para não ficarmos ofendidos. Piglet recebeu uma nova tarefa e retornou às compras. Ele começou a fazer perguntas desconfortáveis ao chefe, ou simplesmente trollar. O suficiente por alguns dias - a própria chefe veio até nós no departamento de TI e disse - ahhh, e esse zoológico?
Bem, eu ainda tenho um plano desde a época de Vasya - aqui, eu digo, vamos fazê-lo. E é isso.
Agora um pouco sobre Rabbit. Ele trabalhou sozinho por muito tempo nas fábricas.
O que acontece com uma pessoa quando ele trabalha sozinho na fábrica para 1C como programador? Ele começa a resistir às tarefas. Ele tem uma qualidade muito alta - lembro que Rabbit é muito inteligente, ele estudou bem na escola e na universidade. Eles trazem uma tarefa para ele, dizem - vamos fazê-lo, e Rabbit responde - não, você não precisa fazer isso e fornece muitas razões aparentemente objetivas para o problema realmente não precisar ser resolvido.
Tudo ficaria bem, mas ele começou a fazer o mesmo comigo. Por exemplo, eu defini a tarefa para ele. Ele não diz nada, senta-se em frente ao computador.
Eu cuido dos meus negócios e sinceramente acho que ele se senta e resolve o problema. E ele, o cachorro, senta-se e pensa por que não deve ser feito . O resultado de seu trabalho em um dia, ou até dois, é uma lista de alta qualidade de razões pelas quais a tarefa não deve ser realizada!
E se ele ainda conseguisse superar esse estágio, recostou-se na cadeira, olhou para o teto e começou a contar que dificuldades encontraria para resolver esse problema. Eu digo - pare! Você sabe como fazer tudo isso? Bem, sim ele faz. Então, por que você está me falando sobre suas dificuldades aqui! Bem, então eu ... - diz Rabbit.
Como resultado, formulamos o princípio mais simples: o problema deve ser resolvido . Não importa o que você pensa sobre isso, se eu, como líder, levei essa tarefa para o trabalho, você terá que resolvê-la - sem opções. Não procure maneiras de evitar essa tarefa. E isso é tudo, mais dessas situações não surgiram.
Este é um princípio muito simples. As tarefas são grandes e pequenas. O Scrum diz - você precisa dividir as tarefas em pedaços para que cada uma não demore mais de um dia.
Mas às vezes acontece assim. Um homem senta-se, executa uma tarefa e termina, por exemplo, às 15h00, duas horas antes do final do dia útil. Relutância em iniciar uma nova tarefa. Da mesma forma de manhã - enquanto café, correio, redes sociais, isso, e só então as tarefas.
Para usar efetivamente esses limites de tempo, identificamos um conjunto especial de tarefas, que chamamos de "shorties". Eles não obedeceram à matriz de Eisenhower, estavam em uma lista separada e foram projetados especificamente para "tapar buracos". Falta uma hora para o final do dia útil - faça algumas coisas. Simples, sem mergulhar no contexto, mas com tarefas benéficas. Se você não os ignorar, poderá obter um aumento na eficiência de trinta por cento.
A mosca importunada sou eu.
O Classic Scrum diz que você precisa fazer reuniões diárias pela manhã. E eu lembro do meu controle favorito e olho através de seu prisma. O que são reuniões diárias da manhã? Este é um ato de gerenciamento uma vez durante o dia. I.e. no Scrum clássico, você pode abordar o leme uma vez por dia.
Isso não é suficiente para mim, porque se na reunião uma pessoa dissesse que tudo estava dando certo para ele e, depois de cinco minutos, não estava dando certo, só saberei no dia seguinte, tendo perdido 20% de eficiência.
Então substituí as reuniões diárias por controle.
- Você pergunta uma vez por dia - você gerencia uma vez por dia;
- Você pergunta uma vez por semana - você gerencia uma vez por semana;
- Você pergunta uma vez por mês - você gerencia uma vez por mês;
- Você pergunta 5 vezes por dia - você gerencia 5 vezes por dia;
- Gerenciamento é uma mudança na direção certa .
Naturalmente, uma placa de scrum não era adequada para esse controle. Ela responde à pergunta "o que foi feito durante o sprint", mas não sabe nada sobre o que foi feito pela manhã ou ontem. Eles tentaram se adaptar - por exemplo, para escrever a data e hora da execução em um adesivo, mas a leitura dessas informações é inconveniente.
Portanto, o quadro de scrum, como líder, me enfureceu terrivelmente - não forneceu informações para a gerência. Bem, eu joguei fora, substituindo a automação simples no sistema de informação. A tarefa encerrada imediatamente caiu no relatório, que eu dividi em duas seções - desde o início da semana e pela manhã. Controlando esses dois indicadores, a qualquer momento vi que algum tipo de falha havia acontecido.
Os princípios são simples:
- Veja o volume de tarefas várias vezes ao dia ;
- Consciente e urgentemente, pergunte sobre dificuldades e obstáculos;
- Entenda imediatamente;
- Obrigado 1C: ANTES, tchau scrum-board.
Resultados finais
Como resultado, obtivemos uma certa técnica com princípios e pontos de controle. Como já criamos os princípios, tivemos que criar um nome, porque, caso contrário, é inconveniente discutir. A busca pelo nome levou exatamente um minuto!
Primeiro assim.
E então assim.
O experimento que realizamos de acordo com a metodologia "Cazaque" durou cerca de um ano.
- Deixe-me lembrá-lo, antes da introdução do clássico Scrum, nossa eficiência estava no nível de 4,2 pontos.
- Book Scrum elevou a pontuação para 7,73 pontos.
- E no Scrum "Cazaque", começamos a distribuir 17 pontos.
E depois de tudo isso, deixei a empresa e um "gerente difícil" veio em meu lugar. Um gerente muito legal, que Scrum chama de "scrum" e diz que essa é uma técnica inovadora. Como meu pessoal permaneceu na empresa, eles continuaram a medir sua eficácia e me deram seus indicadores de como eles estão trabalhando agora. Agora sua eficácia caiu para 2,5 pontos.
Se calcularmos o quociente das medições finais e muito primeiras, verifica-se que todos os métodos e princípios aplicados nos deram um aumento de 4 vezes na eficiência .
PS Há também uma versão em vídeo: um e dois .