Una guía Ágil para el desarrollo Lean, parte 1

mapa con brujulaLa cosa más valiosa que puede gastar un hombre es el tiempo - Theophrastus (372 AC - 287 AC)

Lean es el nombre del método que usa Toyota para producir y desarrollar automóviles. Como desarrolladores de software no hacemos ninguna de esas dos cosas, así que ¿por qué nos debería interesar? La razón es simple: los principios básicos del método de Toyota son principios que en la realidad aplican en cualquier lugar. No son panaceas: los principios son universales, aunque puedan variar las prácticas específicas.

En esta primera parte de la guía vamos a ver los siente principios principios y las bases del pensamiento Lean.

Leer más...

Ejecutando ágil despues de renuncias

Adrian Carr escribió acerca de la adaptación de la implementación de Scrum de su equipo después de renuncias. Originalmente, el equipo era un grupo de cuatro desarrolladores, un tester, un Dueño del Producto y el Scrum Master. Después de los recortes, el equipo se redujo a cuatro miembros con Adrian como Scrum Master en medio plazo y ningún Dueño de Producto dedicado. La unidad de negocio tuvo el mismo problema de personal que el grupo de desarrollo y, por tanto, fue capaz de proporcionar sólo un "punto de contacto senior que entiende el negocio y está autorizado a tomar decisiones sobre el proyecto." Así que la pregunta que se hizo él fue: ¿Qué partes de Scrum se deberían mantener? El primer intento de Adrian incluyó:

Leer más...

Venciendo el estado de negación

Sabemos que una idea importante de los procesos ágiles, es la constante inspección y adaptación a realizar en cada pequeño ciclo (diario o semanal) del proyecto de software, para generar un flujo continuo de mejora en el mismo. Por lo tanto, una de las herramientas más importantes para la aplicación de este concepto, es la reunión de RETROSPECTIVA del Sprint, propuesta por Scrum.

La reunión de RETROSPECTIVA se realiza al final de cada Sprint, con la participación de todos los miembros del equipo, junto con el ScrumMaster y una participación opcional del Dueño del Producto, esa reunión tiene como principal objetivo, evaluar "¿Qué funcionó bien" en el Sprint terminado y sería interesante que se mantenga en el próximo Sprint, y también se plantea "Qué hay que mejorar" en el próximo Sprint, sobre la base de las cuestiones que no han funcionado bien en el último Sprint.

Leer más...

Tasa de Testers por Desarrollador

Una gran cuestión en el desarrollo de softwate es: ¿cuál es la tasa de testers para los desarrolladores? En un reciente debate en la lista de Scrum Development se preguntaba cómo la metodología ágil impacta en esta tasa. La respuesta a la primera cuestión parece ser "eso depende". La respuesta a la segunda cuestión, de acuerdo con Elisabeth Hendrickson, es que los equipos ágiles pueden ejecutar más test, con menos de testers.

Leer más...

Mejora contínua y efectiva a traves del Hansei y Kaisen

De acuerdo a la vision de Taiichi Ohno y Shingeo Shingo, que figuran como grandes pensadores de STP (Sistema Toyota de producción o TPS - Toyota Production System), una de las claves para el desarrollo del sistema productivo, es prevenir la recurrencia de los  problemas en cualquier nivel del proceso, para lograr un estado de mejora continua y efectiva sobre la forma de trabajo y sobre los  productos desarrollados.

Para apoyar esta filosofía, TPS muestra dos elementos principales de la cultura oriental, que son el Hansei y el Kaizen, que, como se muestra a continuación, aunque estos elementos son beneficiosos solos, su sinergia cuando se trabajan juntos, se convierte en esencial para la aplicación de la mejora continua dentro del Pensamiento Lean.

Leer más...

Programación en parejas

Ya hace algún tiempo que la programación de a pares se convirtió en una realidad de mi día a día, confieso que en mis primeros contactos con Extreme Programming (XP) esa era la práctica que menos me gustaba, pero luego de involucrarme más con las prácticas ágiles comencé a darme cuenta de sus beneficios, e incluso empezacé a propagar la idea, pero ahora, que sentí más estrechamente como realmente funciona y me gustaría compartir un poco de lo vengo aprendiendo.

Leer más...

La técnica de los 5 porqué

La técnica de los 5 Porqué es un método basado en realizar preguntas para explorar las relaciones de causa-efecto que generan un problema en particular. El objetivo final de los 5 Porqué es determinar la causa raíz de un defecto o problema.

Esta técnica se utilizó por primera vez en Toyota durante la evolución de sus metodologías de fabricación, que luego culminarían en el Toyota Production System (TPS). Esta técnica se usa actualmente en muchos ámbitos, y también se utiliza dentro de Six Sigma.

Leer más...

Igual no lo van a leer

documentosExtreme Programming presenta el principio de YAGNI (You Aren't Gonna Need It - No lo vas a necesitar), el cual nos advierte sobre no invertir tiempo sobre-construyendo sofware que seguramente no va a necesitar esa funcionalidad extra de todas formas, y que este tiempo podría usarse para construir cosas que si son necesarias. Existe un concepto complementario respecto a la documentación: TAGRI (They Aren't Gonna Read It - No lo van a leer).

Leer más...

Programación en parejas: lo que funciona para mi

numero 2 en mosaicoLa Programación en Pareja es una de las técnicas más importantes de XP, y hay varios enfoques sobre cómo hacer que funcione mejor para las personas.

Mark Needham, después de investigar y compartir opiniones con varios colegas, resume algunos de los puntos en donde más consenso parece haber.

Leer más...

Consenso con manos

equipo y manosCuando un equipo logra el consenso sobre algún tema significa que el grupo apoya la decisión; no tienen que pensar todos que sea la mejor decisión, sino que todos acuerdan poder vivir con ella. Puño hasta Cinco es una herramienta muy facil para crear consenso en los equipos.

Leer más...

El secreto de la organización ágil

carpeta top secret¿Están preparados? Aquí está el secreto... para ser ágil deben... ¡romper todas las dependencias a cualquier costo!

Las depedencias se crean cuando dos elementos discritos dentro de la organización se necesitan mutuamente para hacer parte (o todo) de su trabajo. Las dependencias están por todos lados a nivel organizacional. Son creadas por la forma en la que estructuramos el negocio y cómo preaparamos y ejecutamos el trabajo de nuestros proyectos. Esto hace que sea muy dificil identificarlas, y más dificil todavía eliminarlas.

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw