Substituto flexível
A palavra "Scrum" refere-se a pelo menos duas entidades: filosofia e estrutura.
A filosofia, ou abordagem do trabalho, é descrita em um livro de Jeff Sutherland.
Estrutura, ou seja, um algoritmo de ações descrito em um documento chamado Scrum Guide.
A filosofia se transformou em uma estrutura porque os autores da filosofia queriam ganhar dinheiro com ela (em suas próprias palavras).
A estrutura é bastante simplificada em comparação com a filosofia. O principal é que o objetivo foi simplificado, ou melhor, jogado fora.
O objetivo da filosofia: acelerar a obtenção de resultados. Além disso, às vezes. Existem oito vezes exemplos de aceleração no livro.
O objetivo da estrutura é ter o Scrum. Diz o seguinte: faça de acordo com as instruções - você tem Scrum, viole as instruções - você não tem Scrum.
A estrutura não implica acelerar a consecução do resultado, em geral.
As pessoas que ensinam ou implementam o Scrum trabalham com a estrutura. Eles falam e implementam um algoritmo que não leva a nenhum resultado além de "agora temos Scrum".
O ponto é claro. Filosofia é muito difícil de vender. A estrutura é mais simples.
Uma estrutura é um produto. Ele, como esperado, passou na "embalagem". É simples, compreensível, há suporte e muitos especialistas. Não se parece com nada?
Tudo é bom, exceto pelo resultado - não é.
Se o cliente não estiver familiarizado com a filosofia Scrum, a implementação da estrutura o atenderá perfeitamente.
Se o cliente estiver familiarizado com a filosofia Scrum, ele ficará desapontado com a implementação da estrutura - não haverá aceleração na obtenção do resultado.
Será legal, moderno, moderno, mas nenhuma meta de negócios será alcançada (exceto o desenvolvimento do orçamento para “algo novo”).
Como ser Aprenda a filosofia do Scrum. É baseado na filosofia japonesa de gerenciamento da qualidade, cuja essência é: medições e melhorias sem fim.
Infelizmente, é preciso pensar, experimentar, observar e, infelizmente, trabalhar muito. Se isso não lhe agradar, use a estrutura.
habr.com/en/post/345540Ambiente variável
Para aumentar a eficiência de uma equipe de programadores, você precisa de um ambiente mutável. Já existe algum tipo de ambiente na equipe - precisamos torná-lo mutável.
Um ambiente mutável é a falta de algoritmos de trabalho formais e aprovados.
Os programadores gostam de trabalhar no algoritmo, porque eles mesmos estão envolvidos na criação de algoritmos.
Um ambiente mutável é um tipo de depuração, não é o algoritmo do programa que está depurando, mas o trabalho da equipe.
Basta concordar com a equipe que a era da mudança começou. Hoje, algumas regras, amanhã - diferentes. Não porque as rédeas caíram embaixo da cauda, mas porque a equipe precisa ser depurada.
Depuração é o lançamento de um algoritmo, rastreando sua operação e fazendo ajustes se algo der errado como pretendido ou conforme desejado.
A maioria dos projetos de mudança falha devido à falta de um ambiente mutável. É assustador fazer alterações em pedaços, é assustador introduzir novas regras todos os dias. É muito mais simples, sem alterar nada, desenvolver um Documento Grande, no qual Tudo é Prescrito, e entregá-lo para execução.
Isto é, grosso modo, como escrever o código do programa imediatamente, sem um único começo. Não, às vezes é possível se divertir, mas em tarefas decentes essa abordagem não funciona - você precisa ser muito inteligente. É muito mais fácil fazer depuração em um ambiente mutável.
habr.com/en/post/345830Scrum master
O scrum limpo descrito no livro, quando aplicado corretamente, aumenta a eficiência da equipe em 2 vezes. Isso é testado na prática.
Mas a prática de outras pessoas mostra que nenhuma aceleração acontece. Porque a metodologia descrita no livro foi simplificada para venda. É ela quem é usada - simplificada.
O Book Scrum envolve três níveis:
- O estado de Xiu ("cumprir") é o primeiro estágio, treina, repete, sem se desviar das regras;
- Estado Ha ("romper") - começamos a mudar as regras, improvisar;
- O estado de Ri ("separado") - somos libertados das regras e começamos a construir.
Como regra, o primeiro nível é para venda - instrução e a implementação de sua implementação. Para obter um aumento real na eficiência, você precisa ir para o segundo e terceiro nível. Pense com sua própria cabeça, procure maneiras de otimizar, implementá-las e monitorar o resultado.
O scrum master deve lidar com a aceleração - essa é sua responsabilidade. Por isso, está escrito no livro, cito: A principal preocupação do Scrum-master é levar a equipe à melhoria contínua e procurar regularmente a resposta para a pergunta “Como podemos melhorar ainda mais o que já fazemos bem?”.
Mas este é o segundo e o terceiro nível. E o primeiro está sendo vendido e apresentado.
No primeiro nível, o scrum master tem responsabilidades completamente diferentes. Verifique na Internet, a lista será mais ou menos assim:
Oh
- organiza e realiza comícios;
- Monitora a conformidade com os princípios do scrum;
- Cria uma atmosfera de cooperação;
- Resolve conflitos e protege a equipe.
Nem uma palavra sobre como melhorar a eficiência. Apenas seguindo as instruções.
Se você pensa logicamente, como a eficiência pode aumentar se a equipe trabalha constantemente de acordo com as mesmas regras? Para algo mudar, você precisa mudar alguma coisa. Mas você não pode fazer isso, de acordo com as instruções que não são permitidas. Portanto, a eficiência no primeiro nível não cresce.
Um scrum master deve ser uma pessoa interessada em aumentar a eficiência. Este trabalho não pode ser aprendido se não for interessante. Você precisa pensar muito, montar experimentos, testar hipóteses, constantemente cometer erros e encher cones.
É muito mais fácil emitir instruções e monitorar sua implementação. Bem, às vezes para facilitar (o que isso significa).
Tentei colocar pessoas diferentes como mestres de scrum, mas poucas pessoas se interessaram. Isso é normal.
Se você estiver familiarizado com o teste de Belbin, o gerador de idéias, o analista e o diplomata (investigador de recursos) são os mais adequados.
A função de um scrum master é muito semelhante à de um programador que otimiza o desempenho de um aplicativo. Somente aqui o sistema está vivo, fora das pessoas.
habr.com/en/post/346158Envio do sistema
Resultado da maioria das mudanças organizacionais: falhou.
Subproduto: a técnica é besteira.
A metodologia subjacente às mudanças. Em particular, Scrum.
A razão é muito simples: insubordinação sistêmica.
Bem, a solução é muito simples: envio do sistema.
Não sistemático, mas sistêmico. Submissão como sistema, como princípio.
Em nosso país, a desobediência é elevada ao culto - graças à história secular de nosso estado.
A desobediência sistêmica leva a um feedback estranho: novas regras e leis são criadas levando em consideração o fato de que ninguém as cumprirá.
Isto é especialmente verdade para as mudanças organizacionais. O autor nem considera a opção de as pessoas trabalharem de acordo com as regras propostas. Portanto, ele não se preocupa com a aplicabilidade e adequação das regras.
No entanto, existem exemplos de alterações implementadas com sucesso. Pegue as mesmas câmeras de vídeo nos cruzamentos.
Formalmente, a penalidade por dirigir até o cruzamento no qual o engarrafamento está alinhado já existe há muito tempo. Mas essa regra praticamente não foi observada.
Agora é perfeitamente observado em cruzamentos separados. Naqueles onde as câmeras de captura de vídeo estão instaladas.
As câmeras apenas forneceram o envio do sistema. Assim que as pessoas começaram a obedecer à regra, ficou claro que a regra em si era bastante funcional. A mesma regra que costumavam ficar juntos era considerada algum tipo de porcaria.
Além disso, qualquer outra regra, alteração, algoritmo, técnica ou caso. Qualquer técnica é útil.
Se você pensar de maneira diferente, se disser que “Scrum não funciona” ou “TOS não funciona” ou “Lean é besteira”, você é uma ótima pessoa. Só que você não implementou essa técnica porque não forneceu o envio do sistema. E sua incapacidade de fornecê-lo estava amontoada na inoperabilidade do método.
Fornecer envio do sistema é muito simples. Você tem que começar com você mesmo. Será uma auto-submissão sistêmica.
Apresentando o Scrum em sua equipe? Siga todas as regras declaradas, sem exceções. Todos os dias, sem passes.
Você verá imediatamente as vantagens e desvantagens da metodologia - essa e qualquer outra.
Se houver sucesso, você será o motivo. Se houver falha, você será a causa.
habr.com/en/post/346712