Detección de requisitos débiles en el proceso de construcción

Cuando se escribe una historia de usuario, un catálogo de requisitos o cualquiera que sea la solución que se utilice para dejar escritas unas especificaciones resulta muy complicado por mucho que se le den muchas vueltas que todos los huecos queden cerrados.

Como siempre os digo tenemos que actuar con intención por ese motivo no vale con una sola lectura de esas especificaciones, es necesario que varias personas (que hayan intervenido en su definición) la vean y la discutan si es preciso.

Pero aún así, llegarán requisitos débiles al proceso de construcción y ahí serán los programadores y las personas que estén revisando su trabajo los que tienen que levantar la mano cuando descubran especificaciones inconsistentes, incoherentes con otras o insuficientes para poder desarrollar una funcionalidad sin que el programador se tenga que inventar parte de ella (si hay que inventar que lo haga el usuario ya que tendremos más posibilidades de acertar).

Es importante que lo programadores sepan que su misión no solo es escribir código (de la mejor manera posible) sino entre sus tareas también se encuentra detectar esas fallas en las especificaciones. Para ello es necesario que sepan qué es lo que están haciendo, que conozcan al menos la parte del negocio que compete al módulo que están desarrollando. Esto resulta también importante a la hora de realizar testing sobre las funcionalidades que desarrollan.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: