Agile Project Management

Tom DeMarco y Timothy Lister en su libro Peopleware consideraban que hay dos teorías fundamentales de gestión que son aplicables a la gestión de proyectos. Una, la primera de ellas y quizás la más primitiva, considera que el valor o riqueza existente en la Tierra es una cantidad limitada. Según esta teoría, cuanto más se trabaja para extraerla, más riqueza se obtendrá (y menos quedará para los demás).

Inconscientemente, es la teoría que aplican muchos managers cuando deciden usar las horas extra, los fines de semana trabajados o la penalización si los trabajadores se marchan a su hora. Están dividiendo el número de tareas realizadas a la semana entre 40 horas y no entre las 60 realmente trabajadas. Así creen aumentar ellos la, mal llamada aquí productividad, un pequeño fraude en las cuentas que tanto cuesta a los trabajadores.

Según esta manera de pensar, la tarea del gestor es la de extraer el máximo de trabajo (el trabajo de los colaboradores) usando la menor cantidad posible de recursos (el número y sueldo de esos colaboradores). A partir de ahí el cálculo es sencillo, para maximizar la “productividad” se deberá aumentar el número de horas empleadas y pagar poco por ellas o no contratar muchos técnicos.

Es el cálculo básico que realizan los managers que, como comenta Javier Garzás en su blog, pretenden aumentar la productividad añadiendo 10 becarios de golpe a un proyecto. Imaginen el impacto de eso en un proyecto en un proyecto normal: Hay que parar de trabajar para enseñar a esos nuevos compañeros, buscar algo que hacer para cada uno de ellos, revisar lo que hayan hecho, atender sus preguntas, etc. En lugar de avanzar solo se va a conseguir retroceder durante mucho tiempo.

En la Mecánica Clásica, el trabajo empleado para mover un objeto es el resultado de multiplicar la fuerza empleada por el desplazamiento conseguido. Cuanto más lejos se haya conseguido desplazarlo, más trabajo se ha hecho. Si ponemos a diez personas a mover una gran piedra y esta no se ha movido un milímetro, según la Física, el trabajo realizado es cero. Sucede lo mismo con esta mal entendida productividad.

Si en 40 horas apenas se es capaz de entregar un mínimo de tareas hechas es que algo está fallando en los métodos productivos. Si hay que emplear 60 horas a la semana para conseguir obtener algunas tareas más, eso no es productividad real, en un engaño en los cálculos. Se aumenta un poco la productividad a coste de disparar la fuerza empleada. Y esto sin tener en cuenta el cansancio y la falta de motivación producidos por no tener suficiente tiempo de descanso. Solo se estará consiguiendo reducir el desplazamiento conseguido para la siguiente semana.

Los que aplican estas soluciones para intentar aumentar el trabajo conseguido solo se están fijando en una parte de la ecuación. Miran la fuerza, el número de horas que se trabaja, pero se olvidan de la otra parte, lo que se consigue con esa fuerza, el desplazamiento obtenido ¿De qué vale aumentar solo la fuerza si puede que incluso se esté perjudicando con ello los resultados?

Ya lo dice el ingeniero español José María Acosta en su libro sobre el uso eficaz del tiempo: “Trabajar más horas o más deprisa no es la solución”. Pasar más horas en la oficina tampoco lo es.

¿Le ha gustado este post? Podrá ver más contenidos como este en mi nuevo libro: Dibujando la revolución ágil. Esté atento a este blog. Pronto anunciaré la preventa del libro a un precio especial.

¿Cuántos proyectos conoce que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿No? Esto pasa en casi todos los sectores, no solo en la industria del software, pero probablemente esta industria tiene una tasa de proyectos fracasados más alta que otras. Puede verse esto tras cada uno de los estudios del informe CHAOS del Standish Group que, siendo aún muy discutibles, pueden dar una aproximación del estado de la industria.

