SG #16

Lean Software Development: Libera tus proyectos

sg — Mon, 12 Mar 2018 22:30:42 +0000

Lean Software Development: Libera tus proyectos sg Mon, 03/12/2018 - 16:30

Publicado en

SG #16

Tierra libre

Autor

Emilio Osorio

En los seminarios sobre métodos ágiles que realizo, típicamente pregunto lo siguiente a la audiencia: “Levante la mano por favor, aquella persona a la cual un diagrama de Gantt le haya sido la diferencia para sacar adelante un proyecto, o que para darle mantenimiento al software de alguien más haya utilizado documentación separada al mismo código, o tal vez aquel líder de proyecto que le haya funcionado asignar y controlar el avance de microtareas por cada miembro del equipo, para que así se comprometan más con una fecha de entrega.

Sorprendentemente (o no tanto), hasta la fecha nadie ha levantado la mano. Si todas estas prácticas que son la quinta esencia de la administración de proyectos, y para las cuáles invertimos miles de pesos en herramientas y cursos no funcionan, entonces ¿por qué lo seguimos haciendo?

Al parecer, pensamos que cuando algo no sale bien lo que necesitamos es una capa más de “control”, un proceso más definido y detallado que “obligue” a los programadores rebeldes, negligentes o apáticos, a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. Anhelamos recetas secretas, pero en realidad lo que necesitamos es tan solo un conjunto sólido de principios y sentido común.

¿Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance; es libre, gratis y simplemente funciona. LSD fue desarrollado por Mary y Tom Poppendieck a partir de experiencias en 3M y Toyota, y se basa en aplicar al desarrollo de software los principios de “lean” que han hecho tan exitosas a estas empresas. Se le considera parte de los métodos ágiles, pero desde mi punto de vista está por encima de ellos, ya que LSD nos obliga a pensar, cuestionarnos y encontrar nuestras propias respuestas.
LSD se basa en los siguientes 7 principios:

Eliminar el despilfarro. Es decir, evitar todo lo que no agregue valor al proyecto. ¿Qué es aquello que no agrega valor al proyecto? Sencillo, todo lo que el cliente no pidió, pero en lo que invertimos tiempo. En esta categoría entra funcionalidad adicional a la que pidió el usuario, o especificación de requerimientos demasiado detallada en etapas tempranas del ciclo de vida. Aprendamos a ver éstas cosas como un despilfarro.
Ampliar el aprendizaje. Debemos aceptar que nunca se sabrá exactamente lo que se tiene que construir al principio del proyecto. Así que cualquier tiempo que ocupemos tratando de hacer que el cliente nos “firme” el requerimiento, rompe con el principio anterior. Ampliar el aprendizaje significa aceptar que el desarrollo es un proceso de aprendizaje, por lo tanto tenemos que repetirlo muchas veces para aprender. Solución: Muchas iteraciones cortas, tan cortas como haga sentido.
Retrasar los compromisos. Cada vez que aceptamos trabajar en un proyecto que tiene fecha de entrega pero no tiene requerimientos fijos es como si decidiéramos casarnos con alguien que conocimos hoy mismo. Si no lo hacemos en la vida real, entonces ¿por qué hacerlo en nuestro trabajo? Las iteraciones cortas ayudan a comprometernos con tan solo lo que podemos estimar bien.
Liberar rápido. Todos hacemos desarrollo por iteraciones, ¿verdad? Bueno, tener iteraciones no es lo mismo que liberar rápido. Liberar rápido significa que si te piden un sistema que facture, liberes “a producción” la funcionalidad para facturar lo antes posible, aunque no se haya terminado el resto del sistema. Empresas como Google o Yahoo entienden esto y lo aplican en sus desarrollos. Libera funcionalidades, no sistemas.
Facultar al equipo. ¿Qué es lo mejor que puede hacer un líder de proyecto? No estorbar. Tenemos que confiar en que las personas pueden ponerse de acuerdo, trabajar en equipo y en esencia autodirigirse. Si, cometerán errores. Pero si liberan rápido y tienen iteraciones cortas, entonces sus errores no nos costarán caro, y sobre todo se ampliará el aprendizaje. Si no pueden resolverlos por ellos mismos, entonces debemos evaluar si tenemos el equipo correcto. El trabajo en equipo ES el desarrollo de software.
Construir integridad intrínseca: En Japón, las mismas máquinas que producen las piezas para manufactura, prueban las piezas que producen, las miden y desechan las que no cumplen con los requisitos mínimos. No hay una inspección o control de calidad separada de la producción. Nuestros equipos nunca podrán alcanzar madurez, en un esquema donde el responsable de la calidad sea otro grupo separado del de desarrollo.
Pensar en el todo. “O todos coludos, o todos rabones” decían nuestros abuelos. Al parecer, antes se entendía mucho cómo hacer que una organización o una familia funcionara como un equipo. Abandonemos el modelo de programador estrella, lo único que producimos son divas y gangsters. En un equipo todos ganan y todos pierden, así que olvidémonos de las mediciones de desempeño individuales. Lo único que esto provoca es que los que salgan bien se busquen un trabajo donde les paguen más, y los que no salgan tan bien, harán lo mismo. Creemos equipos que compartan logros y fracasos y reduciremos la rotación de personal.

