Dado: Uma empresa que usa o Scaled Agile Framework (SAFe) para escalar o desenvolvimento Agile em toda a organização; 10 equipes de desenvolvimento combinadas em uma grande equipe (Agile Release Train, de acordo com a terminologia SAFe) para entregar 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, com distância entre os mais remotos que excedam 6 mil quilômetros e a diferença de tempo de trabalho correspondente de 5 horas; experiência anterior em planejamento, que implicava o uso de quadros analógicos / quadros brancos / marcadores / notas adesivas e a presença física de todos os funcionários-chave na mesma sala.
* Essa construção pesada "O plano de trabalho das equipes de TI para os próximos três meses" ameaça aumentar significativamente o tamanho do texto, então, a seguir, substituirei por "o compromisso". Assim, elaborar e adotar um plano de trabalho será “comprometer-se”.
Por que precisamos disso?
1) Fadiga com métodos de trabalho analógicos. Enquanto naves espaciais estão arando o espaço, e Elon Musk está aborrecendo seus túneis, nós, pessoal de TI, escrevemos persistentemente com marcadores em notas adesivas colando-as nas placas - há realmente algum tipo de dissonância nisso, não existe? ? É assim que nosso compromisso se parecia há um tempo:
Sim, é uma folha de papel de cerca de 2 por 5 metros, com cada nota adesiva a ser transformada em uma tarefa do JIRA após o planejamento ...
2) Fadiga de nossos colegas nômades. Apesar do fato de nossa sede estar localizada em um país agradável e acolhedor, fiquei surpreso ao descobrir no ano passado que eles estão longe de serem felizes com todas as viagens. Meus argumentos "Oh, bem, você pode se divertir relaxando ao sol à beira-mar" foram recebidos não muito calorosamente. Como se constatou que nem todos estão prontos para viagens de negócios frequentes, que muitas vezes não são bem-vindos por suas famílias, alguns colegas simplesmente não aguentavam o tempo todo, considerando as distâncias entre os escritórios e a frequência das reuniões.
3) Envolver mais colegas de TI no processo de planejamento. Como está claro no parágrafo acima, dificilmente podíamos permitir que toda a equipe de TI dos três escritórios viesse para o planejamento, portanto apenas os Escolhidos foram selecionados, o que meio que excluiu os demais do processo. Isso não foi benéfico para o espírito de equipe em geral.
4) Otimização de custos. Sim, este é um momento sensível - existem muitas pessoas-chave e tê-las voando quatro vezes por ano não é nada barato.
Parte Zero: Trabalhando com o Backlog do Portfólio
Tudo começa muito antes do planejamento real. Para trabalhar produtivamente no compromisso durante o planejamento, é necessário ter algo pelo qual se comprometer. Para garantir isso, tenho que "carregar" os empresários com trabalho em iniciativas prováveis (ou, na terminologia SAFe, Epics, mas daqui em diante vou usar nosso termo usual) o mais cedo possível. Idealmente, esse processo deve ser completamente divorciado da natureza iterativa do planejamento trimestral e seguir seu próprio caminho Kanban. Tomamos como base o SAFe Portfolio Kanban:
Temos um projeto JIRA separado com três tipos de problemas: épicos, iniciativas de negócios e iniciativas de arquitetura; bem como o Conselho Kanban correspondente. O algoritmo para o proprietário da empresa da iniciativa é simples: ele adiciona um problema a esse projeto e ele é enviado para o Backlog por padrão, que é o primeiro status do nosso fluxo Kanban -
Funil:
Aqui, as Iniciativas ainda não prontas para Revisão são armazenadas. O proprietário da empresa trabalha com o conteúdo da iniciativa até se sentir pronto para a próxima etapa. O mínimo necessário nesta fase é ter campos preenchidos de Declaração do Problema, Resultado Desejado e Medida de Sucesso, além de uma apresentação um pouco mais detalhada, mas simples e clara. Nesta fase, é importante deixar de lado soluções técnicas e focar nos parâmetros de negócios. Quando todos os dados são coletados, o Proprietário da empresa move a tarefa para o próximo status -
Revisando.Realizamos Revisões semanalmente para Iniciativas Empresariais e Arquitetônicas. Idealmente, esta é uma apresentação de cinco minutos com perguntas e respostas subsequentes. Como resultado da Revisão, é tomada uma decisão sobre o que acontece com a Iniciativa a seguir. Pode:
- retornado ao funil para revisão,
- ser abolido sem chance de vida futura (neste caso, uso um status desatualizado especial oculto no quadro Kanban),
- ser aprovado e movido para a próxima etapa - Analisando.
Nesta fase, nós - Yippee !!! - pode finalmente envolver os profissionais de TI: analistas, arquitetos, leads, qualquer pessoa. Por "nós", eu me refiro como um engenheiro de trens de lançamento. Mas, idealmente, também devem ser os Proprietários de empresas, que já adquiriram alguma experiência e autonomia necessárias para envolver as equipes certas e lançar análises de forma independente. Mais uma vez, estou escrevendo sobre o caso ideal aqui. De fato, o nível de auto-organização de nossos colegas é flutuante e, em alguns casos, eles pedem ajuda a um facilitador especialmente designado, mas tento me afastar dessa prática.
O objetivo desse estágio é a análise preliminar ou, como chamamos, a pré-descoberta. Como resultado, devemos obter um mínimo que nos permita comprometer: soluções propostas, riscos e dependências, requisitos não funcionais e de infraestrutura, mapas de usuários, esquemas de arquitetura. Além disso, solicitamos às equipes que façam uma avaliação preliminar dos pontos da história no nível do recurso - isso nos permitirá determinar prioridades no final do trimestre.
Um Conselho Kanban pessoal é criado nesse estágio para cada Iniciativa, na qual recursos e histórias podem ser vistos, com um link preliminar para uma iteração específica, que é fornecida por um fluxo de trabalho JIRA separado. Portanto, alterando o status, podemos atribuir o problema a alguma iteração. As raias de natação nos Kanban Boards são configuradas por equipes de desenvolvimento. Como nosso ecossistema JIRA é bastante complicado, durante a Pré-descoberta e a Descoberta, criamos tarefas em projetos separados para não desarrumar os atrasos das equipes:
Também na fase de pré-descoberta, envolvemos arquitetos ou, como tem sido praticado ultimamente, suas pessoas de confiança - "EA Ambassadors". Sua tarefa é transmitir a visão do departamento de arquitetura a todos os participantes, ajudar a encontrar a melhor solução e, finalmente, aprová-la com o chefe de arquitetura corporativa da empresa.
Quando todas as pessoas envolvidas acreditam que a Iniciativa foi analisada o suficiente e está pronta para a próxima etapa, ela passa para o próximo status -
Backlog do portfólio.Nesta fase, é importante realizar uma priorização da WSJF (
primeiro trabalho mais curto ponderado ). Para fazer isso, temos uma grande reunião três semanas antes do planejamento, que, infelizmente, até agora sempre durou muitas horas. Durante esta reunião, os membros do Conselho de Administração avaliam o valor comercial, a criticidade do tempo, a redução de riscos e a ativação de oportunidades com a ajuda do pôquer de planejamento alinhado por Fibonacci:
Para poder rastrear o histórico das Iniciativas, para cada uma delas, adiciono um rótulo no JIRA com dados trimestrais: 2018Q4, 2019Q1, etc.
Olhando para o futuro, deixe-me descrever todos os status possíveis. Após o compromisso final no PI Planning, as iniciativas levadas ao trabalho com sucesso são movidas para o status
Implementing , enquanto as 'não ajustadas' recebem o status de
estacionado e podem ser consideradas para os próximos trimestres. As iniciativas entregues são movidas para o status
Concluído .
Como resultado, temos a seguinte imagem no Quadro Kanban:
É claro que ainda não estamos no meio do caminho, mas no momento já posso notar que, graças à implementação do Backlog do portfólio
- Os empresários começaram a trabalhar detalhadamente em suas Iniciativas e a se preparar minuciosamente para a Revisão.
- As revisões se tornaram mais meticulosas em um bom caminho.
- As equipes têm mais tempo para a pré-descoberta.
- Não perco iniciativas antigas - sempre posso voltar para as iniciativas estacionadas, não entregues ou esquecidas e continuar trabalhando nelas.
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- Cores de plug-in para Jira - para destacar iniciativas de negócios e arquitetura
- O plug-in 'Estrutura - Gerenciamento de projetos em escala' - para visualizar a estrutura feita de iniciativas e recursos pertencentes a eles e sua priorização da WSJF
- Confluência Atlassiana - fonte de documentação interna
- Lucidchart e seus plugins para Jira e Confluence - para desenhar diagramas
Parte I. Preparação para o planejamento de PI
Um mês antes do PI Planning é quando chega a hora mais movimentada. Muitas coisas precisam ser levadas em consideração e, para não deixar nada de fora, eu tenho que criar um formulário do Google "logístico" de várias páginas. Deixe-me descrever as guias mais importantes deste formulário e as atividades ao seu redor.
Comentários Alguns dias após cada Planejamento do PI, realizamos uma Retrospectiva, o que nos ajuda a não esquecer quais conclusões chegamos e como precisamos ajustar o curso. Esta é uma parte importante em termos de melhoria contínua.
Preparação técnica. Com a transição para o planejamento remoto, surgiram solicitações específicas, como qualidade da conexão à Internet (priorização e otimização de rotas para JIRA e Confluence) e presença de vídeo e áudio (usamos os kits do Logitec Group, microfones Jabbra e fones de ouvido pessoais em várias combinações , webcams, software Zoom para videoconferência).
Facilitadores. É 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.
Audiência A lista completa de todos os convidados.
Lista de verificação A lista completa de tarefas importantes com prazos e pessoas responsáveis. Para fornecer algumas dicas abaixo, você pode encontrar vários exemplos das tarefas mais típicas e vitais relevantes para cada Planejamento do PI: treinamento de facilitadores (um manual de treinamento foi preparado com todas as etapas necessárias, como organizar uma equipe de trabalho, cronometrar as reuniões e decompor a iniciativa em uma lista de recursos); atualização dos planos de localização dos grupos de trabalho para cada escritório; controle da atualização do Velocity para todas as equipes de desenvolvimento; encomendar refeições; criação de relatórios de trimestres anteriores; impressões de listas de iniciativas e horários.
Parte II Planejamento de PI e o processo de compromisso
Após toda a preparação, esse momento finalmente chega - o início do PI Planning. Em dois dias, temos que descobrir todas as iniciativas, garantir que as informações sejam suficientes e confirmar. Após algumas conversas animadas, os grupos de trabalho vão para seus lugares e começam a trabalhar. No momento, o número de grupos é distribuído entre os três escritórios como 4x4x2, e os usuários remotos são conectados ao grupo necessário por meio de um canal Zoom dedicado.
Após a conclusão da descoberta em cada uma dessas iniciativas, o facilitador garante que todos os dados necessários, como critérios de aceitação, solução técnica, riscos, dependências e a necessidade de uma nova infraestrutura, estejam disponíveis e marque a iniciativa com o 'IT Caixa de seleção Terminada sessão 'para facilitar o rastreamento do progresso. Depois disso, o grupo de trabalho pode passar para a próxima iniciativa.
Após uma dúzia de PI Plannings, a sensação de estar sob constante estresse e pressão de tempo, que estava conosco desde o início, diminuiu significativamente e agora é mais como o trabalho de sempre. À tarde, no primeiro e no segundo dia do Planejamento, é hora de um compromisso sem pressa, de acordo com as prioridades. Para cumprir um compromisso, tenho várias estruturas separadas. O primeiro é uma estrutura que contém uma lista de recursos e histórias agendadas para o compromisso:
Infelizmente, essa estrutura na captura de tela contém apenas tarefas que não se encaixavam no comprometimento do trimestre atual, portanto a amostra não é representativa. De qualquer forma, no campo de pesquisa, posso selecionar a Iniciativa necessária em ordem de prioridade por número, que é colocada em um campo separado para cada recurso e história, alterar o status dos problemas de Planejado para Confirmado e colocá-los na iteração desejada , comprometendo-se assim a eles:
Como resultado, o problema desaparecerá dessa estrutura e aparecerá em um novo, o que reflete o crescente compromisso:
Como você pode ver na captura de tela, nessa estrutura, as histórias caem na pasta da equipe de desenvolvimento à qual elas pertencem e são agrupadas por iteração. Aqui, vejo a velocidade total da equipe no nome da pasta e, além disso, na coluna Compromisso, o comprometimento excessivo é automaticamente determinado e destacado para cada equipe, usando uma fórmula personalizada.
Obviamente, se as Iniciativas de primeira e mais alta prioridade forem incluídas em um compromisso com muita facilidade, em breve, à medida que mais e mais equipes preencherem seus pedidos em atraso até o fim, poderá haver problemas respectivos com algumas das iniciativas, após certos argumentos e discussões. adiado (estacionado) como resultado.
No final desse processo bastante direto, as equipes juram entregar seu compromisso com a bandeira da empresa (ok, não de verdade) e se apressam para suas casas (bem, novamente, não de verdade, principalmente elas fogem para algum bar para comemorar).
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- O plug-in 'Estrutura - Gerenciamento de projetos em escala' - para monitorar o processo de descoberta e durante a execução do compromisso.
Parte III Problemas de clonagem no ecossistema JIRA da empresa
Enquanto todo mundo está bebendo, o RTE está trabalhando na criação de compromissos na forma em que pode ser distribuído aos backlogs das equipes 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 faz clonagem coletiva ao menu Bulk Change e possui os recursos necessários como clonagem de links, atualização de links entre clones recém-criados, atualização de links épicos e adição de resumo prefixo e rotulagem automática:
Eu adiciono status como um prefixo, porque no estágio de planejamento os status refletem a iteração planejada de conclusão. Como resultado, eu posso ver imediatamente no Resumo quando planejamos terminar o recurso ou a história.
Inicialmente, clono absolutamente todos os problemas em um projeto Global Backlog separado, pois mantemos épicos nele e preciso ter conexões reais com histórias épicas em tarefas recém-clonadas. E já como um segundo passo, faço solicitações JQL para cada equipe de desenvolvimento separadamente e movo as histórias para os projetos de trabalho das equipes.
Como resultado, crio uma estrutura que reflete o compromisso atual e consiste em histórias finais, que depois uso para monitorar:
Em geral, as vantagens dessa abordagem são as seguintes:
- É mais fácil para um profissional de TI digitar novos recursos e histórias do que anotá-los com um marcador em uma nota adesiva.
- Muitas coisas, como a capacidade restante e a atualização do WSJF, dependendo das estimativas de matérias, são calculadas automaticamente usando fórmulas personalizadas.
- Graças à clonagem, o Compromisso original é preservado para a história e sempre podemos voltar a ele.
- Isso economiza tempo e energia na fase de planejamento da preparação - o manuseio de papel consome energia.
- Obviamente, é ótimo que não precisamos mais adicionar problemas ao JIRA digitando notas adesivas.
Ferramentas usadas nesta fase:
- Atlassian Jira Software Server
- O plug-in 'Profissional em massa de clone para Jira' - para clonar recursos e histórias em projetos JIRA em funcionamento.
- O plug-in 'Estrutura - Gerenciamento de projetos em escala' - para a criação da estrutura de compromisso final.
Epílogo
Queridos amigos, é claro que entendo que a visão geral acima é bastante superficial, e muitas coisas podem ser reveladas de maneira mais detalhada - monitorando a distribuição de capacidade entre iniciativas de negócios e arquitetura e tarefas operacionais, calculando fórmulas personalizadas em estruturas, gerenciando riscos e muito mais Mas ainda não sei se esse tópico é interessante para o público e, se sim, do que exatamente. Se houver algum interesse, terei prazer em compartilhar minha visão sobre os tópicos relevantes.
E mais uma coisa: é difícil acreditar que isso seria possível, mas ainda assim eu realmente gostaria de evitar comentários relacionados a Agile, frameworks, gerentes eficazes e "efetivos" nos comentários. Lembre-se de que descrevi a parte técnica de todo o processo, na esperança de atrair o interesse das pessoas que estão próximas do tópico, e estou ansioso por discussões relevantes.
Vejo você nos comentários!