Las estimaciones de tiempo y coste de un proyecto se salen de toda escala y se incumplen habitualmente los relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tienen todas las personas no deprimidas. Debido a él, se cae, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómeno, el de la falacia de la planificación, es debido a que los seres humanos tienden a subestimar cuanto nos va a llevar terminar una tarea. Se es demasiado optimista y siempre se piensa que se va a tardar mucho menos de lo que finalmente va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio a los estudiantes de una universidad. En él preguntaron a 87 estudiantes cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto. solo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55,5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness). Es el efecto que nos dice que por muy bien que se planifique el proyecto será difícil planificar los imprevistos porque son eso, imprevistos, y no se conocen de antemano. Se planifica todo lo relacionado con las especificaciones del proyecto, pero nos olvidamos de calcular los imprevistos. En nuestra mente, no tenemos en cuenta las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera.

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: “Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter”.

Y si esto ocurre y el proyecto se alarga más de lo previsto, probablemente se caiga todavía en más costes de lo que supone terminar más tarde. Como no se llega a la fecha del fin del proyecto la presión llevará a meter a más gente dentro del proyecto para intentar terminar a tiempo. Lo que se conseguirá es tener que contabilizar gastos extra directos como el salario de estas nuevas personas, pero también indirectos de los cuáles no siempre se es consciente.

Al incluir más personas se olvida que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores a los que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya decía Brooks en los años 70: “Añadir más gente a un proyecto retrasado, hará que se retrase aún más”.

Pero la presión por terminar a tiempo aún hará incurrir en más costes en el proyecto. Las prisas terminarán haciendo bajar la calidad del producto que se produce. Aparecerán más errores que también necesitarán tiempo para ser corregidos, o se saltarían las pruebas para asegurar la calidad del proyecto con lo que saldrá a la venta con defectos. Errores que harán perder la confianza y credibilidad del cliente. Y por supuesto, queremos que este cliente nos contrate de nuevo ¿No?

Vimos la semana pasada un poco de historia sobre Extreme Programming y su creador, Kent Beck. Veamos ahora los valores y fundamentos detrás de XP y que hacen que este funcione:

Simplicidad: Se trata de usar la solución que funcione que sea la más simple posible. Aprovechar el concepto de la Navaja de Ockham o seguir el principio KISS (Keep It Simple, Stupid) para desechar ideas demasiado complejas y no hacer over-engineering.

Para ello se tomarán pequeños pasos hasta el objetivo y se iterará hasta conseguirlo. Se adaptará por el camino a lo que se haya aprendido en lugar de pensar una solución compleja al inicio y desarrollarla al pie de la letra.

Comunicación: Kent Beck se dio cuenta de que muchos de los problemas en los equipos de trabajo se debían a que no había una correcta comunicación entre sus miembros. Para ello propone:

1. Que todos los miembros del equipo de trabajo se comuniquen cara a cara de forma diaria (similar a las reuniones diarias de Scrum)
2. Que todo el mundo trabaje en todas las partes del proyecto, desde la toma de requisitos hasta la codificación.
3. Que se cree un sentimiento de pertenencia al equipo y de cooperación entre todos los integrantes.

Coraje: Se trata de crear un ambiente en el que no haya miedo a ser castigado o criticado por cometer un error o por ir retrasado en su tarea. Un ambiente en el que cada persona se sienta libre de decir cuál es realmente el estado en el que está la tarea en la que está trabajando.

Se quiere conseguir la valentía suficiente para que se tomen decisiones libremente porque se busca lo mejor para el proyecto. Se trata de evitar, por ejemplo, que se documenten páginas y páginas de lo que realmente son excusas. Cuando se escribe mucha documentación en realidad se quiere decir “Se me dijo así por lo que yo diseñé/implementé esto”. De esta forma se quiere que nadie pueda poner un “pero” a la decisión que se ha tomado.

