Metodologia como Construtor: Instruções de Montagem

Apenas um modelo de brinquedo pode ser montado a partir do designer moderno da LEGO, por exemplo, um avião. Personalizar? Você pode trocar de lugar para piloto - isso é tudo personalização. Há cerca de 30 anos, do projetista era possível montar quase tudo, de avião a caminhão, com o mesmo número de peças que as modernas. Os criadores das metodologias mais modernas da infância jogaram o antigo Lego. Aqueles que agora usam metodologias já tocaram no moderno. A diferença nas práticas de engenharia é enorme.



Sob o corte, Philip Delgado ( dph ) falará sobre a abordagem de engenharia para formar uma metodologia. Todos os projetos e equipes são diferentes e os líderes são únicos. Ajustar uma metodologia para todos não funcionará - simplesmente não há. Teremos que contratar um designer e criar algo único a partir dele. Ao decifrar um dos melhores relatórios do TeamLead Conf , não haverá segredos secretos dos monges Shaolin - apenas banalidades verificadas pela experiência. Estamos aguardando um catálogo de detalhes da metodologia de desenvolvimento, o que procurar ao projetá-la e implementá-la e as regras para reconstruir metodologias. Para todas as idéias, exemplos reais são dados a partir da experiência de Philip. Durante sua carreira, ele tentou de tudo, desde o Visual Basic até o hardcore SQL, desenvolveu o maior mecanismo de apostas na Rússia e no Yandex.Money e agora trabalha em projetos Java carregados. Ela faz apresentações regularmente em várias conferências, incluindo o HighLoad ++.

Desafio

Alguns anos atrás, voltei a um projeto para criar um sistema de pagamento do zero. No início do projeto, não havia nada: sem desenvolvedores, sem processos, sem produções. Por onde começar o trabalho se não houver nada? A introdução imediata de algo é estranha e até estúpida. Portanto, o primeiro passo é entender o que é realmente necessário a partir da técnica.

Kent Beck, no final de seu livro sobre SCRUM, escreveu:

Todos os métodos são baseados no medo. Você está tentando desenvolver seus hábitos que o ajudarão a impedir que seus medos se tornem realidade.

Portanto, a primeira coisa a fazer é descobrir do negócio do que ele tem medo .

Normalmente, os negócios estão assustados com todo o projeto: assustador demais ou quase impossível . Tecnologicamente, ele tem medo de confiabilidade e segurança . No nosso caso, esses medos são justificados: o sistema de pagamento é contraparte, dinheiro e obrigações sérias.

Diferentes medos levam a diferentes metodologias. O medo de pagar demais leva à contratação de desenvolvedores baratos e fáceis de mudar - é o SCRUM. O medo do erro leva a GOSTs ou RUPs com vários documentos formalizados.

Os desenvolvedores também têm seus próprios medos: escrever sem suporte ou se sair mal . Infelizmente, quase ninguém está desenvolvendo metodologias sob o medo dos desenvolvedores. Apenas o XP menciona brevemente que os desenvolvedores têm medo de se sair mal, vamos tentar ajudá-los a fazer seu trabalho bem.

Além dos medos, a empresa deseja com que objetivos otimizar processos:

• rápido
• barato;
• previsivelmente;
• de maneira controlada;
• qualitativamente;
• escalável
• HYIPOVO.

Escolha qualquer opção e, talvez, algum dia, provavelmente, se nada acontecer e Marte convergir com a Lua em Capricórnio, você terá sucesso. A maioria dos desejos de otimização também se refere ao medo, apenas com uma expressão diferente: barato - sobre o medo de pagar a mais, controlado - sobre o medo de fazer a coisa errada, previsivelmente - sobre o medo, não há tempo.

Normalmente, uma empresa quer tudo de uma vez . Ao coletar requisitos, siga o pressuposto "o paciente sempre mente". Quando uma empresa quer tudo, ele mente. Tente entender o que a empresa realmente quer e tente vender para ele. Este não é o conjunto de habilidades mais padrão para um líder de equipe. Mas se você não souber descobrir os requisitos reais de uma empresa, precisará encontrar uma pessoa que possa.

Além dos desejos do negócio, você precisa descobrir as limitações significativas.

