Archivos de Categoría: Blog

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.