Cuando estudiaba el 6to Semestre de la carrera, entré a laborar a una pequeña fabrica de software en Pachuca, Hidalgo (México). De 2 años para acá comencé a interesarme en temas más específicos de Ingeniería de Software pasando por la Administración de Proyectos, Casos de Uso, hasta metodologías y procesos como MoProSoft y Personal Software Process. Confieso que desde un inicio nunca pude comprender al 100% estas prácticas de métodos formales, sin embargo las acepte en un inicio. Más adelante la relación entre estas prácticas y yo fue insostenible y las abandone para dar paso a la filosofía ágil de la cual sencillamente estoy encantado.
A partir de aquí, inicia una serie de comentarios que expresan mi opinión personal (muy posiblemente equivocada) sobre bibliografía y material que voy estudiando con el objetivo de crear notas y compartirlas principalmente con estudiantes de carreras afines.
¿QUÉ ES LEAN SOFTWARE DEVELOPMENT?
Comparto con ustedes un video-presentación que realizó Emilio Osorio donde explica lo que es Lean Software y sus principios básicos. Debajo de la presentación, comparto mi poca experiencia, opiniones personales y posiblemente no tan acertadas pero que eso es lo que hace tan valioso a la filosofía ágil, que no existe una receta a seguir y que el proceso se debe amoldar según el entorno.
PARA INICIAR...
Debo comenzar diciendo lo que digo siempre que hablo de metodologías formales.
Martín Fowler, un Gurú en el mundo de Java comenta en su artículo The New Methodology, que las metodologías formales basan sus principios en otras Ingenierías como la Civil y la Mecánica, en donde la mayoría de sus problemas, son susceptibles de un análisis matemático y modelado previo a la construcción. Los métodos formales y nuestros maestros nos enseñaron que en el Software la mejor forma de hacer las cosas bien, son hacerlas a la primera! El error de la Ingeniería de Software tradicional es tratar al desarrollo de Software como un fenómeno predictivo de otras ingenierías, entendiendo como predictivo aquello que es susceptible de un modelado y de un análisis matemático para predecir el comportamiento de un Sistema al aplicar una fuerza.
Pueden leer este otro artículo que escribí titulado ¿Por qué fracasan los proyectos de SW?... Este artículo lo considero bien documentado, y es sencillamente una recopilación de ideas que varios autores a nivel mundial han escrito.
PRINCIPIO 1: ELIMINAR EL DERROCHE
Como desarrolladores estamos tentados a comenzar por desarrollar aquellos módulos más fáciles o más bonitos ó con más reto personal, aunque éstos no agreguen un valor de negocio al usuario, , peor aún, desarrollamos cosas que el cliente no pide. Por ejemplo si debemos desarrollar un Sistema de Reporte de Ventas, muchas veces como desarrolladores comenzamos desarrollando la funcionalidad que grafique los datos, aunque quizá el cliente solo pidió tabularlos, peor aún, desde la filosofía ágil, nosotros debemos entregar funcionalidad cada 2 o 3 semanas, desde esta perspectiva quizá hemos omitido el desarrollo de la autenticación y autorización al sistema y hemos dado paso a desarrollar funcionalidades que no son prioridad en ese momento.
Alguien podría preguntarse ¿Y el desarrollar la funcionalidad para que grafique datos no es algo bueno?... Seguro que sí, pero si el cliente inicialmente no lo pidió, debemos mejor entregar una pieza de software funcional y usable con el que el cliente/usuario comience a trabajar. El usuario, al ver el sistema en funcionamiento seguramente pedirá los datos graficados y más funcionalidad extra, pero en ese momento, él ya estará sacando provecho al Sistema.
Finalmente en este momento puede venir una pregunta más para el lector, con lo anterior ¿no estamos propiciando a que el cliente pida y pida de forma insaciable nuevos requerimientos?... Desde luego,... Pero entonces el proyecto no será costeable para la empresa!... Bueno, desde la perspectiva tradicional efectivamente el proyecto no será costeable, saldrá de sus límites y no será un buen negocio para la empresa que desarrolla el Software, pero desde la perspectiva ágil sencillamente se pagara justo lo que se desarrolla con el plus de que tendremos a un cliente bastante contento. A diferencia de los métodos formales, los métodos ágiles te impulsan a entregar funcionalidad cada 2 o 3 semanas, de tal forma que el costo del desarrollo no se va sobre el proyecto, sino sobre funcionalidad. El cliente no pagará un Sistema, más bien pagará funcionalidad hasta completar un Sistema, de esta forma, si el cliente posteriormente agrega más requerimientos sobre algo ya desarrollado, podremos justificar más fácilmente un costo extra con el plus que el cliente al estar contento no tendrá tantos inconvenientes en pagar por mejorar o agregar funcionalidad extra de algo que ya esta usando. En el caso de una mejora, incluso la misma empresa que desarrolla, puede pensar en no realizar un cobro extra.
Como lo dice Emilio en su presentación, el derroche será todo aquello que no agrega valor al negocio del cliente. No debemos confundir "Eliminar el derroche" con no desarrollar o proponer requerimientos que tengan un valor agregado al negocio del cliente, por el contrario, siempre es buena idea dar un valor agregado al negocio del cliente, una ventaja competitiva que lo ponga un paso adelante sobre sus competidores. Debemos eliminar documentación innecesaria como Diagramas UML, planeaciones en gantt, decenas o cientos de hojas de Casos de Uso.
Lo anterior resulta muy delicado dado que el RUP y las herramientas como UML son tan aceptadas en nuestra industria, sería muy difícil de entender y aceptar que el 90% de los diagramas de UML son en su mayoría inútiles. ¿Qué tan similares son los diagramas de clases realizados al inicio con las clases que se tienen al término del proyecto? La verdad es que son muy diferentes. Si alguien en este punto esta pensando que el Diagrama de Clases es útil por que nos da una vista rápida de como esta construido el sistema, obviamente que desconoce de las herramientas de Ingeniería inversa que nos ayudan a generar diagramas en base a las clases de un Sistema. Existen numerosos autores que ponen en duda la utilidad de UML, muchos otros autores reconocidos como Craig Larman conscientes de los puntos débiles del RUP pero convencidos de su utilidad defienden su utilización desde un punto de vista ágil. Para efectos de este punto, podemos leer un artículo de Bertrand Meyer (el creador del Lenguaje Eiffel) titulado "UML: The Positive Spin" donde verdaderamente se burla de lo absurdo que puede resultar el UML. De igual forma, podemos leer "Death by UML Fever" donde se explica que verdaderamente tenemos una Fiebre de UML. En conclusión podemos decir que UML puede resultar una buena herramienta de modelado post-development, como base para generar documentación para el mantenimiento del Sistema, pero no resulta tan bueno para generar documentación de requerimientos y análisis.
Son muchísimas cosas que agregan un derroche a nuestros proyectos, y considero yo que para este punto, solo falta un poco de sentido común para detectarlo.
Más adelante continuaré con los principios restantes de Lean Software, mientras tanto debí seguir leyendo el libro de Mary Poppendieck que me regalaron.
Lo anterior resulta muy delicado dado que el RUP y las herramientas como UML son tan aceptadas en nuestra industria, sería muy difícil de entender y aceptar que el 90% de los diagramas de UML son en su mayoría inútiles. ¿Qué tan similares son los diagramas de clases realizados al inicio con las clases que se tienen al término del proyecto? La verdad es que son muy diferentes. Si alguien en este punto esta pensando que el Diagrama de Clases es útil por que nos da una vista rápida de como esta construido el sistema, obviamente que desconoce de las herramientas de Ingeniería inversa que nos ayudan a generar diagramas en base a las clases de un Sistema. Existen numerosos autores que ponen en duda la utilidad de UML, muchos otros autores reconocidos como Craig Larman conscientes de los puntos débiles del RUP pero convencidos de su utilidad defienden su utilización desde un punto de vista ágil. Para efectos de este punto, podemos leer un artículo de Bertrand Meyer (el creador del Lenguaje Eiffel) titulado "UML: The Positive Spin" donde verdaderamente se burla de lo absurdo que puede resultar el UML. De igual forma, podemos leer "Death by UML Fever" donde se explica que verdaderamente tenemos una Fiebre de UML. En conclusión podemos decir que UML puede resultar una buena herramienta de modelado post-development, como base para generar documentación para el mantenimiento del Sistema, pero no resulta tan bueno para generar documentación de requerimientos y análisis.
Son muchísimas cosas que agregan un derroche a nuestros proyectos, y considero yo que para este punto, solo falta un poco de sentido común para detectarlo.
Más adelante continuaré con los principios restantes de Lean Software, mientras tanto debí seguir leyendo el libro de Mary Poppendieck que me regalaron.
Saludos!
Entradas
