Antes de começar, preciso emitir um pedido de desculpas preventivo:
É muito provável que parte da terminologia / vocabulário que eu uso neste post esteja totalmente errada. Também há uma boa chance de eu ter interpretado completamente mal alguns dos aspectos principais. Eu sou novo nisso, então não seja muito crítico, mais do que bem-vindo feedback construtivo;)
fundo
Atualmente, estamos migrando um departamento de desenvolvimento de 200 pessoas da multi-metodologia para o "Agile". Os porquês, prós e contras disso estão muito além do escopo desta questão.
Este departamento de desenvolvimento contém uma equipe de Serviço de Arquitetura, composta por 10 pessoas, oficialmente conhecidas como "Arquitetos de Soluções". Na realidade, eles cobrem mais do que apenas a solução, são pessoas técnicas que cobrem todos os aspectos técnicos da arquitetura de um projeto (ou seja, hardware, software, segurança, governança etc.). Eles também fornecem funções ad-hoc para a equipe de desenvolvimento (revisões de código, orientação de padrões etc.) e negócios mais amplos (participação técnica em licitações, pré-visualização técnica pré-contratual dos requisitos do cliente)
Como parte dessa transição, fui encarregado de criar um quadro Kanban com o objetivo de obter uma visão das atividades de trabalho pelas quais a equipe do Serviço de Arquitetura é responsável. Existem inúmeras placas de exemplo para equipes de desenvolvimento / codificação, mas nenhuma que eu possa encontrar para Arquitetura. Então, eu peguei de várias fontes e criei "algo", eu realmente apreciaria um feedback genuíno sobre isso.
Também é importante notar que isso será apresentado à equipe como ponto de partida / trabalho em andamento. É o conselho deles e eu quero que eles sejam os donos dele, tudo o que estou fazendo é estabelecer uma base para os caras desenvolverem (e mudar, se necessário)
Até agora eu tenho algo parecido com isto
A placa principal
O quadro principal é onde mantemos todos os projetos ativos / pendentes - todo o trabalho ativo estará neste quadro. Isso será revisado brevemente no scrum de arquitetura diário, com uma revisão mais aprofundada no final de cada semana.
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
| Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done |
-------------------------------------------------------------------------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------------------------------------------------------------------------------
As descrições / finalidades da coluna são:
Avaliação : Projetos em que a pessoa está fazendo uma análise técnica inicial, ou seja, executando opções técnicas com o proprietário do produto, determinando o tamanho do projeto. Como exemplo, um projeto de Avaliação pode ser o Arquiteto avaliando uma nova tecnologia ou trabalhando com um cliente para produzir uma solução técnica mutuamente acordada.
Implementação : Projetos que estão ativamente em desenvolvimento (codificação, teste etc.) e a pessoa está atuando em uma função de SA para a equipe de projeto mais ampla. Como exemplo, isso poderia ser o desenvolvimento de aspectos de codificação da "solução técnica mutuamente acordada" mencionada acima, da mesma forma que também poderia estar supervisionando arquitetonicamente a implementação de algum novo hardware.
Ad-Hoc : Todas as coisas estranhas e maravilhosas que surgem que não podem ser colocadas nas outras duas colunas. Como exemplo em um mundo recursivo estranho, há um cartão para mim na coluna ad-hoc para criar um quadro KanBan :).
Pessoa : Bastante auto-explicativa, a pessoa que "possui" as cartas nessa linha. Para tornar as coisas um pouco mais divertidas, isso na verdade contém um avatar da escolha das pessoas.
Todo : é efetivamente nosso backlog, os cartões aqui são ordenados de cima para baixo em prioridade. À medida que o espaço em uma pessoa que faz célula se torna disponível, tiramos do topo de todo.
Fazendo : Bastante auto-explicativo
Concluído : itens que foram concluídos desde a última revisão da pensão completa (sexta-feira à tarde toda semana)
Limites WIP
Em vez de fazer o que fazemos agora (ou seja, dar trabalho até que alguém grite), eu gostaria que a diretoria trabalhasse com limites de WIP objetivos / baseados em evidências. A intenção é dimensionar cada uma das cartas do tabuleiro com:
- XS (Extra Pequeno): 3 pontos
- S (Pequeno): 5 pontos
- M (Médio): 8 pontos
- L (Grande): 13 pontos
- XL (Extra Grande): 21 pontos
O tamanho é muito do ponto de vista da carga de trabalho de arquitetos, por exemplo, um projeto que requer 1 ano de codificação para 10 pessoas, mas o mínimo de entrada da arquitetura seria XS ou S. No entanto, um projeto que possui uma entrada de arquitetura massiva, mas com um mínimo de codificação pode ser um XL.
Com o tempo, poderemos determinar o limite WIP para cada pessoa. Portanto, sabemos que Jonny Smith pode trabalhar com uma velocidade de 42 pontos e, portanto, alocar projetos até esse nível.
Como não fizemos isso antes de minha intenção é definir o limite inicial alto, a idéia é que, quando uma pessoa grita, podemos (em equipe) olhar para isso objetivamente e determinar se é realmente demais ou é porque nossos processos etc são muito onerosos e devem ser simplificados.
- NOTA : De tudo aqui, esses cálculos WIP são os que "parecem" os menos corretos *
The Funnel Board
Para acompanhar todas as coisas aleatórias que passam pela equipe, também temos um quadro de funis. Esta é uma placa relativamente simples que se parece com isso:
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
------------------------------------------------------------------------
| | | |
| | | |
| | | |
| | | |
| | | |
------------------------------------------------------------------------
Como a equipe está ciente de um "projeto", mas isso ainda não foi oficialmente sancionado (ou seja, pode ser colocado nas colunas Todo na placa principal), então ele entra na placa do funil. Os itens aqui não são alocados a uma pessoa. A idéia é que podemos rastrear as coisas aleatórias que surgem e garantir que elas não sejam esquecidas. Além disso, à medida que a pessoa conclui um projeto de avaliação, isso passa da Avaliação da placa principal concluída para a placa do funil de implementação (a menos que se torne imediatamente um projeto de implementação)
Ocasionalmente, um membro da equipe é encarregado de acompanhar tudo no quadro do funil, ou seja, telefonema rápido para o proprietário do produto perguntando se isso ainda é relevante (este seria um projeto ad-hoc no quadro principal)
O Conselho de Sucessos
Este é apenas um quadro simples para acompanhar o que fizemos nos últimos X meses. Ele contém os cartões que passaram pelo Funil e / ou Placas principais
------------------------------------------------------------------------
| Successes |
------------------------------------------------------------------------
| |
| |
| |
| |
| |
------------------------------------------------------------------------
A idéia é que ocasionalmente podemos contornar este quadro e dar uns tapinhas nas costas um do outro :)
Cartões
Os cartões que estão nos quadros contêm as seguintes informações:
------------------------------------------------------------------------
| SIZE (XS,S,M,L,XL) | OWNING TEAM MEMBER | RAG |
------------------------------------------------------------------------
| |
| PROJECT TITLE |
| |
------------------------------------------------------------------------
| | |
| DEPENDENTS | DEPENDENCIES |
| | |
------------------------------------------------------------------------
| |
| MISC INFORMATION |
| |
------------------------------------------------------------------------
| WIDER PROJECT TEAM (AS APPLICABLE) |
| Other Architects, Project Manager, Principal Developer, Business |
| Analyst, Scrum Master |
------------------------------------------------------------------------
Como você notará que a granularidade do cartão está em um nível "Projeto" razoavelmente alto, não estou planejando criar um quadro de estilo para desenvolvedores dividido em tarefas (considerações a este respeito). Também vale ressaltar que, dependendo de onde o cartão não estiver, todas as seções serão aplicáveis. Também estou pensando em codificar por cores os cartões, como uma primeira facada que tenho:
Amarelo: qualquer coisa contratual do cliente Rosa: qualquer coisa interna (ou seja, não voltada para o usuário final) Verde: qualquer coisa que seja um projeto de grupo da empresa
Os cartões serão magnéticos em vez de post-it, espero encontrar alguns que sejam como mini quadros brancos, pois isso facilitará a vida à medida que as coisas mudam
Outras coisas
- Se não estiver em um cartão de uma placa, no que diz respeito à equipe, ela não existe
- As pranchas são quadros brancos com rodas, podemos levá-los para onde quisermos
- Podemos considerar ir para um quadro virtual virtual no futuro (quadros físicos físicos são mais fáceis de mudar quando decidimos que a coluna X é melhor à esquerda de Y e não à direita)
Questões
- Depois de ler meu novato Kanban War and Peace, quais são seus pensamentos? (por favor, vá devagar comigo)