Tech Lead compartiendo ideas prácticas sobre artesanía del software, TDD, liderazgo, Bitcoin e IA. Artículos, resúmenes de libros y charlas.Zola2023-05-31T00:00:00+00:00https://chemaclass.com/es/tags/scrum/atom.xmlUna Guía para Principiantes sobre Implementación y Liderazgo Ágil2023-05-31T00:00:00+00:002023-05-31T00:00:00+00:00 Jeremy Savellhttps://chemaclass.com/es/readings/agile-project-management/

Los proyectos Waterfall solían pasarse de presupuesto y entregar software mediocre. En 2001, un grupo de desarrolladores firmó un manifiesto de 68 palabras que cambiaría todo.

<span id="continue-reading"></span> <p>Una visión general básica y directa de lo que es Agile, presentando algunos ejemplos de frameworks bien conocidos hoy, como Scrum o Kanban, todo condensado en un libro de unas 100 páginas que puedes leer en un par de horas.</p> <h2 id="capitulos">Capítulos <a class="heading-anchor" href="#capitulos" title="Copy link" aria-label="Link to this section">#</a> </h2> <ol> <li>El manifiesto fluido</li> <li>Siendo ágil</li> <li>Proceso ágil</li> <li>Planificando para el éxito</li> <li>Comunicación ágil</li> <li>Fundamentos de Scrum</li> <li>Introducción a Kanban</li> <li>Construyendo un equipo adaptativo</li> <li>Liderazgo y gestión colaborativa</li> <li>Errores comunes detrás del fracaso ágil</li> <li>Palabras finales: ágil es adaptación</li> </ol> <hr /> <blockquote> <p>“Los beneficios de los proyectos Ágiles se extienden no solo al equipo que lo usa, sino también al cliente que recibe el producto final.”</p> </blockquote> <blockquote> <p>“Hay una métrica crítica subyacente que consistentemente lleva al éxito de un proyecto Ágil: la comunicación. La mala comunicación, la poca comunicación, o la comunicación deficiente de cualquier tipo lleva al colapso y fracaso de dicho proyecto.”</p> </blockquote> <hr /> <h3 id="puntos-clave">Puntos clave <a class="heading-anchor" href="#puntos-clave" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>Los proyectos que seguían una metodología <strong>Waterfall</strong> tendían a exceder sus gastos con el tiempo, mientras que el producto entregado estaba por debajo del estándar y era difícil de usar.</p> <p>Esa situación originó que un grupo de desarrolladores firmara un breve manifiesto de 68 palabras en 2001.</p> <h4 id="un-breve-trasfondo">Un breve trasfondo <a class="heading-anchor" href="#un-breve-trasfondo" title="Copy link" aria-label="Link to this section">#</a> </h4> <p>Durante los años 1960, el software entró en una gran crisis; crear software era complejo pero cambiarlo después se convirtió en puro caos. <strong>Waterfall</strong> al rescate.</p> <p><strong>Waterfall</strong> delineó un conjunto simple y lógico de procesos que una empresa necesitaría seguir para que un proyecto fuera exitoso. Su nombre viene de la metáfora del agua cayendo suavemente en una corriente predecible, constante e incremental. Su ciclo de vida de desarrollo de software estaría en seis pasos simples.</p> <ol> <li>Requisitos</li> <li>Análisis</li> <li>Diseño</li> <li>Código</li> <li>Testing</li> <li>Operaciones</li> </ol> <p>Durante 10 años, <strong>Waterfall</strong> fue la metodología estándar en el universo del software. Y durante 10 años más, el caos persistió. Aunque la intención era buena, la realidad es que el conjunto siempre cambiante de restricciones no se lleva muy bien con esta metodología porque cada paso depende del anterior.</p> <p>El 86% del tiempo que una empresa usa el método <strong>Waterfall</strong> para gestión de proyectos, el cliente recibe software inadecuado o inútil. Muchos proyectos de software no se usaron o nunca se terminaron.</p> <p>Durante los años 70 y 80, <strong>Desarrollo Iterativo e Incremental (IID)</strong> probó ser una opción viable. En los 90 surge la <strong>Entrega Evolutiva (ED)</strong>, que cambia la situación. El desarrollador es responsable de escuchar las reacciones del usuario temprana y frecuentemente. El usuario comienza a jugar un rol directo en el proceso de desarrollo.</p> <p>Unos años después, surgió un nuevo método <strong>Prototipado de Producción Iterativa Rápida (RIPP)</strong>, más tarde llamado <strong>Desarrollo Rápido de Aplicaciones (RAD)</strong>, que afirmaba <em>“Software funcionando en 90 días… o te devolvemos tu dinero.”</em></p> <p>Por último, durante los 90 se definieron en detalle <strong>Extreme Programming (XP)</strong>, <strong>Scrum</strong> y <strong>Crystal</strong>.</p> <p>Estas soluciones distintas pero similares estaban descentralizadas, trabajando independientemente unas de otras. Esta realización llevó a esa noche en Utah la unificación de estas ideas bajo una bandera, en un documento.</p> <p><strong>Agile</strong> se convirtió en el estándar definitivo para el desarrollo de software.</p> <h3 id="el-manifiesto-agil">El Manifiesto Ágil <a class="heading-anchor" href="#el-manifiesto-agil" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li>Individuos e interacciones sobre procesos y herramientas</li> <li>Software funcionando sobre documentación comprehensiva</li> <li>Colaboración con el cliente sobre negociación de contratos</li> <li>Responder al cambio sobre seguir un plan</li> </ul> <blockquote> <p>Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.</p> </blockquote>Matando la agilidad con reuniones excesivas2022-12-06T00:00:00+00:002022-12-06T00:00:00+00:00 Chemaclasshttps://chemaclass.com/es/blog/ignoring-scrum-to-get-more-agile/