• Prazos apertados . No meu caso, não havia prazo final, por exemplo, as Olimpíadas, quando existem apenas duas opções: chegar a tempo ou não.
• Contrato estrito . Se você trabalha com uma empresa estatal, o contrato é algo que não deve ser violado. Tudo o resto pode ser feito como você deseja. Isso afeta muito a técnica.
• Envio regular . Você precisa implantar constantemente novos recursos, isso é importante para os negócios.
• Certificação: CB, PCI DSS . Essa é a principal limitação do design do sistema de pagamento. Os maiores riscos e preocupações estão relacionados à certificação de valores mobiliários, PCI DSS e outros.

São as limitações essenciais que distinguem, por exemplo, processos FixPrice de processos Tempo e Material.

Em nosso projeto do sistema de pagamento, como se viu, era assustador demorar demais e não ter medo, assustador por confiabilidade e segurança, mas é aconselhável fazer tudo rapidamente. Ao mesmo tempo, não há produções no início do trabalho, não há desenvolvedores, mas há especialistas na área de assunto (por exemplo, eu). Apenas blocos grandes e bastante independentes um do outro são claros: processamento, clientes, integrações, back office e front office.

Depois de descobrir os objetivos e as limitações, você pode começar a construir uma metodologia para entender como exatamente desenvolveremos o sistema desejado - pelo menos no primeiro estágio.

Estamos construindo uma metodologia para iniciar um projeto

Mas o que é uma técnica? O que queremos construir em geral? A resposta para as perguntas é uma bela foto de Alistair Cowber com vários pontos.



Três coisas são importantes para nós a partir desta imagem em primeiro lugar: pessoas - aqueles que fazem; processos - como eles fazem; e artefatos - o que precisa ser feito. Ainda não temos pessoas e processos, então vamos descobrir quais artefatos precisamos.

Começar com artefatos é um bom padrão ao projetar uma técnica , mesmo se pessoas e processos já existirem. É aconselhável iniciar o design dos artefatos “a partir do final”, com o valor entregue, daqueles artefatos que serão dispostos na venda ou enviados ao cliente. Por que é melhor assim - uma pergunta separada para um artigo separado. Se você souber a resposta - escreva nos comentários.

Escolhendo artefatos

Tomamos medos e entendemos quais artefatos os medos se aproximam.

O medo de "trabalhar em um projeto por muito tempo" é salvo por um plano de longo prazo e por um fato marcante . De medo de confiabilidade - autotestes . Por medo de "não fazer" - levante a posição "quase combate". Vamos demonstrar o progresso dos negócios . Assim, você pode ver imediatamente o que é e o que funciona e, em breve, publicaremos pelo menos algum resultado.

Formamos processos

Estamos no início do desenvolvimento, portanto não há tempo e razão para criar processos formalizados complexos. Por isso, simplificamos todos os processos e focamos em facilitar a comunicação .

Como resultado, existem exatamente dois processos: descobrir uma grande tarefa - pensar em uma solução e verificar o que foi concluído . Esses processos são longos, de pesquisa e pouco conectados entre si, o que leva a práticas de desenvolvimento apropriadas.

Para acelerar, contratamos funcionários legais . Mas especialistas legais não recorrem a um sistema de pagamento desconhecido para qualquer pessoa no mercado. De alguma forma, deu certo, mas a solução para esse problema é uma discussão separada. A propósito, escreva nos comentários como você o resolveu em casa e você decidiu?

---

Retiro: sobre a contratação

Ao contratar, eles geralmente analisam as descrições de cargos padrão e as gradações usuais dos níveis de candidatos, traçando um mapa das funções da equipe:



Porém, descrições padrão não nos permitem entender a necessidade de uma pessoa específica em um projeto. Normalmente, tento manter vários mapas diferentes na minha cabeça para diferentes projetos, destacando diferentes papéis e competências importantes para o projeto. Por exemplo, tecnológico .

Solucionador de problemas . Essa é uma pessoa que pode mergulhar em um código legado com algum tipo de bug sem documentação e testes por 2 dias e criar a frase: "Nesta linha, substitua + por - e ele funcionará".

