Archivo de la etiqueta: ágil

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!

Anuncios

Deja un comentario

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

Charla Abierta en el Colegio de Ingenieros: ¿Qué metodología será más adecuada para tu proyecto de Software?

El miércoles 1 de agosto de 2012 el equipo de ChileÁgil dará una mirada transversal a los métodos usados en proyectos de software y comparará sus respectivas fortalezas.

La descripción oficial es la siguiente:

Desde que se ha tratado de incluir métodos que liberen a los proyectos del software del caos han surgido diversas perspectivas, desde el tradicional ciclo de vida en cascada hasta la familia de métodos agiles en boga en la actualidad. A partir de la experiencia de decenas de proyectos apoyados, se describirá una guía sencilla que permita seleccionar el mejor enfoque a aplicar.

La charla se realizará en el Auditorio del Colegio de Ingenieros de Chile, (Av. Santa María 0508 – Providencia) el Miércoles 01 de Agosto de 19:00 – 21:00 hrs.

ACTUALIZACIÓN: Las presentaciones se encuentran disponibles en esta página

Fuente: http://www.chileagil.cl/2012/07/25/charla-en-el-colegio-de-ingenieros-que-metodologia-sera-mas-adecuada-para-tu-proyecto-de-sofware/

Artículo Original: http://www.leansight.com/destacados/charlaque-metodologia-usar-en-tu-proyecto-de-software/

Deja un comentario

Archivado bajo Ingeniería de Software

Desafío Kanban, un primer paso hacia la agilidad

Esta obra está publicada bajo una Atribución-No Comercial-Licenciar Igual 2.0 Chile de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.0/cl/

Un Primer paso hacia la agilidad

La agilidad se puede confundir con hacer cosas fáciles – de hecho, lo que se busca es definir soluciones sencillas e implementarlas paso a paso , lo es que sí es algo dificil :) – y quienes nos hemos echado a navegar en estas aguas sabemos que es un viaje largo y no exento de contratiempos.

Por esto les queremos proponer un punto de partida, un experimento que servirá de primer paso a la agilidad, que hemos denominado Desafío Kanban.

Esta actividad está pensada para ser ejecutada por una persona de forma individual.

Preparación

  1. Al comenzar la semana, listar en post-its las tareas de cada uno para la próxima semanas
  2. Frente al escritorio de trabajo, crear un panel (que llamaremos Tablero Kanban) con 3 columnas:
    • En Cola
    • En Curso
    • Terminado
  3. En la columna En Curso definimos un máximo de tareas que vamos a permitir en ella. Así limitamos el trabajo en curso y evitamos caer en el desperdicio que provoca la multi-tarea. Recomendamos poner un límite de 1, y si no es posible mantenerlo, un máximo de 2.

Ejecución del trabajo

  1. Durante la semana, revisar las tareas desde las que están a punto de terminar hasta las menos avanzadas (seguimos el mantra “Para de comenzar, comienza a terminar”).
  2. Mover los post-its de una columna a otra a medida que se progresa
Evaluación (Medición) y replanificación

  1. Al comenzar la semana siguiente, nos fijamos en la columna de tareas terminadas y comparamos las tareas entre sí según el esfuerzo que nos significaron. Recomendamos usar la siguiente escala de puntaje de esfuerzo: 1,2,3,5,8,13,20,40,100. Las tareas más simples significarán 1. Las tareas que no fue posible abarcar dentro de la semana estarán en el rango de 13 hacia arriba
  2. Sumamos la cantidad de puntos logrados. Esto será el ancho de banda logrado la semana pasada.
Proyección

  1. Listar las nuevas tareas a ejecutar que han aparecido. Estimar el puntaje de esfuerzo de cada nueva tarea. Si una tarea estaba en curso, estimar el esfuerzo que queda.
  2. A partir del ancho de banda medido de la semana anterior, seleccionar aquellas tareas que sumen una cantidad de piuntaje similar a lo realizado la semana anterior. Así ajustamos nuestro compromiso a lo que sabemos que podemos realizar
  3. Volver a ejecutar

Fuente: http://www.leansight.com/desafio-kanban/

Deja un comentario

Archivado bajo Ingeniería de Software, SCRUM