Lista de Chequeo Scrum

Clic sobre la imagen para ampliar. Clic para [Descargar] la Lista de Chequeo Scrum

De las muchas listas de verificación que encontré, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.

Esta es la traducción al español.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum, o para evaluar tu actual implementación de Scrum.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum, pero se aseguraron de que el propósito de la práctica Scrum se cumplió de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la Retrospectiva como una herramienta de discusión, no como una herramienta de evaluación.

¿Cómo la uso?

•        Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”.

•        Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad”.

•        Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado, pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.

•        Lisa: “Mira, también nos hace falta ‘Entregar producto funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque Mercadeo siempre se está quejando de eso!”

•        Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido.”

•        Lisa: “Buena idea, intentémoslo.”

¿Cómo NO la uso?

•        Gran Jefe: “Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”

•        Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”

•        Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del sprint! ¡Las quiero ver!”

•        Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario”.

•        Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”

¿Es esta una lista de chequeo oficial?

No. La lista de chequeo refleja mi opinión personal y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Descargar la lista de chequeo Scrum

Puedes descargar la lista en formato PDF aquí.

Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puedes leer este artículo:

"Scrum: lo fundamental" en:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

¿Por qué existe Casos de Uso 2.0?

Necesitamos prácticas que nos apasionen y que se enfoquen en las personas sobre los procesos pero que además nos posibiliten resultados de calidad. Necesitamos además que nuestro trabajo sea aún más colaborativo y permita una integración unificada, continua. Precisamos de un enfoque que permita bajar la tensión “ellos versus nosotros” entre desarrolladores y verificadores.

Requerimos prácticas que nos licencien para manejar mejor los cambios y que nos habiliten para entregar productos de manera incremental. Y también necesitamos prácticas que soporten un mejor manejo del conocimiento de los productos que construimos y que nos apoyen cuando hacemos frente a situaciones adversas, que nos permitan mantenernos enfocados en lo que es de valor para nuestro cliente.

Casos de Uso 2.0 es precisamente eso, una práctica escalable y ágil que usa casos de uso para capturar un conjunto de requisitos y conducir el desarrollo incremental de un sistema que los ejecute. Casos de Uso 2.0 se reenfoca en lo esencial y ofrece una forma de trabajo liviana y más limpia para que los equipos de software logren los beneficios del desarrollo iterativo e incremental a un nivel corporativo.

Pero para llegar más al corazón de Casos de Uso 2.0, necesitamos mirar la radiografía de los casos de uso: ¿Qué hizo tan popular a los casos de uso? Con el tiempo, los casos de uso alcanzaron un uso multitudinario porque comunican efectivamente lo que el sistema debe hacer, porque ponen los requisitos en el contexto de las metas de un usuario específico y porque conducen el desarrollo a través del diseño, el código y, si se quiere, las pruebas.

En el fondo, el modelado de casos de uso es una idea muy simple. Esto quiere decir que con Actores, Casos de Uso, Inclusiones y algunos otros artilugios podemos llegar al núcleo de lo que el sistema debe hacer, porque nos enfoca inequívocamente en quién (o qué) usará el sistema y nos permite encontrar con rapidez asombrosa lo que el sistema debe hacer para que ese quién logre algo útil en su proceso de negocio.

Otra pregunta que debemos responder antes de dar el salto de versión es ¿por qué necesitamos casos de uso todavía? Si hay muchas otras prácticas relacionadas de requisitos populares, ¿por qué estás no han reemplazado la necesidad de casos de uso? Por ejemplo, las historias de usuario son grandiosas para sistemas pequeños y equipos pequeños, aunque bien es cierto que con pequeños incrementos podemos construir un sistema grande.

También hay otros enfoques, como la especificación de características, fabulosa para manejo de productos; los tradicionales requisitos declarativos, excelsos para capturar cualidades independientes atómicas; el modelado de dominio, extraordinario para sistemas de funcionalidad simple y ricos en información. Sí, hay muchas otras buenas técnicas pero a todas les hace falto algo para reunirlas y proporcionar una solución simple y escalable.

Ahora sí, ¿por qué necesitamos casos de uso 2.0? En principio, para corregir algunos de los malentendidos:

• Los casos de uso son livianos, no pesados
• Los casos de uso son historias, no funciones
• Los casos de uso son simples, no complicados
• Los casos de uso son para todo tipo de desarrollo, no solo para desarrollo de aplicaciones nuevas y “planas”.
• Para reenfocarnos en lo esencial, de vez en cuando viene bien un refrescamiento de ideas y de experiencias.
• Para dar un mejor soporte a las innovaciones y mejoras tales como Desarrollo Dirigido por Pruebas (TDD), Kanban y Scrum.