Las personas se vuelven esclavas de sistemas que se supone que ayudan. Las reuniones aburridas están matando el agile. Las reuniones requieren participación activa de todos. De lo contrario, podrías no ser esencial para esa reunión, y mejor usar tu tiempo con algo más.

<p>Hablando con un amigo sobre agile, me hizo una pregunta interesante: a veces Agile y Scrum encajan mal, especialmente con las reuniones. Aquí van mis reflexiones.</p> <span id="continue-reading"></span> <blockquote> <p>“¿Crees que tendría sentido simplemente usar agile e ignorar scrum (sprints) completamente en una empresa basada en producto? Siento que es difícil ser agile cuando tienes 10 horas de reuniones por semana.” Filip G.</p> </blockquote> <p>Esto conecta con la esencia de <a href="/es/readings/xp-embrace-change/">Extreme Programming</a>: el primer valor es la Comunicación Efectiva.</p> <blockquote> <p>“Probablemente algunas empresas no saben usar bien las reuniones y las hacen por costumbre.” Filip G.</p> </blockquote> <p>No diría ignorar Scrum del todo. Scrum (bien hecho) es un gran “Framework de Gestión de Producto”. Para entenderlo mejor recomiendo: <a href="/es/readings/scrum-the-art-of-doing-twice">Scrum: The Art of Doing Twice the Work in Half the Time</a>.</p> <p>El problema principal con Scrum hoy es que la gestión tomó el control y los desarrolladores no saben practicarlo de forma realmente Agile. Ahí empieza el problema. Recomiendo <a href="/es/readings/zombie-scrum-survival-guide/">Zombie Scrum Survival Guide</a>, un libro divertido y fácil de leer que aborda los problemas típicos de equipos Scrum.</p> <p>No es “Agile sí, Scrum no”. Son compatibles. El reto es enfocar los procesos del equipo desde una perspectiva agile.</p> <h2 id="agile-en-pocas-palabras">Agile en pocas palabras <a class="heading-anchor" href="#agile-en-pocas-palabras" title="Copy link" aria-label="Link to this section">#</a> </h2> <p>Recientemente escribí un post sobre fundamentos agile, que te recomiendo leer para entrar en los detalles: <a href="/es/blog/working-agile-with-non-agile-teams/">Trabajando agile con equipos no agile</a>. Pero, el <strong>tl;dr</strong>: <ins>Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.</ins></p> <p><a rel="external" href="https://agilemanifesto.org/">Agile</a> es sobre mantener estos valores siempre presentes:</p> <ul> <li>Individuos e interacciones sobre procesos y herramientas</li> <li>Software funcionando sobre documentación extensiva</li> <li>Colaboración con el cliente sobre negociación de contratos</li> <li>Responder ante el cambio sobre seguir un plan</li> </ul> <blockquote> <p>Aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.</p> </blockquote> <h2 id="scrum-en-pocas-palabras">Scrum en pocas palabras <a class="heading-anchor" href="#scrum-en-pocas-palabras" title="Copy link" aria-label="Link to this section">#</a> </h2> <p>Scrum es un framework de gestión de proyectos orientado al desarrollo de software, aunque se usa en ventas, marketing y más. Está pensado para equipos de 5-9 personas (ver <a href="/es/blog/dunbar-number/">número de Dunbar</a>) autónomos y responsables de dividir su trabajo en partes pequeñas para completar en iteraciones llamadas sprints (1, 2 o 4 semanas).</p> <p>Las ceremonias/reuniones típicas son:</p> <ul> <li><strong>Stand-up</strong>: 15 min (o menos) para sincronizar al equipo y actuar si alguien está bloqueado o necesita ayuda.</li> <li><strong>Refinement</strong>: ~2h para asegurar que los tickets están listos antes de planificarlos.</li> <li><strong>Planning</strong>: ~2h para planificar el trabajo del siguiente sprint.</li> <li><strong>Demo/Review</strong>: ~2h para mostrar el trabajo hecho al equipo, stakeholders e interesados.</li> <li><strong>Retrospectiva</strong>: ~2h para que el equipo reflexione y mejore.</li> </ul> <p>La pregunta clave es cómo organiza tu equipo estas reuniones y, sobre todo, si son efectivas. Estas son solo algunas de las reuniones de cualquier “Equipo Scrum”.</p> <p>Pero además de estas, se acumulan muchas otras reuniones. De pronto el día entero se ha ido y sientes que no has producido el valor esperado. Si tu trabajo no consiste en estar en reuniones constantemente, algo está mal.</p> <h3 id="reuniones-aburridas">Reuniones aburridas <a class="heading-anchor" href="#reuniones-aburridas" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>¿Has estado alguna vez en una reunión pensando “<em>Esto es aburrido, qué pérdida de tiempo…</em>”? Yo lo he vivido más de una vez. ¿A quién culpar? Esa suele ser la primera pregunta. Seguida de: “<em>Mi jefe, obviamente. Él organizó esta reunión, me invitó, estoy obligado a asistir, y esta pérdida de tiempo es su culpa.</em>”</p> <p>No creo que sea una respuesta honesta. Culpar a otros y alejar responsabilidades es mucho más fácil que mirarse a uno mismo.</p> <p>“<em>Estoy obligado a asistir, y esta pérdida de tiempo es su culpa</em>” puede ser cierto. Quizás estabas obligado y estás perdiendo el tiempo. Pero, ¿de verdad no hay forma de actuar al respecto?</p> <p>Cuando algo no funciona como espero (no me gusta el resultado, creo que algo está mal), antes de culpar a otros prefiero reflexionar: ¿cuál es la raíz del problema? ¿Qué puedo hacer para mejorar la situación?</p> <hr /> <h2 id="que-puedes-hacer-al-respecto">¿Qué puedes hacer al respecto? <a class="heading-anchor" href="#que-puedes-hacer-al-respecto" title="Copy link" aria-label="Link to this section">#</a> </h2> <p>Volviendo al tema de “muchas reuniones”: si estás en una que se siente mal o aburrida, pregúntate:</p> <blockquote> <p>¿Me aburro? ¿Por qué? ¿Quizás no participo en el resultado de la reunión? Si es así, ¿mi presencia es realmente necesaria? ¿Podría pedir un resumen después y salir para hacer algo más productivo?</p> <p>O al revés: ¿está bien aburrirse en esta reunión? ¿Debería participar más y contribuir al resultado?</p> </blockquote> <p>Veo este patrón:</p> <ul> <li>Si la reunión no aburre, es productiva y dará buenos resultados para todos.</li> <li>Si aburre, hay dos opciones: A) está bien que aburra, pide salir educadamente y pide el resumen después; o B) no está bien que aburra porque tu participación es necesaria. Involúcrate más con tus compañeros y la reunión dejará de ser aburrida.</li> </ul> <p>Hay muchas estrategias. Depende de ti actuar cuando veas algo mejorable.</p> <p>Está bien señalar el “<em>elefante en la habitación</em>” y pedir ayuda para mejorar cualquier situación que sientas que no funciona como debería.</p> <p><img src="/images/blog/2022-12-06/footer.webp" alt="blog-footer" /></p>Un viaje hacia la recuperación2021-03-01T00:00:00+00:002021-03-01T00:00:00+00:00 Christiaan Verwijs Johannes Schartau Barry Overeemhttps://chemaclass.com/es/readings/zombie-scrum-survival-guide/

