Identificación de casos de uso

Disculpa, pero esta entrada está disponible sólo en Català.

Implementación de modelos conceptuales persistentes con Java y JPA

Disculpa, pero esta entrada está disponible sólo en Català.

Domain Model: Del diseño a la implementación persistente

Disculpa, pero esta entrada está disponible sólo en Català.

Cuando evitar el acoplamiento

Disculpa, pero esta entrada está disponible sólo en Català.

Lean Software Development

Ya hace tiempo que quiero escribir sobre el libro Lean Software Development: An Agile Toolkit ya que lleva a cabo una tarea que me parece fundamental: Explicar cómo trasladar buenas prácticas de ingeniería (la parte lean) al desarrollo de software y lo hace, además, proponiendo las metodologías ágiles como resultado. ¿Qué más se puede pedir?

Aunque espero poder profundizar más en futuros posts, podríamos resumir la filosofía lean según los siete principios que nos proponen los Poppendieck:

1. Evitar despilfarro (eliminate waste)
2. Amplificar el aprendizaje (amplify learning)
3. Decidir lo más tarde posible (decide as late as possible)
4. Entregar lo antes posible (deliver as fast as posible)
5. Dar poder al equipo (empower the team)
6. Incluir la integridad de entrada (build integrity in)
7. Tener una visión global (see the whole )

La verdad es que, visto así, resulta difícil no estar de acuerdo con los principios lean. Otra cosa es estar de acuerdo o no en la interpretación de los mismos y en su aplicación al desarrollo de software. Aunque pienso que las metodologías ágiles no son la única traslación posible de los principios lean al desarrollo de software (por ejemplo, dependerá de lo que entendamos por desperdicio) sí pienso que son la traslación más natural, lo cual explicaría por qué lean y agile son dos términos que, últimamente, se suelen ver emparejados.

En mi opinión, uno de los grandes aciertos del libro de los Poppendieck consiste en no trasladar tal cual el Toyota Production System al campo del software sino abstraer los principios básicos del mismo y trasladarlos teniendo en cuenta que no se trata de un proceso de manufactura sino de desarrollo. Por ejemplo, el desarrollo secuencial puede ser necesario en una cadena de montaje donde los componentes tienen que montarse en un orden determinado pero no lo es tanto en el desarrollo de software donde los distintos requisitos pueden trabajarse fácilmente en paralelo.

En conclusión, un libro muy interesante y altamente recomendado para cualquiera que desarrolle su actividad profesional en el campo del desarrollo de software.

Actualización: He añadido un enlace a la entrada donde hablo del primer principio Lean, “evitar el despilfarro”.

Lean Software Development: Evitar despilfarro

A priori, “waste” (en adelante, despilfarro) es “todo aquello que no añade valor para el cliente”. Esto significa que, a priori, deberíamos producir solamente aquellas cosas que aportan un valor visible para el cliente, lo que nos lleva a reflexionar sobre el valor que aporta, por ejemplo, una especificación formal de requisitos o un diseño detallado con contratos OCL.

El cliente, normalmente, no verá dicha documentación, por lo que difícilmente podrá aportarle un gran valor. Sin embargo, como desarrolladores, sabemos que la documentación tiene el potencial de ayudarnos a desarrollar mejor, con mayor calidad, por lo que, indirectamente, estaría aportando valor al cliente. Esta es, en mi opinión, la principal trampa en cuanto a este principio, ya que una vez abrimos la vía del valor “indirecto”, cualquier actividad podrá encajar en dicha categoría.

¿Cómo podemos, entonces, identificar el despilfarro? Shigeo Singo, uno de los desarrolladores del “Toyota Production System” identificó siete tipos de “desperdicio” que los Poppendieck trasladan al mundo del desarrollo de la siguiente manera:

1. Inventario -> Trabajo no finalizado
2. Procesamiento extra -> Procesos extra
3. Sobreproducción -> Funcionalidades de más
4. Transporte -> Cambio de tareas
5. Espera -> Espera
6. Movimiento -> Movimiento
7. Defectos -> Defectos

