Costa Rica se ha convertido en el paraíso para las empresas de tipo Agencia. Y no es de extrañar pues tenemos en nuestras tierras a creativos muy talentosos, desarrolladores de front-end y back-end muy habilidosos. Al día de hoy, muchas agencias de Estados Unidos externalizando todo su desarrollo de software a Costa Rica.

Quiero presentar en este post algunos retos que afectan el ciclo de vida de desarrollo de software en empresas tipo agencia. Aún si su empresa no es tipo Agencia, notará males que aquejan al desarrollo de software en general.

La raíz de los retos que presentaré yace en una mala ejecución del Aseguramiento de la Calidad.

La pesadilla al especificar requerimientos

Calidad es el cumplimiento medible de lo especificado en lo producido. Con el fin de tener un claro entendimiento de lo que el cliente quiere, se pueden usar algunos artefactos tradicionales para especificar requerimientos visualmente: Wireframes y Guías de Diseño Visuales. Hay pros y contras sobre el uso de wireframes, pero asumamos que usted los usa para especificar User Stories.

Los problemas más comunes que he visto en las empresas que usan este forma de trabajo son:

• No hay un artefacto dedicado a especificar comportamiento de los requerimientos. Esto deja la puerta abierta a que los desarrolladores empiecen hacer supuestos sobre el flujo que un requerimiento tiene. Esto es un hueco en la Calidad.
• Ningún artefacto de especificación visual obtiene la aprobación del cliente antes que empiece el desarrollo. Normalmente esto pasa porque el cliente tiene muchos requerimientos, todos de la misma alta prioridad (que al final es lo mismo decir que no tienen prioridad) y quiere wireframes para todos esos requerimientos. Al mismo tiempo se siente la presión del tiempo, los desarrolladores se comprometen a implementes requerimientos incompletos o no totalmente claros cuyas especificaciones cambian mientras están siendo desarrolladas. El equipo de desarrollo es penalizado por este retraso. En Kanban, estos serían los cuellos de botella en el flujo del valor: 1) Muchas tarjetas kanban en un mismo estado, 2) una tarjeta kanban se mueve a la siguiente sin estar lista para ello.

El Aseguramiento de la Calidad ‘paga los platos rotos’

El mayor error es confundir Control de Calidad con Aseguramiento de Calidad. Muchas empresas lo que es solo Control de Calidad, y algunas lo hace muy pobremente:

• El Control de Calidad de nuevos requerimientos no es intencional. No hay un sistema que lleve rastro de las nuevas funcionalidades a las que hay hacerles pruebas para luego ser agregadas al repositorio de pruebas de regresión. Cada vez que se piden estimados para nueva funcionalidad, no se toma encuentra de forma seria el tiempo necesario para control de calidad, dejando en el mayor de los casos una cantidad fija y arbitraria de tiempo para ‘QA’.
• Las pruebas no son automatizadas del todo. Correr una prueba de regresión completa requiere de varios días de esfuerzo manual.
• No hay un límite explícito para la capacidad de resolución de defectos reportados por el cliente a largo de todos los Sprints.  No hay un acuerdo en la esfuerzo máximo semanal/mensual que se puede dedicar a la resolución de pulgas externas al Sprint. No tener este límite elimina la predictibilidad y cadencia de todo el flujo de control de calidad.
• El equipo de testing se siente forzado a dejar de lado la parte esencial del Aseguramiento de Calidad para enfocarse completamente en Control de Calidad. Deja de hacer tareas preventivas como crear y automatizar de antemano las Pruebas de Aceptación para los desarrolladores.
• Si el cliente tiene por su parte un equipo de testing para certificar que lo entregado es lo que se pidió: ¿Contra qué ese equipo está certificando calidad? ¿Está ese equipo usando los mismos artefactos de especificación que usted usó para crear la nueva funcionalidad?
• Establezca un Límite para el Trabajo en Curso (Work In Progress Limit o WIP limit) para la etapa de especificación, concéntrese en finalizar (obtener aprobación del cliente ) de un artefacto de especificación a la vez. Solo wireframes y guías visuales completar establecen la señal para el inicio de su desarrollo. ¡Priorice tomando en cuenta su WIP limit!
• Utilice una herramienta de Behavior Driven Development para especificar funcionalidades de la aplicación y escenarios de usuario tal como Cucumber, cuyos escenarios tienen la feliz naturaleza de ser potencialmente ejecutables.
• Incluya el esfuerzo de Aseguramiento de Calidad en los futuros estimados para nueva funcionalidad.
• Establezca un límite superior al esfuerzo dedicado al manejo de defectos reportados por el cliente.
• Junto con el producto terminado, entregue al cliente todos los artefactos de especificación usados para crear la nueva funcionalidad.
• Empiece esfuerzos por automatizar aunque sea algunas partes o algunas pruebas de regresión. Una Buena forma de empezar es crear y soportar la ejecución de las especificaciones de Cucumber.

Ítemes de Acción que me han funcionado

• Establezca un Límite para el Trabajo en Curso (Work In Progress Limit o WIP limit) para la etapa de especificación, concéntrese en finalizar (obtener aprobación del cliente ) de un artefacto de especificación a la vez. Solo wireframes y guías visuales completar establecen la señal para el inicio de su desarrollo. ¡Priorice tomando en cuenta su WIP limit!
• Utilice una herramienta de Behavior Driven Development para especificar funcionalidades de la aplicación y escenarios de usuario tal como Cucumber, cuyos escenarios tienen la feliz naturaleza de ser potencialmente ejecutables.
• Incluya el esfuerzo de Aseguramiento de Calidad en los futuros estimados para nueva funcionalidad.
• Establezca un límite superior al esfuerzo dedicado al manejo de defectos reportados por el cliente.
• Junto con el producto terminado, entregue al cliente todos los artefactos de especificación usados para crear la nueva funcionalidad.
• Empiece esfuerzos por automatizar aunque sea algunas partes o algunas pruebas de regresión. Una Buena forma de empezar es crear y soportar la ejecución de las especificaciones de Cucumber.

Algunos consejos extra

Mantenga una constante y despiadada cacería de cuellos de botella en su flujo de valor.

Sea firme con su cliente y diga: “No podemos empezar desarrollo de nuevas User Stories si no están completamente entendidas y acordadas por todas las partes.”

Evite el Parálisis del Análisis: No es necesario tener completamente especificada cada User Story del Product Backlog, solo aquellas que serán desarrolladas en el próximo Sprint. Reconozca el hecho que el resto del Product Backlog inevitablemente cambiará, así que no desperdicie tiempo en definir detalles que serán desechados.

Los artefactos de especificación son habilitadores de conversación, no substitutos de conversación.

Continúe hablando con su cliente para refinar y manejar detalles inesperados que aparecerán durante el Sprint.

El Aseguramiento de la Calidad es una responsabilidad del equipo entero, el mayor mérito consiste en prevenir defectos.

Vigile muy cercanamente la calidad del código durante los Sprints.