Em um modelo de gerenciamento repressivo, um líder seleciona, por via de regra, funcionários mais estupidamente que ele ou aqueles a quem ele pode "hipnotizar" ou chantagear de uma maneira ou de outra. Eles estão procurando por "cães" fáceis de manejar e envenenados. As instruções idiotas que vêm de cima serão enviadas por proxy sem alterações, e aqueles que podem procurá-las abaixo sobreviverão, o resto estourará. habr.com/post/124716
Tudo é tão ruim com a liderança da equipe? Se deve impor formalmente um scrum quando ninguém entende sua necessidade, e isso realmente não é sentido, ou apresentar seus elementos gradualmente, para que a equipe sinta sua eficácia.
Conflitos de interesse são uma situação frequente em coletivos de trabalho e não apenas em programadores. E muitas vezes não há certo e culpado, há um choque de experiências e visões. Como liberar o potencial de todos os funcionários e obter sinergia quando 1 + 1 = 11, não 2.
Inspirado após a copa do mundo de futebol. A história da retirada do Scrum. Todos os eventos são fictícios, todas as coincidências são aleatórias. Uma situação generalizada e bastante simplificada.
Assim, a equipe é formada, analista, front-end, full-stack-back-end. Não scrum. A equipe é formada por um líder de equipe bastante competente, diversificado e experiente, com amplos poderes. A administração da empresa delega a ele autoridade total.
Por uma analogia, imagine que um projeto seja uma liga de futebol. toda a equipe com um feil, ou seja, um projeto fracassado ou prolongado. O sucesso é considerado um produto entregue de alta qualidade e pontual, ou seja, a melhor posição da equipe no campeonato, de acordo com os resultados de todos os jogos. Jogos são sprints. Sprint - uma iteração no scrum, durante a qual o crescimento do software é criado. É rigidamente fixado no tempo, como uma partida de futebol. Visão geral da primeira partida (sprint), a situação é bastante real.
Início do trabalho no projeto (primeiro tempo, tudo está indo bem, placar de 1 a 0)
Assim, o apito e os jogadores experientes o suficiente individualmente, mas não jogados juntos, fazem seu trabalho muito bem. O analista define as tarefas, o front-end faz a aplicação no back-end do mok. No começo, tudo está indo bem, layout, arquitetura do projeto, páginas são criadas rapidamente, o cliente recebe rapidamente resultados, a equipe recebe feedback dele. Todo mundo está feliz.
O back-end é desenvolvido separadamente, a arquitetura está sendo construída, um banco de dados está sendo criado, métodos aproximados estão sendo lançados.
Back-end não orientado para o cliente (Momento perigoso, objetivo, ajuda mal na zona intermediária, 1 - 1)
O analista, mostrando muito boas qualidades individuais, transfere a tarefa para a equipe, tela e descrição.
O front-end, recebe um passe, digita o formulário, escreve o código do cliente, passa o passe para o fullstack-bekender. E espera algo como:
Get / some / method
Fullstek-backender (capitão da equipe, também conhecido como líder da equipe) recebeu um passe e deu:
Como regra, as pilhas completas têm um conhecimento superficial em áreas (simplesmente porque fisicamente não podem cobrir tudo profundamente), mas veem o projeto como um todo. Eles são bons em pequenos projetos em que fazem tudo sozinhos e são ineficazes no desenvolvimento da equipe.
Houve uma pausa e perplexidade, quando perguntado por que, silencioso e ignorado, o líder da equipe sabe o que está fazendo. Com transmissões repetidas e perguntas subsequentes, por que? Resposta: "Confie em mim, eu sei o que estou fazendo, você não tem visão do sistema como um todo." Enquanto o empate é 1-1. E nada pode ser feito aqui, nem para o líder, nem para a liderança.
Trabalho em equipe fraco (informações, objetivo, 2-1 leads fakap)
O Frontender pensa e se esforça. O que você precisa jogar na tela? Ele pergunta novamente, mas a interação não se mantém. Tim-leader-full-stack-beckender está nervoso, respostas dispersas. "Pense!" "É mais fácil fazer isso sozinho", "Kicker". O jogo não pega, o time perde o segundo gol.
Fortalecimento por meio do desenvolvimento da equipe (o tempo não é a favor da equipe, o placar de 2-1 é o mesmo)
O front-end tenro pouco palpite sobre os parâmetros, aprendeu a prever a direção do passe, mas ainda havia um casamento no jogo. O provedor front-end não percebe tudo de ouvido e pede ferramentas de desenvolvimento de equipe (Redmine, Jira, Trello). Liderança vai se encontrar. Iniciado com tarefas, como:
Saudação -> ??? (qual campo extrair dos dados)
Parâmetro 1-> ??? (qual campo extrair dos dados)
Parâmetro2 -> ??? (qual campo extrair dos dados)
Por uma questão de clareza, os dados são limpos diretamente até a chegada do back-end e, de forma compreensível, são lançados em html. O jogo se estabilizou, mas o tempo está se esgotando, a conta é a mesma a favor do fakap.
Lesão, refatoração do código (A equipe ganha de volta, mas perde o gol 3-2)
O front-end fica ferido e deixa o campo por um tempo (férias planejadas); nesse momento, o back-end, rasteja para o código do front-end, gasta tempo refatorando-o e heroicamente desembaraça os dados do back-end diretamente em html. Objetivo rápido, ótimo! Mas, em resposta, ele recebe bugs do analista e tarefas pendentes para o sprint atual. Sim ... a equipe recebeu rapidamente uma meta de retorno. Beckender entra na lista dos melhores marcadores. O Frontender se recuperou rapidamente e estava de volta ao jogo. Mas como os passes não vão e o líder da equipe se autogerencia, a frente ainda não está muito envolvida. O apito final, a partida acabou. 3-2 a equipe perdeu, mas à frente do próximo jogo (sprints).
Retrospectiva do Sprint (Análise do primeiro jogo, front-end no banco)
No scrum, para identificar problemas nos estágios iniciais e no autoajuste flexível da equipe, os sprints são conduzidos retrospectivamente pelo scrum master (treinador da equipe), mas como ele não está no clube. O Frontender inicia. Reúne todos os participantes e explica a falácia de se recusar a jogar o passe, pois um momento não pode melhorar o jogo da equipe ao longo do campeonato (final do projeto) e pede a todos os membros da equipe para falarem. Em resposta, o capitão da equipe - líder da equipe - full stack, oferece a transferência do front-end para outro projeto, pois as opiniões dos jogadores não incomodam ninguém. A equipe está em silêncio - a gerência do clube também. A transferência foi adiada, o front-end pairando no banco.
Como operar a administração do clube? Tim leader ou scrum master? Discussões abertas, expressão de opiniões ou ordens únicas do líder da equipe. De fato, não há resposta certa. Para esclarecer a situação, você precisa entrar em um testador e observar o jogo em mais alguns sprints. Tudo depende do tamanho do projeto.
Epílogo (o tempo passou):
Muito obrigado pelos comentários!
Qual é a nossa vida? O jogo ...
Boa noite no clube intelectual. Onde Quando? O único lugar em que todo espectador pode ganhar dinheiro com sua própria mente ...
Então, silêncio no corredor.
Caros especialistas (scrama). Mais uma vez, chamo a atenção para o fato de o artigo, no início, enfatizar claramente que o que a equipe fez não foi um scrum, mas apenas uma tentativa de exibir uma disputa foi descrita.
O Scrum é como o pôquer, possui regras muito simples, mas muito estritas. Mas, ao mesmo tempo, poker e scrum são jogos muito difíceis.
Agora, atenção é a resposta correta.
No processo, uma regra muito simples e básica do scrum foi violada. Existem poucos papéis no scrum e eles são claramente explicitados. Não existe um papel chamado líder de equipe. A tarefa do scrum master é monitorar claramente a implementação desta regra. E interrompa qualquer tentativa de violá-lo. Resumindo, o caos do back-end foi para a frente e o projeto tropeçou.
Scrum é uma estrutura de desenvolvimento de software flexível. A estrutura é baseada em um método empírico (baseado na experiência) e destina-se ao desenvolvimento de produtos de alto valor em um ambiente complexo. en.wikipedia.org/wiki/Scrum
Rodada. 1-0 - a favor dos telespectadores. Os conhecedores fazem uma pausa musical ... E se preparam para a próxima rodada.