¿Por que hablo con tanta seguridad? Sencillo, yo mismo he pasado de creer en cosas que no funcionan y sufrir en mi trabajo, a experimentar los frutos de LSD en mi propia práctica. Finalmente, les recomiendo que busquen en Internet a Mary Poppiendick y agradecerán como yo, todo el material gratuito que tiene a nuestra disposición para ayudarnos a empezar. Regalar sus libros a nuestros directores de sistemas probablemente serán los pesos mejor invertidos en mucho tiempo en nuestras carreras.

Bio

Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org

El Mariachi Orientado a Objetos, Entendiendo el diseño OO

Anonymous — Tue, 04 Sep 2007 20:58:05 +0000

El Mariachi Orientado a Objetos, Entendiendo el diseño OO

Anonymous Tue, 09/04/2007 - 15:58

Publicado en

SG #16

Autor

Carlos Ordoñez

¿Cómo hacen los diseñadores de automóviles para construir un auto compacto, que pueda ser conducido por una persona que mide 1.60 de estatura, y un grandulón de 2.10? La respuesta es sencilla: considerando al momento de diseñar, y antes de fabricar, los potenciales de cambio, tomando así las medidas pertinentes para crear una solución “flexible”: la palanquita que recorre los asientos.

Cuando desarrollamos sistemas, todos nos hemos enfrentado a esta constante de nuestra profesión: el cambio. Cambio de requerimientos, cambio de versiones, cambio de plataforma, etcétera. Para combatirlo, tenemos que dedicar una buena parte del tiempo de análisis y diseño a la flexibilidad de nuestra solución, con el único objetivo de disminuir el riesgo y el costo que éste implica, para tener un cliente satisfecho con menos dinero.

El Mariachi orientado a objetos es un divertido ejemplo de cómo lidiar con los cambios de requerimientos al diseñar clases flexibles, utilizando el patrón de estrategias para diseño orientado a objetos.

Cantemos con Mariachi

Supongamos que tenemos un cliente extranjero cuya pasión musical es desmesurada, y nos ha pedido desarrollar una aplicación que simule la forma de hacer música de un Mariachi, sólo desea integrar un guitarrista, un violinista y un trompetista a la simulación, dado que todos tocan música de diferentes formas y tienen un canto característico, la mayoría comenzaríamos planteando un diagrama de clases similar al mostrado en la figura 1.

Figura 1. Primer acercamiento a la solución.

Nuestro cliente quedó satisfecho con la solución, mas sin embargo, al ver que los integrantes del Mariachi pueden bailar, no esperó mucho para solicitar un cambio de requerimientos: “Ahora quiero Mariachis bailarines”. Nuestro equipo de diseño reacciona rápidamente y agrega el método bailar a la clase Músico. (Véase figura 2).

Figura 2. Mariachi con músicos bailarines.

