Se você não pode descrever a estrutura da sua organização, departamento, trabalho em geral, significa que você está fazendo isso de forma ineficiente.
Eficiência e transparência nunca são a mesma coisa. Você pode fazer de maneira transparente coisas ineficazes e efetivamente coisas opacas.
Construir uma estrutura de trabalho é um processo complexo e individual, com um toque de audácia. Porque precisamos não apenas de coragem e reflexão (“trabalhamos ineficientemente, por quê?”), Mas também da capacidade de fazer pilhas graciosas.
Montes graciosos são a chave para criar estruturas. Parece que "não precisamos, trabalhamos e tudo bem, por que precisamos de camadas extras", mas na verdade - uma camada ponderada elevará seu trabalho a um novo nível. É um monte, mas é elegante. Algo como injeção de dependência ou uso de photoshop em vez de tinta.
Se agora você pensou "não, tudo é eficaz conosco" - nem espere. Ineficaz. Mesmo que você absolutamente, completamente, nunca fique preso em seu trabalho, simplesmente vive em ilusões. Isto não é possível. Eficiência é um processo, não um dado. E uma pessoa específica deve fornecer esse processo. E outros - para apoiar. Não porque "eles disseram", mas porque todos ficarão bem - todos trabalharão como se sentirem confortáveis e eficazes.
Em resumo, chamamos nossa criação de montes graciosos de "o pássaro insolente das estruturas" ou "fluxo de desenvolvimento". Agora vamos descrevê-lo e também comeremos alguns de seus cães em disputas.
Por que é necessário
O fluxo de desenvolvimento foi projetado para cumprir quatro obrigações:
- Estruturação de processos
- Soluções para problemas
- Dá feedback
- Fornece uma linguagem de interação universal
O Development Flow é uma ferramenta de criação de
sistemas .
O sistema
O sistema consiste em elementos, os elementos são diferentes e a “corrente” passa por eles - o processo de trabalho. Em TI, "falar" é o código, design, documentos e outras coisas com as quais trabalhamos.
Faltam sistemasSe você não sabe em que estágio do seu Fluxo Privado está atualmente (por exemplo, “desenvolvendo um recurso”) e não sabe em que estágio está no Fluxo Geral (por exemplo, o quarto, após o Dono do Produto, Scrum Wizard e Designer) e qual o estágio deve ir atrás de você, quais são os critérios de retorno dele e muitas outras coisinhas ainda ...
Ou, se você souber, mas, para o seu trabalho, o gerente de projeto deve sentar-se ao seu lado e lembrá-lo do que exatamente você deve fazer naquele exato momento (não se afaste do monitor e dos seguintes programas) ...
Ou se você apenas sente que é ineficaz ...
... então provavelmente você não tem um sistema.
O sistema está inoperante corretamenteNem todo o ouro que brilha. Nem todos os V12 estão sob o capô. E o mais importante - nem todo motor funciona corretamente, mesmo se estiver viajando (olá, amada indústria automobilística).
É importante ter um sistema funcionando corretamente, porque é nossa confiança. Em seu trabalho, no trabalho de todo o sistema. Você encontrará imediatamente problemas, a maioria dos quais você pode resolver.
Um motor em funcionamento tem um som. Ele é rítmico, agradável. Se houver um problema, é ouvido pelo ouvido sensível do mestre. Ranger, espirrar, perturbação do ritmo, bater. Destrói o motor devagar ou rapidamente, e a "máquina comercial" quebra quando você toma uma hipoteca em uma nota de três rublos dentro do ringue.
No sistema de trabalho das pessoas, esses ruídos - violação de prazos, descontentamento, vazamento de pessoal, baixo tom de funcionários, lançando problemas para o próximo departamento - e muito mais. Um bom gerente anda pelo escritório com localizadores supersensíveis espalhados em vez de ouvidos. Ele conhece a tempestade iminente, sente que a pressão caiu. Ele ouve todos os suspiros curtos e percebe seus olhos retraídos. Ele é o sistema.
Fluxo de desenvolvimento: sistema
O sistema DF implica duas seções - Fluxo Geral (funcionamento do sistema como um todo) e Fluxo Privado (funcionamento de suas partes individuais).
Fluxo total
O sistema consiste em elementos combinados em uma estrutura para atingir o objetivo pretendido.
O objetivo em TI é lançar o produto no momento certo, com a qualidade certa. Elementos do sistema - participantes do processo: proprietário do produto, gerente de projeto, Scrum Master, desenvolvedor, designer, testador, redator técnico ... Esses são todos os elementos, e nem todos estão presentes o tempo todo. Às vezes, os papéis são combinados. Você precisa destacar seus elementos.
Você precisa destacar seus elementos. Escreva-as e desenhe sua primeira seta de fluxo. Isso é chamado de fluxo comum.
Proprietário → SM → Designer, Desenvolvedor → Testador → Escritor técnicoA tarefa é combinar os elementos em uma estrutura e mostrar quais interações profissionais são possíveis. Não profissional - que o designer e o proprietário do produto morem juntos, não é necessário. São apenas funções necessárias. O proprietário não deve interagir com o Designer ou Desenvolvedor. Somente Scrum master. Somente Mestre Scrum.
Quando destacamos as interações, essas setas, devemos mostrar o que o Primeiro fornece e que o Segundo o retorna como feedback. Então o sistema começa a viver.
Proprietário → fornece uma descrição da tarefa → SMA SM reformulará tanto o Proprietário quanto o restante. A avaliação da tarefa - aproximada - se alinhará. Mas a tarefa do SM - a partir de uma descrição simples, aplicando uma pilha graciosa, para fazer SUFFICIENT_DESCRIPTION. Ele discutirá e distribuirá partes deste ANTES com a equipe.
SM → fornece peças para → Designer e desenvolvedorO DO inclui um esquema, todos os seus estados possíveis e muito mais (não quero acumular ainda). Todo mundo recebe sua parte. Nem sempre ao mesmo tempo. Normalmente, o Designer é um sprint à frente do Desenvolvedor.
Designer e desenvolvedor em um comício diário, enquanto o feedback da SM retorna a ele sua visão da tarefa. Garantimos que entendemos tudo da mesma maneira. Demora 25-28 segundos. E economiza horas e semanas.
Desenvolvedor → após seu fluxo particular (mais sobre isso mais tarde), passa o código → para o TestadorO desenvolvedor fornece o código, o testador examina sua parte do TO e cumpre seu fluxo. O Feedback do testador é para SM → "positivo", isto é, como ele entende a tarefa, e para o desenvolvedor → "negativo" - somente se estiver quebrado.
O desenvolvedor não tem idéia de que seu código é testado até que haja problemas.
Eu acho que o
General Flow está corretamente formulado da seguinte maneira. A primeira dá para o segundo, o segundo processo, retorna Feedback "positivo" ou "negativo", avança no fluxo Geral. Feedback positivo é a crença de que tudo funciona como pretendido; feedback negativo - mostra onde e o que deu errado.
Fluxo privado
Neste artigo, descreverei o fluxo privado de Owner, CM e Developer, como um exemplo. Se você estiver interessado, postarei o restante do trabalho.
O dono
Objetivo principalDeclaração do problema (backlog ← descrição), leia o feedback
O que vem a seguirQuando as tarefas são formuladas pelo Proprietário, o SM as descreve → leva a Sufficient_Description.
Feedback deO SM reescreve a tarefa e discute os principais marcos rapidamente com o Proprietário, incluindo prazos.
Interage comSM
SMObjetivo principalAceite a tarefa, traga-a para a forma de Descrição Adequada, avalie as tarefas, distribua, leia o feedback
O que vem a seguirDistribui tarefas aos funcionários
Feedback deDesigner, desenvolvedor, testador, redator técnico
Interage comProprietário, Designer, Desenvolvedor, Testador, Escritor Técnico
Desenvolvedor
Objetivo principalDesenvolvimento de recursos e correções de bugs. No General Flow, ele recebe tarefas da SM e, com a ajuda de sua atividade profissional, as implementa (fluxo git, fluxo rebase, fluxo de recursos, etc.).
O que vem a seguirEle pode fazer sugestões de modificações, discutindo-as com a SM e o Designer.
Feedback deCM, Designer, Testador
Interage comSM, pelo Designer, (é importante - ele não pode gerar interação com o Testador)
(Nesta descrição, eu realmente não gosto do esquema,
esta é a minha apresentação com uma descrição diferente, e tenho mais prazer em trabalhar com ele. Mas estou explorando opções, tentando, aprimorando, e ficou assim.)
No resíduo seco
O fluxo de desenvolvimento resolve os seguintes problemas:
- Estruturação de processos
- Resolução de problemas
- Dá feedback
- Fornece uma linguagem universal sobre a qual ainda não dissemos uma palavra.
As principais vantagens - todos sabem o que está acontecendo, o que fazer e não são carregados com trabalho desnecessário.
O Scrum Masters tem muito trabalho (Timlid, CTO). Mas deve ser assim, ele é o principal trator nessa abordagem.
apresentação muito curta e secaFique no escuro ou crie estruturas ousadas. Oferecemos nosso pássaro, mas é grande e isso é apenas parte, na primeira aproximação. Precisamos de mais do que qualquer caso. Portanto, eu pergunto a você - pendure todos os cães em mim, quero desvendar um tópico melhor.
(Eu tive que cortar muito para limitar o tamanho do artigo pelo menos um pouco. Por causa disso, eu poderia perder alguma coisa, mas vou corrigi-la rapidamente, escrever.)