Archivos de Categoría: Blog

En 2003, Tom and Mary Poppendick escribieron su famoso libro Lean Software Development: An Agile Toolkit basado en las experiencias de Tom y Mary. Tom era desarrollador software y Mary trabajó en una fábrica donde se usaban métodos de Lean y del Toyota Production System.

En este libro Tom y Mary definen siete principios básicos del Lean Software Development:

• Eliminar desperdicios (Eliminate waste) considerando a éstos en la industria del software como los defectos o bugs que se puede incluir por error en el código. También se considera residuo o desperdicio a las funcionalidades y características extras incluidas en el producto y que no se necesitaban o no se usan (Over production). Estas funcionalidades no habrían sido incluidas si se hubiesen seguido los principios KISS (KeepIt Simple, Stupid) y YAGNI (You Aren’t Gonna Need It). Otros desperdicios en la producción son:
  • Las esperas (Waiting): Se producen cuando no se tiene la suficiente información o los elementos necesarios para terminar la tarea.
  • Procesos no estándares: Diferentes miembros del equipo usan diferentes métodos para realizar una misma tarea.
  • Transporte (Transportation): Cuando documentos o cualquier tipo de elemento debe ser transportados de un lugar a otro. Por ejemplo, cuando se necesita una copia de seguridad de una base de datos y el volumen de datos es tan grande que no se puede transmitir vía Internet. Podría ser necesario enviar por correo un dispositivo de almacenamiento hasta el centro de datos físico donde están los servidores, para luego transportar la copia físicamente hasta el origen.
  • Intelecto: Cuando el conocimiento y cualificación de un miembro del equipo de trabajo no es utilizado en las tareas donde se le podría sacar más provecho. Está asignado a tareas inferiores donde no se obtiene tanto rendimiento.
  • Movimiento (Motion): Aquel que se realiza cuando se tiene, por ejemplo, que mover documentos en papel hasta un archivador para luego volver a ir a buscarlo cuando se necesita.
  • Exceso de inventario: Cuando se ha creado demasiada documentación, cuando la bandeja de entrada de emails está demasiado llena o cuando se tienen demasiadas llamadas de ventas esperando.
• Aumentar el aprendizaje (Amplify Learning): Usar cualquier método al alcance para poder aumentar el conocimiento sobre el producto y los usuarios o el mercado que lo va a usar. Podrían utilizarse, por ejemplo, test automatizados, que permitirán aprender mejor sobre los errores del software. Puede también aumentarse el aprendizaje con la integración continua. De esta forma no se espera a la integración final de todo el software para saber si hay partes que funcionan bien con las otras o no.
• Retrasar el compromiso (Defer the commitment): Decidir lo más tarde posible. Cuanto más se haya avanzado en la producción del sistema, más se sabrá de él por lo que se cometerán menos errores al decidir.
• Entregar rápido (Deliver fast): No retrasar la entrega de software hasta la finalización del proyecto. Entregar versiones previas cuantos antes. Permitirá aumentar la satisfacción del cliente que recibirá antes su Retorno de la Inversión (ROI) y aprender mejor lo que el cliente usa o no.
• Respetar a la gente (Respect the people): Dejar que los miembros del equipo de trabajo tomen sus propias decisiones, respetarles y potenciar sus individualidades. Se conseguirá un mejor ambiente de trabajo, que se sientan considerados y que se animen a aportar ideas y soluciones que de otra manera no se tendrían.
• Incorporar la calidad (Built quality in): No usar la calidad como una etapa al final de la construcción del producto sino incorporarla en todas las fases del desarrollo. Mantener la calidad siempre presente. El objetivo es prevenir la introducción de errores que haya que corregir posteriormente.
• Optimizar el conjunto (Optimize the whole): En lugar de optimizar pasos o tareas individuales del proceso de desarrollo de software debe intentarse optimizar el flujo completo de este proceso.

Lean es un término que proviene del sistema de producción de Toyota que implantó después de la Segunda Guerra Mundial. En Toyota tomaron de estadounidenses como W. Edwards Deming, que acudieron allí a ayudar en la reconstrucción del país, los conceptos de calidad en los sistemas productivos. Aprendieron estos conceptos, pero también los mejoraron poco a poco, añadiendo otros como Lean y Kanban, hasta convertir a fabricantes como Toyota en el líder mundial en producción de automóviles.

Lean en inglés significa algo así como esbelto, en el sentido de carente de desperdicio o “grasa” sobrante. Pasó de ser un término muy popular en la producción de automóviles de la mano de Toyota a serlo también en otras industrias manufacturación y de todo tipo. Años después se crearon, entre otras, metodologías o frameworks como Lean Manufacturing, Lean in Services, Lean Management (gestión y dirección de empresas), Lean Startup o Lean Software Development.

Lean trata de un conjunto de ideas y principios a aplicar en los procesos. No es un proceso en sí o una metodología a aplicar sino más bien, al igual que Agile, es una actitud o forma de pensar que aplicar al trabajo diario. Aunque Lean no prescribe un método a seguir sí que incluye muchas herramientas para aplicar a esta actitud o mentalidad.

