Seleccionar página

Calidad software en servilletas de papel

Insights -> Tendencias y Actualidad

Requisitos software …veo un fuerte paralelismo entre la construcción del software y la medicina. En ambos casos no basta con tener un ambiente pulcro y estéril durante la «operación», se necesita arrancar con un buen trabajo previo y ser aplicados en el seguimiento del paciente. ¿O no?

Todo el sector está realizando ímprobos esfuerzos en la mejora de los procesos de construcción del software. Metodologías, herramientas, formación, ecosistemas … ¡de todo!. Sin embargo, el paciente sigue flojo («Propongo eliminar las palabras Calidad software ..»), ¿por qué? Estamos descuidando el diagnóstico (los «requisitos») y la convalecencia  (los datos con los que trabaja el producto entregado).

En este artículo vamos a centrarnos en un viejo rockero:
la gestión de Requisitos software.

Está comúnmente aceptado que sin estudiar los síntomas de un paciente es muy arriesgado diagnosticarle una enfermedad y aún más difícil acertar con el tratamiento correcto. Poca gente lo discute. Sin embargo,  muy pocos también se sienten realmente incómodos pidiendo que se empiece «¡ya!» un desarrollo software sin siquiera disponer de una estructura de trabajo para que fluya la información de lo que se pretende construir entre el usuario real y el equipo de desarrollo.

El (mutuo) conocimiento viene derivado de conversar, intercambiar puntos de vista, sintonizar en suma. Si la distancia entre usuario y desarrollo es sideral, ¿qué nos queda? ¿La telepatía? ¿Aquello de «tómese un fármaco genérico de amplio espectro» y fuera?.

Cuando el conocimiento empieza a fluir tenemos entre manos la delicada esencia que alienta cualquier proceso de construcción de software: necesidades de negocio («business needs»). ¿Qué podemos hacer con esas necesidades, expectativas u objetivos que realmente aportan valor a nuestro cliente? Mimarlos. Un trabajo conjunto permitirá ir consolidando hacia requisitos, estresarlos, cambiarlos hasta lograr tener un diagnóstico suficientemente preciso como para ponernos manos a la obra con ciertas garantías de satisfacción.

Si nuestro enfoque es ágil, podremos empezar las labores de construcción de prototipos que ayuden a seguir avanzando en ese mutuo conocimiento.

Bienvenido sea el cambio …
sobre todo de aquello que todavía ¡no ha sido construido!

El proceso es importante pero también debemos cuidar las herramientas. Los correos electrónicos, las conversaciones de mensajería, las «multis», las servilletas de papel o los documentos voladores permiten mantener conversaciones pero no consolidan. Guardemos el avance en sistemas de gestión de requisitos. Tenemos que cuidar a todo el equipo (y a todos los usuarios), los que estuvieron en las conversaciones y los que no. Los que desarrollan y los que prueban … ¡o aprueban!.

trazabilidad

Los requisitos son el primer activo de un proceso de construcción de software, no los despreciemos. Seamos ambiciosos, queremos que todos sepan qué se está haciendo, por qué y para qué. Trazable.

Por muy moldeable que sea el material,
por muy bueno que sea el artista,
es imposible hacer un retrato
sin conocer al modelo
… salvo Picasso.

Ciertamente queda todo el camino por andar, pero ya tenemos un buen equipo de supervivencia:

  • Organicemos equipos multidisciplinares para trabajar el conocimiento -> requisitos (valor).
  • Probemos los conceptos. Si ni siquiera funciona en el papel, ¿qué esperar? (estrés).
  • Recopilemos, compartamos y evolucionemos los requisitos. Un requisito débil es una lotería (compartir).

Si te interesa seguir explorando estas cuestiones, te invitamos a reflexionar sobre medir el desperdicio derivado de requisitos no implementados, sobre la Innovación rentable del gran Masa K Maeda o sobre «Estrategias para implementar épicas de negocio» . Si por el contrario quieres aterrizar y ponerte manos a la obra, en @PanelSistemas trabajamos con Enterprise Architect y con sistemas de peticiones como Redmine o JIRA de Atlassian.

¿o eres más de servilleta de papel?
(ecoLógica, por supuesto)

Requisitos software

 

Miguel Ángel Nicolao

Miguel Ángel Nicolao

Miguel Ángel es CIO, Director de Innovación y co-fundador de Panel Sistemas. Sigue a @mnicolao11 en Twitter, o visita su perfil en Linkedin. También puedes contactar con él vía e-mail en esta dirección.

Comentarios

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This