Una prueba vale más que mil opiniones de

expertos.

 Bill Nye, El individuo de la ciencia

Capítulo 5

Realimentación Ágil
En un proyecto ágil, nosotros siempre estamos buscando realimentación con
el fin de hacer algunos pequeños y continuos ajustes. Pero ¿De dónde viene
toda esta realimentación?

En el capítulo anterior hablamos acerca de cómo trabajar estrechamente con

los usuarios, para obtener una buena realimentación de ellos y actuar
consecuentemente. En este capítulo hablaremos principalmente de cómo
obtener realimentación por otros medios. Como Bill Nye nos dice: Las pruebas
de cualquier clase son definitivas. Nosotros implementaremos esa idea para
asegurarnos de que usted siempre sepa el estado de su proyecto y no tenga
que adivinarlo.

Muchos proyectos tienen errores debido a que el código base está fuera de
nuestras manos. Corregir errores genera más errores, lo cual hace que se
generen más correcciones y por ende más errores, y todo comienza a caer
como un castillo de naipes. Necesitamos un monitoreo constantemente, una
constante realimentación para estar seguros que el código base no se ha
deteriorado y continúa trabajando bien como la última vez o mejor. Usted lo
verá en Ponga Ángeles Sobre Sus Hombros comenzando a partir del capítulo
19.

Pero eso no le impide diseñar una interfaz o una API que es complicada o
difícil de usar correctamente. Para ello, tendrás que Usarlo Antes De
Construirlo (el cual se inicia en el capítulo 20).

Pero por supuesto, sólo porque trabaje para la prueba unitaria en su máquina
no significa que automáticamente funcionará igual en cualquier otra máquina.
Ver por qué La Diferencia Hace La Diferencia a partir del capítulo 21.

Ahora que usted tiene APIs bastante buenas y un código limpio, podría ser
una buena idea para asegurarse de que el código realmente produce los
resultados que los usuarios esperan. Usted puede Automatizar Las Prueba De
Aceptación para asegurarse de que el código es correcto, y permanecerá de
esta forma. Eche un vistazo al capítulo 22.
Todos quieren ver el progreso de un proyecto, pero es fácil extraviarse
observando indicadores engañosos o siendo víctima de una falsa autoridad de
un bonito diagrama de Gantt o PERT o una buena herramienta de calendario.
En su lugar, Mida el progreso real, le mostraremos cómo en el capítulo 23.

Aunque hemos hablado acerca de cómo trabajar con los usuarios para obtener
realimentación durante el desarrollo, hay otro momento, tiempo después de
que el producto ha sido lanzado cuando se necesita una vez más, Escuchar A
Los Usuarios y esto se explica a partir del capítulo 24.