Lean se basa en dos principios básicos:

1. Centrarse en el cliente, es decir, ver el proceso desde su punto de vista. Tratar maximizar el valor que se le proporcionará y reducir los desperdicios o residuos del proceso (waste): Minimizar los recursos usados.
2. Mejorar todo el proceso que genera valor para el cliente (Value Stream) y no las tareas o procesos individuales. De esta manera se trata de mejorar el flujo general intentando reducir el tiempo usado, el número de personas empleadas y reducir los costes y los defectos de la producción. Si los esfuerzos se centran en mejorar una tarea concreta del flujo se podría estar obviando que el cuello de botella está en otra. No se conseguiría así mejorar el valor generado al final de todo el proceso.

Aquí tienes los cinco conceptos de Lean que ayudarán a comprender mejor esta filosofía para cualquier tipo de proceso:

• Valor (Value): El generado por el proceso y por el que el cliente está dispuesto a pagar.
• Value Stream: Cadena de valor que sigue el proceso para añadir más valor al producto o servicio que se están generando.
• Flujo: Se trata de crear un flujo suave para el Value Stream de modo que no haya cuellos de botella, estrés o desperdicios en algunos pasos de este flujo.
• Pull: Se “tira” (Pull) o pide del sistema la cantidad correcta de producto en el momento justo y no más o menos. Se reduce la cantidad de stock porque se tiende a producir cuando el cliente lo pide. Por ejemplo, para solucionar embotellamientos en un cruce, colocar un semáforo es colocar un sistema Push, lo contrario a Pull. Se le llama así porque se basa en una predicción de cuánto tiempo tiene que estar parada una vía para dejar paso a la otra y viceversa. Puede tomarse la decisión equivocada y generar más congestión dando el alto a una vía cuando la contraria no tiene vehículos. Colocar una rotonda en lugar del semáforo es un sistema Pull porque los coches hacen uso de la vía a medida que lo “solicitan”.
• Perfección: Eliminar todos los residuos y desperfectos de la cadena de valor o Value Stream.

Es después del fracaso de metodologías como RUP o Métrica v3 en España cuando surge Agile. Diecisiete profesionales de referencia en la industria del software, representantes de eXtreme Programming, Scrum, Crystal, FDD o Pragmatic Programming, deciden reunirse en un complejo turístico de esquí en las montañas de Utah. Están desencantados con los modelos actuales de desarrollo de software y quieren proponer una alternativa a estos procesos. Procesos que ellos denominaban “pesados” y que consideran demasiado orientados hacia la documentación.

De esta reunión, en 2001, en la que participaban ingenieros software, anarco-organizacionales, sólo pudo obtenerse un resultado meramente simbólico, un manifiesto con cuatro valores máximos y 12 principios “ágiles”. Estos valores y principios lograban resumir lo que estos diecisiete representantes habían llegado a acordar. El único “pero” lo puso Martin Fowler, británico, que indicó que la mayoría de americanos no sabrían pronunciar la palabra Agile.

Estos cuatro valores ágiles indican que se valorará más:

• A los individuos y sus interacciones que a los procesos y las herramientas
• Al software que funciona frente a la documentación excesiva
• A la colaboración con el cliente frente a la negociación del contrato
• A responder ante el cambio antes que seguir un plan

Algunos de sus principios más importantes son:

• <<Nuestra más alta prioridad es satisfacer al cliente a través de entregas tempranas y continuas de software de valor>>
• <<Damos la bienvenida a los cambios a los requerimientos, incluso tarde en el desarrollo. Son una ventaja competitiva del cliente>>
• <<Entregar al cliente software que funciona con frecuencia, desde un par de semanas a un par de meses, con preferencia a la menor escala posible>>
• <<Los proyectos se construyen alrededor de individuos motivados. Dales el entorno y el apoyo que necesitan y confía en que tendrán el trabajo hecho>>
• <<La forma más eficiente y efectiva de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara>>
• <<La gente de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto>>
• <<El software funcionando es la principal medida de progreso>>
• <<La continua atención a la excelencia técnica y el buen diseño mejora la agilidad>>

Tras estudiar estos valores y principios se puede ver que la agilidad es una forma de pensar y no un proceso o una metodología. Una forma de pensar que no descarta totalmente las metodologías, pero quiere poner de nuevo un equilibrio en ellas indicando, por ejemplo, que:

• <<Acepta la documentación, pero no cientos de páginas en tomos que rara vez se usan o se actualizan>>
• <<Planificamos, pero reconocemos los límites de la planificación en entornos cambiantes>>

Cómo se resuelven los problemas del modelo en cascada

Algunos de los principales inconvenientes del modelo en cascada eran la tardía detección de problemas de “traducción” entre la gente de negocio y los desarrolladores. Además, se validaba tarde con el usuario si se habían satisfecho las necesidades que este tenía.

