User Stories: Definition of done.
Si no puedes entender el resultado que se espera de tu trabajo, entonces no puedes manejar tu trabajo. Uno de los mayores dolores de cabeza que tienen las personas involucradas en el desarrollo de software es la ambigüedad en la descripción de las tareas. Primero, la falta de contexto, si la descripción de la tarea no logra posicionar que se necesita, como se necesita y que necesidad se busca resolver, cada persona involucrada puede entender lo que quiera.
En un escenario donde las descripciones de las actividades son escasas o nulas. Un desarrollador puede entender una tarea, resolverla de acuerdo a lo que él cree que es el problema y luego finalizarla a como él o ella entienda, ¿en qué momento alguien se aseguro que se está entregando el valor correcto al usuario?, la respuesta es nunca. El fallo comienza desde la descripción de la actividad, nadie especifico el resultado esperado. La probabilidad de que alguien genere desperdicio resolviendo un problema con una descripción pobre se incrementa, la probabilidad de que se entregue el producto equivocado es igual de alta. Para evitar esto, cada actividad sin importar lo sencilla y baladí que sea debe tener una «definición de hecho» (definition of done).
¿Qué es la definición de hecho?.
La definición de hecho es un párrafo que se adjunta en cada actividad que indica como se va a verificar que el trabajo ya fue completado. De ser posible redactarlo en un lenguaje no técnico y desde la perspectiva del usuario. Puedes describir una acción condicional, por ejemplo: para que la actividad se considere terminada no debe poder reproducirse este error en el ambiente. También puedes agregar un momento en el tiempo, por ejemplo: para que la actividad se considere terminada debe ejecutarse la matriz de pruebas y ser liberado en producción.
Lo importante es que la actividad sea auditable, vas a alejarte de los yo pensé, yo creía, yo supuse… para dar mecanismos que creen confianza y expongan transparencia en tu trabajo. Cualquiera puede ver la actividad y comprobar que ya fue terminada o no, no importa si es desarrollador o es de otra área.
Actividades sin definición de hecho generan desperdicio.
Cuando no hay una definición de hecho redactada, cada persona puede interpretar cuál es el resultado esperado. Mientras que el programador o programadora puede suponer que la actividad termina luego de hacer commit en el repositorio, el product owner puede suponer que es hasta que el cambio llega a producción y sé válida. El cliente puede suponer que es hasta que se da el visto bueno, cualquier respuesta aplica. El problema está cuando se obvian estos detalles y la gente que espera recibir el valor de tu trabajo no lo recibe porque alguien no fue claro. Si existe ambigüedad se incrementan las posibilidades de que lo que se espera, lo que se construyo y lo que se definió no sean la misma cosa. Esto te lleva a tirar trabajo porque hay que reconstruir cosas.
Actividades sin definición de hecho te exponen como incompetente o perezoso.
El re trabajo es parte del mundo del desarrollo del software, pero, el re trabajo sistemático en un área de desarrollo no es sano. Tener actividades atoradas en el tablero por semanas o correos electrónicos con rollbacks no ayudan a generar confianza hacia tu trabajo. El principal culpable de un fallo vas a ser tu como desarrollador, independientemente de si tienes la culpa o no, va a llegar el momento en el que deberás justificar tu trabajo y exponer el porqué tomaste las decisiones.
En un escenario donde tienes una definición de hecho puedes argumentar que hiciste lo que se te pidió, aunque esto no sirva, es posible, sucede todo el tiempo, no está mal. Lo malo es que los demás no puedan entender el porqué de tus acciones al momento de entregar el trabajo. En un escenario donde se platico que se necesitaba o se menciono en una reunión y todo mundo quedo de acuerdo vas a tenerla muy difícil para defender tu trabajo. Un enfoque transparente acerca de lo que haces ayuda a detectar fallos antes de que sean demasiado caros.
Redactar una definición de hecho, cuesta poco, muy poco.
El coste de una redacción mínima en tus items de trabajo es poco, unos minutos al día te permitirán tener en punto óptimo tu tablero. Esto ayudará a que todos puedan ver el trabajo que se hace, que tanto cuesta y que tan efectivo eres al momento de entregar trabajo. Puedes ser muy efectivo, pero si nadie puede verlo entonces es igual a no serlo. No veas la redacción de tu definición de hecho como un gasto, velo como una inversión.
Autor imagen: Tatiana Vdb
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
Una respuesta a «User Stories: Definition of done.»
Los comentarios están cerrados.