¿Cuando una Historia de Usuario está Terminada? Cada persona puede tener criterios o interpretaciones distintas para considerar terminado o a medio hacer algo. Es por esto que surge en el desarrollo Ágil de Software el concepto de "Definición de Terminado" (DdT), que básicamente son las pautas mínimas para que algo pueda considerarse terminado.
En este artículo les mostramos nuestra DdT acompañada por comentarios que pueden servirles si lo que están buscando es unificar el criterio de Terminado en sus equipos.
Calidad de Software
El software que entregamos tiene calidad productiva. Eso es lo que buscamos desde que empezamos a implementar Scrum + XP en nuestro equipo. Y uno de los pilares para lograrlo es mantener una Definición de Terminado que guía nuestro desarrollo. Con el pasar de los años fuimos refinandola, sacando partes, agreando otras. Así que les presento nuestra DdT al día de hoy, con algunas notas para explicar la razón de ser de algunos puntos.
Definición de Terminado
El software que entregamos tiene calidad productiva
Por historia de usuario
- Cumple el requerimiento funcional (si no hubiese definición de usuario, cumple con lo asumido por el equipo)
- Comprobación cruzada de la DDT y HTD (otro integrante del equipo corrobora lo hecho en la historia)
- Funciona en entorno de Desarrollo
- Diseño: diagrama de componentes de alto nivel de la aplicación, mostrado en la demo
- Diseño: diagrama de clases con Services y DAO (y métodos públicos)
- Diseño: diagrama de clases con el modelo de dominio
- Diseño: diagrama de clases de la presentación
- Contrato definido y probado para todos los Services y DAO
- TDD (Test-driven development)
- Pair Progamming
- Tareas de build en Ant, armadas y mantenidas con NetBeans
- Hudson "Ok" (Herramienta de integración continua) en color "Azul"
- Probado por el desarrollador (ver lista detallada más abajo)
- Probado en Firefox 3.x y en Internet Explorer 7 y 8
- Cumple con los parámetros básicos de usabilidad (ver lista detallada más abajo)
- 100% de cobertura (Services y DAO) en desarrollos nuevos
- 0 advertencias de Checkstyle
- 0 advertencias de PMD
- Scripts para la Base de Datos completos
- Scripts y documentación completa para la demo
- Integrado con Sistemas de Integración externos
- Documentación subida al directorio /doc del proyecto en el SVN
- Propiedades del proyecto configurables en archivos .properties cuando sea posible
- Prueba manual por parte de alguna persona externa al proyecto
- BDD (Behavior-driven development) en html con los casos funcionales de la historia
Generales
- Manual de Instalacion al finalizar el Sprint
- Tag o Revisión en SVN por item del backlog documentada en la wiki interna del proyecto
- Wiki completa al inicio y fin del Sprint
- DdT Demostrada durante la Demo
- Historias y tareas de investigación demostradas durante la Demo
Pair Programming
Siempre debemos hacer Pair Programming. Luego a veces no somos pares y entonces ¿que hacemos?, seguimos trabajando, la idea es que en la mayoría del tiempo estemos trabajando en parejas y en pocas ocasiones no lo hagamos cuando:
- Seamos impares en el equipo
- Alguna persona falte
- Alguna persona esté haciendo teletrabajo
Lista de comprobación de "Probado por el desarrollador"
Casos generales y comunes a probar en una pantalla
- Caso correcto (que funcione!)
- Vacios en campos obligatorios
- Usar alfanuméricos en campos numéricos
- Validaciones haciendo copy-paste en el campo
- Fechas en todos los formatos y rangos posibles
- Case sensitive
- Campos de texto con espacios
- Caracteres "raros" (ñ, acentos, etc.)
- Verificar datos guardados en la base de datos
- Probar botones de "siguiente" y "volver"
- Utilizar plug-in de Firefox para problemas JavaScript
- Mensaje de error coherente para el error cometido
- Botón de refrescar del navegador
- Botón de volver del navegador
- Seguridad de la página activada
- Logs de la aplicación comprensibles
- Probar en la resolución de pantalla del usuario
- Para el buscador:
- con y sin el uso del buscador
- paginado
- Probar el comportamiento de la pagina al llenar los campos en un orden diferente al natural, por ejemplo empezando por el ultimo.
Lista de comprobación de "Usabilidad"
Parámetros comunes de usabilidad de nuestras aplicaciones web.
- Textos en castellano
- Colores y estilos unificados
- Evitar el scroll horizontal
- Evitar la paginación de resultados
- Usar tooltips en los campos de ingreso no obvios
- Todas las pantallas con botón "Volver" o "Cancelar"
- Nombres de botones distintos para acciones distintas
- Botones de confirmación al final del formulario
- Campos obligatorios con valores fijos siempre con defaults sensatos
- Usar defaults sensatos
- Combos ordenados alfabéticamente
- Combos / Buscadores con código y descripción
- Tabs ordenados
- Ocultar campos que no se puedan completar
- Usar mensajes de error descriptivos
- Avisar ante operaciones que demoren mucho tiempo (Cargando...)
- Focus inicial en donde corresponda
- Agregar tooltip a los botones con imágenes
- Agrupar los campos relacionados
Conclusiones
Lo que nos permite tener esta DdT son los criterios mínimos de aceptación comunes. Importante mencionar que son "minimos". Es decir, todo lo que se pueda implementar y mejore esta DdT es totalmente bienvenido y deseable. En el caso de que funcione bien, evaluamos la posibilidad de agregarlo a la DdT de todos nuestros proyectos.
Tal como les mencionaba antes, esta lista fue evolucionando. Por ejemplo, hace unos meses nuestras aplicaciones webs debían contar con test de Selenium que recorran la aplicacion y corroboren su estado general. Mecanismo que ahora reemplazamos con pruebas cruzadas con externos al proyecto por diferentes razones (sobre todo problemas de mantenibilidad de los test de Selenium, frágiles ante cambios en la presentación).
La DdT debe existir y es importante tener en claro que no es estática en el tiempo. Al comenzar un Sprint el equipo de desarrollo debe acordar cuál será la DdT que van a utilizar en el mismo y es responsabilidad del equipo asegurarse de que se cumpla.
Para terminar, cuál es la definición de terminado que utilizan en sus equipos?