Si se hace caso a los principios ágiles como la entrega frecuente de software que funciona se estará poniendo en producción cada cierto tiempo una versión del producto. Aunque esta versión no esté totalmente terminada, permitirá al usuario usarla y validar pronto si esto que han desarrollado es o no lo que él tenía en mente.

Además, con los departamentos de negocio y de desarrollo trabajando codo con codo se reducirá la posibilidad de mala “traducción” entre lo que el usuario quiso decir y lo que finalmente se entendió. Ideas que más tarde se transmitirán a diseñador y desarrolladores en conversaciones cara a cara y no sólo en documentos de cientos de páginas.

Podían existir también problemas de integración cuando se unían en producción los diferentes componentes y funcionalidades del software. Éstos se detectaban muy tarde en los modelos en cascada. Con esta mejor comunicación, la priorización de la excelencia técnica y la entrega frecuente de software funcionando, no se permitirá que todas las líneas de código lleguen a verse juntas demasiado tarde. Se integrarán en una fase temprana del proyecto, limitando así el problema antes de que sea tan grande que obligue a repetir buena parte de lo que ya se ha hecho.

Referencias:

• BECK K. et al. (2001). Agile Manifesto. Disponible en: http://agilemanifesto.org.html/
• BECK K. et al. (2001). History: The Agile Manifesto. Disponible en: http://agilemanifesto.org/history.html

Los desarrollos o modelos en cascada como RUP (Rational Unified Process) y Métrica v3 eran las metodologías de desarrollo software más ampliamente usadas en la industria hasta los años 2000. Se les llamaba así, en cascada, porque este enfoque metodológico ordena de forma rigurosa las etapas del proceso de desarrollo de modo que una no podía comenzar hasta concluir la anterior. Estas etapas quedaban así dispuestas de forma que, casi sugiriendo gravedad, el desarrollo iba “cayendo” de una fase a otra.

Las fases del modelo en cascada son más o menos así:

Análisis de requisitos

        Diseño del sistema

                Codificación

                        Pruebas

                                Implementación

                                        Mantenimiento

Pero ¿qué sucedía si había un error en el diseño o se entendió mal un requisito? ¿Y si al unir todas las piezas juntas en la fase de codificación, se percibe que durante las pruebas no se integran bien? Es una fase muy tardía y ahora habría que comenzar todo el trabajo desde el principio o rehacer buena parte de lo que ya se ha hecho.

En mis años trabajando para Administraciones Públicas me tocó sufrir particularmente Métrica 3. Era una metodología definida por el Consejo Superior de Informática del Gobierno de España por lo que era habitual que se exigiese en numerosos contratos públicos pero ¿Lograba mejores proyectos? Sinceramente creo que no. Sólo soluciones mastodónticas, poco flexibles y con toneladas de documentación.

Probablemente nadie se leyó nunca todos esos tomos de documentación, los hojearían a lo sumo para comprobar que se decían cosas coherentes y no era sólo relleno. Y no los culpo, creo que quién debía revisar todos esos papeles intentaba hacer bien su trabajo, pero leer documentos no les iba a ayudar a saber si se había hecho un buen producto. Era mejor dedicar ese tiempo a entrar en la aplicación, probarla, usarla y ver si de verdad era útil o no.

Esas toneladas de papel tampoco eran útiles en el momento del desarrollo. Se creaban al inicio del proyecto se pasaban a los programadores y ahí comenzaban a surgir dudas, cambios, incoherencias. Se intentaba mantener la documentación actualizada pero no era práctico. Siempre resultaba mejor un boceto rápido y una conversación con el analista o con el cliente. La documentación terminaba siempre actualizada a posteriori, después de haberse tomado una decisión y haber sido puesta en práctica en el desarrollo.

En la imagen puede verse parte del ya popular chiste sobre los malentendidos en la gestión de requisitos software donde cada participante entiende lo que hay que hacer de manera distinta.

Fuente: CVR/IT

Es muy popular este chiste sobre la toma de requisitos en el software, pero es sólo un chiste ¿o no? ¿Y si el software pasa la fase de pruebas porque todos los requisitos están implementados y llega a la fase de operaciones y mantenimiento? Para entonces los usuarios finales habrán comenzado a usarlo y pueden estar pensando “Esto no es lo que yo les dije, no me entendieron bien”, “Esto no es lo que necesito”. Ya es demasiado tarde. Se ha invertido una cantidad enorme de tiempo y dinero en poner en producción un software con las ideas que se explicaron verbalmente al analista quizás uno o dos años antes. Ahora se comprueba que no cumple las funciones para las que fue pensado ¿Qué sentido tiene hacer las cosas así?

Referencias:

• Metodologías en los 80 y en los 90 de Javier Garzás.

Pues eso, que ahora mi libro va a participar también en la promoción Kindle Monthly Deal de julio. Esto significa que el libro estará con un 50% de descuento del 1 al 31 de julio de este año. Aprovecha a comprarlo en ese mes!

A propósito también, el libro sigue best seller en tres categorías al mismo tiempo y en la posición 24 en el listado de libros más vendido de la tienda Kindle de Amazon España.