¿Cómo puedo rastrear atributos de calidad en Kanban de mi equipo?

Mi equipo utiliza un sistema Kanban para rastrear el progreso del día a día y funcionó muy bien para comprender el progreso de las funciones (capturadas como historias de usuarios). Hemos permitido en gran medida que surja el diseño de nuestro sistema a medida que desarrollamos características que funcionaron bien hasta hace poco. En las últimas dos semanas hemos tenido varias discusiones sobre compensaciones arquitectónicas específicamente relacionadas con el rendimiento y los atributos de calidad de modificabilidad.

Creo que lo que está sucediendo es que a medida que implementamos características y diseñamos el sistema, tomamos decisiones implícitas sobre la arquitectura pero no las consideramos en términos de nuestros requisitos de atributos de calidad conocidos. Sería realmente genial si pudiera rastrear / capturar / representar visualmente 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 características de nuestra pizarra no son exclusivamente funcionales y, a veces, ocultan la complejidad arquitectónica.

¿Cómo puedo seguir el progreso de los atributos de calidad (u otras decisiones arquitectónicamente relevantes) visualmente en el kanban de mi equipo?

implícitamente tomamos decisiones sobre la arquitectura pero no consideramos 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 tablero de Kanbad con su propio límite de WIP. El límite de WIP dependerá de cuántos arquitectos / diseñadores tenga que participar en estas revisiones.

El equipo de desarrollo es responsable del flujo horizontal de izquierda a derecha de las historias de los usuarios. 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 carril horizontal visualiza la reunión de desarrollador (es) y arquitecto (s).

Uno de los equipos donde trabajo tiene un paso similar en el que hacen 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 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 usuarios ya realizadas que representan requisitos no funcionales. Entonces, la definición de hecho para una nueva historia de usuario incluiría no romper esas pruebas.

AGREGADO : El paso del flujo de trabajo de "revisión arquitectónica" puede ser sospechoso de un problema llamado tragedia de los bienes comunes . Aquí hay una gran publicación de blog sobre cómo la visualización de Kanban puede ayudar a lidiar con ella y las posibles soluciones.

Realmente hay dos partes para esta pregunta. Una parte es: ¿Cómo sabemos cuándo 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 cambia 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. Cree una columna en el tablero para la revisión de la arquitectura. Luego mueva una carta 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, entonces debemos vincularnos con otra persona" es un ejemplo de una de esas políticas. En un proyecto, teníamos una política de que los cambios de código en ciertos módulos especializados tenían que realizarse mediante el emparejamiento 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 similar con la arquitectura.

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

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

Soy un gran fanático 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. Puede ejecutarlo, imprimirlo y pegarlo en la pared una vez por semana más o menos. 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 le permiten hacer es hacer que su arquitectura y diseño sean visibles. Los miembros del equipo lo mirarán de vez en cuando y lo comentarán si algo se puede cambiar, refactorizar o hacer de una mejor manera.

También he visto este problema. ¡Toma de decisiones implícita! Si la cuestión es lo implícito, ¿lo resolverá lo más explícito posible? Lo que sugiero es ajustar un poco el proceso de arquitectura para 'comenzar a explicitar' 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 del camino.

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

Lo que voy a sugerir podría 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. Sugiero que también pueda asignarlos a la plantilla de escenario de seis partes e improvisar el tablero kanban para acomodar los hallazgos, los QA pueden rastrearse.

Vikram

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 que no necesariamente tiene que implementar en este momento). Su arquitectura en evolución (que intenta ser minimalista y flexible) debe adaptarse al soporte existente o futuro para tales requisitos.

Sin embargo, lo que es más importante, su arquitectura en evolución NO DEBE implementar artefactos que obstaculicen (o puedan interferir) con dichos requisitos clave de manejo, incluso si esos artefactos están destinados a resolver los requisitos actuales. Podemos referirnos a tales artefactos como artefactos interferentes , artefactos que entregan 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 de conducción clave futuro.

En los casos en que debe implementar un artefacto que interfiere, su tarea sería planificar su eliminación en algún momento (para que pueda implementar el requisito de conducción clave 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 hacerse explícito, tanto los requisitos clave de conducción como los que son auxiliares. No es necesario implementar un requisito desde el principio. Solo necesita poder dar cuenta de ello.

PD. Por requisito, me refiero a los requisitos arquitectónicos a nivel de sistema y no necesariamente a los requisitos efímeros a nivel de aplicación que pueden acomodarse sin cambios sustanciales en la arquitectura. Espero eso ayude.