En mi opinión, la traslación al mundo del desarrollo es perfectamente correcta. Los desarrolladores no tenemos inventario que almacenar pero sí tenemos tareas que realizar y funcionalides que implementar. Acumular trabajo no finalizado es un riesgo que no deberíamos asumir a la ligera. En este sentido, considero muy interesante el concepto de “Definition of Done” [1] que, básicamente, viene a obligarnos a decidir en qué momento está finalizada una tarea, de modo que no la cerramos en falso ni seguimos dedicándole esfuerzo una vez la hemos finalizado.

Un punto en el que ha habido cierta controversia [2] ha sido respecto a si el “product backlog” es o no despilfarro. En general coincido con la opinión de que un backlog excesivamente detallado sería equivalente a un exceso de inventario, por lo que es necesario cuidar el backlog y mantenerlo “en forma” o lo que Mike Cohn denomina [3] el “Product backlog iceberg”. La idea es sencilla: se trata de ir refinando las historias de usuario (requisitos) a medida que se van convirtiendo en más prioritarias y se va acercando el momento de su implementación. De este modo tendremos, al principio del sprint, las historias más prioritarias (y que podrían entrar en este sprint) bien detalladas, el resto de historias que irán en esta release pero son menos prioritarias menos detalladas y, finalmente, aquellas que no irán en esta release las tenemos poco detalladas (normalmente en forma de “epic”). De este modo no realizamos trabajo innecesario y el backlog no se convierte en “desperdicio”. Otro enfoque es el que propone Mary Poppendieck en [4]: calcular el tiempo medio de permanencia de una historia en el backlog y eliminar todas aquellas que lleven más tiempo en el backlog que dicha media bajo el supuesto de que se están acumulando al final del backlog y que, probablemente, nunca llegarán a subir (serían algo así como el poso del backlog).

En cuanto a los procesos extra, por más formal que pretenda ser una metodología, no conseguirá evitar los malentendidos en cuanto a requisitos o la introducción de defectos. De hecho, la práctica demuestra que las metodologías ligeras y ágiles son más efectivas para solucionar estos problemas que las metodologías pesadas. Evidentemente, siempre hay que tener en cuenta el contexto, ya que por ejemplo, al desarrollar el software de control de un avión, hay poco margen a la interpretación y al cambio de requisitos (por no decir lo complicado que debe ser traer a la fábrica a todos los aviones para actualizarles el software). En este sentido, los Poppendieck proponen que nos hagamos una pregunta muy sencilla: ¿hay alguien esperando a que esto sea producido? Es obvio, por ejemplo, que si no hay nadie esperando a que un documento esté finalizado podremos considerarlo como superfluo ya que “nadie va a echarlo de menos”. De este modo, la necesidad o no de cualquier artefacto dependerá del contexto. Por ejemplo, un documento detallado de diseño puede ser requerido por la implementación de la ISO en una cierta organización mientras que en otra se trabaje sin este requisito. En este caso, el documento de diseño sería superfluo para el segundo equipo pero no para el primero.

¿Quién no ha dicho nunca aquello de ya que estamos, no nos cuesta nada añadir una opción para hacer …(a rellenar por cada cual) ? Sin embargo, como usuarios, es posible que la funcionalidad en cuestión no nos aporte gran cosa, es más, incluso puede que nos distraiga de otras funcionalidades más importantes. No deberíamos perder de vista casos como el del iPod, que consiguió monopolizar todo su mercado gracias a una interfaz de usuario simple a pesar de que le faltasen funcionalidades tan primitivas como la de borrar una canción. Este es el peligro de sobreproducción para los equipos de desarrollo: Desarrollar funcionalidades que, en el mejor de los casos no aportan valor y, en el peor, complican la experiencia de usuario.

Durante el desarrollo de software prácticamente no hay costes de transporte, pero es cierto que hay un cambio constante de niveles de abstracción; tan pronto estamos en la mente de un usuario sin conocimientos de informática que intenta darse de alta en nuestro sistema como estamos solucionando un problema con una herramienta superavanzada de mapeo objeto-relacional o corrigiendo un problema con la implementación del CSS de cualquier navegador. Estos cambios de abstracción son costosos y nos hacen perder la concentración, por lo que es importante evitar realizar varias tareas al mismo tiempo. También es costoso el cambiar entre proyectos o actividades (y como desarrollador-emprendedor-profesor sé perfectamente de qué hablo). Es por esto que las metodologías ágiles proponen siempre equipos con dedicación completa al proyecto.

Las esperas no necesitan traslación. Cada vez que alguien está parado esperando que algo pase se está desperdiciando su tiempo, incluso en el caso de que dicha persona pase a dedicarse a otra tarea (con lo que incurrimos en otro tipo de “desperdicio”) estaremos incrementando el volumen de trabajo a medias (nuestro inventario) y retrasando la obtención de valor por parte del usuario. En el caso de Scrum, una de las tareas fundamentales del “Scrum Master” es, precisamente, eliminar los impedimentos que hacen que los desarrolladores estén esperando.

El movimiento, en nuestro caso, no se limita a movimiento físico de piezas sino que los Popeendieck proponen (creo que con acierto) aplicarlo al movimiento de artefactos entre equipos y personas. Cada vez que un artefacto (documento de requisitos, análisis, etc.) se mueve hay una parte de información que se pierde ya que, por más exhaustivos que sean los documentos, nunca reflejarán el 100% de la información que recibió la persona/equipo que escribió el documento. Para reducir este tipo de despilfarro lo más fácil es reducir el número de artefactos. En este sentido, lo ideal sería que el propio desarrollador que implementará la funcionalidad fuese quien hablase con el cliente/stakeholder/usuario para obtener los requisitos de primera mano (esta es la parte “Conversation” del Card-Conversation-Confirmation de las historias de usuario). Eso sí, esta filosofía va radicalmente en contra del mito del “informático-sin-habilidades-sociales-que-se-encierra-en-su-cueva-y-no-habla-con-las-personas-porque-nadie-le-entiende” (y ya va siendo hora de que vayamos derribando ese mito).

Finalmente, para reducir el despilfarro asociado a la presencia de defectos nada mejor que probar intensivamente todo el código (pruebas unitarias, de integración, de aceptación, etc.), así como realizar integración contínua.

No voy a hablar aquí de la técnica del “Value Stream Mapping” puesto que considero que ya hemos tenido una primera aproximación al mundo del “despilfarro” y ya me he extendido más de lo que había pensado incialmente.

[1] http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

[2] http://www.infoq.com/news/2007/10/product-backlogs-wasteful

[3] http://www.mountaingoatsoftware.com/system/presentation/file/78/Cohn_PrioritizingYourBacklog.pdf

[4] http://tech.groups.yahoo.com/group/leanagile/message/332

[5] http://martinfowler.com/bliki/TechnicalDebt.html

Línias de código como métrica de la calidad de un diseño

Spag(s)

http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html

Lean Software Development: Evitar despilfarro

A priori, “waste” (en adelante, despilfarro) es “todo aquello que no añade valor para el cliente”. Esto significa que, a priori, deberíamos producir solamente aquellas cosas que aportan un valor visible para el cliente, lo que nos lleva a reflexionar sobre el valor que aporta, por ejemplo, una especificación formal de requisitos o un diseño detallado con contratos OCL.

El cliente, normalmente, no verá dicha documentación, por lo que difícilmente podrá aportarle un gran valor. Sin embargo, como desarrolladores, sabemos que la documentación tiene el potencial de ayudarnos a desarrollar mejor, con mayor calidad, por lo que, indirectamente, estaría aportando valor al cliente. Esta es, en mi opinión, la principal trampa en cuanto a este principio, ya que una vez abrimos la vía del valor “indirecto”, cualquier actividad podrá encajar en dicha categoría.

¿Cómo podemos, entonces, identificar el despilfarro? Shigeo Singo, uno de los desarrolladores del “Toyota Production System” identificó siete tipos de “desperdicio” que los Poppendieck trasladan al mundo del desarrollo de la siguiente manera:

1. Inventario -> Trabajo no finalizado
2. Procesamiento extra -> Procesos extra
3. Sobreproducción -> Funcionalidades de más
4. Transporte -> Cambio de tareas
5. Espera -> Espera
6. Movimiento -> Movimiento
7. Defectos -> Defectos

En mi opinión, la traslación al mundo del desarrollo es perfectamente correcta. Los desarrolladores no tenemos inventario que almacenar pero sí tenemos tareas que realizar y funcionalides que implementar. Acumular trabajo no finalizado es un riesgo que no deberíamos asumir a la ligera. En este sentido, considero muy interesante el concepto de “Definition of Done” [1] que, básicamente, viene a obligarnos a decidir en qué momento está finalizada una tarea, de modo que no la cerramos en falso ni seguimos dedicándole esfuerzo una vez la hemos finalizado.

