Programación en pareja, tomada de https://miro.medium.com/max/700/1*sBJhFwmpfbftanqzxOeK_w.jpeg
La programación en parejas es una práctica ágil donde dos personas trabajan en una sola computadora para resolver un problema. La programación en pareja abre un canal de comunicación y retroalimentación inmediata entre dos personas, para analizar, diseñar, probar y crear una solución utilizando código de programación.
¿Cuántas veces no hemos necesitado ayuda para resolver un problema?
¿Para lavar los trastes? – Oye, dejaste jabón en esa parte, – El plato tiene una manchita ahí.
También cuando manejamos un automóvil, nuestro copiloto nos dice:
Dobla a la derecha, este camino es más corto.
¡Aguas de este lado viene carro! ¡Ahí hay un bache!
Aquí es donde otra persona y dos ojos más entran en acción.
Las grandes cosas vienen en parejas
Parejas de inventores, músicos, pintores y emprendedores
Desde un inicio, desde que existe la interacción social, siempre se busca simplificar las tareas y hacerlas con la mejor calidad posible. Como vemos en la sección anterior, el trabajo en pareja siempre ha existido y da muy buenos resultados.
Un cazador enseña a su hijo como cazar una cebra y le indica que el mejor lugar para clavarla es justo debajo de la oreja, donde puede atravesar su cráneo, pero ese es un tiro muy difícil. El tiro más fácil es – “Apuntar a las rayas que la cebra tiene en el pecho” (mientras dibuja las rayas en el tronco de un árbol).
– “Sigue practicando el tiro a una distancia de 20 pasos hasta que claves la lanza correctamente”, luego -“No espera, sostén la lanza así”, más tarde – “Si, así está mejor, continua así” … – “Ahora, pídele a tu tío que te enseñe cómo hacer que la cebra se acerque a una distancia de 10 pasos”
Betty Jean Jennings Bartik y Frances Bilas Spence usando ENIAC
Betty Snyder y yo, desde el principio, éramos una pareja. Y creo que el mejor diseño y todas esas cosas son hechas en pareja porque mutuamente se puede criticar, identificar errores y usar las mejores ideas de ambos.
Betty Jean Jennings Bartik, ENIAC programmer 1946
Jean Bartik formó parte de las ahora justamente reconocidas primeras programadoras de ENIAC, donde según fuentes también practicaban “Test First development”.
Frederick Phillips Brook, 1953
Fred Brook, autor del libro The Mythical Man-Month: Essays on Software Engineering del año 1975, un libro sobre ingeniería de software y administración de proyectos. También conocido por la ley de Brook, la cual empezó a definirla cuando trabajaba para IBM en el desarrollo del sistema operativo OS/360. En este libro él menciona lo siguiente:
Agregar mano de obra a un proyecto de software retrasado, lo retrasa aún más.
Frederick Phillips Brook
Brook le escribió a Laurie Williams:
Compañero de posgrado Bill Wright y yo probamos por primera vez la programación en parejas cuando era un estudiante graduado (1953 -1956). Produjimos 1.500 líneas de código libre de defectos; se ejecutó correctamente en el primer intento.
Frederick Phillips Brook
Richard P. Gabriel en 1972
1972-1973, Dick Gabriel hace programación en pareja con Jonl White, usando Lisp como lenguaje de programación. Después como encargado del desarrollo de Common Lisp, programación en parejas fue una de las prácticas principales.
Dynamic Duos, 1978-1988
Larry Constantine, pionero en la ingeniera de software, con más de 200 publicaciones y 22 libros. Reporto en su visita a Whitesmiths Inc. que en cada terminal había dos programadores trabajando. Le llamó “Dynamic Duo”, Whitesmiths creó el primer compilador comercial del lenguaje de programación C.
“Las personas a veces sienten que pueden resolver un problema solo si tienen ayuda. Algunos problemas son más grandes que los de cualquier individuo”. La solución propuesta del patrón organizacional es “emparejar diseñadores compatibles para trabajar juntos; …
James Coplien
El proyecto Pasteur extrajo muestras empíricas de 50 organizaciones de desarrollo de software altamente efectivas, usando técnicas de análisis y recopilación de datos similares a las usadas por sociólogos y antropólogos.
Finalmente Kent Beck, unos de los firmantes del manifiesto ágil, creador de programación extrema y de sus propias palabras, el “redescubridor de TDD” en 1998 agregó “pair programming” como una de las prácticas de Extreme Programming.
Beneficios de programación en parejas
Todos los beneficios de más abajo se resumen en los tres principales aquí listados, que desde el punto de vista de negocio, son el objetivo de implementar cualquier práctica ágil.
Disminuir los tiempos
Reducir el Estrés
Aumentar el Dinero o las ganancias
Además estos beneficios son el resultado de aplicar los siguientes principios ágiles:
Individuos e interacciones sobre procesos y herramientas.
Respuesta ante el cambio sobre seguir un plan.
Software funcionando sobre documentación extensiva.
Canal de comunicación y colaboración
Se abren muchos canales de comunicación (más si se rotan las parejas) que estimulan la colaboración. Si combinamos diferentes perspectivas, ideas, conocimiento técnico y conocimiento del negocio, entonces el resultado es una solución superior, una solución más simple y más sólida. Sin mencionar que el tiempo en llegar a una solución se reduce considerablemente.
Muchísimas veces ni siquiera tenemos que esperar a que nuestra prueba falle o esperar a debuguear para notar un error, nuestro compañero con su lindo cerebro y sus dos ojos nos lo puede indicar de inmediato.
Incluso ni siquiera tenemos que recordar la especificación del problema a resolver (por eso de la pérdida de enfoque), porque tenemos otra mente que nos lo recuerda.
Code Review Continuo
Cuando se está programando en pares se obtiene retroalimentación inmediata de nuestro compañero, vamos a llamarle “code review instantáneo”. Así que actuamos ante ese cambio de idea, perspectiva, mejora, error cometido, cualquier cosa que nos ayude a resolver el problema o mejorar la solución.
Te falta un punto y coma.
¿No te falto definir la variable que contiene los datos de tu parámetro?
Ahí debe ser un string no la referencia al método
Son frases que he escuchado mucho antes de ejecutar la verificación de la prueba, el feedback o review lo obtengo aún mucho más rápido que la prueba automatizada. Esto en realidad es un ciclo de retroalimentación más eficiente.
Esparcir el conocimiento técnico y de negocio
Transferencia de conocimiento, siempre existe algo que aprender del compañero, tanto del entendimiento del problema y el negocio, como técnicamente.
Esparcimiento y homologación del estándar y estilo de programación definido por el proyecto.
Si un integrante del equipo se va, no importa, todos los demás tienen contexto y el conocimiento adecuado.
Mucho menos tiempo descubriendo lo que hizo el excompañero
Los nuevos integrantes del equipo obtienen el conocimiento y el contexto rápidamente de los compañeros con más tiempo en el proyecto, preguntando y haciendo programación en parejas.
Aumento en la calidad del producto
Si solo armas lo primero que piensas, nunca tendrás tiempo para pensar en una segunda cosa mejor.
Kent Beck
Diferentes perspectivas que ayudan a encontrar una solución mucho más simple. Esto significa menos tiempo desarrollando, las soluciones simples son mucho más sustentables, es más fácil comprenderlas, implementarlas en otros lugares/casos, modificarlas y mejorarlas. Siguiendo el principio ágil de “Simplicidad, el arte de maximizar el trabajo no realizado”.
Combinación de ideas y creatividad para mejorar la solución. Casi siempre el desarrollo de cualquier cosa que usa dos mentes, resulta en un diseño superior. Y este punto se relaciona mucho con el siguiente principio ágil. “La excelencia técnica y el buen diseño, mejoran la agilidad”.
Utilizar cada pieza del sistema como una verdadera caja negra, debido a un diseño superior creado por dos mentes, porque es simple y de mayor calidad, nos ahorra tiempo revisando los cables detrás de una funcionalidad. Nos permite enfocarnos en el problema y no como funcionan las piezas necesarias.
Disminuye la necesidad de documentación en etapas tempranas de desarrollo. Por que el conocimiento se esparce, la documentación pierde sentido en etapas tempranas, una documentación solo funciona cuando se tiene una versión muy estable de una pieza de software, no queremos perder el tiempo en modificar la documentación cada vez que cambiamos algo en el código.
Lo recomendado es invertir ese tiempo en tener un conjunto de pruebas automatizadas y claramente diseñadas, enfocándose en transmitir de manera transparente los requerimientos, que sean fácilmente entendidos en la primera lectura. No necesitamos documentación que nos dé una especificación desactualizada o errónea. Al hacer pruebas y mejor aún, “test-first developement” en pareja, aumenta considerablemente la calidad.
Ahorra tiempo, mayor velocidad
En lugar de pasar una hora atorado haciendo una tarea individual, en pareja muchas veces lo resuelven en cinco minutos. ¿Nunca te ha pasado que estás atorado durante dos horas, luego te vas a dar una vuelta, regresas y en menos de cinco minutos encuentras la solución? Pues en pareja no necesitas esperar esas dos hora e irte a dar una vuelta, tu compañero podría tener la solución o conversándolo con él en conjunto cristalizan una aún mejor.
El tiempo que te sobra lo ocupas para todavía hacer más.
Debido al beneficio de esparcir el conocimiento, aceleramos el nivel técnico y de negocio de los nuevos integrantes.
Por el aumento de calidad ya explicada, las integraciones son más rápidas, se resuelven, es más rápido modificar funcionalidades e implementar nuevas por la simplicidad de las mismas.
Reduce el Estrés
Entre menos tiempo pases trabajando tendrás menos estrés y una mente fresca y creativa (comprobado científicamente). Por lo cual tus tareas las resolverás más rápido, con ganas y con orgullo. Tendrás más tiempo después de tus horas de trabajo para estar con la familia, con la novia o esposa, o simplemente hacer tus cosas personales
Ahorra dinero
Es bueno para el negocio, entregas más rápidas, iteraciones con mayor alcance y por supuesto mejor retorno de inversión por la calidad del software y la flexibilidad de adaptarse a las nuevas necesidades del usuario final (por el diseño superior creado en pareja).
¿Como hacer programación en parejas?
Existen varias formas de usar la programación en parejas, los más usados y simples son:
Driver y navigator
Ping Pong
Driver y navigator
Se tiene dos perspectivas en cuanto al código.
El driver es la persona que controla la computadora y escribe el código, el navigator sentado a su lado observa el proceso desde otra perspectiva, revisando cada línea de código mientras el driver escribe, al mismo tiempo que apoya al driver dándole dirección y desbloqueándolo.
Una persona se encarga de la táctica (driver) y la otra de la estrategia (navigator).
Es importante cambiar los roles continuamente, así mitigamos el aburrimiento y cambiamos de perspectiva para tener ideas frescas.
El navigator puede anotar sus ideas para no cortarle la inspiración al driver, estas ideas se pueden mencionar cuando el driver termine de escribir el código que tenía en su mente.
Según la neurociencia, la programación en parejas une dos tipos de pensamientos. El driver trabaja en un modo de pensamiento enfocado, mientras que el navigator trabaja con un modo de pensamiento difuso.
Porque ahora tenemos dos mentes, podemos separar estas dos perspectivas y utilizarlas al mismo tiempo.
Ejemplo de esto es lo que ya comentamos, cuando estás atorado con un problema por dos horas, te vas a dar una vuelta, tomar café o algo y regresas, te sientas enfrente de tu computadora y en cinco minutos lo resuelves.
Ping pong
El primer developer escribe la próxima prueba
El segundo developer hace pasar la prueba y escribe la próxima prueba
El primer developer hace pasar la prueba
Después de que alguno de los programadores hace pasar la prueba, ambos hacen el refactor utilizando driver y navigator.
Esta es una técnica bastante sencilla y útil para cambiar frecuentemente entre driver y navigator, así ambos programadores practican ambos modos de pensamiento. Fomenta la creatividad y el uso de prácticas ágiles como TDD y BDD.
¿Cuánto cuesta hacer programación en parejas?
Uno puede pensar que el costo de hacer programación en parejas es el doble debido a que dos personas trabajan para completar una sola tarea, pero no es así, según estudios realizados por Laurie Williams en el año 1999 en la universidad de Utah, haciendo programación en parejas solo aumentó un 15% de tiempo para completar la tarea.
Ese 15% de tiempo gastado fue recuperado en un código con 15% menos defectos.
Según este estudio el código generado individualmente es 15 veces más costoso debido al mayor esfuerzo de arreglar los defectos. Luego si ese defecto se filtra a producción, entonces el costo es 60 veces más.
¿Por qué es más costoso el desarrollo con programadores individuales? Porque el diseño individual es inferior a un diseño creado por dos personas. Dos cabezas son mejor que una.
Este resultado se alinea con la filosofía de prevención de incidencias y que entre más tiempo pasa en encontrar el defecto, es más costoso porque primero se tiene que volver a replicar, entender el problema, entender el código relacionado y además el tiempo gastado en la solución. ¿Qué pasa si es un defecto que se detecta después de un año? ¿Qué pasa si la persona con más conocimiento del contexto ya no está en el proyecto o no está disponible?
¿Y si tenemos un equipo distribuido? ¿Cómo hacemos programación en pareja?
En la actualidad existen muchas aplicaciones de videollamadas para compartir pantallas, IDEs con extensiones o plugins y hasta aplicaciones para compartir el control de tú maquina que te permiten tener una colaboración en tiempo real sobre el código en cuestión.
Jeff Dean y Sanjay Ghemawat. Super reconocidos en google porque salvaron a la empresa de morir, arreglaron el enorme crawler de google que había parado de funcionar en el año 2000. Han creado juntos en google a mapReduce, BigTable y Spanner. Y muchas cosas más fuera de google.
Kent Beck (Co-creador principal de extreme programming) y Erich Gamma (co-autor del libro Design Patterns: Elements of Reusable Object-OrientedSoftware). Juntos crearon JUNIT el principal framework de automatización de pruebas para Java y también para Kotlin.
Alistair Cuckborn. Creador de la familia de métodos Crystal clear y Heart of agile
Ron Jeffries. Firmante del manifiesto ágil y co-creador de extreme programming
Ward Cunningham. Firmante del manifiesto ágil y co-creador de extreme programming
Martin Fowler. Firmante del manifiesto ágil y autor del libro Refactoring: Improving the Design of Existing Code
Robert C. Martin. Firmante del manifiesto ágil y conocido por acuñar los principios de diseño SOLID
Michael Feathers. Autor del libro Working Effectively with Legacy Code
No todo es color de rosa en la práctica
¿Cuándo no hacer programación en parejas?
Si la tarea es demasiada sencilla o algo repetitivo.
Cuando ninguno tiene mucho conocimiento del problema y/o código a modificar.
Mejor ambos se asignan tareas de investigación para retroalimentarse después y compartir ese nuevo conocimiento.
Cuando uno de los pares ya pasó mucho tiempo haciendo programación en parejas. Continuar haciéndolo por mucho tiempo es demasiado desgaste mental.
¿Cuánto tiempo hacer programación en parejas?
Definitivamente no 8 horas al día, mucho tiempo haciendo programación en parejas es muy cansado, según fuentes lo recomendado es de 1.5 a 4 horas diarias.
¿Qué tan a menudo cambiar de pareja?
Cada vez que se sienta la necesidad según el problema a resolver. Se recomienda cambiar de pareja diariamente para esparcir el conocimiento técnico y de negocio, pero si alguien aún no entiende un concepto con su pareja actual, entonces no debería cambiar de pareja hasta que tenga sólido ese concepto.
Recomendaciones de interacción social
Super importante tener como base siempre estos tres principios humanos latentes en cada momento para las interacciones sociales.
Respeto, de hecho un valor de scrum y extreme programming.
Honestidad, alineado con la transparencia del empirismo de scrum y el coraje en extreme programming.
Justicia, es justo pensar en el bienestar de todas las personas involucradas. Da el coraje (otro valor de scrum y XP) de hacer programación en pareja y buscar acuerdos mutuos. Al mismo tiempo te hace pensar en lo más justos para ambos, como pareja.
Las personas importan
Piensa en tu compañero, lo más importante son las personas, actua de la forma mas justa posible para entablar comunicacion y acuerdos.
También ponte en los zapatos de los usuarios finales, ¿Querrías tener problemas si fueras tú el que usa la aplicación? Esto ayuda a tener una mente positiva y darnos el coraje de hacer pair programming por el bien de todos. Genera Compromiso y justicia hacia los involucrados.
Tres hábitos para la comunicación y no estancarse.
Piensa en ganar/ganar. A veces puede haber conflictos de ideas, piense en lo más importante, las personas, todos pueden salir ganando, en lugar de perder mucho tiempo debatiendo ¿Por qué no prueban ambas ideas? Paso a paso se darán cuenta de lo mejor para el problema o muchas veces son una combinación de las dos posturas.
Procura primero comprender y después ser comprendido.
Cuando se debaten ideas debemos entender profundamente la otra idea, escuchar con la verdadera intención de comprender. Un buen doctor primero hace un diagnóstico antes de dar una receta.
Ahora tu turno de exponer tu idea.
Sinergizar. Encontrar la solución juntos, tu idea en combinación con la mía genera una mejor, 1 + 1 = 3, 4 o 5, de esas dos ideas sale una tercera, una superior.
Reitero, si el debate sobre las ideas se está alargando, es mejor elegir un término medio y empezar a tirar código, conforme avancen verán por cuál idea se inclinan más.
Planifica
Tengan un horario de sesiones, con el objetivo de no solaparse con reuniones importantes. Con tu familia establece acuerdos y horarios para que tampoco te interrumpan a menos que de verdad sea algo importante.
Por ejemplo, si tu hijo quiere que juegues con él en el momento de la sesión de pair programming, aunque de verdad yo creo que jugar con tu hijo es más importante que trabajar, también podrías establecer con tu hijo los horarios de juego para que no se solapen con los horarios de trabajo.
Sin distracciones
Sin distracciones mientras se hace pair programming, respeta el tiempo de tu compañero y mantente enfocado en lo que están haciendo juntos, no leas emails, no veas mensajes de WhatsApp o de Facebook, trata de no hacer llamadas. Así eres justo con el tiempo de la otra persona.
Pomodoro
Es bueno tomar breaks cada veinticinco minutos o más dependiendo como se sientan y utilizar de cinco a diez minutos como recompensa para ahora si hacer lo que quieran, como revisar Facebook o el WhatsApp. Esto disminuye la fatiga y mantiene las ideas frescas porque constantemente te recompensas y le dices a tu cerebro que los próximos veinticinco minutos valen la pena.
Apertura
Mucho, mucho respeto a las ideas de tu compañero, no importa si tienes más experiencia o menos, recuerda que diferentes ideas y perspectivas nos llevan a mejores soluciones. El genio John Von Neumman pedía constantemente a sus compañeros que revisaran su trabajo.
Piensa en la crítica como algo que te ayude a mejorar.
Elimina el condicionamiento social
Normalmente se tiene la idea de que equivocarse es malo, de que no saber es herejía, al contrario, ser vulnerable en estos aspectos ayuda mucho a mejorar como individuo, como equipo y a mejorar el producto. Y todo el mundo debe estar consciente de esto, a no juzgar y abrazar las diferencias, las cuales son muy importantes a la hora de innovar porque diferentes perspectivas siempre nos permite construir una mejor forma de ver las cosas, lo que lleva a generar mejoras ideas y aumentar la creatividad.
La importancia de Celebrar
Celebren juntos después de terminar con una tarea, vayan a tomar un café, coman algo, jueguen un videojuego, que sé yo, el chiste que celebren. Esto promueve un mini team building y entrenan a su cerebro para no cansarse y tener pensamientos positivos para continuar. Ayuda al estrés.
De programación en parejas a Mob programming
Es una práctica ágil moderna que extiende la idea de pair programming a todo el equipo, donde se puede incluir todo tipo de involucrado en el producto. Desde programadores, administradores de base de datos, gente de diseño y experiencia de usuario, product owners, project managers, hasta clientes y usuarios.
Toda la gente brillante trabajando en lo mismo, al mismo tiempo, en el mismo espacio, en la misma computadora
Woody Zuill
Mob Programming es integración continua para ideas.
Aunque probablemente el cambio de desarrollo tradicional a desarrollo ágil empezó mucho antes de los acontecimientos que voy a mencionar, estos son los más importantes que marcaron la base para lo que hoy en día llamamos agilidad, como todo buen cambio, no sucedió de la noche a la mañana, fue un proceso lento, como un cambio de paradigma, el cual la sociedad de la administración de proyectos y software empezaron poco a poco a interiorizar o al menos a utilizar.
En cuanto a los métodos, puede haber un millón y algo más, pero los principios son pocos. El hombre que capta los principios puede seleccionar con éxito sus propios métodos. El hombre que prueba métodos, ignorando principios, seguramente tendrá problemas.
Ralph Waldo Emerson
Es importante mencionar que a pesar de que el movimiento ágil se relaciona mucho con del desarrollo de software, realmente no tiene que ver específicamente con esta industria, más bien sus raíces son en las personas mismas, por lo que se aplica a todas las áreas que te puedas imaginar donde existan personas, es decir, en todo.
El desarrollo ágil es un cambio cultural, lleno de principios y valores humanos, que todos y cada uno de los integrantes de un equipo y de una empresa deben tener arraigado muy en su ser, para que de esta manera sucedan cosas mágicas, como la creación de productos que llenan de enorme satisfacción al usuario y los clientes, velocidad de producción, reducción de costos, proyectos exitosos, empleados felices y en general el beneficio de todos los involucrados, tanto internos como externos, directos o indirectos.
Total Quality Management (TQM)
El primer cambio significativo con dirección al desarrollo ágil sucede durante la segunda guerra mundial donde Williams Edwards Deming les enseño control estadístico de los procesos a los ingenieros estadounidenses con el fin de mejorar los materiales de guerra, aun así, parece que los estadounidenses no le prestaron mucho interés, probablemente debido a la guerra. Después de esto en 1950, Deming se trasladó a Japón, en la época donde la industria y economía de este país estaba en crisis, esta vez si pudo transmitir exitosamente sus conocimientos y filosofía de la calidad de los productos y servicios. Los japoneses lo escucharon y estuvieron dispuestos a cambiar la cultura de trabajo.
Al implementar los principios de la metodología de Deming, los japoneses convirtieron totalmente su economía e industria posicionándose como lideres mundiales en ámbitos como tecnología, industria manufacturera y comunicaciones
De hecho la metodología TQM que creo Deming fue la base para el nacimiento del movimiento ágil, los principios más importantes de TQM son los siguientes:
Mejorar la calidad resulta en reducción de costos, reducción del costo de los defectos, reducción de soporte al cliente y menos llamadas de los mismos en relación con defectos.
Mejora continua en todos las partes del sistema y las personas.
Orgullo del trabajo que hace una persona, es la clave principal para obtener la calidad necesaria de un producto/servicio, que los empleados disfruten su trabajo y con orgullo.
Plan – Do – Check – Act (PDCA) – Ciclo de desarrollo para poder probar y obtener retroalimentación sobre soluciones de problemas y creación de sistemas complejos.
Del punto uno y dos, Deming fomentó lo siguiente:
Mejorando la calidad, automáticamente, mejora la productividad.
Williams Edward Deming
En la actualidad, existe un principio ágil muy relacionado con lo que dijo el señor Deming:
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Del punto tres tenemos su relación con el principio actual
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Si analizamos los primeros tres puntos de TQM y en concreto el tercer punto, podemos concluir que al preocuparnos por las personas obtendremos calidad y una mejora continua tanto en los sistemas y procesos como en las personas mismas, por que al final de todo, los individuos son el recurso que genera productos/servicios y forman empresas.
En el manifiesto Ágil que veremos en otra publicación, el primer elemento de manifiesto y el más importante dice así:
Individuos e interacciones sobre procesos y herramientas.
Como podemos ver el desarrollo ágil no es realmente algo nuevo, siempre se ha estado buscando mejores maneras de trabajar.
Sobre el último punto, el ciclo PDCA se parece mucho a lo que se utiliza actualmente en Lean, Lean startup, Lean thinking, Design thinking, RAD, DSDM, Extreme programming, Scrum, Crystal clear y demás metodologías estilo ágiles. El objetivo es obtener retroalimentación inmediatamente para aprender y mitigar errores o direcciones equivocadas.
Este ciclo PDCA nos permite responder al cambio, con lo cual se ejerce un principio fundamental del manifiesto ágil:
Ahora veamos los diagramas de algunos de los ciclos de retroalimentación que tiene las metodologías ágiles:
Design Thinking Ciclo de retroalimentación
Lean Startup ciclo de retroalimentación
Scrum ciclo de retroalimentación
Extreme Programming
DSDM ciclo de retroalimentación
¿Qué tal, todos estos ciclos son muy parecidos verdad?
Toyota Production System (TPS)
Este sistema desarrollado entre 1948 y 1975, y presentado formalmente en los 80´s fue inspirado en los trabajos de Henry Ford y también en TQM debido a que sus inicios datan de la misma época cuando Edwards Deming fue a Japón a transmitir sus conocimientos de Gestión de calidad Total (TQM) y en esos tiempos Taichii Ohno estaba trabajando para Toyota Motors Company. Como todo buen diseño, no solo de una fuente surgen las inspiraciones y las ideas, pero podemos notar la influencia y evolución de TQM en TPS.
Este sistema fue el precursor de Lean Manufacturing y demás metodologías Lean de la actualidad. Los principios en los que se basa TPS son los siguientes:
Mejora continua, tomando como base a las personas, mejorando su ambiente laboral, su aprendizaje, su creatividad e ideas para que de esta manera mejoren en todo lo que hacen incluyendo los procesos, herramientas y métodos utilizados en toda la empresa.
Respeto por las personas. Aquí de nuevo otra constante clave del éxito de este sistema, el respeto por las personas. Aunque también el enfoque es en la mejora continua, esto nunca se lograría sin el respeto, ¿Qué es el respeto? Para mí, y esto ya lo escribí en otro post cursi sobre agilidad (¿Qué es Scrum? ¿Por qué es importante en la creación de productos y/o servicios? Valores, empirismo y pilares) es el amor por otra persona, aunque no intenso, es la naturaleza del ser humano preocuparse por los demás, un sentimiento latente en mayor o menor medida, todos somos diferentes, y lamentablemente algunos de nosotros lo tenemos muy escondido, pero ahí esta, un principio natural que genera un ciclo infinito de buenas intenciones.
A través del principio de mejora continúa y respeto por las personas, TPS propone lo siguiente:
La eliminación de desperdicios (Muda), los cuales son provocados por la sobrecarga de trabajo y estrés de los empleados, máquinas, procesos, etc (Muri), también por inconsistencias y variaciones no previstas que causan un desequilibrio en la producción (Mura). Con Muri y Mura podemos destacar de nuevo la importancia de las personas para el éxito de este método. TPS define 7 tipos de desperdicios, solo los voy a mencionar:
Desperdicio por sobreproducción
Desperdicio por Tiempo de espera
Desperdicio por transporte
Desperdicio por procesos
Desperdicio por inventario
Desperdicio por movimientos
Desperdicio por defectos
Lotes pequeños. La mejor manera de encontrar errores, aprender de ellos y mitigar sus efectos negativos lo más pronto posible es por tareas/procesos pequeños y simples mucho más fáciles de manejar y entender.
Kanban. Para eliminar el desperdicio, Taiichi utilizó un tablero con tarjetas (Kanban) donde se puede visualizar lo que se tiene que hacer, lo que sé está haciendo, lo que se terminó y si una tarea necesita de materiales o de la finalización de otra tarea para continuar.
Pruebas constantes. Siempre probando con lotes pequeños para encontrar errores y mitigarlos inmediatamente. En cada lote pequeño es más fácil hacer pruebas, actualmente en agilidad se utilizan las pruebas unitarias y funcionales de un lote pequeño de elementos del sistema que entregan valor para los usuarios/clientes en periodos cortos de tiempo.
Estos últimos puntos están muy relacionados con el siguiente principio ágil:
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Todo lo anterior permite que Toyota se encuentre actualmente como una de las tres mejores compañías de autos, con un 70% de satisfacción de sus empleados. ¿Que compañía logra eso? el enfoque de respeto hacia las personas ha hecho de Toyota lo que hoy en día es.
¿El modelo en cascada propuso algunas practicas de lo que hoy llamamos desarrollo ágil?
¿Qué? ¿Cómo? y seguro pensaras algo así, “A mí me enseñaron que el ciclo del modelo en cascada era secuencial, no te creo”. Bueno a mí también me enseñaron lo mismo, pero investigando resulta que hay un mal entendido global de lo que propuso Winston Royce acerca del modelo en cascada y la prueba que encontré esta aquí, por si quieres abrir los ojos por ti mismo.
Expliquemos lo que propuso Winston Royce en su documento del año 1970, si, como he estado explicando, siempre ha existido una tendencia hacia el desarrollo ágil. Winston Royce presento el siguiente diagrama:
Pero inmediatamente aclaró que este modelo era muy riesgoso y propenso al fracaso. ¿Entonces por que demonios lo empezamos a utilizar? No lo sé, pero en mi caso, lamentablemente fue lo que me enseñaron en la universidad, cuando en esa época ya existían mejores métodos para el desarrollo de software como XP y Scrum que se establecieron formalmente a los mediados de los 90’s. Winston Royce propuso cinco mejoras al método de cascada, son los siguientes:
El diseño del sistema debe ser primero
Documentar el diseño
Hacerlo dos veces
Planear, controlar y monitorear pruebas
Involucrar al cliente
Aunque las dos primeras mejoras se podría decir que no son ágiles, los ultimas tres mejoras claramente tienen su merito ágil. Aun así el método que propone Winston Royce no es secuencial, sino más bien iterativo e incremental, bueno, tampoco no tan iterativo e incremental como actualmente lo es el desarrollo ágil pero era un gran comienzo. Veamos ahora el diagrama con las cinco mejoras de Royce:
Modelo cascada ágil
No explicare a detalle las cinco mejoras, pero las describiré brevemente y su relación con los principios fundamentales del desarrollo ágil. Antes de eso si se fijan de lado derecho existe otro ciclo de retroalimentación que va desde pruebas, desarrollo y requerimientos, por lo que totalmente lineal waterfall nunca lo fue.
El diseño del sistema debe ser primero, esto actualmente siempre se hace solo que en ciclos pequeños e incrementales sobre todo el sistema, también en escala aún más pequeña al realizar las pruebas unitarias o funcionales se piensa inmediatamente primero en el diseño de la funcionalidad antes de escribir código para poder crear la prueba.
Documentar el diseño. En las metodologías ágiles de hecho se realiza documentación solo que muchas veces no están en documentos, sino en las pruebas unitarias y funcionales, es decir, en lugares donde no se podrá mentir, en la fuente, el código. Pero esto último es otro tema, lo de mayor prioridad es tener un software funcionando, aun así la documentación también se hace por ciclos iterativos e incrementales.
Hacerlo dos veces. Royce empieza a recomendar ciclos iterativos e incrementales al sugerir realizar dos veces la creación del sistema. Actualmente en desarrollo ágil no solo se realiza dos veces, sino muchas veces en periodos cortos del mismo día, en horas y hasta en minutos, también siendo iterativo e incremental,
Planear, controlar y monitorear pruebas. En metodologías ágiles se utilizan las pruebas para obtener retroalimentación lo más pronto posible y hacer los arreglos necesarios, aunque el modelo de Royce a mi parecer no implementa las pruebas tan seguido como en las metodologías ágiles actuales, mínimo lo hace dos veces durante una iteración.
Involucrar al cliente. Este es el más importante para mí porque hace mucho hincapié sobre las interacciones de las personas. En el manifiesto ágil de la actualidad tenemos lo siguiente:
Colaboración con el cliente sobre negociación contractual
En el ámbito de la creación de software, mucha antes de la creación del famoso manifiesto ágil, metodologías y frameworks tradicionales que se utilizaban para crear productos o proyectos no estaban funcionando, existía un porcentaje muy alto de fracaso.
El porcentaje alto de fracasos fue influido por la mala implementación del modelo en cascada de Winston Royce. Entonces varias personas empezaron a preguntarse si habría mejores maneras de desarrollar software, es aquí donde empezaron a crear sus propias métodos ágiles, empezaron a surgir metodologías como:
Rapid Application Development (RAD) – 70s – 80s
Como vemos en este ciclo de retroalimentación, existen iteraciones en las fases de diseño y construcción.
RAD ciclo de retroalimentación
Dynamic software development method (DSDM) – 80s
En el ciclo de retroalimentación de esta metodología, incluye iteraciones en la factibilidad y fundación, es decir, los requerimientos, además de poder hacer iteraciones en las fases diseño y construcción.
DSDM ciclo de retroalimentación
Extreme Programing (XP) – Mediados de los 90s, Kent Beck, Ward Cunningham, Ron Jeffries
Este es un mejor ciclo de retroalimentacion en comparacion con los anteriores, en todo momento se hacen iteraciones, en todos los niveles, además:
Mucho uso de TDD, continuamente durante todas las etapas
Pruebas de aceptación y unitarias
Origen de los Dailys o stand up meetings
También las famosas historias de usuario.
Extreme progamming ciclo de retroalimentación
Scrum – A mediados de los 90s – Ken Schwaber, Jeff Sutherland
Bueno este es el más conocido de todos y el más usado actualmente, para mas detalles sobre este framework te dejo los siguentes enlaces:
Aunque estos frameworks ya habían empezado con el desarrollo ágil, era necesario definir ciertos principios comunes para mejorar el entendimiento y la rápida adopción de estas nuevas formas de crear software.
En el 2001, 17 desarrolladores de software se reunieron en Snowbird, Utah para analizar sobre los métodos de desarrollo de software ágil que estas 17 personas estaban utilizando, DSDM, Extreme Programming, Scrum y crystal clear. El resultado fue el Manifiesto ágil y los 12 principios ágiles.
¿Por que es de suma importancia el manifiesto y los 12 principios ágiles?
Es importante entender que más adelante podría surgir un nuevo framework ágil con una mejor manera de hacer las cosas y que probablemente deberíamos de adoptar, pero el manifiesto y los principios ágiles seguirán siendo la base primordial que si se comprende bien y se interiorizan, cualquier equipo u organización podra utilizar el framework o método que más le convenga en determinadas circunstancias o proyectos.
Es como la creación de código y piezas de un sistema computacional, no importa el lenguaje de programación, librería o frameworks de desarrollo, si no las bases de lógica, patrones y principios de diseño y arquitectura, los que harán entender cualquier nuevo lenguaje o framework que pudiera salir en el futuro.
Hablando un poco más sobre las prácticas utilizadas en los frameworks ágiles, estás prácticas están subordinadas por los principios, es decir, en un proyecto, se utilizarán las prácticas más acordes a las circunstancias del problema que se quiere solucionar. Por la tanto es importante comprender el porque se ejecuta una práctica, o sea, que practica me dará mejores resultados y agilidad basándome en los principios y factores específicos del problema.
¿Qué es ágil?
La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulento
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otras personas a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación de contratos.
Respuesta ante el cambio sobre seguir un plan
Es decir, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.
En esta publicación explico a detalle la razón y como aplicar el manifiesto ágil:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Una startup es una institución de seres humanos diseñada para crear un nuevo producto o servicio bajo condiciones de extrema incertidumbre.
Lean Startup toma su nombre de la revolución Lean manufacturing que Taiichi Ohno y Shigeo Shingo desarrollaron en Toyota. Se basaron en Lean Thinking para alterar los sistemas de la cadena de producción y suministros. Entre sus principios está la utilización del conocimiento y creatividad de los individuos, la reducción de los lotes, el método justo a tiempo para los sistemas de gestión de producción y control de inventarios, y una aceleración en las iteraciones. Enfocados en la creación de valor para los clientes y eliminar el desperdicio de esfuerzo.
Lean Startup adapta estas ideas en el contexto de emprendimiento. Para Lean Startup, emprendimiento es un tipo de administración, así es, un emprendedor es un tipo de administrador. La única deferencia es que muchas veces los administradores trabajan en una ambiente más controlado con un producto o servicio existente.
Pero ¿Qué sucede cuando en una empresa se requiere agregar una característica nueva o innovar en un producto existente? Muy probablemente la incertidumbre va a crecer. Y ¿Qué pasaría si una empresa quiere lanzar un nuevo producto o servicio?, en este último caso, podemos decir con seguridad que la incertidumbre es extrema. Esto es lo que realmente sucede en las empresas, porque vivimos en un mundo con cambios sumamente constantes y los administradores necesitan adaptarse a estos cambios.
Debido a esta incertidumbre extrema, una startup no se puede gestionar con los métodos tradicionales, el fracaso en una startup es necesario para el aprendizaje, cometer errores tempranamente para validar tus ideas iniciales y entonces adaptarse mejorando el producto a la necesidad real del cliente.
Con la anterior definición podemos listar los 5 principios de Lean startup:
Emprendedores hay en todas partes
Si ponemos atención la definición de arriba sobre lo que es un emprendedor, podremos comprender que un emprendedor está en todas partes, desde la compañía más grande e internacional, hasta la más pequeña, en cualquier sector, en cualquier industria y en condiciones de extrema incertidumbre.
Emprendimiento es Administración
Así es, una startup es una institución, y requiere un nuevo tipo de administración enfocado en el contexto de condiciones de extrema incertidumbre. Esto quiere decir que una startup no solo se trata del producto, sino de una institución humana completa.
Aprendizaje validado
Una de las claves para el éxito de una startup es el aprender como crear un negocio sustentable, y este aprendizaje se valida usando experimentos frecuentemente de tal forma que se pueda probar cada elemento de la visión de la startup.
Construir-Medir-Aprender
Es el proceso fundamental de una startup, convertir ideas en productos, medir como los clientes reaccionan y aprender si se debe cambiar la estrategia o seguir adelante con la ruta actual. Este proceso está siempre en mejora continua para acelerar la retroalimentación del cliente.
Innovación contable
Como decíamos, necesitamos métodos diferentes, ¿Cómo podemos medir el progreso de la startup?, ¿Cómo definir metas? y ¿Cómo priorizar nuestro trabajo? La contabilidad de una startup no solo son números financieros, lo más importante es medir el valor que le proporcionamos a nuestros clientes y como obtener crecimiento basándonos en ese valor.
Ciclo de retroalimentación Construir-Medir-Aprender y motor de crecimiento
Lean startup es administración de empresas que proporcionan productos o servicios en ambientes de extrema incertidumbre. Aunque existe mucho material sobre administración de negocios, muchas veces no se toma en cuenta la incertidumbre en el que estos negocios se encuentran.
Lean Startup recomienda medir la productividad de manera diferente, este nuevo enfoque existe porque muy a menudo se construye algo que nadie quiere, entonces no importa si se construye a tiempo o dentro del presupuesto si al final nadie va a querer el producto o servicio.
El objetivo de una startup es descubrir lo más pronto posible lo que el cliente realmente quiere y va a pagar por ello, de esta manera se construye solo lo necesario de mucho valor y se evita el desperdicio de tiempo, dinero y esfuerzo. Es una nueva forma de ver el desarrollo de nuevos productos e innovaciones donde se utiliza mucho las iteraciones ágiles con un gran enfoque en el comportamiento del cliente y la combinación de una gran visión de lo que se quiere lograr.
Eric Ríes utiliza la metáfora del automóvil de combustión interna para describir lo que es Lean startup. Dentro de un automóvil existen dos importantes ciclos de retroalimentación:
El motor en sí, llamado Motor de Crecimiento.
Conductor y volante, llamado Construir-Medir-Aprender.
Motor de crecimiento. Se encuentra dentro del motor, cada explosión de los pistones provoca la suficiente fuerza para hacer girar las ruedas y al mismo tiempo impulsa la ignición para la siguiente explosión de los pistones y así generar el continuo movimiento de las llantas de un coche. Esto se traduce a todas las operaciones, marketing y mejoras del producto que se realizan dentro de una institución, esto permite que el motor continúe su función e impulse al crecimiento. En una startup, la mayor parte del tiempo se invierte en poner al 100% este motor, mejorándolo constantemente basándose en los resultados del segundo ciclo de retroalimentación.
No sé mucho de autos, y mucho menos de motores, pero imaginemos que se utilizan distintos motores según el terreno por el cual un coche se desplaza, con esto se explica la relación con el segundo ciclo de retroalimentación, si vamos a nuestro destino a través de una autopista y un camino plano, es claro que necesitamos un motor con mucha velocidad y que aguante la aceleración más rápida durante mucho tiempo, pero si al contrario vamos en un camino de tierra con terreno irregular, con subidas y bajadas bruscas, es necesario un motor con mayor aguante a los cambios continuos entre pausas y aceleraciones, y que por lo tanto además de rapidez para avanzar también necesitamos resistencia a estos terrenos irregulares para llegar a nuestra meta. Necesitamos afinar o cambiar el motor en función del terreno por donde nos desplazamos.
Es importante mencionar, que como el motor de un coche, si no se le da el adecuado mantenimiento y afinaciones necesarias podemos provocar que nuestro coche deje de avanzar, es decir, detenemos el crecimiento de nuestra startup.
Construir-Medir-Aprender. Cuándo se usa un automóvil para llegar a un lugar específico, puedes ir a ese destino incluso si no sabes llegar, revisas un mapa, en el camino puedes preguntarle a personas por indicaciones, cambiar de dirección más de una vez, descubrir un atajo, tomar una ruta que haga que te desvíes pero que inmediatamente lo reconozcas y puedas corregir la dirección hacia tu meta, en fin muchas cosas pueden pasar.
Otra analogía es que si planeas correr un maratón, empieza con unos kilómetros diarios, investiga mejores formas de obtener condición física rápidamente y cada día aumentas un kilómetro o más, vas aumentando tu kilometraje conforme vas mejorando tu condición hasta obtener los kilómetros deseados para tu maratón, es obvio que necesitas hacer esto cuanto antes para fallar lo más pronto posible y aprender antes del día del maratón. No sería inteligente esperar a unos días antes del maratón o peor aún, simplemente correr el maratón completo y fracasar en el intento, tu cuerpo y tu mente no estarán preparados para aguantar el maratón.
En contraste, para lanzar un cohete al espacio se necesita mucha planeación y cálculos, cada cambio de ruta debe estar calculado con anticipación, el minúsculo error hará que un cohete no llegue a su destino o provocar una catástrofe. Hacer las cosas cómo lanzar un cohete, todo a mucho detalle y que el más mínimo error resulte en el fracaso del negocio no es para nada deseable. Por desgracia muchos planes y estrategias de negocios son tratados igual que el lanzamiento de un cohete, lo ideal es ver el plan de negocios tal como manejar un coche.
Por esta razón Lean Startup está diseñado para enseñar cómo gestionar una startup de la misma forma que manejar un carro, en lugar de hacer planes complejos basados en un montón de suposiciones, puedes hacer constantes cambios con un volante llamado Construir-Medir-Aprender.
Con este manejo de volante, podemos saber si de verdad necesitamos cambiar de ruta y cuando hacerlo, a esto se le llama pivotar, o seguir con la ruta actual, esto último llamado perseverar. Una vez que se ha aprendido y construido lo suficiente para que el motor de crecimiento esté en óptimas condiciones, se puede escalar y crecer con la máxima aceleración gracias a los métodos que Lean Startup ofrece.
Ahora bien, existen tres componentes claves que permiten alcanzar los objetivos dentro de Lean startup. Imaginemos que vamos manejando al trabajo, estamos decididos en llegar y no nos damos por vencidos debido a un desvío o porque tomamos una ruta equivocada. De la misma manera Lean Startup tiene una brújula de hacia dónde se quiere llegar, a crear un negocio que cambie la vida de muchas personas y que sea próspero para todos, esto es llamado Visión.
Para lograr esa visión, Lean startup emplea una estrategia, la cual incluye el modelo de negocio, el roadmap del producto, un punto de vista de la competencia y los socios, e ideas sobre quiénes serán los clientes.
Gracias a la visión y estrategia se llega al punto final, el producto. El producto cambia constantemente en un proceso de optimización llamado Afinación del Motor. Con menos frecuencia la estrategia sufre cambios, a estos cambios se le llama pivote, la visión muy rara vez cambia porque se está totalmente enfocado en conseguir los principios establecidos en la visión.
Visión, producto, estrategia
Una startup es un portafolio de actividades. Muchas cosas suceden simultáneamente; el motor está corriendo, consiguiendo nuevos clientes y atendiendo a los existentes; se afina el motor, tratando de mejorar el producto, marketing y operaciones; se está dirigiendo con el volante Construir-Medir-Aprender, dónde se decide si es necesario un cambio en la estrategia y cuándo hacerlo (pivotar).
Aunque hablamos de dos importantes ciclos de retroalimentación, Motor de crecimiento y Construir-Medir-Aprender. Este último tiene una gran importancia e influye poderosamente al primero gracias al aprendizaje validado que se obtiene. A medida que vamos aprendiendo con el ciclo de Construir-Medir-Aprender, podremos hacer cambios en el motor, podemos definir con mejor seguridad que tipo de motor necesitamos y que mejoras debemos hacer a este motor para acelerar el crecimiento, y por supuesto, que dirección tomar.
El motor de crecimiento realmente es tu producto o servicio, y depende de las decisiones tomadas en tu estrategia, la cual a su vez está subordinada por el ciclo Construir-Medir-Aprender, y la última parte, la visión de tu startup, es la base de todos estos componentes. Podríamos decir que la pirámide de los tres componentes claves para una startup se encuentra en el centro del ciclo Construir-Medir-Aprender, los resultados de este ciclo influyen en cambios en el producto y en la estrategia, pero como mencionamos antes, muy rara vez influirá en la visión, pero no se descarta que su influencia en la visión pueda suceder.
Un diagrama representando esta relación sería el siguiente:
Veamos con más detalle este grandioso ciclo de aprendizaje validado, recuerda que decimos que es un aprendizaje validado porque nos permite saber lo que el cliente realmente quiere y está dispuesto a pagar por ello.
En la imagen de arriba vemos que tenemos flechas en ambas direcciones, esto es así porque el orden en que se ejecutan las tres etapas es inverso a su planeación, describamos un poco estas etapas, empezaremos con la planeación, que es lo primero que haríamos antes de ejecutar nuestro plan. Una startup transforma ideas en productos, estas ideas u oportunidades de negocio nos permite definir nuestra visión en dos partes, esto sería nuestro primer aprendizaje base:
Hipótesis de valor, que nos permite probar que nuestro producto es de valor para nuestros clientes potenciales.
Hipótesis de crecimiento que nos revela de que manera nuevos clientes pueden fácilmente descubrir los beneficios del producto y expandir nuestro alcance.
Luego teniendo la definición de nuestras hipótesis, ahora podemos utilizar innovación contable para saber que es lo que específicamente necesitamos medir para que en la ejecución podamos determinar si estamos obteniendo aprendizaje validado.
Posteriormente basado en las dos etapas anteriores sabremos definir lo que se va a construir, es decir, que experimento correr y obtener los datos necesarios para saber si vamos por buen camino (perseverar) o necesitamos pivotar.
Ya que tenemos el plan de nuestra iteración, es el momento de la ejecución, es decir, Construir, Medir y Aprender.
Los productos que se construyen en una startup son nada más que experimentos, experimentos realizados lo más pronto y lo más ágil posible, y lo ideal es realizar avances pequeños (lotes chicos) para aprender rápidamente cómo construir un negocio sustentable.
Muchas iteraciones de este ciclo serán experimentos fallidos y también habrá experimentos exitosos, pero esto es bueno, una Startup necesita de los aciertos y de los errores lo más temprano posible para conseguir sus objetivos.
Estos aciertos y errores son medidos antes de obtener nuestro aprendizaje, pero esta medición es muy diferente a las métricas tradicionales, es por eso que se le llama innovación contable.
Ahora que terminamos de construir nuestro experimento, lo pusimos a prueba con clientes potenciales y obtuvimos las métricas necesarias en nuestra iteración, es hora de Aprender. Ya que tenemos nuestro aprendizaje validado, sabremos si pivotar o perseverar y de nuevo planeamos la siguiente iteración para poder ejecutar de nuevo este ciclo.
NOTA: Solo soy aprendiz de Lean Startup, es un tema del que estoy aprendiendo muchísimo y del cual plasmo ese aprendizaje a través de esta publicación, una publicación que espero les sea de gran utilidad.
, Kent Beck 1998
, Kent Beck 1998
ES_MX 
EN