Definición de Hecho en Ágil

Definición de Terminado

¿Con qué frecuencia ha escuchado a alguien decir que algo está hecho, pero cuando mira más de cerca, realmente no está hecho? Quizás un niño dice que ha terminado de limpiar su habitación, pero todavía quedan algunos calcetines debajo de la cama. O un estudiante dice que ha terminado con su proyecto de ciencias, pero todavía necesita armar la carpeta que contiene toda la información sobre el experimento. O alguien dice que terminó de empacar para un viaje, pero olvidó su pasaporte.

En cada uno de esos casos, la persona no había terminado realmente con lo que estaba haciendo. Casi habían terminado. En el desarrollo de software ágil, los desarrolladores a menudo usan algo llamado definición de hecho (DoD) para determinar cuándo realmente terminaron con una pieza de software.

El desarrollo de software ágil es una forma de desarrollar software que se centra en producir pequeñas piezas de funcionalidad a un ritmo rápido y con comentarios frecuentes de los clientes. Esto es diferente de los métodos de desarrollo tradicionales que podrían hacer que un equipo pasara meses trabajando en una gran aplicación, solo para descubrir que lo que construyeron no era realmente lo que el cliente quería.

Esta lección explicará por qué es importante una definición de hecho y proporcionará un modelo que puede seguir para preparar su propio DoD. Tenga en cuenta que el Departamento de Defensa de un equipo será exclusivo de las circunstancias y el tipo de trabajo de ese equipo. Esta lección presenta un ejemplo, no instrucciones estrictas que todo equipo debe seguir al pie de la letra.

Elaborar una definición de hecho

Para ayudar a comprender qué es una definición de hecho, imagina que eres parte de un equipo de desarrollo que es contratado por un gran estudio de música. El gerente del estudio quiere que su equipo desarrolle una aplicación web que ayude al estudio a rastrear qué canciones y artistas se están vendiendo mejor. El primer requisito que le da es el siguiente:

• La página de búsqueda de la aplicación debe proporcionar campos de texto que permitan a los usuarios buscar un artista utilizando el nombre y apellido del artista.

Esto parece bastante simple, por lo que su equipo se pone a trabajar rápidamente. Dos semanas después, regresa y le muestra con orgullo al gerente del estudio una página de búsqueda con un campo de texto donde el usuario puede ingresar el nombre del cantante que desea buscar. Uh-oh, espera. El gerente solicitó campos para el nombre y apellido, pero solo proporcionó un campo.

El producto final no cumple con las expectativas del gerente, por lo que rechaza la página de búsqueda y usted tiene que regresar y arreglarlo. Este descuido provocó una pérdida de tiempo por ambas partes y una pérdida de dinero para el estudio de música. Para evitar repetir este error, su equipo pega una hoja de papel en la pizarra donde todos puedan verla. El documento dice: ‘Asegúrese de hacer todo lo que dice el requisito. ‘

Después de presentar una página de búsqueda con el número correcto de campos de texto, el gerente le da a su equipo su siguiente requisito:

• La aplicación debe poder utilizarse tanto en pantallas de ordenador grandes como en pantallas de dispositivos móviles pequeños.

Su equipo vuelve a trabajar, asegurándose de hacer todo lo que dice el requisito, y después de dos semanas más, le muestra con orgullo al gerente lo bien que se ve la aplicación tanto en su computadora de escritorio como en su teléfono móvil. Pero cuando le pide a un empleado cercano que mire la aplicación en su propia computadora, ve que las cosas no están alineadas correctamente y algunas fuentes no se ven bien. Entonces nota que el empleado está usando un navegador de Internet diferente al del gerente. Otro error de su equipo: olvidó probar la aplicación web en diferentes navegadores. Técnicamente, cumpliste con el requisito del gerente al pie de la letra, pero él no sabe mucho sobre desarrollo web (por eso te contrató), por lo que tu equipo no puede depender de tener todos los detalles técnicos detallados en los requisitos. Cuando regrese a la oficina,Prueba en los principales navegadores. ‘

Después de arreglar la aplicación web para que funcione en todos los navegadores principales, el administrador le da a su equipo otro requisito:

• La página principal de la aplicación debe mostrar el logo del estudio.

El administrador le proporciona el archivo de imagen con el logotipo y usted lo guarda en la carpeta C: MyExcellentFiles de su computadora. Luego, escribe un código que le dice a la aplicación que busque en C: MyExcellentFiles la imagen del logo. Pruebas la aplicación en tu computadora, y la página principal con el logo se ve bien, entonces tu equipo va al gerente y le pide que verifique si le gusta cómo configuras el logo. Pero cuando abre la aplicación en su computadora, todo lo que ve es un espacio vacío donde debería estar el logo.

Te das cuenta del problema: la carpeta llamada C: MyExcellentFiles es una carpeta personal que creaste en tu propia computadora, pero esa carpeta no existe en la computadora de nadie más. Cuando la aplicación busca el archivo del logotipo, no puede encontrar la carpeta C: MyExcellentFiles en la computadora del administrador, por lo que simplemente deja esa parte de la página web vacía. Avergonzado, su equipo regresa para solucionar el problema y agrega otro recordatorio a la hoja de papel: ‘Todos los archivos requeridos deben guardarse en la carpeta de la aplicación, no en una carpeta personal. ‘

Su equipo finalmente finaliza la aplicación web y luego se reúne para discutir qué podrían haber hecho mejor con ese cliente. Un miembro del equipo toma la hoja de papel de la pizarra y sugiere: “Cada vez que pensamos que habíamos terminado, resultó que en realidad nos perdimos algo. Necesitamos asegurarnos de que cada uno de estos (señala los tres recordatorios) esté marcado antes de decir que realmente hemos terminado ‘. El resto del equipo está de acuerdo, pegan el papel a la pizarra y agregan un título en la parte superior: Definición de Listo .

Resumen de la lección

Una definición de hecho es una lista de verificación de criterios específicos que deben cumplirse antes de que se considere que una pieza de software está completa.

• La definición de hecho de un equipo debe adaptarse a sus circunstancias particulares.
• No tener, o tener pero no seguir, una definición de hecho puede llevar a una pérdida de tiempo y dinero, y a clientes insatisfechos.
• La definición de hecho puede crecer a medida que los desarrolladores identifican nuevos problemas que afectan la satisfacción del cliente.

Rodrigo Ricardo Editor y fundador