Feedback: En XP se da por sentando, que no se puede implementar la opción correcta a la primera. Se debe iterar y volver a mejorar la opción tomada o desarrollar una diferente. Para conseguir esto se necesita obtener retroalimentación de lo que sucedió en la iteración anterior para poder mejorar.

Se generará tanto feedback como se pueda manejar y tan rápido como sea posible. Se irá más despacio si el equipo no puede adaptarse a tanto feedback recibido.

El feedback puede venir en muchas formas posibles, por ejemplo, en resultados de los test ¿Funcionaron? ¿Qué falló? Opiniones de los clientes que ya están usando la aplicación, o funcionalidades introducidas en la aplicación ¿Recibieron muchos clics? ¿Las completaron? ¿Han preguntado por ellas?

Respeto: Es el valor que resume los otros cuatro y sin el que los demás no funcionarán. Si no hay respeto entre los miembros del equipo y éstos no respetan al proyecto y sus compañeros difícilmente se obtendrá un feedback correcto. No tendrán el coraje suficiente para tomar las mejores y más simples decisiones y fallará la comunicación. Nadie, en un equipo de trabajo que usa XP, es más importante que nadie. Ni lo es el jefe del proyecto sobre el resto de miembros ni lo es el ingeniero software sénior con muchos años de experiencia en el trabajo.

eXtreme Programming, también llamada XP, es una metodología de programación considerada ágil, aunque se creó en 1996, años antes de que se firmara el Manifiesto Ágil. Los fundamentos de XP vienen de las prácticas tomadas a cabo por Kent Beck en un proyecto para el pago de nóminas en Chrysler. El trabajo de Kent en este proyecto se hizo popular por haber tenido éxito en tan sólo un año y dos meses cuando un equipo de 30 personas había fracasado durante años.

Esta aplicación de nóminas, llamada C3, pretendía sustituir una aplicación anterior hecha con una tecnología antigua. En el momento de la incorporación de Kent al proyecto, tres años después de su inicio, C3 no había podido pagar una sola nómina en Chrysler.

Implementando principios de las industrias de fabricación, como Lean Manufacturing, el equipo de Kent consiguió aumentar enormemente la eficiencia del sistema. Al principio se calculaba que ejecutar el proceso de pago de nóminas llevaría unas 1000 horas. Diversas actividades de mejora redujeron este tiempo a alrededor de 40 horas, luego a 12 y por último quedó en tan sólo 9 horas.

A pesar del gran avance que supusieron estas técnicas, el proyecto C3 fue cancelado solo unos años después, en el 2000, tras la compra de Chrysler por Daimler-Benz. Con esto puede verse que, usar XP, no es una garantía de éxito.

La palabra eXtreme proviene del concepto de que si algo se considera bueno por qué no llevarlo al límite y usarlo al máximo. Si, por ejemplo, que alguien revise lo que cada miembro del equipo hace se considera una buena práctica ¿Por qué no llevarlo al extremo y hacer que esos miembros del equipo de trabajo se sienten juntos todos los días y se revisen y mejoren el código a diario?

Referencias:

• Extreme Programming (XP)
• Chrysler Comprehensive Compensation System en la Wikipedia.

Lean Startup toma el nombre del libro más popular de Eric Ries. En él, Eric definía una metodología para desarrollar negocios y productos que se hizo pronto muy popular en el mundo de la creación de pequeñas empresas. Con el tiempo también llegó a hacerse muy conocido entre los desarrolladores de software que percibieron que muchos conceptos eran igualmente válidos para la creación de este tipo de productos.

Scrum, XP o Lean Software Development ayudan a construir rápida y efectivamente un nuevo producto. Desafortunadamente, cuando se trata de construir productos que van a salir al mercado, no dicen nada sobre si van a tener éxito o no esos productos ¿Qué sucede si se ha construido una app que luego no se vende? Se puede haber construido eficazmente, pero todo ese trabajo quedará en la basura si no despierta interés en el mercado.