E vai funcionar. Pessoas como o trevo de quatro folhas são raras. Infelizmente, o mercado não valoriza essas pessoas, é difícil explicar aos negócios que uma solução de problemas é extremamente necessária e merece respeito e um grande salário. Como resultado, a maioria deles vai para líderes de equipe, e esse recurso está esgotado. Resta apenas promover a utilidade de tais especialistas, e talvez depois de algum tempo a situação mude.

Integrador Essa é uma pessoa que sabe como criar algo integral a partir de vários componentes, bibliotecas e módulos. Ele não é mais um programador XML, mas alguém que entende a estrutura interna. Essa é uma habilidade extremamente rara, que geralmente é muito procurada em desenvolvimento real.

Guru: Framework, Segurança, Banco de Dados, DevOps . Tudo está claro sobre o guru - são pessoas que podem ser contatadas com perguntas sobre tópicos relevantes.

Além disso, também existem papéis "não tecnológicos", um mapa social de papéis. Um gerador de idéias é uma pessoa que pode criar alguma coisa. Crítico - quem pode criticar construtivamente. Experiente - uma pessoa experiente que pode dizer: "Tentamos e acabou tudo sem sentido". Um perfeccionista é uma pessoa que quer que tudo seja bom. Este é um papel importante. Se não estiver lá, geralmente tudo rapidamente se deteriora, porque não há quem lhe diga: "Você entendeu de novo, tudo está errado - vamos consertar!"

Se alguma função no mapa de funções do seu projeto específico não for preenchida, a equipe precisará cumpri-la.

Portanto, pense em quem escolher e lembre-se de que entrevistas diferentes são adequadas para diferentes papéis e posições . Com um veterano experiente, a entrevista será rápida - basta descobrir o que ele estava fazendo. Você geralmente precisa conversar com um júnior por um longo tempo, executar tarefas de teste e descobrir o que ele pode fazer.

Quanto maior o nível do candidato, menor a entrevista.

De que outras pessoas você precisa?

Um extrovertido é aquele que deseja e pode se comunicar ativamente fora do desenvolvimento. Como não temos produções exatas, precisamos de algumas pessoas que possam entender os usuários finais, incluindo os internos, por exemplo, nossos contadores. Um extrovertido não tem medo de falar, descobrir as necessidades de tais "não programadores" incomuns - e existem poucas pessoas assim.

Crítico - primeiro preciso de um crítico de mim. Essa é a pessoa que criticará minhas decisões. Sem críticas, tenho medo de estar carregando algumas bobagens. Quando eles me criticam, tenho que pensar seriamente nos argumentos, e acontece que isso não é totalmente bobagem.

Especialista em problemas monótonos : relatórios, integrações. Eu tinha certeza de que teríamos um grande número de relatórios no projeto. Seis meses para escrever relatórios contábeis e não enlouquecer - uma habilidade rara. Dispersar essa função entre pessoas diferentes também é inconveniente, então eu precisava de um especialista em problemas monótonos.

Não se importe . É uma pessoa que não se importa com o que fazer, mesmo que pague. Esse papel é extremamente importante para o projeto, porque havia tarefas diferentes: monótonas, mas complexas, insanamente interessantes ou não relacionadas à nossa experiência anterior, devido ao requisito externo assustador.

Vamos voltar ao nosso projeto. Não precisamos do Solucionador de problemas, porque o legado ainda não existe. Precisávamos de um integrador e um conjunto de gurus. O Security Guru é realmente cultivado por dentro.

O Database Guru foi terceirizado com sucesso. Eu realmente gosto da idéia de “assumir competência no banco de dados em algum lugar externo” - encontrar essa pessoa na equipe geralmente não é realista se você não tem uma empresa enorme e são necessárias pelo menos cinco pessoas para oferecer suporte a um importante banco de dados 24 * 7. Também terceirizamos o DevOps Guru, mas não com tanto sucesso, esse papel é mais difícil para artistas externos.

Os papéis sociais também foram preenchidos (e houve até alguns críticos).

---

Prática

Então, descobrimos os artefatos necessários, descobrimos o que as pessoas precisam e quais requisitos do processo. O que aconteceu, como exatamente organizamos o desenvolvimento:

