¿Cómo puedo hacer un seguimiento de los atributos de calidad en el Kanban de mi equipo?

13

Mi equipo utiliza un sistema Kanban para rastrear el progreso diario y está funcionando muy bien para comprender el progreso de las funciones (capturadas como historias de usuarios). Hemos permitido en gran medida que el diseño de nuestro sistema surja a medida que desarrollamos funciones que funcionaron bien hasta hace poco. En la última semana, hemos tenido varias discusiones sobre compensaciones de arquitectura específicamente relacionadas con los atributos de calidad de rendimiento y modificabilidad.

Creo que lo que está sucediendo es que a medida que implementamos características y diseñamos el sistema, tomamos decisiones implícitamente sobre la arquitectura, pero no consideramos esas decisiones en términos de nuestros requisitos de calidad de atributo conocidos. Sería realmente genial si pudiera realizar un seguimiento / captura / representación visual de cómo se toman estas importantes decisiones de diseño para que los miembros del equipo tengan una mejor oportunidad de no crear tensión adicional en la arquitectura del sistema a medida que se implementa. Y, por supuesto, para complicar más las cosas, las funciones de nuestro tablero no son exclusivamente funcionales y, a veces, ocultan la complejidad arquitectónica.

¿Cómo puedo hacer un seguimiento del progreso de los atributos de calidad (u otras decisiones arquitectónicas relevantes) visualmente en el Kanban de mi equipo?

    
pregunta Michael 02.10.2010 - 17:56

4 respuestas

7
  

estamos tomando decisiones implícitamente sobre la arquitectura, pero no estamos considerando esas decisiones en términos de nuestros requisitos de atributos de calidad conocidos.

Creo que puede visualizar esto creando un paso de "revisión arquitectónica" en su flujo de trabajo. El paso estaría representado por una columna de placa Kanbad con su propio límite WIP. El límite de WIP dependerá de cuántos arquitectos / diseñadores tengas que participar en estas revisiones.

El equipo de desarrollo es responsable del flujo horizontal de izquierda a derecha de las historias de usuario. El arquitecto (s), en la mayoría de los casos, tocará las historias solo cuando estén en la columna de revisión arquitectónica / técnica. La intersección de la columna con un swimlane horizontal visualiza la reunión de desarrollador (es) y arquitecto (s).

Uno de los equipos en los que trabajo tiene un paso similar en el que realizan una revisión del esquema de la base de datos con el arquitecto jefe de datos. No usan Kanban, pero si lo hicieran, es muy probable que tengan esta columna en su tablero.

Los atributos de calidad conocidos podrían entonces representarse como:

  • la definición de hecho para el paso de revisión arquitectónica.
  • pruebas de aceptación en torno a las historias de usuario ya hechas que representan requisitos no funcionales. Luego, la definición de hecho para una nueva historia de usuario incluiría no interrumpir esas pruebas.

AGREGADO : el paso del flujo de trabajo de "revisión arquitectónica" puede ser sospechoso de un problema llamado tragedia de los comunes . Aquí hay una excelente publicación en el blog sobre cómo la visualización de Kanban puede ayuda a lidiar con esto y posibles soluciones.

    
respondido por el azheglov 10.11.2010 - 22:36
6

Realmente hay dos partes en esta pregunta. Una parte es: ¿Cómo sabemos cuándo se cambia la arquitectura? La segunda parte es: ¿Cómo sabemos que la arquitectura sigue siendo buena?

Para esta primera parte: ¿Cómo saber cuándo se modifica la arquitectura?

El objetivo aquí es tomar algo que se está haciendo implícitamente y hacerlo explícito

  • La sugerencia de Alexei es una opción. Crear una columna en el tablero para la revisión de la arquitectura. Luego mueva una tarjeta allí si requerirá decisiones arquitectónicas
  • Otra opción es crear una política explícita sobre cómo manejar esto: "Si necesitamos cambiar la arquitectura, debemos emparejarnos con otra persona" es un ejemplo de una de esas políticas. En un proyecto, tuvimos la política de que los cambios en el código de ciertos módulos especializados debían realizarse mediante la vinculación con personas específicas. Cuando alguien quería cambiar el código allí, pedían un par y formaban un equipo. El resto del trabajo se realizó en solitario. Puedes hacer algo parecido con la arquitectura.