En Scrum, por ejemplo, un Product Owner dice lo que necesita, suele ser un representante del cliente y sabe lo que necesita. Define también la lista de cosas que hay que construir que luego se llevan a cabo, pero ¿Y si no hay Product Owner o somos nosotros mismos los que tenemos la idea de negocio? ¿Y si el Product Owner conoce muy bien su negocio, pero no sabe tanto sobre cómo funcionan los mercados?

Es aquí donde entra Lean Startup que ayuda a saber qué construir más que al cómo construirlo. Eric Ries en su libro declara:

<<Debemos construir lo que el cliente realmente quiere, no lo que ellos dicen que quieren ni lo que nosotros creemos que deben querer>>

Para hacer esto Lean Startup se basa en tres bases fundamentales:

La primera, el aprendizaje validado (Validated Learning, ver figura 3), se basa en aplicar a cada idea o suposición que se tenga para el mercado un ciclo por el que:

1. Establecer una métrica que permita medir el éxito o no de esa idea.
2. Construir una prueba o experimento que permita medir ese éxito (construir un experimento, no el producto completo)
3. Aprender del resultado de esta prueba, analizar y decidir sobre ella. No apostar todo a construir el producto hasta que no se ha aprendido si va a funcionar o no.

El segundo fundamento importante de Lean Startup es que se debe completar este ciclo de la forma más rápida posible. De esta manera se puede reducir el gasto o desperdicio o llegar al mercado cuanto antes, lo que puede suponer una ventaja competitiva.

El tercero y último de los principios más importantes de Lean Startup es que esta metodología es una aproximación iterativa e incremental. Una vez terminado uno de estos ciclos de Aprendizaje, Experimentación y Medición, se realizará otra prueba para tener un conocimiento mayor o más exacto. Se trata de averiguar si la idea o el producto funcionarán o se prueba otro concepto distinto repitiendo así constantemente el ciclo.

Parece un principio obvio, respetado seguramente por los jefes de proyecto y managers en muchos de los equipos de trabajo, pero casi con toda seguridad no en todos.

Pero ¿qué significa exactamente respetar a la gente? En lo básico se trata de:

• Escuchar con atención.
• No desechar las opiniones cuando son diferentes de las propias.
• Animar a la gente a que diga lo que piensa.
• Tener empatía con los demás.
• Intentar ver las cosas desde otros puntos de vista.

Se debe practicar esto con cuidado porque se puede caer en una situación en la que se esté de acuerdo con la opinión de todo el mundo y esto no siempre es posible. Se trata de ser asertivo y saber decir que no se está de acuerdo con una opinión sin sonar agresivo o imponer siempre la opinión propia.

Además de estos puntos básicos, también es importante facilitar el que los miembros de los equipos tomen sus propias decisiones. Son, en numerosas ocasiones, expertos en su campo y nadie mejor que ellos conocen las implicaciones positivas y negativas de una decisión. Si frecuentemente no ven respetadas sus opiniones, o se les desautoriza, dejarán de atreverse a proponer ideas nuevas o a expresar los pros y los contras a las ideas que otros sugieren.

Como no, respetar el crecimiento de los miembros del equipo de trabajo, es también un punto a resaltar en el trabajo como responsables de un proyecto. La gente trabaja, acumula aprendizaje y experiencias proyecto tras proyecto y se merece crecer en responsabilidades para mejorar sus condiciones, aprender cosas nuevas y enseñar lo que ha aprendido. Limitarlos a lo que han hecho siempre porque son difíciles de sustituir o porque se está acostumbrado a verlos ahí no beneficia a nadie, ni al proyecto ni a ellos.

Por último, deben también respetarse los límites naturales de los miembros del equipo de trabajo. No todo el mundo puede entregar al mismo nivel todo el tiempo. Además, el bajo rendimiento de un miembro del equipo podría ser debido a su situación personal, laboral o su estado de salud. Presionarles, ahogarles en trabajo o quemarles (en japonés Muri, en inglés Overburden) no mejorará su productividad, al contrario, la empeorará.

