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 :))
fuente
Respuestas:
¡Guauu! Eso tomó un tiempo para digerir y comprender completamente. Felicitaciones por decidir adoptar Kanban para su iniciativa ágil. Muy buen análisis y modelado hasta ahora. ¡Gracias por compartirlo aquí y permitirnos ayudar y contribuir a esa iniciativa!
Tengo algunos pensamientos y sugerencias, ¡espero que esto ayude!
R. Primero, solo para obtener una "vista general" del sistema, creo que las tres tablas que ha mostrado son SOLO para rastrear el trabajo de los Arquitectos, no el resto del trabajo del Departamento de Desarrollo, ¿es correcto?
B. Dada la forma en que lo ha descrito, parece que cada una de las columnas de la placa de embudo es esencialmente la columna "Lista" para las secciones correspondientes de la placa principal.
¿Es necesario tener la placa de embudo separada? ¿No sería más simple tener una sola placa, donde tiene columnas "Embudo" o "Listo" para cada sección de la Placa principal?
Del mismo modo, la Junta de éxitos se puede ver como una gran columna a la derecha de la Junta principal, donde todo el trabajo completado con éxito se acumula durante un período de tiempo.
Entonces, dependiendo del número de proyectos en el embudo y en progreso (en cualquiera de las etapas) en cualquier momento, sería más simple administrarlos todos en una sola Junta que tenga el siguiente diseño:
¡Por supuesto, es muy probable que ya haya evaluado esto y haya decidido que podría ser demasiado grande para administrarlo en una sola Junta! (¿Podría considerar dejar caer los carriles de tareas pendientes en cada sección ya que el carril de embudo podría servir para el mismo propósito?)
C. En términos del diseño del tablero principal, realmente depende de cuáles sean sus objetivos generales para implementar Kanban. Algunas preguntas sobre el diseño del tablero:
¿Desea mejorar los tiempos de plomo / ciclo para las personas (lo que sería fácil de hacer en el diseño actual) o para diferentes tipos de proyectos (que podrían ser más difíciles (pero no demasiado dada su codificación de colores)? este último, ¿podría preferir que los carriles no sean definidos por personas sino por tipo de proyecto (similar a la clase de servicio)?
¿Es posible que tenga dos arquitectos trabajando en un solo proyecto? Si es así, tener carriles por personas dificultaría modelar eso, a menos que tuviera dos tarjetas para el mismo proyecto contra cada persona.
¿Es posible que diferentes tipos de proyectos tengan un flujo de trabajo diferente? Por ejemplo, ¿podría un proyecto del cliente requerir un mayor escrutinio (validación o prueba o revisión) que los demás? Si es así, Kanban le permite tener diferentes flujos de trabajo para diferentes tipos de trabajo, lo que no sería posible en este diseño.
Si alguno de los puntos anteriores 1-3 tiene sentido en su situación, le sugiero que desee considerar los carriles no basados en personas sino en algún otro aspecto. De lo que ha hablado, hacerlo por tipo de proyecto parece ser una opción, pero estoy seguro de que también hay otros criterios posibles.
Otra sugerencia, solo para una visualización más intuitiva, ya que las personas asocian el flujo de izquierda a derecha (o de derecha a izquierda en algunas partes del mundo) como la dirección del flujo, ¿crees que tener la sección Ad Hoc para el derecho de las columnas de implementación puede ser confuso? Mi preferencia sería tener proyectos Ad Hoc que tengan su propio Swim Lane separado.
Entonces, la placa principal podría verse de la siguiente manera:
En todo lo anterior, podría tener algunas "pegatinas de avatar" para mostrar qué arquitecto (s) estaba trabajando en cada proyecto que podría pegar en las tarjetas de Proyecto. Si es necesario, una leyenda en un lado del tablero podría explicar qué avatar era qué arquitecto.
Finalmente, una pregunta más grande: usted declaró inicialmente que estos tableros estaban destinados a rastrear proyectos de los que los arquitectos eran responsables. Supongo que estos proyectos son parte de proyectos (más grandes) que está realizando el departamento general de Desarrollo. ¿Cómo planea mostrar las dependencias entre esos proyectos (más grandes) y el trabajo de los arquitectos?
D. En cuanto a los límites de WIP, según lo que he visto hacer a varios de nuestros clientes, ¡no se preocupe demasiado al principio! Pero a medida que avanza, es fundamental establecer límites de WIP, y cambiarlos cuando sea necesario, en lugar de no tener límites de WIP. Si ya tiene algunos datos sobre cuántos proyectos manejó cada Arquitecto o todo el equipo Arquitecto en los últimos meses, podría usar eso para definir algunos límites iniciales de WIP.
Si considera ir a un tablero Kanban virtual en el futuro, algunos de estos podrían ser más fáciles de administrar, cambiar y jugar, por ejemplo:
Espero que esto ayude, al menos al arrojar algunas ideas para que consideres.
Mejor,
Mahesh
fuente
Lectura interesante, y sobre todo tiene sentido.
Lo único que comentaría de inmediato es que un tablero Kanban está destinado a representar un flujo de trabajo, de izquierda a derecha. Como imagino que su trabajo no fluye de Implementación a Ad-hoc, esto realmente no funciona en su tablero.
Una mejor opción (imo) sería tener los carriles horizontales como Evaluación, Implementación y Ad-hoc, y luego hacer que las tarjetas contengan los nombres de las personas en ellos. Esto tiene la ventaja de permitir que más de una persona trabaje en una actividad (aunque tal vez no lo necesite).
Además, como dice el otro póster, no ha considerado dependencias externas. Puede valer la pena tener una columna 'Bloqueada' para mostrar el trabajo que está esperando a alguien o algo fuera del equipo.
Espero que esto sea útil
fuente