Probablemente iría con el primero, si muchas tarjetas requieren revisión, o si el arquitecto no forma parte del equipo y se requiere un traspaso, o la revisión será lo suficientemente detallada como para tomar el tiempo que desee. Para rastrear en el tablero. Esta última es una opción si solo unas pocas tarjetas tocan la arquitectura y es fácil encontrar un par a pedido.

Ahora vamos a la segunda pregunta: ¿Cómo sabemos que la arquitectura sigue siendo buena?

Soy un gran fan de la visualización. Podría tener un gráfico en la pizarra con notas post-it que describan los componentes y la arquitectura.

También hay analizadores estáticos que analizarán la base del código y generarán una imagen con un gráfico de dependencia de varios componentes. Podrías correrlo, sacar una impresión y pegarla en la pared una vez a la semana. Tal vez las dos últimas impresiones podrían estar en la pared, para que pueda ver si algo ha cambiado en la última semana.

Lo que estos le permiten hacer es hacer que su arquitectura y diseño sean visibles. Los miembros del equipo lo verán de vez en cuando y comentarán si algo se puede cambiar, refactorizar o hacer de una mejor manera.

    
respondido por el Siddharta 01.11.2011 - 23:11
4

También he visto este problema. Toma de decisiones implícita! Si la implicación es el problema, ¿lo resolverá lo más explícitamente posible? Lo que sugiero es modificar un poco el proceso de arquitectura para 'comenzar a explicar' los pensamientos implícitos que progresan para convertirse en decisiones. El propósito del paso adicional en el proceso es hacer que los miembros del equipo entiendan que todos son propensos a tomar decisiones arquitectónicas implícitas. Este paso solo mantendrá la decisión implícita fuera de la pista.

Mantener la "Explicación de decisiones implícitas" como parte de kanban para cada uno de los escenarios podría ayudar.

Lo que voy a sugerir puede ser engorroso. Pero si el proceso se asigna a un conjunto de elementos kanban y si se incluye en el tablero para cada escenario de arco, ¿no le ayudará a rastrearlo? Le sugiero que también puede asignarlos a la plantilla de escenario de seis partes e improvisar el tablero kanban para acomodar los hallazgos, se pueden rastrear los QA.

Vikram.

    
respondido por el vikram 04.10.2010 - 21:55
3

Es uno de los riesgos de retrasar las decisiones arquitectónicas en los equipos ágiles. Obviamente, lo más responsable de ser ágil es retrasar las decisiones arquitectónicas hasta el último momento responsable . Pero es probable que el último momento responsable pueda (o deba) ocurrir desde el principio.

Una cosa que ayuda es delinear claramente desde el principio sus requisitos clave de manejo; cosas que claramente sabe que debe tener (pero no necesariamente tiene que implementarlas en este momento). Su arquitectura en evolución (que intenta ser minimalista y flexible) debe adaptarse al soporte existente o futuro de dichos requisitos.

Lo que es más importante, sin embargo, su arquitectura en evolución NO DEBE implementar artefactos que se pongan (o se puedan poner) en la forma de soportar tales requisitos clave de manejo, incluso si esos artefactos están diseñados para resolver los requisitos actuales. Podemos referirnos a tales artefactos como artefactos interferentes , artefactos que brindan un valor real (ya que implementan una solución a los requisitos existentes) pero cuya presencia hace que sea difícil / costoso implementar un requisito clave de manejo en el futuro.

En los casos en los que debe implementar un artefacto interferente, su tarea consistiría en planificar su eliminación en algún momento (para que pueda implementar el requisito de manejo de claves que se está interfiriendo).

Obviamente, todo esto es esotérico sin un contexto real y tangible (como un proyecto real). Pero más o menos su modelo de proceso de desarrollo y su arquitectura en evolución deben tener en cuenta estas consideraciones.

Los requisitos implícitos son la muerte de las arquitecturas. Todo debe ser explícito, tanto los requisitos clave de manejo como los que son complementarios. No es necesario implementar un requisito desde el principio. Solo necesitas poder contabilizarlo.

PS. Por requisito, me refiero a los requisitos de arquitectura a nivel de sistema y no necesariamente a los requisitos de nivel de aplicación efímeros que se pueden acomodar sin cambios sustanciales en la arquitectura. Espero que ayude.

    
respondido por el luis.espinal 13.10.2010 - 18:36

Lea otras preguntas en las etiquetas