Archivo de la categoría: CMMI

Explorando la metodología DWDP+1 parte I

Introducción

Más de alguno se estará preguntando ¡que diablos es la metodología DWDP+1 en inglés o DRDP en español!, pues la siglas vienen de Draw – Write – Draw – Prototype o en español Dibuja – Redacta/Escribe – Dibuja – Prototipa, posteriormente en el detalle explicaré de dónde viene el +1.

Esta metodología nace de la necesidad de poder llegar a una forma de trabajo que sea sencilla y práctica de poder levantar y detallar las primeras etapas de construcción de un software, sin complejizar demasiado el proceso.  Principalmente aquellas etapas que tienen que ver con la Ingeniería de Requerimientos o Requisitos, antes de entrar de lleno al diseño y construcción del software, lo anterior mirado desde una perspectiva ágil de desarrollo del software.

Hagamos un poco de historia

Con el transcurso de los años se han desarrollado recursos que conforman la ingeniería del software, es decir, herramientas y técnicas de especificación, diseño e implementación del software: la programación estructurada, la programación orientada a objetos, las herramientas CASE, la documentación, los estándares, CORBA, los servicios web, el lenguaje UML, etc.

En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los productos software hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

En general la ingeniería del software consiste en:

  • Proceso de desarrollo de software (especificación, implementación y diseño, etc…).
  • Metodologías para el desarrollo de software (RUP, patrones, framework…).
  • Herramientas de desarrollo de software.

Hay cuatro actividades fundamentales comunes a todo proceso software:

  • Especificación: usuarios e ingenieros definen el software a producir y las restricciones en su funcionalidad.
  • Desarrollo: fase en la cual el software se diseña y se programa.
  • Validación: el software debe ser probado para asegurar que cumple con las necesidades del cliente.
  • Evolución: el software debe poder ser modificado para adaptarse a cambios en el mercado y en las necesidades de los usuarios.

A mi me gustaría centrarme en la primera actividad fundamental: la especificación, pero con un enfoque más holístico que incorpore algunas técnicas de la Ingeniería de Requerimientos, no perdiendo el foco ágil.

Las metodologías actuales y el auge de la agilidad

Todas las metodologías ágiles coinciden en que un producto debe construirse de forma evolutiva en pequeñas entregas. Y aunque esto no es suficiente, sino que debemos hacerlo de forma criteriosa para que cada entrega pueda aportar valor suficiente a los usuarios finales. Esos grupos de características se denominan MMF: Minimum Marketable Features, y pueden definirse como “el conjunto más pequeño posible de funcionalidad que, por si misma, tiene valor en el mercado”.

Cuando nosotros nos acercamos al cliente, asumimos que él sabe exactamente qué quiere hacer (What?)  y nosotros le damos el cómo (How?). Sin embargo, esto no es así y nuestro trabajo se convierte en algo así como adivinar el futuro con una bola de cristal.

Todas las metodologías ágiles que he consultado e intentado aplicar (Scrum, xP), se basan en el hecho de que los implicados son “relativamente profesionales” y están muy orientados a resultados, con altas capacitaciones en sus campos. Cuando intentas llevar esto a la realidad práctica, los clientes no saben qué quieren, no están dispuestos a formalizar sus peticiones en algo parecido a un informe de requerimientos (porque el tiempo apremia), los programadores que trabajan para ti pueden ser lentos y tener una capacidad de adaptación baja, con lo cual los temas se eternizan (aunque no en todos los casos, no quiero generalizar).

En resumen, al final cada uno debe resolver el problema con lo que tenga a su alcance (quizá un buen analista funcional o un comercial especialmente preparado para “adivinar” las necesidades de los clientes).  Creo que muchos al leer esto se sentirán identificados con parte del problema.

El auge de las metodologías ágiles y las herramientas nuevas que aparecen (con mucha frecuencia) creo que tienden un poco a nublar la visión de los gestores de proyecto, porque a veces no consultan la fuente de la información y se arma un lío gigante que es complicado de desenmarañar, campo que ha sido cultivo para que muchos “coaches” vean esto como una oportunidad de negocio para emprender (lo que encuentro genial!).  Cuando la base de todo esto se encuentra en la filosofía especificada en el Manifiesto Ágil, y que creo muchas personas debiésemos retomar de vez en cuando.  En resumen el manifiesto ágil dice:

  1. Las personas (individuos) e interacciones entre los individuos están POR SOBRE los procesos y las herramientas

  2. Software funcionando POR SOBRE documentación extensiva

  3. Colaboración con el cliente POR SOBRE la negociación de un contrato

  4. Responder a los cambios ANTES que seguir un plan (punto cuestionable de acuerdo a algunos dinosaurios del PMP)

Sobre la base de este manifiesto se crearon los 12 principios de agilidad para el desarrollo de software.  Sin embargo no deseo entrar tanto en detalle para concentrarme de lleno en explicar el problema y el porqué creo que esta metodología que he credo puede aportar en la “etapa de análisis” de las metodologías ágiles u otras más tradicionales.

El problema

“Cuando nosotros nos acercamos al cliente, asumimos que él sabe exactamente qué quiere hacer y nosotros le damos el cómo. Sin embargo, esto no es así y nuestro trabajo se convierte en algo así como adivinar el futuro con una bola de cristal.”.

¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente antes de que el producto salga al mercado? teniendo en mente que el objetivo es evitar por todos los frentes posibles que nos transformemos en verdaderos adivinos con una bola de cristal.

Sabemos por ejemplo que de acuerdo a SCRUM, la validación que hace el cliente (product owner) de la pila de requisitos (backlog desde ahora en adelante) no la podrá obtener sino hasta que se construya el primer incremento (potentially shippable product), es decir, hasta que pueda obtener una versión funcional del producto (testeable).  Sin embargo también sabemos que el Product Owner (PO desde ahora en adelante) es un agente partícipe activo del Sprint Planning, área que puede usarse para obtener con antelación una validación de este mismo stakeholder (involucrado).

Desde las primeras etapas del proceso de SCRUM cuando se comienza a recopilar la pila del producto (backlog), la única inferencia que el PO tiene en dicha pila es: para ordenar las historias de usuario.

Luego de armar las características de las historias especificadas con el comportamiento deseado desde la perspectiva del usuario, el PO no tiene inferencia hasta la etapa de planificación del sprint, donde básicamente se define:

  1. el What?
  2. el How?

y con lo anterior se genera el Sprint Backlog.

Luego durante 10 o 15 días (configurable de acuerdo al proyecto y las necesidades del PO), se comienza el desarrollo del primer sprint, y ya nos desconectamos completamente de la validación que podría hacer el PO sino hasta la entrega del incremento funcional.  De acuerdo a mi perspectiva la pregunta inicial planteada a modo de hipótesis sigue siendo:

¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente (PO) antes de que el producto salga al mercado?

Para poner más claro el problema me gustaría compartir con ustedes una discusión entre Zach Bonaker, agile coach de Willis Towers Watson y Jaya Shrivastava, coach de AGILE++ Engineering.  Obviamente personas que saben mucho más que yo.

Destaqué en rojo los temas que creo relevantes para el problema en cuestión.  Fuente: https://www.scrumalliance.org/community/articles/2014/august/why-definition-of-minimum-marketable-feature%E2%80%9D-is-a

La traducción es:

Zack:

Un equipo que desarrolla historias que resultan en un software que no se puede usar o que no tiene utilidad no es un fallo de una “definición de característica comercial mínima” (MMF). Es debido a un backlog muy pobre, probablemente el resultado de prácticas ágiles fallidas en las etapas iniciales donde el equipo planeó realmente el sprint.

Jaya:

Sí, cada iteración produce algo valioso, pero ¿los clientes lo usan?

En el mundo real, la respuesta es un rotundo NO. Los clientes no están dispuestos a asignar recursos para probar o liberar lo que se produce al final de los sprints.

En su lugar, los clientes están dispuestos a tomar incrementos que creen que pueden ser liberados al mercado.

Esto falta ya que no trabajamos lo necesario para poder liberar una característica mínima que sea comercializable.

Vaya problema…

El asunto importante es que si llegásemos a poder tener una validación inicial antes de la entrega del incremento funcional, podríamos disminuir un riesgo importante: que es justamente que el producto llegue defectuoso al mercado.

En una próxima entrega iré desmenuzando la solución (de acuerdo a mi visión) que adopté a través de la creación de esta metodología DWDP+1, que busca ir en apoyo de una definición más concreta y sencilla de requerimientos antes de entrar a las etapas de construcción.

Cualquier aporte es siempre bienvenido, sobre todo para corregir algunos temas principalmente relacionados con el mundo ágil.

Nos vemos en la siguiente entrega y buena lectura!

Deja un comentario

Archivado bajo CMMI, Desarrollo de Software, Ingeniería de Software

Mitos del desarrollo de software: Proceso es sinónimo de ciclo de vida en cascada

Con el tiempo, uno se da cada vez más cuenta de la gran cantidad de mitos arraigados que se pueden encontrar en esta nuestra profesión del desarrollo / ingeniería del software. Tantos que hasta da para una serie post.

Por empezar por alguno, uno de estos mitos arraigados en ciertos grupos y colectivos es aquel que habla de que “los procesos implican ciclos de vida en cascada”. Mito que también podemos encontrar sustituyendo la palabra “procesos” por algún modelo de procesos concreto, principalmente CMMI o ISO 15504 / ISO 12207. “No implantamos CMMI porque implica ciclo de vida en cascada”. “ISO 15504 / ISO 12207 no funciona porque trabajamos de manera ágil, iterativa, y el cv en cascada no funciona”.

Para comprobar si hay veracidad detrás de este mito, y ya que “aparentemente” los procesos implican tanto al ciclo de vida en cascada, fui al documento que describe uno de los modelos de procesos más famoso, el CMMI, e hice una búsqueda por la palabra “waterfall”, para contar las apariciones de la misma en el documento.

Y sí, efectivamente aparece… pero una sola vez. Algo tan aparentemente importante para implantar procesos, solo aparece una vez en las 482 páginas. Y como ejemplo de ciclo de vida, y junto al iterativo y el incremental.

Deja un comentario

Archivado bajo CMMI, SCRUM