• Planejamos grandes traçados. Como não temos produções, é impossível planejar com mais precisão. É necessário criar uma conta pessoal em três meses - e é tudo. Realizamos planos no Confluence.
• Cada um é um pouco de analista . Não há produções normais e a competência na área de assunto é mantida por pessoas que não sabem escrever produções. Ninguém os ensinou, você precisa remover essas informações. Mas temos "extrovertidos".
• Um rastreador não é necessário . Temos apenas 20 tarefas principais para o projeto - por que iniciar um rastreador?
• Uma filial no VCS. No estágio inicial, não é necessário um trabalho complexo com controle de versão.
• Os processos são aproximados . Ainda existem poucas pessoas, não há comunicações e problemas, e o projeto em si é instável. Não há necessidade de descrever nada em detalhes.

Quando as pessoas falam sobre métodos semelhantes, não muito formalizados, costumam dizer simplesmente: " Temos uma agilidade".

Também adquirimos o clássico "We have Agile". Mas eu entendi claramente por que essa técnica e por que era "ágil", e não algo mais específico e complexo. E eu (e negócios), essa técnica era bastante adequada.

Um leitor atento perceberá que, ao projetar a metodologia, esquecemos dois medos importantes: o medo pela segurança e a necessidade de certificação . Vamos tentar descobrir como lidar com eles.

---

Digressão: Cowburn Matrix

Em 1980, Alistair Cowbern desenhou uma matriz da complexidade do projeto .


Vertical - a criticidade do projeto . O que pode ser perdido em caso de erros significativos: da perda de conforto do usuário à perda de vida do usuário, por exemplo, se projetarmos software para usinas nucleares. Horizontal - o tamanho da equipe . Tamanho afeta o número de comunicações. A crítica está nos detalhes dessas comunicações. No total, afeta a complexidade do processo.

Alistair argumenta que mover-se para a direita ou para cima em cada quadrado complica muito e aumenta o custo do desenvolvimento. Isso é lógico - mais pessoas exigem mais custos de comunicação. Se forem necessários relacionamentos mais formais, serão necessários mais custos de comunicação. I.e. quanto mais longe, mais recursos são gastos em tarefas e perdas improdutivas.
A propósito, como um terceiro eixo, a Alistair otimiza para diferentes desejos de negócios.

Vamos tentar colocar nosso sistema de pagamento nessa matriz. A matriz é muito conveniente como modelo para entender a complexidade estimada do seu projeto, do seu sistema.

Temos um sistema de pagamento, o que significa que, com uma pitada, perderemos algum dinheiro do usuário. É claro que isso é desagradável, mas não leva a um aumento acentuado da complexidade.

Mas temos quase um banco e, em alguns casos, em caso de violação dos padrões ou requisitos do Banco Central, é possível obter uma licença do banco. Isso já é uma perda de muito dinheiro, quase fechando um negócio, muito triste.


Como temos uma equipe de cerca de 20 pessoas, entramos na praça E30 . Isso é ruim, porque um bom exemplo da técnica nesse quadrado será o Rational Unified Process completo - processos formais, muitos documentos, declarações claras. 20 a 30 pessoas não conseguem lidar com isso. Você precisa contratar 50, e a dificuldade crescerá como uma bola de neve. Sistemas semelhantes em tais metodologias são geralmente escritos por centenas ou mais pessoas.

O que fazer Problemas? Não, nem todo o projeto é igualmente crítico . Temos apenas algumas peças críticas.

• Cheque para lavagem de dinheiro - pelo qual o Banco Central bateu forte na cabeça.
• Trabalhando com cartões bancários - para os quais os sistemas de pagamento mundiais são difíceis de acertar.
• Armazenamento de dados pessoais - para isso, o estado bateu forte na cabeça.

Vamos destacar módulos críticos individuais . Escreveremos práticas especiais para trabalhar com essas partes do nosso projeto para elas: uma auditoria completa do PCI DSS para cada confirmação , boa documentação, uma revisão de código dupla, um processo de cálculo especial e muito mais. Deixe apenas desenvolvedores seniores escreverem essas partes do projeto.

Mas essas partes são poucas. Portanto, a matriz Cowbern para o projeto é a seguinte.


Para diferentes partes do projeto, haverá uma complexidade diferente da metodologia, um conjunto diferente de práticas. O mais difícil e terrível são três pessoas . Lógica de pagamento - pessoa 8. Quaisquer outras tarefas menos importantes, como acima de tudo, como um sistema de ajuda ou layout de um site para back office, no qual o erro não é fundamental, são tratadas principalmente por pessoas. Mas existem processos que podem ser os mais fáceis e mais informais.