Al parecer nuestra solución ha sido suficientemente flexible para adaptarse a los cambios, hasta que el cliente nos solicita un nuevo músico: “hagamos una mezcla cultural, quiero escuchar un Mariachi con batería”. Inmediatamente pasa por nuestra mente agregar una nueva clase: Baterista (véase figura 3).

Figura 3. Mariachi con Baterista.

El problema es claro: “Bateristas Bailarines”. Esto lo podemos resolver de una forma muy sencilla, sobrescribiendo el método bailar en Baterista de tal forma que no baile:

public void bailar() {
// hacer nada …
}

Evidentemente, después de este cambio, estamos violando el principio de sustitución de Liskov, el cual indica que “debe ser posible utilizar cualquier objeto instancia de una subclase, en el lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado”. En nuestro caso, esto significaría que no será posible reemplazar semánticamente a cualquier Músico por un Baterista, pues el último limita la funcionalidad del primero.

Días mas tarde y aún sin resolver el problema del Baterista, recibimos una nueva petición de nuestro cliente: “¿Cómo podemos agregar un cantante de Ópera a nuestra simulación?”. La figura 4 indica otro “parche” más para satisfacer este requerimiento.

Figura 4. Mariachi con cantante de opera

La solución parece suficiente. No obstante, nos damos cuenta que estamos en un gran aprieto: Cantantes de Ópera que cantan como Mariachi… ¡Ah, y bailan!

Hasta ahora no hemos tenido éxito entre clases rígidas y malos diseños, lo que definitivamente nos convierte en presa fácil de un exceso de presupuesto. Es entonces que uno de los diseñadores sugiere: “intentémoslo con interfaces”.

La figura 5 muestra una solución utilizando interfaces.

Figura 5. Mariachi usando interfaces
Esta solución parece correcta. Incluso hasta el trompetista ha dejado de cantar, para dedicarse únicamente a tocar música y bailar.

Sin embargo, este diseño tiene un problema muy grave: “reutilización de código”. Cuando volteamos y vemos que los métodos bailar, tocar música y cantar tienen que ser implementados por las clases concretas, estamos en aprietos.

Patrón de estrategia

Es en estos momentos, donde el patrón de diseño denominado “Estrategia” llega a nuestro rescate. Este es uno de los patrones descritos en el libro “Gang of Four”, que como sabemos, es la biblia de los patrones de diseño orientado a objetos. De acuerdo con esto, el patrón estrategia: “Define una familia de algoritmos encapsulados y los hace intercambiables (…) permite al algoritmo cambiar, independientemente del cliente que lo utiliza”

En concreto, el patrón de estrategia nos permite construir una colección de comportamientos intercambiables, independientemente de quién haga cantar al Mariachi. La figura 6 muestra la estructura de una solución genérica utilizando el patrón de estrategia.

Figura 6. Solución propuesta por el patrón de estrategia

Lo que tenemos que hacer entonces es encontrar cuáles son los potenciales de cambio, es decir, cuáles clases y/o comportamientos tienen una gran probabilidad de ser modificadas y aislar los cambios de las demás clases, y al mismo tiempo, explotar el polimorfismo agregando una clase abstracta o una interfaz para cubrir las diferentes estrategias.

Siguiendo este consejo, se detecta que el comportamiento de los músicos es el que tiende a cambiar, entonces se decide crear un conjunto de estrategias para cada método con alto potencial de cambio. Para cada una de estas estrategias se construye una interfaz o clase abstracta que define qué es lo que hacen cada uno de los conjuntos de algoritmos, y aplicando el patrón de estrategias obtenemos el resultado en la figura 7.

Figura 7. Mariachi utilizando el patrón de estrategia

Bio

Carlos “Fofo” Ordóñez es Ingeniero en Sistemas Computacionales por el ITESO. Actualmente labora como arquitecto de software en Vision Consulting Occidente, ubicada en el Centro de Software de Guadalajara. Colabora como profesor de asignatura en el ITESO, donde imparte materias de Programación e Ingeniería de Software. La información en este artículo representa el punto de vista del autor y no necesariamente el de Vision Consulting o ITESO. fofo@iteso.mx

