Lo primero es entender que es un artefacto. Lo podemos identificar como cualquier herramienta que nos ayuda a mantener el proceso y controlar su avance, puede ser manual, (un pizarrón, tarjetas, incluso un lápiz y un cuaderno) o electrónica (hojas de cálculo, aplicaciones de diagramación, tableros de control), no existe una limitante y corresponde a cada equipo definir las mejores opciones para poder documentar y controlar su avance.
En este entendido, lo siguiente que debemos contemplar es que existen algunos artefactos que se utilizan regularmente en casi todos los proyectos, aunque dependendiendo de su naturaleza, pueden variar, a continuación veremos los más frecuentes en la metodología.
Y como es de esperar, les explicaremos brevemente cada uno.
Ya se ha mencionado en otras ocasiones dentro de la serie, ya que es la fuente principal de donde se definen los alcances del proyecto, primero en la forma de una épica que da una idea general del mismo y luego, se aterriza a historias muy concretas y puntuales, que deben contemplar cierta información básica para que puedan ser medibles para incluirse en un sprint posteriormente.
Es muy importante que cada historia refleje una parte de la funcionalidad del proyecto, debe ser independiente de las demás, lo que permite desarrollarla en su totalidad sin tener que depender de otra que le preceda, además que debe ser una unidad que pueda incluirse en el producto al final de sprint. Y no debemos olvidar que una historia de usuario no debe incluir o especificar aspectos técnicos, sólo su definición, ya que el equipo SCRUM es quien lo decide.
Una buena historia debe tener estos componentes.
Ejemplo de un formato de historia de usuario, se puede mofificar conforme se requiera.
La redacción de las historias de usuario son responsabilidad del product owner y se apoya en el SCRUM Master, para que estás sean claras y tengan los elementos necesarios, además de ser entendibles para todo el equipo y que se cuenten con los criterios de aceptación necesarios. En los casos que el requerimiento sea muy complejo, será necesario replantearlo con historias más puntuales para poderlo agregar a un sprint y sea procesado.
Este es un concepto que se aplica tanto a las historias de usuario en particular como al producto en general.
Por un lado, cada una de las historias debe contar con los criterios de aceptación, mismos que al momento de presentar el demo o incremento, se cumplen y si son aceptados por el product owner, se considera realizado. Por otra parte, se debe tener un concepto general, aceptado y conocido por todos los involucrados en el proyecto, incluso los stackholders, para reconocer si se logra este punto al finalizar la ejecución del sprint.
Este concepto debe ser práctico y aplicarse a todas las historias del product backlog, un ejemplo, en el caso de servicios, puede ser "todas las especificaciones de la historia de usuario deben cumplirse, documentarse correctamente en un formato específico e integrarse en el producto sin interferir con otras funciones"; si se trata de un proyecto de desarrollo, se puede utilizar una idea como "codificar las funciones con el standard acordado, realizar pruebas exitosas de funcionalidad e integración, realizando la documentación al 100%".
Cabe mencionar, la definición general puede cambiar conforme se revise durante el sprint retrospective y se vaya enriqueciendo con todo el equipo involucrado.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
Con las historias de usuario, se genera una lista, responsabilidad del product owner, que no requiere un orden en particular pero es de donde se jerarquizan estas historias y con base a esto, se definen los sprints durante la planeación del sprint.
Fuente: Scrum.org.
Otra de sus funciones es darle un vista al producto owner sobre el avance del proyecto y conocer las características o funciones faltantes. Es recomendable que todavía sean lo bastante genéricas y vagas para que se puedan adaptar al producto conforme avanccen los sprints, en atención al Principio de Adaptabilidad.
Lo anterior es relevente, ya que la historia original, al momento de modelarla dentro del proceso de producción, nos podemos encontrar que se deconstruye en otras historias para incluirlas en el sprint, lo que puede impliar que no haya una correspondencia exacta entre el product backlog y el sprint backlog.
En ocasiones, a cada historia se le va indicando el estado en que se encuentra (diseño, desarrollo, planeación, demo, liberado, etc.) para tener un control muy preciso de su avance individual.
Este listado es una herramienta propia del product owner, el puede compartirlo con el equipo si lo cree conveniente, pero por lo general es mejor si lo gestiona el sólo.
Se deriva del ritual sprint planning, en el que se definen las historias a desarrollar y el tiempo estimado para su desarrollo de cada una. Durante el ritual, se realiza la negociación de la prioridad y las funcionalidades a trabajar, posteriormente se le asigna una puntuación para medir la duración de cada uno y en su totalidad.
Con esto, se acomodan en un tablero en orden de importancia (o puntaje), por lo general con cuatro columnas posteriores (el formato puede variar, no existe una regla) con el que se controla el avance. Igualmente, cuando algún miembro del equipo termina con su parte encomendada, selecciona otra historia del tablero para continuar con esta; es importante que se mantenga el orden que tienen las historias, ya que están acomodadas de acuerdo a la prioridad para su atención.
Se recomienda que el tablero esté en un lugar visible, para que pueda ser consultado por todos, lo que mejora la transparencia del proyecto y ofrece un punto que mejora la comunicación del proyecto.
Fuente: Scrum.org.
Recordemos que el avance se revisa diarimente durante el ritual Standup Meeting y con frecuencia se realiza alrededor del Scrum board para mantener el foco de los entregables.
Como se mencionó al principio, los artefactos pueden ser físicos o electrónicos y en ese entendido, es perfectamente válido usar una pizarra o un tablero con tarjetas pegadas en cada sección, sin embargo, esto se presta a que se cambien de forma intencional o no su ubicación o se pierda alguna, por lo que es preferible usar alguna aplicación electrónica para este fin, aquí tenemos algunas recomendaciones.
En algunas opciones, se ofrecen opciones de paquetes gratuitos con limitaciones y las versiones de paga, que se ajustan a diferentes presupuestos, de acuerdo a cada fabricante.
Este diagrama es de los más utilizados en la metodoloigía, ya que muestra, a lo largo de los sprints, la cantidad de trabajo que se realiza en cada uno y que en escencia, permite ver el incremento de la cantidad de historias o de la complejidad de las mismas a lo largo del proceso.
Con cada entrega, se usan los puntos asignados a cada sprint para tener la referencia del puntaje acordado y del completado, lo que conforme madura el equipo SCRUM se deberá de notar que tiende a la estabilidad, es decir, que cada vez el puntaje de historias concluídas es menos errático. Eventualmente, el cálculo de las entregas será más preciso y se podrán comprometer de forma específica estas últimas.
Es muy importante notar que esta herramienta no necesariamente debe ir incrementando el puntaje de historias que se completan, sino que es una métrica para determinar la estabilidad del equipo, por lo que es normal que llegado a un punto, se note el puntaje medio que realmente puede comprometer el equipo.
Fuente: Workfront.com.
Si una historia no fue completada durtante el sprint, no se considera ya que no cumple con el criterio de terminado, por lo que no se contabiliza.
Este es un gráfico de avance que se genera diariamente, por lo general posterior al standup meeting, que es responsabilidad del SCRUM master y permite verificar el avance del equipo con respecto a los entregables y calcular la conclusión de los entregables. el puntaje puede ser calculado por el valor de la historia o por las actividades de cada participante.
Por lo regular, esta gráfica tiene una línea en diagonal que comienza en el extremo de la línea superior izquierda y termina en la inferior derecha, que es la referencia del trabajo que se debe realizar para concluir el sprint. Las columnas o barras representan los puntos o esfuerzo que el equipo realiza para concluir con sus historias y en principio, cada día debe tener una barra más pequeña que el previo conforme se vayan terminando las historias, hasta que se encuentren en cero; es infrecuente que una barra se incremente, pero se puede deber a algunas condiciones como un bug que se identificó al finalizar una historia y es necesario corregirlo, que se le denomina Scope Creep.
Fuente: Wikipedia.
Es muy importante notar que el incremento de las barras de forma regular es una alerta sobre el proceso mismo, indicando que no se están definiendo correctamente los alcances de las historias o que se realizan cambios en las mismas una vez inciado el sprint.
Este es artefacto final con el que cerramos ese artículo, al igual que todos los sprints. Escencialmente, al terminar las historias e integrarlas en elsprint demo, pasan a la etapa de revisión y una vez que se revisan y se considera que cumple con los criterios de aceptación (definición de terminado), es incorporado en el producto final, con lo que se convierte enun artefacto por si mismo.
En este punto y dependiendo de sus características, puede ser liberado para la revisión de las áreas usuarias o utilizado para pruebas de operación, lo que a su vez, cumple con el principio de liberación constante.
Hemos revisado los artefactos que se utilizan de forma regular en un sprint, con la idea que puede ser lo bastante flexiblepara que se modifique su presentación o forma de generación para adecuarse a la operación de cualquier equipo de trabajo, pero que mantengan el espíritu de una gestión flexible, transparente y eficiente.
En nuestro próximo artículo, comentaremos sobre la incorporación de grandes equipos de SCRUM en la organizción de proyectos de grandes dimensiones en cualquier industria.
Tu opinión