Nosso mundo é muito estranho. E quanto mais você vai, mais estranho fica. E você entenderá o que diabos.
Existem engenheiros e programadores no mundo. Às vezes, tudo reunido em um. Pessoas que entendem o que é um algoritmo. Além disso, pessoas que criam esses algoritmos. Eles sabem que o algoritmo criado é adequado para solucionar um problema, mas não para outro. Entendendo que, se o algoritmo for ligeiramente alterado, ele poderá resolver problemas relacionados. Não hesite em jogar fora metade do algoritmo de outra pessoa para que ele resolva melhor o problema atual.
Os programadores criam uma solução para uma tarefa ou para uma classe de tarefas. Essa é a essência da profissão. Sempre que possível, use peças prontas próprias ou o código de outra pessoa. E está tudo bem.
Mas, assim que se trata de criar algoritmos fora do computador, os programadores de repente perdem a cabeça. Não estou falando de desenhar diagramas de algoritmos no papel, como foi o caso no exame da universidade - aqui qualquer um de nós pode lidar com isso.
Estou falando de "implementação de técnicas", "trabalho na estrutura", "uso obrigatório de todos os artefatos". Sobre seitas, em suma.
Um pouco de idiotice
Todo mundo sabe o que é um operador condicional. Não há vida sem ele. Nenhum algoritmo decente funcionará. Nem no computador, nem na vida.
Agora imagine: uma certa pessoa apareceu, por exemplo, John, e percebeu que há uma declaração condicional no BASIC. Eu peguei, descobri, tive certeza - é, funciona, sem qualquer forma.
Digamos que John é burro. Mas ele decidiu conquistar o mundo. Fui vender BASIC. Não é a linguagem em si, mas algum tipo de "técnica mais legal de desenvolvimento de software", cujo link central é ... E John não dirá até que você conclua o curso.
Ok, havia amantes do curso, principalmente porque o preço não é alto. Eles vieram, ouviram, ofegaram. O principal elemento da metodologia mais legal de desenvolvimento de software é o Operador Condicional. Ouvimos muito sobre a declaração condicional. Por exemplo, como transformá-lo em um operador de múltipla escolha. Eles ofegaram novamente - que Operador Condicional poderoso.
Metade da platéia era de programadores. Relinchando, fui para casa. Outro trimestre foram gerentes. Eles se tornaram pensativos, fizeram perguntas, alguém decidiu implementar essa técnica legal em sua casa. O último trimestre foi o mesmo que John. Eles convenceram o sujeito a criar uma franquia, Comunidade, Autoridade de Certificação e Universidade Contingente.
Os programadores do curso voltaram ao trabalho, não se lembrando mais do Operador Condicional. Mas uma hora depois, os gerentes vieram e anunciaram que agora o desenvolvimento de software será conduzido de acordo com o método mais legal. Sim, que é sobre o Operador Condicional. Em geral, é melhor escrever em básico.
As objeções tímidas, se não tímidas, dos programadores foram ignoradas. Frases como “caramba, é um operador condicional, está em toda parte” foram percebidas como tentativas de se exibir. A roda girou.
E John rapidamente percebeu que apenas um Operador Condicional não é suficiente. Também deve haver um loop, sub-rotina, variável, matriz, etc. Deveríamos, de alguma forma, chamar tudo ... Em uma palavra ... Oh, que sejam artefatos! Nem mais, nem menos!
A principal coisa permaneceu: adicionar à metodologia uma cláusula de que a metodologia mais legal de desenvolvimento de software é um conhecimento holístico e holístico. Portanto, nem uma única peça pode ser jogada fora dela. E você não pode adicionar nada a ele - ele deixará de funcionar. Como está escrito, faça-o.
Graças ao entusiasmo de John e seus amigos, agora o mundo inteiro usa não um operador condicional, mas um operador condicional, não um ciclo, mas um ciclo etc., de acordo com a lista. Aqueles que entenderam a idiotice da situação há muito se aposentam ou calam a boca. Aqueles que vieram recentemente acreditam firmemente que o Operador Condicional faz parte da técnica mais legal de desenvolvimento de software criada por John. E todos os outros operadores condicionais são uma aparência miserável, uma cópia desbotada e um pedaço de conhecimento arrancado do contexto.
Quem se atreve a votar na Internet (ou, se Deus não permitir, dentro da equipe) será submetido a uma condenação feroz e minúscula irritação - você, botas, não vê os benefícios do Operador Condicional! E se a pessoa infeliz pedir para explicar qual é o significado e a diferença do operador condicional em C ++, javascript ou até 1C, ele receberá a resposta "é impossível explicar", "você não entende" ou "leia o guia".
Ferramentas e algoritmos
Todo mundo entende o que é um operador condicional e como usá-lo em algoritmos. Da mesma forma, todos entendem o que, por exemplo, é um adesivo com uma tarefa gravada. Os adesivos apareceram antes do scrum e moram fora dele. Olhe para o computador de um contador, fornecedor ou vendedor. Eles ainda não eliminaram o hábito de pendurar um monte de adesivos com tarefas urgentes no monitor. Uma senha será gravada em um dos adesivos.
Qualquer técnica pode ser facilmente desmontada em ferramentas, princípios e relacionamentos. Assim como qualquer algoritmo é desmontado em figuras de diferentes formas e propósitos - o início e o final do algoritmo, ação, condição, sub-rotina.
Qualquer técnica tem um escopo. Nem tudo está absolutamente lá - há um ambiente mais adequado, há menos. O mesmo que algoritmos.
Qualquer técnica pode ser modificada. Jogue fora peças, adicione novas, modifique ferramentas específicas. Assim como algoritmos.
Qualquer técnica pode ser misturada, no todo ou em pedaços. Pegue metade de um, um quarto do outro, outro quarto - invente você mesmo. Quando você cria um aplicativo ou serviço, isso é óbvio para você.
É verdade que permanece a pergunta - a metodologia será uma metodologia, se for alterada?
Veja como responder a essa pergunta, por exemplo, o conhecido Guia Scrum:
“Os papéis, artefatos, regras e eventos do Scrum não estão sujeitos a alterações. Embora o uso de elementos individuais dessa estrutura seja aceitável, o resultado não pode ser chamado de Scrum. O Scrum existe apenas como uma estrutura completa, mas pode acomodar outras técnicas, metodologias e práticas. ”
Um pouco como John e seu Operador Condicional, não é? Parece, mude se você quiser, só que não será um scrum. E qual será o resultado - o inferno sabe. Só para garantir, eles observaram que você pode tentar empurrar algo para dentro. Mas a espinha dorsal deve permanecer. Caso contrário ... é até assustador imaginar.
É realmente assustador? O que acontecerá se alguns dos artefatos forem jogados fora ou substituídos? E de qualquer maneira, qual é o objetivo? De onde eles vieram? Por que acredita-se que eles trabalhem apenas nessa combinação, como decidiram os autores?
Vamos tentar descobrir as partes.
Sprint e Backlog da Sprint
Ótima ferramenta, a propósito. Inventado, provavelmente, há mil anos atrás. Sempre foi chamado de forma diferente, mas o mais comum, provavelmente, é o "Plano". E humanamente - "fazer uma certa quantidade de trabalho por um certo período de tempo".
Para mim, como 1Sniku, é mais conhecido como planejamento de calendário espacial (OKP). É amplamente utilizado no planejamento de produção e vendas. Por exemplo, o plano de vendas de um gerente de 1 milhão de rublos por mês é uma reserva e um sprint. Às vezes, basta um número, às vezes há uma discriminação por grupo de produtos, ou restrições no mercado, ou até mesmo uma lista específica de itens, se exigida pela estratégia da empresa.
A produção é ainda mais fácil. Buchas - 1000 unid., Eixos - 2000 unid., Rotores - 500 unid. Este é, digamos, um plano semanal. Ele é o backlog do sprint semanal do local de produção. É verdade que os trabalhadores não podem ser explicados que isso não é um plano, mas um sprint.
A ferramenta é boa em comparação com o gerenciamento de tempo generalizado, quando o pool de tarefas do programador é estimado por custos de mão-de-obra, classificados por algum critério, e cada tarefa tem um prazo. Na produção, isso é chamado de planejamento de turno, ou planejamento de oficina, a partir do qual são criadas tarefas de produção que contêm uma lista de peças e produtos semi-acabados, operações técnicas, materiais, entradas e saídas (onde obter o que e onde transferir o resultado).
Para os programadores, o planejamento da oficina não funciona bem e não há nada para discutir aqui. O tempo de processamento de uma peça em um modelo específico da máquina é conhecido e com bastante precisão. Frequência de serviço - também. Suficiência dos materiais avaliados. Pegue e faça. Variações que interferem na implementação do plano na produção em massa geralmente não têm efeito significativo. E, se o fizerem, existem excelentes métodos para analisá-los e eliminá-los.
As variações do programador são muito mais fortes. Ele não é uma máquina-ferramenta, como alguns gerentes que vieram para TI de vendas ou produção não gostariam. Portanto, o planejamento da oficina (tarefa + prazo) não é adequado para um programador. Surgiram pessoas sensatas - você precisa subir para um nível mais alto, não para agendar o desempenho em minutos, mas para dar volume por um período. Somente eles criaram outro nome - sprint e backlog.
O preenchimento do plano de produção do calendário volumétrico é baseado em princípios semelhantes à formação de um backlog de sprint. Mesmo existe uma coisa dessas: "escolha um plano". Existem necessidades do mesmo departamento de vendas (= backlog grande), há taxa de transferência de produção (= capacidade da equipe em números), além de critérios de seleção claros - quantidade de vendas, lucratividade de cada posição, parâmetros do cliente (por exemplo, condições de pagamento). Marcou um plano de produção - e veja imediatamente o resultado financeiro aproximado que você obtém. Esta não é uma "liberação" efêmera.
Há alguma desvantagem nessa ferramenta? Claro, como qualquer outro.
Se você entender, o backlog do sprint é o mesmo planejamento da oficina, apenas sem uma sequência bem organizada de solução de problemas. Portanto, todas as tarefas têm um prazo final - o final do sprint. Depois que as tarefas têm um prazo, um efeito desagradável aparece - no início do sprint, a atividade pode ser significativamente menor do que no final.
É assim que qualquer psicologia humana funciona. Você sempre deseja ficar no início do período de execução, seja uma tarefa ou uma lista de pendências. Faça uma pausa do período passado, especialmente - de sua parte final, quando foi necessário dar um resultado "enorme". Claro, existem pessoas que são estáveis e rítmicas, trabalhando a semana toda na mesma velocidade, mas a maioria começa a "trabalhar normalmente" em algum lugar na quarta-feira.
É possível ficar sem o sprint e seu backlog? Fácil.
Por exemplo, aplicando a ferramenta "o mais rápido possível". Em geral, essa não é uma maneira de Praporsky, mas uma estratégia bastante normal para o mesmo planejamento da oficina (o mais rápido possível, o mais rápido possível). Isso significa que os problemas "ficarão" no início do intervalo de tempo, ou seja, Na segunda-feira, não na sexta-feira, como na estratégia "O mais recente possível, ALAP".
Planejar como tal não é necessário neste caso. Há uma lista de pendências de produtos, há prioridades, há uma regra "o mais rápido possível". Você pega o primeiro e faz. Terminado - você pega o segundo. E assim - da cerca para o jantar. Sprint, ou melhor, sua essência, ou seja, o período de tempo que você pode deixar para entender e analisar a produtividade (semana a semana, mês a mês, etc.).
Existem deficiências na estratégia "o mais rápido possível"? Claro, um milhão. Primeiro de tudo, uma pessoa pode se cansar rapidamente. Em segundo lugar, ele se sentirá como uma máquina-ferramenta. Em terceiro lugar, ele provavelmente fugirá - para onde são usados sprints comuns com uma lista de pendências. Ou eles simplesmente definem tarefas e aguardam o resultado. Em geral, onde é mais calmo. Mas a prática mostra que "o mais rápido possível" é possível viver por anos, se é senso comum que essa é uma estratégia de planejamento, e não um moletom.
É possível lançar um sprint e seu backlog? Não. Não porque essas são noções únicas do mesmo scrum, mas porque esse é um método de planejamento natural que todos, de uma forma ou de outra, usam. Existem muitas variações, um princípio - você precisa fazer uma certa quantidade de trabalho por um determinado período de tempo.
Uma ferramenta como um sprint é um elemento único e essencial de uma técnica? Não. É o mesmo que dizer que digitar código no teclado é uma noção única de alguma técnica. Quase todos os textos são digitados no teclado.
Scrum board
Formalmente, um quadro não é um artefato ou uma regra, mas acho que vale a pena falar sobre isso também, porque existe um padrão bastante óbvio entre as pessoas: um scrum é um quadro com adesivos.
Aqui, em geral, você mesmo entende tudo. Um quadro com adesivos nos quais as tarefas são gravadas não é exclusivo. Esta é, grosso modo, uma ferramenta multiplataforma. Minha esposa na geladeira às vezes esculpe adesivos com listas de tarefas, embora ela não saiba nada sobre scrum.
Essa ferramenta é boa? Depende do que comparar. Sim, talvez uma boa.
Por exemplo, ele permite avaliar rapidamente, examinar o pool de tarefas. Em um computador ou em qualquer outro dispositivo eletrônico, as tarefas precisam ser invertidas - tudo geralmente não cabe em uma tela. Portanto, em um relance - também.
Outra vantagem importante é a disponibilidade geral da equipe. A qualquer momento, você pode vir e ver, não entrar em nenhum sistema, pesquisar, fazer uma seleção etc.
Muitas pessoas gostam da natureza não virtual do quadro. Afinal, tudo é virtual em um computador; você não o toca com as mãos. E aqui - por favor, pelo menos lamber. Alguns, nesse sentido, adoram placas de cortiça. A diferença é algo entre papel e e-books.
Especificamente para uma placa de scrum, pode-se notar uma vantagem como a separação em duas partes - isso é feito no trabalho. O manuseio doméstico de adesivos envolve jogar fora aqueles que já foram concluídos - não muito bons, porque o progresso é visto pior.
Existem desvantagens nas placas scrum? Claro. Como qualquer placa.
Para começar, uso doméstico - rascunhos, adesivos de baixa qualidade, caligrafia ruim, sabotagem. Como resultado, tarefas perdidas e confusão no gerenciamento.
No quadro, o progresso não é muito visível. Em geral, para o sprint - sim. Hoje, ontem - não. Daí a necessidade de discussão diária.
Especificamente, o status das tarefas não é visível no quadro de scrum, se a vida é mais complicada do que “planejada” - “concluída”. O quadro Kanban parece preferível.
O conselho não permite o trabalho normal se a equipe estiver distribuída geograficamente. Portanto, placas eletrônicas aparecem.
A placa eletrônica, parece-me, é um sinal claro de sectarismo. Ela perdeu todos os benefícios do habitual, mas, por algum motivo desconhecido, ela continua a usá-lo. Provavelmente apenas porque é um quadro. Parte da metodologia.
Em geral, uma ferramenta é como uma ferramenta. Em certas situações - bom. Em alguns, é terrível.
O scrum funcionará sem uma placa? Fácil. E comprovado pela prática. E parece que, como o conselho não é um artefato obrigatório, será possível continuar chamando scrum-scrum.
Scrum master
Quem é esse papel milagroso? Como é isso?
Existem muitas opções. Por exemplo, um scrum master é como um treinador de esportes. Existe, digamos, um clube de futebol. O proprietário dos produtos existe um gerente que define os objetivos da equipe. Um treinador é aquele que ajuda uma equipe a atingir esses objetivos.
No ambiente de produção habitual, não há treinadores - se o clube de futebol funcionasse dessa maneira, o chefe simplesmente viria ao vestiário antes da partida e diria: "vá e ganhe". E quando eles perdem, ele ficaria feliz com a farsa. Ele expulsou alguém, ameaçou alguém, etc. Como uma fábrica.
E o treinador, como o scrum master, atua como provedor entre a equipe e o gerente. Obviamente, o treinador tem mais poder - ele não é um servo líder. Mas o resultado também é exigido dele de forma mais rápida e compreensível - ninguém esperará até que ele facilite alguém lá. O treinador, como o scrum master, entende como a equipe deve funcionar, ou seja, ele simplesmente define tarefas e explica como resolvê-las. Estabelece conexões, motiva, cria e mantém uma atmosfera, etc.
Outra analogia é o comandante de pelotão, algumas forças especiais. Este é um treinador de jogos. Executa tarefas juntamente com subordinados, resolve missões de combate da mesma maneira. Em seu tempo livre, ele supervisiona a preparação e o aprimoramento de habilidades, o desenvolvimento de novos equipamentos e o treinamento físico. Obviamente, ele trabalha constantemente com a equipe em termos de psicologia - ela motiva, apoia, ajuda. Por métodos peculiares, é claro, às vezes, mas o objetivo é um - a máxima eficácia de combate do pelotão.
Scrum master, comparado com esses caras, um freeloader. Para o resultado não é particularmente responsável. A falta de autoridade formal, ao que parece, é percebida como uma vantagem - ele é um líder-servidor, mas na verdade ele pode se tornar irresponsável. Alguém pode facilitar infinitamente, sem exercer nenhuma influência sobre o resultado? E quando eles os expulsarem, procure outra equipe para facilitar lá.
É possível alterar ou remover o papel de um scrum master? Claro. Por exemplo, combine essa função com o proprietário do produto. Eu sei que na Metodologia está escrito que é melhor não fazer isso - isso impedirá que o mestre facilite. Mas, por outro lado, acrescentará metas e responsabilidades claras. Quando o objetivo é compreensível e mensurável, a facilitação passa de uma porcaria opcional e incompreensível para um dever tangível e muito específico que afeta diretamente o resultado. Como um treinador ou um esquadrão.
É verdade que o significado de chamá-lo de scrum master se perde. Provavelmente será um líder de equipe - não esqueça que o "líder" é o líder. Um líder não é apenas uma bandeira em suas mãos, mas também trabalha com motivação, objetivos, capacidade de levar adiante, introdução de novos métodos de trabalho, treinamento de competências, etc. O driver do comando, em suma. E no sentido de desenvolvimento interno e no sentido de alcançar resultados.
Se você substituir o mestre por timlida in scrum, o que acontecerá? Isso não pode mais ser chamado de scrum - uma das principais funções foi descartada. E como isso afetará o resultado? E se não houver um scrum master? Se suas funções estão manchadas sob comando, como foi recomendado Belbin? , , . .
Total
, . , – , , . ? , , .
, , , , -. , , – , ! ! , !
, - , - . , . …
? , . , , . , . , , . , , .
? - , . - . - , . , , . , – , , . - . – .
Alguém pega os componentes de origem e os monta à sua maneira - conforme necessário em um projeto ou produto específico.Você pode fazer o mesmo com qualquer técnica. Eu queria escrever “é possível e necessário”, mas não imponha minha opinião - todo mundo decide, afinal.Quero terminar com uma citação de Goldratt. Este talvez seja o único dos luminares que desenvolveu alguns métodos, falando honestamente sobre a necessidade de mudança, adaptação, layout e, mais importante, entendimento dos princípios de funcionamento.Há uma diferença entre métodos práticos e os conceitos fundamentais nos quais esses métodos se baseiam. Os conceitos são gerais, métodos práticos são a adaptação de conceitos a um ambiente específico. Como já vimos, essa adaptação não é simples e torna necessário o desenvolvimento de certos elementos da solução. O que devemos lembrar é que essa solução é baseada nas premissas iniciais (às vezes ocultas) sobre um ambiente específico. Não devemos esperar que esta solução funcione em um ambiente em que essas premissas iniciais não sejam verdadeiras. Podemos economizar muito esforço e evitar decepções se formularmos cuidadosamente essas premissas iniciais.