October 22, 2019

Criterios de Terminado "Releasable"

DoDLos criterios de terminado deben cubrir todos los aspectos del ciclo de vida de desarrollo para permitir lograr un incremento de producto que potencialmente se puede lanzar al mercado. Los criterios de terminado pueden ser enfocados en dos partes, en la primera parte consideramos los que provienen de los estándares de la organización de desarrollo que este caso es la empresa que lleva adelante la iniciativa de desarrollo, estos estándares pueden ser a nivel de arquitectura, seguridad, legales entre otros. La segunda parte son los criterios de terminado definidos por el equipo de desarrollo con apoyo del Product Owner para aquellos aspectos no cubiertos por los estándares de la organización. Los criterios de terminado ayudan a identificar requerimientos no funcionales que pueden dar origen a PBIs dentro del Product Backlog. Algunos aspectos transversales como seguridad, arquitectura y criterios operacionales a nivel de empresa pueden ser parte del conjunto de criterios de terminado. Estos elementos requieren reflejar ese trabajo para completarlos, este trabajo se puede definir entonces como parte del Product Backlog.

Las consecuencias de no incluir estos dos aspectos es un incremento del producto al final del Sprint que no tenga las condiciones necesarias para que pueda ser usado por el cliente. Hay situaciones donde el equipo trabaja incesantemente en el desarrollo del producto pero desde el punto de vista del Product Owner y negocio no entrega producto terminado y esto es debido a que no ha considerado aspectos propios del proceso de pase a producción, seguridad y otros y por lo tanto este trabajo no se realiza dentro del Sprint.

Los criterios de terminado ayudan a identificar requerimientos no funcionales que pueden dar origen a PBIs dentro del Product Backlog. Algunos aspectos transversales como seguridad, arquitectura y criterios operacionales a nivel de empresa pueden ser parte del conjunto de criterios de terminado. Estos elementos requieren ser reflejados como trabajo para que el equipo se enfoque en realizados, este trabajo se puede definir entonces como parte del Product Backlog. También podemos identificar los criterios de terminado a partir de los elementos en el Product Backlog.

En muchas situaciones que me ha tocado participar es sumamente complicado definir las dos partes de los criterios de terminado debido a que muchos de los estándares de grandes empresas se encuentran lejos de los equipos de Scrum y aparecen en algún momento del desarrollo para decirnos que el producto no ha cumplido determinados estándares y por lo tanto no puede avanzar en los despliegues. Aquí se identifican muchas dependencias que el equipo no puede manejar por si solo. Si el número de dependencias crece y la cantidad de actores o áreas de los cuales se depende también, sería mejor usar Nexus de Scrum.org para escalar Scrum. Los criterios de terminado deben enfocarse en crear un incremento integrado que incluya todos los incrementos de cada uno de los equipos. Sin importar si la organización de los equipos es de tipo componente o de capas o funcionales, se necesita integrar continuamente el trabajo de todos los equipos durante el Sprint.

Los criterios de terminado son la base de la transparencia y permiten la inspección y adaptación. Ayudan a mejorar la transparencia del Product Backlog.

Un punto de partida para elaborar los criterios de terminado es elaborar un diagrama de arquitectura de despliegue que permita visualizar el flujo del proceso para lanzar producto al mercado. La arquitectura ayuda a definir cuáles son los ambientes que deben ser considerados para el desarrollo, pruebas y despliegue, así como las pruebas necesarias en cada ambiente por los criterios de terminado. Para este ejemplo tenemos un ambiente de calidad, un ambiente de pre producción y un ambiente de producción. Cada uno de los ambientes tiene un conjunto de requerimientos o políticas que deben seguirse definidos por la organización. Tal vez el equipo de Scrum tenga clara la definición de lo que debe realizar para terminar en el ambiente de calidad, pero a medida que avanza en el proceso de despliegue va a depender más de otras áreas o personas para definir e implementar estos estándares. El siguiente ejemplo en Azure DevOps es un punto de partida para iniciar la discusión acerca de los estándares de la empresa y la necesidad de incluirlos en los criterios de terminado, así como reflejar este trabajo en el Product Backlog.

Ahora bien, para elaborar esta arquitectura el equipo de desarrollo necesita algunas veces contar con el apoyo y participación de personas otras áreas de la organización. Trabajar en equipo no es solamente una necesidad en el equipo Scrum sino también en la organización para brindar el soporte necesario a los equipos Scrum. Tal vez se necesita del arquitecto empresarial, o el encargado de seguro y debido a que pueden estar en varios proyectos a su relevancia en ciertos aspectos, se puede optar por invitarlos a participar y formar parte del Nexus Integration Team en Nexus para que ayuden en la gestión de las dependencias no solamente en esta definición sino continuamente para enseñar y aportar en el desarrollo del producto. Una alternativa a la visualización del flujo de la entrega de valor y visibilidad de los criterios de terminado como políticas puede ser usar un tablero Kanban.

d

Joel Francia H.

https://www.linkedin.com/in/joelfrancia

Pueden ponerme en contacto conmigo a los correos:

jfrancia@discoveryfast.con

jfrancia@3devnet.com

Pueden ver mis siguientes entrenamientos programados en:

https://tinyurl.com/y44xltvo