Antes de comenzar, necesito emitir una disculpa preventiva:
Es muy probable que parte de la terminología / vocabulario que utilizo en esta publicación sea simplemente errónea, también hay una buena posibilidad de que haya malinterpretado por completo algunos de los aspectos clave. Soy nuevo en esto, así que no sea demasiado crítico, más que bienvenido comentarios constructivos;)
Antecedentes
Actualmente estamos haciendo la transición de un departamento de desarrollo de 200 personas de metodologías múltiples a "Agile". Los por qué, por qué, los pros y los contras de esto están más allá del alcance de esta pregunta.
Este departamento de desarrollo contiene un equipo de servicios de arquitectura que está compuesto por 10 personas que se conocen oficialmente como "arquitectos de soluciones". En realidad, cubren más que solo la solución, son personas técnicas que cubren todos los aspectos arquitectónicos técnicos de un proyecto (es decir, hardware, software, seguridad, gobernanza, etc.). También proporcionan funciones ad-hoc para el equipo de desarrollo (revisiones de códigos, guía de estándares, etc.) y negocios más amplios (aportes técnicos en las licitaciones, vista previa técnica previa al contrato de los requisitos del cliente)
Como parte de esta transición, se me ha encomendado la tarea de crear un tablero Kanban con el fin de obtener una visión de las actividades de trabajo de las que es responsable el equipo del Servicio de Arquitectura. Hay una miríada de paneles de ejemplo para equipos de desarrollo / codificación, pero ninguno que pueda encontrar para Arquitectura. Así que tomé varias fuentes y creé "algo", realmente agradecería comentarios genuinos al respecto.
También vale la pena señalar que esto se presentará al equipo como un punto de partida / trabajo en progreso. Es su tablero y quiero que lo tengan, todo lo que estoy haciendo es establecer una base para que los muchachos construyan (y cambien si es necesario)
Hasta ahora tengo algo como esto
El tablero principal
El tablero principal es donde tenemos todos los proyectos activos / atrasados: todo el trabajo activo estará en este tablero. Esto se revisará brevemente en el scrum arquitectónico diario con una revisión más profunda al final de cada semana.
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
| Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done |
-------------------------------------------------------------------------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------- ----------------- ---------------- -----------------
Person | | | | | | | | | |
-------------------------------------------------------------------------------
Las descripciones / propósitos de la columna son:
Evaluación : Proyectos en los que la persona realiza un análisis técnico inicial, es decir, ejecuta opciones técnicas con un propietario del producto, determinando el tamaño del proyecto. Como ejemplo, un proyecto de Evaluación puede ser el Arquitecto evaluando una nueva tecnología o trabajando con un cliente para producir una solución técnica mutuamente acordada.
Implementación : Proyectos que están activamente en desarrollo (codificación, prueba, etc.) y la persona está actuando en una función SA para el equipo de proyecto más amplio. Como ejemplo, esto podría ser el desarrollo de aspectos de codificación de la "solución técnica mutuamente acordada" mencionada anteriormente, igualmente podría supervisar arquitectónicamente la implementación de algún hardware nuevo.
Ad-Hoc : Todas las cosas extrañas y maravillosas que surgen que no se pueden poner en las otras dos columnas. Como ejemplo en un mundo recursivo extraño, hay una tarjeta para mí en la columna ad-hoc para crear un tablero KanBan :).
Persona : bastante explicativa, la persona que "posee" las tarjetas en esa fila. Para hacer las cosas un poco más divertidas, esto realmente contiene un avatar de la elección de esa persona.
Todo : es efectivamente nuestra cartera de pedidos, las tarjetas aquí se ordenan de arriba a abajo en prioridad. A medida que el espacio en una celda de personas está disponible, tomamos desde la parte superior de todo.
Hacer : bastante autoexplicativo
Hecho : elementos que se han completado desde la última revisión de la junta completa (viernes por la tarde todas las semanas)
Límites de WIP
En lugar de hacer lo que hacemos ahora (es decir, dar trabajo hasta que alguien chille), me gustaría que la junta principal trabaje con límites WIP basados en objetivos / pruebas. La intención es dimensionar cada una de las tarjetas del tablero con:
- XS (extra pequeño): 3 puntos
- S (pequeño): 5 puntos
- M (medio): 8 puntos
- L (grande): 13 puntos
- XL (extra grande): 21 puntos
El tamaño es muy importante desde la perspectiva de la carga de trabajo de los arquitectos, por ejemplo, un proyecto que requiere 1 año de codificación para 10 personas, pero una entrada arquitectónica mínima sería XS o S. Sin embargo, un proyecto que tiene una entrada arquitectónica masiva pero una codificación mínima podría ser un XL.
Con el tiempo, deberíamos poder calcular el límite de WIP para cada persona. Por lo tanto, sabemos que Jonny Smith puede trabajar con una velocidad de 42 puntos y, por lo tanto, asignar proyectos hasta ese nivel.
Como no hemos hecho esto antes, mi intención es establecer el límite inicial alto, la idea es que cuando una persona chilla podemos (como equipo) mirar esto objetivamente y determinar si es realmente demasiado o es porque nuestros procesos etc.son demasiado onerosos y deberían simplificarse.
- NOTA : De todo lo que hay aquí, estos cálculos de WIP son el bit que "se siente" menos correcto *
La Junta del embudo
Para realizar un seguimiento de todas las cosas aleatorias que vuelan a través del equipo, también tenemos un embudo. Este es un tablero relativamente simple que se ve así:
------------------------------------------------------------------------
| Evaluation | Implementation | Ad- Hoc |
------------------------------------------------------------------------
| | | |
| | | |
| | | |
| | | |
| | | |
------------------------------------------------------------------------
A medida que el equipo se da cuenta de un "proyecto", pero esto aún no está oficialmente autorizado (es decir, se puede poner en las columnas de Todo en el Tablero Principal) luego pasa al tablero del embudo. Los artículos aquí no están asignados a una persona. La idea es que podemos rastrear esas cosas aleatorias que surgen y asegurarnos de que no se olviden. Además, a medida que la persona completa un proyecto de evaluación, esto pasa de la Evaluación de la Junta Principal Realizada a la Junta del embudo de implementación (a menos que se convierta inmediatamente en un proyecto de implementación)
Un miembro del equipo ocasionalmente se encargará de hacer un seguimiento de todo en la placa del embudo, es decir, una llamada telefónica rápida al propietario del producto preguntando si esto sigue siendo relevante (este sería un proyecto ad-hoc en la placa principal)
La Junta de Éxitos
Esta es solo una tabla simple para rastrear lo que hemos hecho en los últimos X meses. Contiene las tarjetas que han pasado por el embudo y / o tableros principales
------------------------------------------------------------------------
| Successes |
------------------------------------------------------------------------
| |
| |
| |
| |
| |
------------------------------------------------------------------------
La idea es que de vez en cuando podamos sortear este tablero y darnos palmadas mutuas en la parte posterior :)
Tarjetas de mesa
Las tarjetas que están en los tableros contienen la siguiente información:
------------------------------------------------------------------------
| 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 notará que la granularidad de la tarjeta está en un nivel bastante alto de "Proyecto", no planeo hacer un tablero de estilo de desarrollador que se divida en tareas (pensamientos sobre esta bienvenida). También vale la pena mencionar que, dependiendo de dónde esté la tarjeta, no serán aplicables todas las secciones. También estoy planeando codificar por color las tarjetas, como primer intento tengo:
Amarillo: cualquier cosa que sea contractual para el cliente Rosa: cualquier cosa que sea interna (es decir, que no esté orientada al usuario final) Verde: cualquier cosa que sea un proyecto grupal de la compañía
Las tarjetas serán magnéticas en lugar de post-it, espero encontrar algunas que sean como mini pizarras blancas, ya que esto facilitará la vida a medida que las cosas cambien
Otras cosas
- Si no está en una tarjeta en un tablero, entonces, en lo que respecta al equipo, no existe
- Las tablas en sí son pizarras blancas con ruedas, podemos llevarlas a donde queramos
- Podemos considerar ir a una pizarra virtual en el futuro (las pizarras físicas son más fáciles de cambiar cuando decidimos que la columna X es mejor a la izquierda de Y no a la derecha)
Preguntas
- Después de leer a mi novato Kanban War and Peace, ¿qué piensas? (por favor, ve con calma :))