Un punto en el que ha habido cierta controversia [2] ha sido respecto a si el “product backlog” es o no despilfarro. En general coincido con la opinión de que un backlog excesivamente detallado sería equivalente a un exceso de inventario, por lo que es necesario cuidar el backlog y mantenerlo “en forma” o lo que Mike Cohn denomina [3] el “Product backlog iceberg”. La idea es sencilla: se trata de ir refinando las historias de usuario (requisitos) a medida que se van convirtiendo en más prioritarias y se va acercando el momento de su implementación. De este modo tendremos, al principio del sprint, las historias más prioritarias (y que podrían entrar en este sprint) bien detalladas, el resto de historias que irán en esta release pero son menos prioritarias menos detalladas y, finalmente, aquellas que no irán en esta release las tenemos poco detalladas (normalmente en forma de “epic”). De este modo no realizamos trabajo innecesario y el backlog no se convierte en “desperdicio”. Otro enfoque es el que propone Mary Poppendieck en [4]: calcular el tiempo medio de permanencia de una historia en el backlog y eliminar todas aquellas que lleven más tiempo en el backlog que dicha media bajo el supuesto de que se están acumulando al final del backlog y que, probablemente, nunca llegarán a subir (serían algo así como el poso del backlog).

En cuanto a los procesos extra, por más formal que pretenda ser una metodología, no conseguirá evitar los malentendidos en cuanto a requisitos o la introducción de defectos. De hecho, la práctica demuestra que las metodologías ligeras y ágiles son más efectivas para solucionar estos problemas que las metodologías pesadas. Evidentemente, siempre hay que tener en cuenta el contexto, ya que por ejemplo, al desarrollar el software de control de un avión, hay poco margen a la interpretación y al cambio de requisitos (por no decir lo complicado que debe ser traer a la fábrica a todos los aviones para actualizarles el software). En este sentido, los Poppendieck proponen que nos hagamos una pregunta muy sencilla: ¿hay alguien esperando a que esto sea producido? Es obvio, por ejemplo, que si no hay nadie esperando a que un documento esté finalizado podremos considerarlo como superfluo ya que “nadie va a echarlo de menos”. De este modo, la necesidad o no de cualquier artefacto dependerá del contexto. Por ejemplo, un documento detallado de diseño puede ser requerido por la implementación de la ISO en una cierta organización mientras que en otra se trabaje sin este requisito. En este caso, el documento de diseño sería superfluo para el segundo equipo pero no para el primero.

¿Quién no ha dicho nunca aquello de ya que estamos, no nos cuesta nada añadir una opción para hacer …(a rellenar por cada cual) ? Sin embargo, como usuarios, es posible que la funcionalidad en cuestión no nos aporte gran cosa, es más, incluso puede que nos distraiga de otras funcionalidades más importantes. No deberíamos perder de vista casos como el del iPod, que consiguió monopolizar todo su mercado gracias a una interfaz de usuario simple a pesar de que le faltasen funcionalidades tan primitivas como la de borrar una canción. Este es el peligro de sobreproducción para los equipos de desarrollo: Desarrollar funcionalidades que, en el mejor de los casos no aportan valor y, en el peor, complican la experiencia de usuario.

Durante el desarrollo de software prácticamente no hay costes de transporte, pero es cierto que hay un cambio constante de niveles de abstracción; tan pronto estamos en la mente de un usuario sin conocimientos de informática que intenta darse de alta en nuestro sistema como estamos solucionando un problema con una herramienta superavanzada de mapeo objeto-relacional o corrigiendo un problema con la implementación del CSS de cualquier navegador. Estos cambios de abstracción son costosos y nos hacen perder la concentración, por lo que es importante evitar realizar varias tareas al mismo tiempo. También es costoso el cambiar entre proyectos o actividades (y como desarrollador-emprendedor-profesor sé perfectamente de qué hablo). Es por esto que las metodologías ágiles proponen siempre equipos con dedicación completa al proyecto.

Las esperas no necesitan traslación. Cada vez que alguien está parado esperando que algo pase se está desperdiciando su tiempo, incluso en el caso de que dicha persona pase a dedicarse a otra tarea (con lo que incurrimos en otro tipo de “desperdicio”) estaremos incrementando el volumen de trabajo a medias (nuestro inventario) y retrasando la obtención de valor por parte del usuario. En el caso de Scrum, una de las tareas fundamentales del “Scrum Master” es, precisamente, eliminar los impedimentos que hacen que los desarrolladores estén esperando.