Entrevista con Scott Ambler

Anonymous — Tue, 04 Sep 2007 17:13:46 +0000

Entrevista con Scott Ambler

Anonymous Tue, 09/04/2007 - 12:13

Publicado en

SG #16

Personas

Scott W. Ambler dirige la práctica de Desarrollo Ágil en IBM. Es considerado como uno de los principales “agilistas” en el mundo, y ha creado varias metodologías entre las que destacan Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), y Enterprise Unified Process (EUP). Scott será uno de los conferencistas magistrales en SG ’07, así que aprovechamos la oportunidad para publicar esta pequeña entrevista donde nos comparte su perspectiva sobre Ágil y otros temas que tratará durante SG ’07.

¿Cómo describirías el estátus actual de Ágil?
Hace unos años, Ágil era visto como un movimiento, una revolución. Sin embargo, creo que actualmente Ágil ya es parte de la “corriente principal” (mainstream) de los métodos de software. Justamente en marzo de este año realicé una encuesta sobre el grado de adopción de ágil, y de las 781 personas que contestaron, el 69% contestó que su organización aplica técnicas derivadas de Ágil. Esto no quiere decir que todo mundo ya esté usando algo como XP como su proceso default, pero si nos indica que la mayoría ya está usando (o considerando usar) una o más técnicas de Ágil.

¿Cuáles consideras que son los principales retos de Ágil en los próximos años?
Creo que el principal reto para Ágil al corto plazo es demostrar que es escalable a proyectos grandes. Precisamente el trabajo que hago con IBM consiste en ayudar a clientes a aplicar técnicas ágiles en proyectos grandes y complejos donde se tienen muchas restricciones de regulación, y el equipo de desarrollo es grande, distribuido geográficamente, y formado por distintos proveedores. Estas organizaciones están interesadas en adoptar Ágil, precisamente porque están interesadas en maximizar su eficiencia. En www.ibm.com/rational/agile tenemos varios documentos y videos al respecto.

¿Crees que Ágil evoluciona? ¿Cómo?
Sin duda, las metodologías ágiles están evolucionando. Por ejemplo, en los últimos años yo he hecho varios ajustes a Agile Modeling; Kent Beck liberó la segunda versión de su libro “Extreme Programming Explained”, donde presenta cambios significativos a la versión original de XP; Enterprise Scrum justo acaba de salir, y básicamente es una extensión de Scrum que toma ideas del Rational Unified Process (RUP). También está el Open Unified Process (OpenUP), que es un método ágil open source que está disponible en www.eclipse.org/epf.
Así que en el espacio de las metodologías, claramente hay una evolución y actualización.

Por otro lado, es interesante ver que el Manifiesto Ágil parece resistir la prueba del tiempo. Los valores y principios en que se basa no han sufrido cambios, y parecen no necesitarlos. Sin embargo, también está el trabajo del Agile Project Leadership Network (APLN), www.apln.org, el cual en cierta forma puede ser considerado una extensión al Manifiesto Ágil.

Al parecer, la gestión de datos (Data Management) también está siendo impactada por Ágil, ¿podrías explicarnos algo sobre esto?
Introducir agilidad al mundo de la gestión de datos es una tarea ciertamente complicada. Desafortunadamente, la gestión de datos se mantenido relativamente estática en cuanto a métodos y procesos, y muchos de los profesionistas de esa comunidad se siguen aferrando a concepciones erróneas sobre como funciona el desarrollo de software en realidad. Por ejemplo, muchos DBAs creen que es difícil evolucionar o refactorizar un esquema de base de datos existente. Esto es algo que Pramod Sadalage y yo demostramos que se puede hacer fácilmente a través de las técnicas documentadas en nuestro libro “Refactoring Databases”. Sin embargo, los DBAs que no comprenden esto se enfocan en hacer demasiado modelado muy temprano en el ciclo de vida, lo cual en el libro “Agile Database Techniques” demuestro que es una forma de trabajo altamente ineficiente. El Data Warehouse Institute estima que tan solo en Estados Unidos, los problemas de calidad de datos generan un costo de $600 mil millones de dólares anualmente. A pesar de esto, la comunidad de profesionistas de datos ofrece muy pocas recomendaciones prácticas sobre lo que se puede hacer para resolver esto.