Um grande projeto complexo pode usar diferentes conjuntos de práticas para seus vários componentes.

Essa é uma das grandes vantagens da arquitetura de microsserviço - a capacidade de prescrever uma imagem na qual serviços diferentes respondem não tanto a técnicas diferentes, mas a práticas diferentes dentro da mesma técnica. Ao mesmo tempo, coisas importantes permanecem comuns: planejamento, artefatos, uma abordagem comum à interação.

---

Resumir

Descobrimos os requisitos para a metodologia : objetivos e limitações. Identificou os elementos básicos : processos, artefatos e pessoas. Eles descreveram práticas : como implementar processos, requisitos para artefatos, que tipo de pessoas são necessárias.

Este é um esquema clássico de projeto de engenharia: temos requisitos, depois especificamos a arquitetura e depois a programamos.

Projetar métodos é uma prática de engenharia, um processo de engenharia que não difere da programação de um módulo.

, .

«?»

.

: , ?

«» — , . - « », . «» , , . , .

, . , , .


— , , . — — , . , , .

IDE Driven Development

JetBrains — ! , IDE.

, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .

, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .

. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .

, — , . : , ,

, : . . .

• . , , .
• . , , , , - .
• . 3 -, , , , . , .
• . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .

.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .

— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?

Planning poker . « » — . , , . Planning poker , .

. :

• ;
• product owner ;
• ;
• .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?

, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

• ;
• ;
• .

.

: , , .

Jira , « » ? - -? ?


, , . , junior product manager — , , , .

, — . . , . — !


Revise antes do código. Eu ouço regularmente como uma pessoa foi responsabilizada por um grande recurso, mas ele fez algo errado e precisa ser refeito. Vamos revisar o código antes de escrevê-lo . Antes de escrever o código, um funcionário da Jira descreve um plano para resolver um problema em duas linhas ou dois parágrafos de texto. A revisão desses dois parágrafos é rápida e fácil, mas erros globais são detectados desde o início, especialmente se você tiver um líder de equipe ou um arquiteto.

Além disso, essa prática permite que o líder da equipe ou o arquiteto esteja ciente de todas as alterações em um grande projeto. Ele não lê um código torto, mas dois parágrafos sobre o que geralmente está acontecendo no sistema e rapidamente pega as pessoas pela mão. Isso é especialmente verdadeiro para partes críticas de um produto, como a lógica de pagamento.

Como mudar a metodologia e não matar o projeto

Então, em 9 meses, mudamos três métodos: “We have Agile”, SCRUM de um dia e Kanban. Como garantir que você não perca recursos? Como mudar a metodologia e não matar o projeto ao mesmo tempo?

Conseguimos alterar os métodos para que alguns desenvolvedores não notassem as alterações. Ninguém lhes falou sobre isso, eles funcionam, e a metodologia é diferente!

O principal é entender quando mudar.

Se você entende o porquê. Muitas vezes, os métodos são alterados, porque chegou um novo diretor técnico que deseja refazer tudo. Esta é uma má razão. Melhor pegar o antigo e renomeá-lo - tudo, a técnica é diferente, é melhor. Se você não pode responder à pergunta por que, é melhor não mudar. Eu geralmente gosto de perguntar o porquê.

Se você pensou "como". Se você entender como vai do ponto A ao ponto B, mude. Até você criar - não há necessidade.

Se satisfeito "quanto". Alterar uma técnica é quase sempre um procedimento caro . Se você se sair bem, a substituição custará vários meses-homem dos custos dos líderes de equipe, RH e personalizadores Jira. Se estiver ruim, alguns meses de todo o trabalho da empresa. Vi muitas vezes a transição do Kanban para o SCRUM e depois para trás, cada uma custando um mês de trabalho durante todo o desenvolvimento. Se você não estiver pronto para esses custos - não inicie.

Preparação

Começamos com antecedência. Para uma equipe pequena, a preparação começa um mês antes do turno.

Desenhamos histórias de usuário. A mesma abordagem que no design do aplicativo. Você usa histórias de usuário ao descrever requisitos, espero?