Lo que hace distintivo a Casos de Uso 2.0 es que nos ayudan a entender el cuadro completo, es una práctica tan liviana como queremos que sea, habilita la entrega incremental del producto, no es solo sobre requisitos, es para todo el ciclo de vida, también es para requisitos no funcionales, para software embebido, incluso no es solo para desarrollo de software, también es para desarrollo de negocios y, finalmente, es escalable en todas las direcciones para cubrir cualquier necesidad real.

Como siempre, cuando se trata de procesos y métodos, aconsejo no desvirtuar la capacidad que tenemos los seres humanos de pensar. Lo que posibilitan las técnicas es precisamente potenciar nuestra habilidad para encontrar el mejor siguiente paso en el camino hacia la satisfacción. Al final de cuentas es el cerebro humano el que visiona productos e ideas, ninguna tecnología ni método puede reemplazar nuestro proceso de pensamiento.


Referencias

El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.

Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario IT:

Casos de Uso 2.0

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html 

Casos de Uso 2.0 y Métodos Ágiles

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html 

Casos de Uso 2.0: Cosas con las cuales trabajar

http://www.gazafatonarioit.com/2012/11/casos-de-uso-20-cosas-con-las-cuales.html 

Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, IV

Al escribir el caso de uso deben evitarse sinónimos “técnicos” para Sistema como “programa”, “módulo”, “rutina”, “función”, “procedimiento”, “procedimiento almacenado” y “subrutina”. Como en:

n. El programa solicita la fecha de ingreso

n+1. El actor proporciona la fecha de ingreso

n+2. El módulo calcula el número de días laborados hasta la fecha

Algunos de estos términos son usados de manera indistinta donde debemos usar siempre “sistema”, otros se usan en pasos específicos donde normalmente estamos suministrando información técnica que no es responsabilidad de los casos de uso, como cuando hablamos de procedimientos almacenados o de rutinas.

Simplemente usamos el término “sistema”.

Ejemplo

Consideremos el siguiente caso de uso de la Web 2.0, relacionado con la publicación de entradas en un blog:

Caso de Uso: Publicar Artículo

Actor: Bloguero

Descripción: este caso de uso permite crear una entrada para su publicación en un blog específico de la Web.

Precondiciones:

1.     El Bloguero está debidamente acreditado ante el Sistema

Secuencia Básica:

1.     El caso de uso inicia cuando el Bloguero opta por publicar un nuevo artículo

2.     El sistema solicita el título del artículo

3.     El Bloguero ingresa el título del artículo

4.     El sistema solicita el cuerpo del artículo

5.     El Bloguero proporciona el cuerpo del artículo

6.     El sistema solicita las palabras clave con las cuales indexar el artículo

7.     El Bloguero ingresa las palabras clave del artículo

8.     El sistema verifica que el título del artículo no existe y solicita confirmación para publicar la entrada

9.     El Bloguero confirma la publicación del artículo

10.   El sistema publica el artículo

11.   El caso de uso termina

Secuencia Alterna 1: el título de la publicación ya existe

8A. El sistema muestra el mensaje “El título del artículo ya existe. Por favor, verifique.”

8B. El caso de uso continúa en el paso 2 de la secuencia básica

Secuencia Alterna 2: el Bloguero cancela la publicación del artículo

9A. El Bloguero cancela la publicación de la entrada al Blog

9B. El caso de uso termina

Poscondiciones:

1.     La entrada se puede modificar durante los siguientes 30 minutos.

2.     El artículo puede ser leído por los lectores del blog.

Nótese que en todo momento sabemos qué hace el sistema y qué hace el actor.

Ecos del Simposio Latinoamericano de Ingeniería de Software

Aunque ya pasó algún tiempo desde que escribí este artículo, el tema de Semat está cobrando vida y afectará el futuro de la Ingeniería de Software como la conocemos hoy. Por consiguiente, impactará en la manera cómo hacemos Ingeniería de Requisitos, en particular, y el universo de los métodos de software en general.

Este es un brevísimo resumen de lo que pasó durante los dos días del simposio: los temas expuestos, la presencia del experto internacional Ivar Jacobson, la creación del capítulo para Latinoamérica de la iniciativa SEMAT, una revolucionaria propuesta que el mismo Jacobson apoya junto a otros prominentes miembros de la industria del software y que busca refundar la ingeniería de software con una teoría sólida, principios probados y mejores prácticas refinadas.

El artículo completo lo pueden descargar en:


https://docs.google.com/file/d/0B5SNac-eZKMMdGY2V2xZVnFtQXc/edit?usp=sharing

El sitio de Semat Central es: http://www.semat.org.