Por qué Scrum se estanca y cómo mejorar tus resultados divirtiéndote en el proceso.

<span id="continue-reading"></span> <p>Disfruté mucho las ideas y experimentos del libro. Pone el dedo en la llaga sobre muchos equipos que dicen hacer Scrum o Agile de forma cuestionable. A eso lo llaman Zombie Scrum.</p> <h3 id="resumen">Resumen <a class="heading-anchor" href="#resumen" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>El libro explica por qué Scrum se estanca y cómo mejorar tus resultados divirtiéndote en el proceso. Con humor y ejemplos muy reconocibles, ofrece enfoques prácticos, ejercicios y herramientas para escapar del Zombie Scrum.</p> <p>Aunque estés rodeado de escépticos, este libro te ayudará a construir lo que los usuarios realmente necesitan, entregar más rápido, mejorar continuamente y sentirte mejor con tu trabajo. Un día recordarás: para esto adoptamos Scrum.</p> <ul> <li>Cómo te infecta el Zombie Scrum, por qué se propaga y cómo prevenirlo</li> <li>Acércate a tus stakeholders y hazles entender el valor</li> <li>Por qué los equipos Zombie no aprenden y qué hacer al respecto</li> <li>Elimina los obstáculos para la mejora continua</li> <li>Logra equipos autogestionados donde la gente actúe como humanos, no como zombies</li> </ul> <hr /> <p>Un buen webinar donde comparten ideas clave del libro y discuten sus hallazgos más recientes.</p> <div style="position:relative;aspect-ratio:16/9;width:100%;"> <iframe src="https://www.youtube-nocookie.com/embed/ylGfrsXXQMs" title="YouTube video" width="560" height="315" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;inset:0;width:100%;height:100%;border:0;" allowfullscreen> </iframe> </div>Creando productos que los clientes aman2021-02-22T00:00:00+00:002021-02-22T00:00:00+00:00 Roman Pichlerhttps://chemaclass.com/es/readings/agile-product-management-with-scrum/

Cómo entender el rol del product owner y dar forma al producto.

<span id="continue-reading"></span><h3 id="temas-principales">Temas principales <a class="heading-anchor" href="#temas-principales" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li>El rol del product owner</li> <li>Cómo visualizar el producto</li> <li>Refinamiento del product backlog</li> <li>Planificación de releases</li> <li>Colaboración en las reuniones de sprint</li> <li>La transición hacia el product ownership</li> </ul>El arte de hacer el doble de trabajo en la mitad de tiempo2020-06-10T00:00:00+00:002020-06-10T00:00:00+00:00 Jeff Sutherlandhttps://chemaclass.com/es/readings/scrum-the-art-of-doing-twice/

Cómo entregar proyectos a tiempo y dentro del presupuesto usando un marco de trabajo ágil que realmente funciona

<span id="continue-reading"></span> <p>Toda organización tiene que lidiar con entregar productos a tiempo y dentro del presupuesto. Da igual el tamaño.</p> <p>Scrum te muestra cómo hacerlo. Te explica cómo definir lo que quieres lograr, cómo armar el equipo adecuado y cómo seguir el progreso hasta completar el proyecto con éxito.</p>