Dado: Uma empresa que usa a estrutura escalável do Agile (SAFe) para escalar o desenvolvimento do Agile em toda a organização; 10 equipes de desenvolvimento, combinadas em uma equipe grande (Agile Release Train, de acordo com a terminologia SAFe), fornecendo um produto comum; a necessidade de um planejamento trimestral de dois dias (PI Planning) para determinar o plano de trabalho das equipes de TI para os próximos 3 meses *; três escritórios de desenvolvimento, a distância entre os mais distantes excede 6 mil quilômetros, com uma diferença correspondente de 5 horas de tempo de trabalho; experiência anterior em planejamento envolvendo a presença física de colegas-chave na mesma sala e o uso de quadros analógicos / quadros brancos / marcadores / notas adesivas.
* A construção pesada "Plano de trabalho da equipe de TI para os próximos três meses" ameaça aumentar seriamente o volume do texto; portanto, no futuro, pretendo escrever simplesmente - "comentar". Nesse sentido, elabore e adote um plano de trabalho - “comprometer-se”.
Por que isso é necessário?
1) Fadiga dos métodos de trabalho analógicos. Enquanto as naves espaciais abrem espaços abertos e Elon Musk cava túneis, nós, especialistas em TI, escrevemos persistentemente com marcadores em pedaços de papel pegajosos e os esculpimos nos quadros - isso é uma espécie de dissonância. É assim que nosso comentário foi há algum tempo:
Sim, este é um pedaço de papel com cerca de 2x5 metros de tamanho e, após o planejamento, cada pedaço de papel deve ser transformado em tarefa no Jira ...
2) O cansaço dos colegas nômades. Apesar de nossa sede estar localizada em um país acolhedor e acolhedor, para minha surpresa no ano passado, descobri que eles não estavam nada felizes com uma vida nômade e meus argumentos no estilo de "vamos nadar no mar, relaxar sob o sol ", que tive a imprudência de expressar, não foram muito calorosamente recebidos - nem todo mundo está pronto para viagens de negócios frequentes, suas famílias nem sempre aceitam isso, alguém não reage muito bem a vôos frequentes.
3) Conectando mais colegas de TI ao processo de planejamento. Como está claro no parágrafo anterior, não podíamos dar ao luxo de enviar todo o escritório para o planejamento; portanto, enviamos apenas os Escolhidos, excluindo assim o restante do processo, o que não agregou vantagens à moral geral.
4) Otimização de custos financeiros. Sim, este é um momento sensível - existem muitas pessoas-chave, e transportá-las para frente e para trás quatro vezes por ano é uma sobrecarga.
Parte zero ou carteira de pedidos em atraso
E tudo começa muito mais cedo - para trabalhar proveitosamente no comentário durante o planejamento, é necessário que haja algo a ser comprometido. Para garantir isso, eu tenho que “carregar” os proprietários do negócio com trabalho nas iniciativas propostas (ou, na terminologia da SAFe, Epicam, mas usarei o termo familiar para mim) o mais cedo possível. Idealmente, esse processo deve ser completamente divorciado da natureza cíclica do planejamento trimestral e seguir seu próprio caminho kanban. Como base, adotamos o portfólio da SAFe Kanban:
Temos um projeto separado do JIRA com três tipos de tarefas: épicos, iniciativas de negócios e iniciativas de arquitetura; bem como o quadro Kanban correspondente. O algoritmo para o proprietário da empresa da iniciativa é simples: ele adiciona a tarefa a esse projeto e, por padrão, se enquadra no Backlog - esse é o primeiro status do nosso Kanban -
Funil:
Ele armazena iniciativas que ainda não estão prontas para revisão. O proprietário da empresa está trabalhando no conteúdo da iniciativa até se sentir pronto para a próxima etapa. O mínimo necessário nesse estágio são os campos Declaração de Problema, Resultado Desejado e Medida de Sucesso preenchidos, além de uma apresentação um pouco mais detalhada, mas simples e clara. Nesse estágio, é importante deixar de mencionar soluções técnicas e focar nos parâmetros de negócios. Quando todos os dados são coletados, o proprietário move a tarefa para o próximo status -
Revisando.Realizamos uma revisão semanalmente, tanto para iniciativas de negócios quanto para arquiteturais. Idealmente, esta é uma apresentação de cinco minutos com respostas subsequentes às perguntas. O resultado da revisão é uma decisão sobre o destino da iniciativa. Ela pode:
- volte ao backlog para revisão
- abolir sem chance de vida futura (para isso, uso um status desatualizado separado, oculto no quadro Kanban)
- obtenha aprovação e vá para a próxima etapa - Analisando.
Nesta fase, estamos aplaudindo! - podemos atrair funcionários de TI: analistas, arquitetos, leads, qualquer pessoa. Por "nós", eu me refiro como um engenheiro de trem de liberação, mas, no caso ideal, proprietários de empresas que já adquiriram alguma experiência e a independência necessária para atrair as equipes certas e iniciar o processo de análise por conta própria. Estou escrevendo sobre um caso ideal, porque o nível de auto-organização de nossos colegas é flutuante e, em alguns casos, eles pedem ajuda na forma de um facilitador especialmente designado, mas tento me afastar um pouco dessa prática.
O objetivo desse estágio é a análise preliminar ou, como chamamos, a pré-descoberta. Na saída, devemos obter o mínimo que nos permita comprometer: as soluções propostas, riscos e dependências, requisitos não funcionais e de infra-estrutura, mapas de usuários, esquemas de arquitetura. Além disso, pedimos às equipes que façam uma avaliação preliminar dos pontos da história no nível dos recursos - isso nos permitirá determinar prioridades no final do trimestre.
Para cada iniciativa, é criado um quadro Kanban pessoal, no qual, à medida que você os cria, é possível ver recursos e histórias, com uma ligação inicial a uma certa iteração, que é fornecida por um fluxo de trabalho separado na forma de iterações futuras. Nos quadros, as equipes personalizadas são configuradas de acordo com as equipes de desenvolvimento. Como o ecossistema JIRA é bastante complicado, durante a pré-descoberta e a descoberta, criamos tarefas em projetos separados para não sobrecarregar os registros de comandos:
Além disso, na fase de análise, os arquitetos estão envolvidos nesse processo ou, como era habitual recentemente, suas pessoas de confiança são "Embaixadores" (Embaixadores da EA). Sua tarefa é transmitir a visão do departamento de arquitetura aos participantes do processo, ajudar a encontrar a melhor solução e, no final, coordenar essa decisão com o arquiteto-chefe da empresa (Chefe de Arquitetura Corporativa).
Quando as equipes acreditam que a iniciativa está bem desenvolvida e pronta para a próxima etapa, elas passam para o próximo status -
Backlog do portfólio.
Nesta fase, um passo importante é realizar a priorização da WSJF (
primeiro trabalho mais curto ponderado ). Para fazer isso, três semanas antes do planejamento, realizamos uma grande reunião, que, infelizmente, leva muitas horas e, durante essa reunião, usando a pontuação de poker de Fibonacci, os membros do conselho de administração avaliam o Valor de Negócios, a importância do tempo ( Criticidade de Tempo), redução potencial de riscos e ativação de oportunidades:
Para acompanhar o histórico das iniciativas, adiciono a cada uma delas um rótulo no gabarito com dados do trimestre: 2018T4, 2019Q1, etc.
No futuro, descreverei os seguintes status possíveis. Após o comprometimento, as iniciativas que foram tomadas com sucesso para o trabalho passam para o status
Implementando , enquanto os “não-formados” obtêm o status
Estacionado e, no futuro, têm a oportunidade de serem consideradas nos próximos trimestres. As iniciativas entregues passam para
Concluído .
Como resultado, temos aproximadamente a seguinte figura no quadro Kanban:
É claro que nem estamos no meio da jornada, mas no momento já posso notar que, graças ao uso do Kanban no nível de carteira e carteira de pedidos em atraso
- Os empresários começaram a elaborar iniciativas em detalhes e a se preparar seriamente para uma revisão
- A revisão se tornou mais meticulosa em um bom sentido
- As equipes têm mais tempo de pré-descoberta
- Não perco iniciativas antigas - você sempre pode voltar para iniciativas estacionadas, não entregues ou esquecidas e trabalhar mais nelas
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- Plug-in Colors for Jira - para destacar iniciativas de negócios e arquitetura
- Plugin 'Estrutura - Gerenciamento de Projetos em Escala' - para visualizar a estrutura de iniciativas com recursos vinculados a elas e sua priorização pela WSJF
- Confluência Atlassiana - Fonte de Documentação Interna
- Lucidchart e seus plugins para Jira e Confluence - para gráficos
Parte I. Preparando para o Planejamento
Em algum lugar um mês antes do planejamento, é um momento quente para a preparação. Há muito a considerar e, para não esquecer nada, você deve criar uma tabela do Google "logística" de várias páginas. Tentarei descrever as guias mais importantes desta tabela e a atividade ao seu redor.
Feedback. Alguns dias após cada planejamento, realizamos uma retrospectiva e, para ajustar o curso, é importante não esquecer as conclusões a que chegamos e como precisamos ajustá-lo. Esta é uma parte importante no contexto da melhoria contínua do processo.
Treinamento técnico. Com a transição para o planejamento remoto, surgiram solicitações específicas, como a qualidade da conexão à Internet (priorização e otimização de rotas para o JIRA e o Confluence) e a presença de televisão e áudio (usamos os kits do Logitec Group, microfones Jabbra e fones de ouvido pessoais em várias combinações, webcams, Zoom para videoconferência).
Facilitadores. Aqui está uma lista de funcionários responsáveis pela facilitação em cada um dos grupos de trabalho, indicando sua localização e um link para o canal de zoom permanente do grupo de trabalho.
A audiência. Conseqüentemente, uma lista completa de todos os convidados.
Checklist. Uma lista completa de tarefas importantes com prazos e os responsáveis. Para uma imersão maior, darei vários exemplos das tarefas mais características e importantes que são repetidas para cada planejamento: treinamento do facilitador (um manual de treinamento foi preparado para os facilitadores com todas as etapas necessárias, desde a organização de uma equipe de trabalho, cronometrando reuniões para explorar opções de soluções técnicas e o processo de decompor a iniciativa em uma lista de recursos) ; atualização dos planos de localização do grupo de trabalho para cada escritório; controle da atualização do Velocity para todas as equipes de desenvolvimento; ordem de almoço; relatórios sobre trimestres anteriores; impressões de listas de iniciativas (disponíveis) e agendas.
Parte II Planejando e comentando
Depois de toda a preparação, finalmente chega esse momento - o início do planejamento trimestral. Em dois dias, teremos tempo para examinar todas as iniciativas, garantir que haja informações suficientes e se comprometer. Depois de alguns discursos curtos, mas incendiários, os grupos de trabalho se dispersam em seus lugares e começam a trabalhar. No momento, o número de grupos é distribuído entre os três escritórios, de acordo com a fórmula 4x4x4, e os usuários remotos são conectados à tabela necessária por meio de um canal Zoom dedicado.
No final da descoberta de cada uma das iniciativas, o facilitador, certificando-se de que todos os dados necessários - como critérios de aceitação, uma descrição da solução técnica, riscos, dependências, necessidade de uma nova infraestrutura - estejam presentes, marca a iniciativa com a caixa de seleção Finalização da sessão de TI para transparência do progresso e o grupo de trabalho pode passar para o próximo.
Depois de uma dúzia de planos, a sensação de tensão nervosa constante e pressão temporária temporária que esteve conosco desde o início se resolveu amplamente, e agora a atmosfera é mais como um trabalho silencioso. Na segunda metade do primeiro e segundo dias, chega a hora de um comentário de acordo com as prioridades. Para executar o commit, tenho várias estruturas separadas. A primeira delas é uma estrutura que contém uma lista de recursos e caminhos planejados para comentários:
Infelizmente, essa estrutura contém os restos de material que não se encaixavam nos comentários do trimestre atual, portanto a amostra não é representativa. Em qualquer caso, na pesquisa, posso selecionar a iniciativa que me interessa em ordem de prioridade por número, que durante o processo de descoberta é colocada em um campo separado para cada recurso e história, altera o status das tarefas necessárias de Planejado para Confirmado e coloca-a na iteração correta, comprometendo-se assim:
Como resultado, a tarefa desaparecerá dessa estrutura e aparecerá em uma nova, refletindo o crescente comentário:
Como você pode ver na captura de tela, nessa estrutura, as histórias entram na pasta da equipe de desenvolvimento à qual elas pertencem e são agrupadas por iteração. Aqui, vejo a velosidade geral da equipe no nome da pasta, bem como na coluna Compromisso, usando a fórmula, o excesso de comentário para cada grupo é determinado automaticamente e nos sinaliza em vermelho.
Obviamente, se as primeiras e mais prioritárias iniciativas forem comentadas sem problemas, em breve, com o surgimento das primeiras equipes que preencheram sua lista de pendências, os problemas começam e algumas iniciativas não ficam sem debate, mas precisam ser adiadas.
No final desse processo simples, as equipes da bandeira da empresa juram solenemente fazer um comentário (uma piada) e espalhar para casa (também uma piada - todos se espalham pelas barras).
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- Plugin 'Estrutura - Gerenciamento de Projetos em Escala' - para monitorar o processo de descoberta e durante a execução de uma confirmação.
Parte III Clonando tarefas em um ecossistema JIRA de uma empresa
Enquanto todo mundo bebe vodka, o RTE está trabalhando na criação de um comentário no formato em que ele pode ser distribuído para os backlogs da equipe de desenvolvimento e monitorado ao longo do trimestre. Para fazer isso, eu uso o plug-in 'Bulk Clone Professional for Jira' - ele adiciona um item que fornece clonagem coletiva no menu Bulk Change e possui os recursos necessários para mim, como links de clonagem, atualização de links entre clones criados recentemente, atualização de links épicos, adição de prefixo no cabeçalho e adicione automaticamente um atalho:
Eu adiciono o status como um prefixo, pois no estágio de planejamento os status refletem a iteração planejada de conclusão e, como resultado, vejo imediatamente no cabeçalho quando planejamos concluir um recurso ou uma história.
Primeiro, clono absolutamente todas as tarefas em um projeto Global Backlog separado, pois armazenamos epopéias nele, e eu preciso ter conexões relevantes de histórias épicas em tarefas recém-clonadas. E como uma segunda etapa, faço solicitações para cada equipe de desenvolvimento separadamente e movo as histórias para os projetos finais das equipes.
Como resultado, crio uma estrutura que reflete o comentário atual e consiste em tarefas finais, que depois uso para monitorar:
Em geral, os benefícios resultantes dessa abordagem são os seguintes:
- Pode parecer brega, mas é mais fácil para uma pessoa de TI imprimir novos recursos e histórias do que escrever com um marcador em um pedaço de papel adesivo.
- Muitas coisas, como o saldo da capacidade e a atualização do WSJF, dependendo das classificações, são calculadas automaticamente usando fórmulas.
- Graças à clonagem, o elenco original do commit é preservado para a história e você sempre pode retornar a ela.
- Tempo e energia são muito economizados na preparação do planejamento - o trabalho com papel exige força.
- Claro, é ótimo que você não precise mais encher quebra-cabeças em uma gira.
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- Plug-in 'Bulk Clone Professional for Jira' - para clonar recursos e histórias nos projetos finais do JIRA.
- Plugin 'Estrutura - Gerenciamento de Projetos em Escala' - para criar a estrutura final.
Epílogo
Amigos, é claro, entendo que a descrição é bastante superficial e muitas coisas podem ser reveladas com mais detalhes - monitorando a distribuição de capital entre iniciativas de negócios e arquiteturais e tarefas operacionais, calculando fórmulas em estruturas, gerenciamento de riscos e muito mais. Mas ainda não está claro para mim se esse tópico é interessante para o público e, em caso afirmativo, o que exatamente. Se houver interesse, estarei pronto para revelar os tópicos necessários.
E mais uma coisa: é difícil acreditar que isso seja possível, mas eu gostaria de evitar todos os problemas relacionados ao Edge, estruturas, gerentes eficazes e "eficientes". Lembre-se de que descrevi todo o processo na esperança de pessoas interessantes que estão próximas a ele com sua implementação técnica e estou realmente ansioso por discussões relevantes.
Vejo você nos comentários!