Se deben respetar estos límites, entender estas situaciones y entender también que no se puede medir el rendimiento de todo el mundo sólo en un número de líneas de código. Cada miembro del equipo de trabajo cumple también otras funciones además de codificar, diseñar o analizar. Algunos son meticulosos con el trabajo entregado, otros son catalizadores que estimulan la confianza, animadores o líderes y un largo etcétera.

Con este principio se trata de evitar emplear los test de calidad sólo en la última fase del desarrollo. Para entonces podría ser demasiado tarde para darse cuenta de errores importantes y, con las prisas, esta fase es siempre la que se ve sacrificada para poder entregar “a tiempo”. Lean propone incorporar la calidad desde el principio del proceso y en cada fase del mismo para, en lugar de perseguir y buscar errores, intentar evitar cometerlos.

Otra de las grandes ventajas de incorporar los test de calidad a todo el proceso es que ayudan a medir el progreso real. Si se desarrolla el código sin testearlo llegará un momento en el que aparentemente se habrá llegado a un 100% del proceso de desarrollo. Sin embargo, en una última fase final de test podríamos llevarnos una desagradable sorpresa: Los errores son muchos y graves. Se habrá caído en la cuenta demasiado tarde para ver que el progreso no fue real y que hay que rehacer grandes partes del código.

Por otro lado, si se incorpora la calidad desde el inicio, se evitarán más errores lo que impedirá también el enmascarado de otros (Defect masking) que podrían estar ocultos por los primeros. Se llama enmascarado de errores a cuando la existencia de un error evita que se perciba la existencia de otros. En una aplicación web, difícilmente podrán verse los errores que contenga la segunda o terceras páginas si no puede accederse a la primera por un error que impide su visualización.

Lean recomienda fomentar en el equipo la importancia de la calidad en el trabajo. Esto se hace propiciando, por ejemplo, que todos los trabajadores participen en la realización de las pruebas. Les permitirá ver de primera mano donde fallan más habitualmente los productos, qué sucede cuando lo hacen y la mala impresión que puede dejar al cliente.

Uno de los principios básicos de Lean Software Development consiste en lo que Tom y Mary llamaron Aumentar el aprendizaje o Amplify Learning. Se trata de 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.

Aumentar el aprendizaje (Amplify Learning)

Ampliar el aprendizaje consiste en incrementar la capacidad del equipo para aprender rápidamente y de un modo efectivo. Aprender sobre las necesidades de los usuarios, sobre la solución a desarrollar o sobre el propio proceso para llegar a ser más productivos.

El desarrollo de software no es una tarea repetitiva que se pueda realizar de forma monótona. Es un proceso creativo y como tal requiere de un aprendizaje. Con el desarrollo no basta con establecer un plan y luego seguirlo al pie de la letra. Este plan va a variar y mucho a medida que se aprende sobre el producto, el proceso, el mercado y el usuario. La aproximación a este tipo de proyectos es el de prueba y error y no la de simple repetición. Cuánto más rápido y efectivos se sea aprendiendo de estas pruebas mejor se hará. Se convertirá en una ventaja competitiva.

¿Cómo se puede aprender rápidamente?

• Usando ciclos de desarrollo cortos en los que se despliegue en producción cada poco, se reciba feedback y se ajusten los próximos desarrollos basándose en esos feedbacks.
• Desarrollar sólo una parte del alcance de la aplicación, entregarla para luego realizar con lo aprendido el resto de partes de la aplicación.
• Daily builds y smoke test: Las Daily builds son una técnica que permite la construcción automática diaria del ejecutable o interpretable de una aplicación. Existen herramientas que toman el código fuente del sistema de gestión de versiones la integra y genera el ejecutable o build de la aplicación. Le pasa luego los smoke test al resultado de manera que avisa si surgieron errores en la integración o en los test. Los smoke test son test básicos que avisan si falla algo grave en el software. Avisan por ejemplo si no hay conexión con la base de datos o si no se imprimen en pantalla los resultados.
• Desarrollar múltiples opciones: Cuando se baraja un determinado conjunto de opciones posibles para el desarrollo se puede caer en la parálisis por análisis. Se tarda mucho tiempo en decidir cuál es la opción más correcta a implementar sin la garantía de que la finalmente elegida sea la óptima. Para evitar esto se propone ponerse manos a la obra e implementar directamente una o varias de ellas. Permitirá aprender de primera mano las ventajas y desventajas de cada opción y se podrá terminar eligiendo la mejor o una combinación de algunas de ellas.

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.