Por exemplo:

• História do usuário : como desenvolvedor, desejo encontrar minha próxima tarefa e prosseguir com sua implementação.
• Critérios de aceitação : como desenvolvedor, posso ver todas as minhas tarefas atuais e avaliar a urgência e a prioridade das tarefas.
• Exceções: se não houver tarefas, o desenvolvedor sabe a quem perguntar.
• Links: cenários para preparar um plano de curto prazo, que mostra onde conseguir a próxima tarefa.

Dessa forma, realize todas as suas principais atividades que surgem na sua metodologia e escreva Histórias de Usuários.

Como o gerente pode ver a eficácia do plano? Como um gerente de topo entende que está tudo bem? Escreva histórias de usuário e adicione detalhes: crie um painel para usuários e gerentes de topo - os Critérios de aceitação são aprovados, está tudo bem.

Quando você já tem histórias de usuário, pode começar a transformá-las em práticas.

Substitua todas as funções por pessoas reais . Uma pessoa real sempre sabe mais do que um papel. Então você encontrará imediatamente o gargalo. Por exemplo, todas as suas histórias de usuário usam uma pessoa específica, embora ela esteja simplesmente usando chapéus diferentes, em funções diferentes. Isso é ruim - descubra como descarregá-lo.

Reduza artefatos e comunicações . Se houver muitos deles - cada história de usuário sugere seus próprios artefatos e comunicações - algo precisa ser feito com isso.

Procure por gargalos . Quando existe um mapa dessa história, você pode começar a fazer algo com ele.

Escolhendo ferramentas

A ferramenta identifica recursos . Existe uma opinião popular de que as ferramentas não são importantes ou que qualquer ferramenta é adequada - isso é um absurdo.

Se a ferramenta for inconveniente, ela não será usada.

Além disso, os vendedores sempre mentem. Se eles dizem que sua ferramenta pode executar "1, 2 e 3", provavelmente não podem executar "1", "2" às vezes e "3", mas é muito ruim. Certifique-se de verificar tudo.

Estamos discutindo ativamente

Sem uma discussão ativa da técnica, você pode esquecer algumas funcionalidades importantes, histórias importantes do usuário e ofender alguém. A pessoa ofendida sabotará a implementação da metodologia : ele foi inicialmente ofendido, esquecido, ninguém falou com ele o que ele precisava.

Nesta fase, as pessoas podem mostrar experiências anteriores negativas com a introdução de outras técnicas.

- Ah, bobagem! Nós já tínhamos isso e nada aconteceu.

Para evitar isso, colete as dores das pessoas, pergunte o que está errado. Grave e demonstre com precisão o que você gravou - para que a pessoa entenda que a ouviu.

Não repita experiências negativas . Retrospectiva não foi? Agora, este é um "bolo de sexta-feira". As paradas às 7 da manhã não foram? Agora isso está "cobrando". Dar nomes diferentes às mesmas práticas para que as pessoas não associem suas experiências negativas passadas a elas frequentemente ajuda.

Infelizmente, não há soluções universais. Construa sobre sua situação.

Implementação

O principal valor no gerenciamento de TI é o respeito.

Economizamos o tempo de outra pessoa . Se você precisar transferir tarefas de um sistema rastreador para outro - escreva um script, contrate o Mechanical Turk para fazer isso por você. Resolva esse problema para que o desenvolvedor não transfira todas as suas tarefas de um sistema para outro por uma semana - isso é uma manifestação de respeito.

Ajudamos na transição . Se introduzirmos uma nova prática, sentamos ao lado de uma pessoa e o ajudamos a entender o novo sistema. Preparamos as instruções com antecedência.

Nós descrevemos ações específicas. Criamos uma documentação muito específica, de acordo com nossas histórias de usuário: “Precisamos assumir uma nova tarefa. Como fazer isso está escrito na documentação - você abre uma e outra página no wiki, e lê mais ou menos. ”
Introduzimos gradualmente - nem todas as práticas de uma só vez . Nossos desenvolvedores não notaram uma alteração nos métodos, porque não implementamos todas as práticas ao mesmo tempo. Quando queríamos alternar suavemente de um SCRUM de um dia para outra coisa, eu não fazia retrospectivas todos os dias, as tarefas pareciam um pouco mais longas, as reuniões diárias da manhã eram silenciosamente migradas para um stand-up mais padrão. Pareceu às pessoas que tudo estava acontecendo gradualmente. Então a prática mudou bastante significativamente. Sobre algumas coisas, é claro, eu lhes disse: "Agora mudaremos um pouco o processo de trabalhar com Jira - agora será assim".