En resumen, creo que hay problemas serios en la gestión de datos, sin embargo la mayoría de los profesionistas se aferran a los métodos que generaron estos problemas en primer lugar. Afortunadamente, la comunidad Ágil está involucrándose y desarrollando alternativas para resolver estos problemas. Yo he escrito varios artículos al respecto que están disponibles en www.agiledata.org y que pueden ser de gran ayuda para los profesionistas de datos.

¿Es cierto que un desarrollador de un equipo que utiliza Ágil necesita mayor habilidad y experiencia que en el desarrollo tradicional, o simplemente es cuestión de una mentalidad diferente?
El aspecto fundamental es la mentalidad. Los desarrolladores ágiles buscan colaborar estrechamente con otros, aprender de cada uno, y desarrollar nuevas habilidades. También tienen un fuerte enfoque a la calidad, típicamente utilizando una estrategia “test-first” (probar primero). El hecho es que ser un desarrollador ágil requiere mayor disciplina que uno tradicional, así que tal vez no sea para todos.

Últimamente has escrito sobre “lean development governance”, ¿de qué se trata esto?
La gobernabilidad tradicional se enfoca en estrategias de comando y control, que buscan administrar y dirigir a los equipos de proyecto de forma explícita. Aunque ésta es una estrategia válida en algunas situaciones, en la mayoría de los casos es semejante a arrear gatos –se aplica un gran esfuerzo pero se obtienen pocos resultados. En cambio, “lean governance” se enfoca en estrategias de colaboración que buscan habilitar y motivar a los miembros del equipo implícitamente.

Por ejemplo, la forma tradicional de hacer que un equipo siga lineamientos de programación es definirlos y luego realizar inspecciones formales para asegurar que se estén siguiendo. En cambio, lo que se haría en un enfoque “lean”, sería escribir los lineamientos en colaboración con los programadores, explicando la importancia de que todos los sigan, y luego proporcionando herramientas que faciliten la adopción y seguimiento de los lineamientos. El enfoque “lean” es semejante a guiar gatos, si tomas un pedazo de pescado, ellos te seguirán a donde vayas.

¿Consideras que el desarrollo dirigido por modelos (MDD) alguna vez será el común denominador de cómo desarrollar software?
Eso depende de qué entiendas por MDD. La versión Ágil de MDD ha sido el común denominador desde hace años, ya que es muy común que los desarrolladores ágiles usen herramientas sencillas como pizarrones y rotafolios para modelar. Lo que no es tan común es el enfoque que promueven los profesionistas de modelado, donde todo se debe hacer en una herramienta CASE. En teoría, esta estrategia es muy buena. Sin embargo, en la práctica muy pocas organizaciones tienen suficiente gente con las habilidades necesarias para lograr esto. Las organizaciones que llegan a tener buenos modeladores, con buenas herramientas, logran muy buenos resultados. Sin embargo, este es un porcentaje pequeño de todas las organizaciones de software, y dudo que eso cambie en el futuro cercano.

¿Qué opinas sobre la programación orientada a aspectos (AOP)?
Creo que AOP es una solución muy interesante que todavía está buscando un problema que resolver, y no veo que eso vaya a cambiar.

¿Qué está sucediendo en cuanto al Eclipse Process Framework (EPF)?
Este es un proyecto muy interesante. El EPF composer permite que las personas puedan definir, personalizar y publicar procesos de software, e incluirlos en la herramienta de desarrollo Eclipse. Hay mucho material disponible, incluyendo el OpenUP y la definición de Extreme Programming para EPF. Últimamente no he estado muy involucrado en este proyecto, pero espero poder hacerlo pronto, para agregar más material sobre modelado de datos ágil.

¿Algunas palabras para nuestros lectores?
Estoy muy entusiasmado de visitar México. Nos vemos en SG ’07.