Hoy he recibido la noticia de que Amazon ha incluido mi libro entre la selección de libros que forman parte del programa Prime Reading durante 180 días. Esto significa que podrás descargártelo completamente gratis en ese plazo si estás suscrito a Amazon Prime. Por 19,95€ anuales puedes disfrutar gratis de una selección de ebooks gratis, gastos de envío de libros en papel gratuitos y Amazon Prime Video. Espero que esto te anime a leértelo!

A propósito, hoy miércoles, sobre las 11:00 de la mañana en España, mi libro ha vuelto ha alcanzar la posición de bestseller pero esta vez en tres categorías al mismo tiempo. En total ha alcanzado el puesto nº 159 en ventas entre todos los libros Kindle de Amazon España (libros de gestión, informática, no ficción o novelas). Estas son las categorías en las que ha quedado nº 1 en ventas:

• Programación y desarrollo web (en papel)
• Internet y web (en formato ebook)
• Internet y web (en papel)

Actualización: Hoy, 1 de junio, el libro sigue todavía de bestseller en las mismas categorías que el miércoles pero está en total en el puesto nº 16 en el ranking de ventas de la tienda Kindle de Amazon (libros de ficción y no ficción).

Este mes se cumplen cuatro años ya desde que se publicó por primera vez el libro Gestión práctica de proyectos con Scrum. Desde entonces ha estado dos veces en el top 100 en ventas de Amazon España, permaneciendo en esta lista en un total de 12 días.

En innumerables  ocasiones más ha estado en la lista de bestsellers para las categorías de libros electrónicos de Programación o Web pero también en la de gestión de proyectos de todos los libros, tanto en papel como en ebook.

No sólo se vende sino que también se lee. Aquí tienen la gráfica que proporciona Amazon sobre el número de páginas de mi libro leídas cada día en todo el mundo (últimos 90 días). Debe ser una media aproximada de una 100 páginas diarias, llegando algunos días a 400 o casi 500 páginas leídas al día. No tiene en cuenta las páginas leídas en formato papel (esto sería defícil de saber).

Páginas leídas en Amazon España del libro Gestión Práctica de proyectos con Scrum

El libro tiene unas 100 páginas lo que supone que al menos un libro completo se lee cada día en alguna parte del mundo. Esto significa que el libro gusta, que se recomienda y que a la gente le sirve para aprender y mejorar. Después de cuatro años, el libro ha pasado de ser un best-seller a ser un long-seller. Estoy más orgulloso de esto que de llegar a top ventas en alguna categoría de vez en cuando.

Les dejo por último con una pequeña selección de algunos de más de 50 comentarios positivos de libro en Amazon España y 30 en Amazon.com:

Un libro interesante y práctico. Escrito desde la experiencia y el sentido común.

— Santi

Lectura imprescindible: El libro está escrito desde la experiencia profesional y eso se nota en cada párrafo.

— Alex Tamarit

No me esperaba encontrar esto y la verdad que me ha sorprendido gratamente. En definitiva, un libro que te ayuda a ser mejor desarrollador y mejor gestor.

— Juan

Situaciones simpáticas y reales (todas), los típicos marrones del mundo de la gestión de software y muchas lecciones aprendidas que las leerás y dirás… «qué razón tienes». Mucho ingenio y sentido común.