Os caminhos pisam por conta própria . Não prescreva imediatamente um fluxo de trabalho rígido - deixe as pessoas encontrarem os caminhos. É conveniente que eles transfiram a tarefa no rastreador de estado para estado, mesmo que eles a transfiram, e então você a corrigirá. Imediatamente prever o que será conveniente é difícil e proibir a transição solicitada é fácil. Mas então você tem que sofrer por um longo tempo para recuperar tudo.

BEIJO . Simplifique, pelo menos no começo. Não complique demais.

Suporte

Reservamos recursos antecipadamente para o processo de transição, porque é caro . A transição de uma técnica para outra é muito dinheiro. Reserve seu tempo e tempo para as pessoas que editarão erros no seu rastreador, no seu fluxo de trabalho, nos procedimentos de cálculo. Se não houver recursos e, ao mesmo tempo, algum tipo de pressa, tudo sairá mal.
Corrigimos os erros o mais rápido possível .

Conclusão

Os projetos são diferentes, as pessoas também - todo mundo precisa de técnicas completamente diferentes ! Todas as famílias felizes são igualmente felizes, todas infelizes - à sua maneira. O mesmo acontece com os projetos - não há dois idênticos.

Criar uma técnica é uma tarefa de engenharia. Exatamente o mesmo que programar e projetar módulos do sistema. É assim que você aborda. Você sabe resolver bem os problemas de engenharia - portanto, use todo o seu conhecimento nesta nova prática.

A mudança de metodologia é um projeto SMART clássico . Use tudo o que você sabe sobre gerenciamento de projetos: defina critérios de sucesso, verifique no final da conformidade com as tarefas definidas, lembre-se do tempo limitado etc.

Meu manifesto pessoal

As pessoas são mais importantes que os processos , porque os processos precisam ser feitos para as pessoas. Se a empresa tem uma idade média de 50 anos e eles vieram das forças armadas, e você está tentando implementar rapidamente o Kanban imediatamente, provavelmente não decolará. As pessoas estão acostumadas a outra coisa.

A principal vantagem de um programador é sua preguiça. Crie processos para que as pessoas gastem menos tempo com eles, e os desenvolvedores são os primeiros a executá-los. Se as pessoas não procuram implementar processos, elas não entendem o porquê.

Acontece que algumas práticas são difíceis de implementar, pois são difíceis de entender. Às vezes, é mais fácil mudar a prática, talvez não corresponda às suas tarefas ou ao seu pessoal. Como último recurso - mude as pessoas, mas é mais caro do que mudar as práticas.

O resultado é mais importante que hábitos . O hábito mais terrível é o hábito de ouvir sobre uma nova ferramenta, trazê-la para casa e usá-la imediatamente. O culto à carga é um hábito terrível de combater. Mas o medo de mudar algum tipo de prática porque "sempre fizemos isso", mesmo que já seja ineficaz, também é prejudicial.

E, às vezes, em geral, as tarefas são tão diversas que os hábitos se tornam perigosos. Por exemplo, ao se comunicar com pessoas vivas.

A persuasão é mais eficaz que as ordens . A melhor motivação é entender o significado do seu trabalho e compartilhá-lo. Os desenvolvedores gostam de facilitar a vida dos usuários, economizar dinheiro das empresas e simplificar suas vidas - então, conte-lhes sobre os objetivos de suas ações. Aprenda a convencer.

Todos os três princípios são minha imagem pessoal do mundo. Se você tiver outros pressupostos, provavelmente precisará de uma metodologia diferente para a construção de técnicas.

No comitê do programa TeamLead Conf , também estamos mais familiarizados com o antigo Lego, por isso selecionamos cubos no programa a partir do qual você mesmo pode criar os processos que mais lhe agradam. Para a conferência de outono em São Petersburgo, um conjunto de 15 partes já foi montado, mas ainda estamos aceitando pedidos de relatórios - escrever .