El movimiento, en nuestro caso, no se limita a movimiento físico de piezas sino que los Popeendieck proponen (creo que con acierto) aplicarlo al movimiento de artefactos entre equipos y personas. Cada vez que un artefacto (documento de requisitos, análisis, etc.) se mueve hay una parte de información que se pierde ya que, por más exhaustivos que sean los documentos, nunca reflejarán el 100% de la información que recibió la persona/equipo que escribió el documento. Para reducir este tipo de despilfarro lo más fácil es reducir el número de artefactos. En este sentido, lo ideal sería que el propio desarrollador que implementará la funcionalidad fuese quien hablase con el cliente/stakeholder/usuario para obtener los requisitos de primera mano (esta es la parte “Conversation” del Card-Conversation-Confirmation de las historias de usuario). Eso sí, esta filosofía va radicalmente en contra del mito del “informático-sin-habilidades-sociales-que-se-encierra-en-su-cueva-y-no-habla-con-las-personas-porque-nadie-le-entiende” (y ya va siendo hora de que vayamos derribando ese mito).

Finalmente, para reducir el despilfarro asociado a la presencia de defectos nada mejor que probar intensivamente todo el código (pruebas unitarias, de integración, de aceptación, etc.), así como realizar integración contínua.

No voy a hablar aquí de la técnica del “Value Stream Mapping” puesto que considero que ya hemos tenido una primera aproximación al mundo del “despilfarro” y ya me he extendido más de lo que había pensado incialmente.

[1] http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

[2] http://www.infoq.com/news/2007/10/product-backlogs-wasteful

[3] http://www.mountaingoatsoftware.com/system/presentation/file/78/Cohn_PrioritizingYourBacklog.pdf

[4] http://tech.groups.yahoo.com/group/leanagile/message/332

[5] http://martinfowler.com/bliki/TechnicalDebt.html

Línias de código como métrica de la calidad de un diseño

Spag(s)

http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html

Lean Software Development

Ya hace tiempo que quiero escribir sobre el libro Lean Software Development: An Agile Toolkit ya que lleva a cabo una tarea que me parece fundamental: Explicar cómo trasladar buenas prácticas de ingeniería (la parte lean) al desarrollo de software y lo hace, además, proponiendo las metodologías ágiles como resultado. ¿Qué más se puede pedir?

Aunque espero poder profundizar más en futuros posts, podríamos resumir la filosofía lean según los siete principios que nos proponen los Poppendieck:

1. Evitar despilfarro (eliminate waste)
2. Amplificar el aprendizaje (amplify learning)
3. Decidir lo más tarde posible (decide as late as possible)
4. Entregar lo antes posible (deliver as fast as posible)
5. Dar poder al equipo (empower the team)
6. Incluir la integridad de entrada (build integrity in)
7. Tener una visión global (see the whole )

La verdad es que, visto así, resulta difícil no estar de acuerdo con los principios lean. Otra cosa es estar de acuerdo o no en la interpretación de los mismos y en su aplicación al desarrollo de software. Aunque pienso que las metodologías ágiles no son la única traslación posible de los principios lean al desarrollo de software (por ejemplo, dependerá de lo que entendamos por desperdicio) sí pienso que son la traslación más natural, lo cual explicaría por qué lean y agile son dos términos que, últimamente, se suelen ver emparejados.

En mi opinión, uno de los grandes aciertos del libro de los Poppendieck consiste en no trasladar tal cual el Toyota Production System al campo del software sino abstraer los principios básicos del mismo y trasladarlos teniendo en cuenta que no se trata de un proceso de manufactura sino de desarrollo. Por ejemplo, el desarrollo secuencial puede ser necesario en una cadena de montaje donde los componentes tienen que montarse en un orden determinado pero no lo es tanto en el desarrollo de software donde los distintos requisitos pueden trabajarse fácilmente en paralelo.

En conclusión, un libro muy interesante y altamente recomendado para cualquiera que desarrolle su actividad profesional en el campo del desarrollo de software.

Actualización: He añadido un enlace a la entrada donde hablo del primer principio Lean, “evitar el despilfarro”.