— Rafael León Lavin

En su texto que es muy ameno, -aderezado con dibujos y citas muy útiles-, vas a encontrar consejos y también la esencia de Scrum. Es conveniente reelerlo otras veces.

— Cliente Amazon

No puedo estar más de acuerdo en las historias y anécdotas de su autor. Un acierto seguro si quieres conocer qué eso del Scrum del que todo el mundo habla en el mundo de los proyectos IT.

— Juan

Definitavemente valió la pena invertir tiempo a la lectura de este libro, muy buen material para aquellos que trabajamos en el area y ni idea tenemos del porque de las juntas. En general excelente material!

— Armando Rodríguez

Me dejó grandes lecciones así como un deseo de aprender mucho más.

— Luis Alberto Sánchez Guzmán

Les dejo en este breve post algunas fotos sobre la charla El jefe de proyectos ágil que tuvimos el pasado jueves en el pabellón B del edificio de coworking de la SPEGC. Gracias a todos por asistir y por el interés mostrado. Gracias a Iván Tejera de IT Proiectus por la organización.

El próximo día 12 de abril, jueves de la próxima semana, daré una charla a las 18:00 en el edificio INCUBE de la SPEGC. La dirección es: Avenida de la Feria 1, Las Palmas de Gran Canaria. La asistencia es gratuita, no faltes. La convocatoria saldrá pronto en el meetup de la SPEGC.

La charla se titula ‘El jefe de proyectos ágil’ y trata de cómo Scrum define los roles de Scrum Master y Product Owner pero ninguno de ellos contempla las tareas del jefe de proyectos tradicional ¿Dónde queda entonces la gestión de los equipos de trabajo o los recursos humanos? ¿Y las prácticas de ingeniría del software?

Para resolver esto, a nuestra ayuda acuden eXtreme Programming y Peopleware que suplen los huecos que deja el marco de trabajo Scrum en la gestión de proyectos.

Aquí tienes la presentación que usaré en la charla. Si te gusta lo que ves, no te olvides de asistir.

Este blog que está leyendo comenzó su andadura hace, casi exactamente, cinco años, el 29 de marzo de 2013. Han sido desde entonces más de 200 entradas en el blog que me han permitido expresarme y contarles casi todo lo que sé sobre gestión ágil de proyectos y Scrum.

Los tres posts más leídos son:

• Certificación Professional Scrum Master (PSM I)
• Ventajas y desventajas de Scrum I y II
• Estimaciones con Scrum

Otros que considero importantes y que no tuvieron tanto éxito en su momento son:

• El ingeniero y el puente
• Scrum para proyectos de mantenimiento
• El sprint número cero de Scrum y el diseño inicial

Atentos a los próximos cinco años de este blog. Habrá más entradas sobre eXtreme Programming, Lean, Peopleware, gestión del tiempo y psicologia o biología en la gestión de proyectos.

Tenemos que empezar a trabajar y la Lista del Producto no está bien detallada o especificada. Esto va a hacer que cuando pasemos cada tarjeta a desarrollo surjan dudas y preguntas o, lo que es peor, se desarrollen las cosas sin estar bien definidas y requiriendo de cambios posteriores. Trabajaremos a la mitad de la velocidad de lo que podríamos hacerlo y para colmo podríamos hacer doble trabajo. Mal trato.

El trabajo del Dueño del Producto es por tanto muy importante y si es un Dueño del Producto nuevo en estas lides difícilmente podrá ser productivo desde el inicio y tener todo el trabajo listo antes del comienzo de cada Sprint. El Equipo de Trabajo podría quedarse sin cosas que hacer si el Sprint Backlog no está bien definido antes de comenzar el Sprint.

Necesitaremos darle todo el apoyo y formación necesarios para que pueda hacer su trabajo. Ayudarle para que sepa cuáles son las cosas más importantes sobre las que debe trabajar de forma que las tenga listas para cada Sprint.