tag:blogger.com,1999:blog-29167896843290185972024-02-07T23:11:28.083-03:00Code & BeyondAlrededor de la comunidad de desarrollo de software en Hispanoamérica.Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.comBlogger284125tag:blogger.com,1999:blog-2916789684329018597.post-36096169628519716852023-03-21T16:13:00.007-03:002023-03-21T16:16:36.193-03:00Habilidades de Scrum Master: Facilitación<p>Una de las habilidades principales a desarrollar como Scrum Masters es la de <b>Facilitación</b>.</p><p>La Facilitación como disciplina es independiente de la agilidad, y se origina alrededor de 1980 como una manera de resolver patrones tóxicos en reuniones de grupos en todo tipo de organizaciones. </p><p><br />Algunos de estos anti-patrones incluyen:</p><p></p><ul style="text-align: left;"><li><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDMK-vKXN-LwYVcvimMkANwE0DArquSi65CMPeO_-JSL89D8XfE1-Rsw_pm1y91FVrdl3L32eWO-yvm9w3E3ksUJXj_WvgNmVvm718hbC3RS09xbhwcODx-cV_HEfFy1qbt-J3cjYnEoineKBS5le9ry5mQ8IJRIyJ96XQXym1wbHf-C3xr0W-BhDq/s780/toxic.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="755" data-original-width="780" height="154" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDMK-vKXN-LwYVcvimMkANwE0DArquSi65CMPeO_-JSL89D8XfE1-Rsw_pm1y91FVrdl3L32eWO-yvm9w3E3ksUJXj_WvgNmVvm718hbC3RS09xbhwcODx-cV_HEfFy1qbt-J3cjYnEoineKBS5le9ry5mQ8IJRIyJ96XQXym1wbHf-C3xr0W-BhDq/w159-h154/toxic.png" width="159" /></a></div>Asumir que se llegó a acuerdos porque nadie se opuso a una decisión (aunque la mayoría de las personas participantes no hayan tenido la posibilidad de hacerlo)</li><li>Presencia en la reunión sin posibilidad de participación activa, e incluso sin comprender el propósito de la reunión</li><li>La pérdida de foco en el objetivo de la reunión, yéndose del tema, incluso dejando fuera de tema a una parte importante de las personas participantes</li></ul><div>Como una manera de cambiar esta dinámica, surgió el rol de Facilitadora ó Facilitador.</div><div><br /></div><div>Al asumir ese rol, nuestras responsabilidades pasan a ser:</div><div><ul style="text-align: left;"><li>Previamente a la reunión<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhj2wVZUmFa8XaWWnFw-tbyTQakmFE1w_L9KWQV7fuxG6vBSIV_hBcIHveQmSV3dUFFcWQInfwsna6MmrByAl3zvknHS7rUJrfepeOUKOc_el05cIZoXgrMhw_jQ8Z_dQEbCugB2sA4vIg2ZEqBT-1lXcVKMSHSW1wZ6SBjniK1Wa-36e4oJmwCzJKw/s484/antes.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="428" data-original-width="484" height="131" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhj2wVZUmFa8XaWWnFw-tbyTQakmFE1w_L9KWQV7fuxG6vBSIV_hBcIHveQmSV3dUFFcWQInfwsna6MmrByAl3zvknHS7rUJrfepeOUKOc_el05cIZoXgrMhw_jQ8Z_dQEbCugB2sA4vIg2ZEqBT-1lXcVKMSHSW1wZ6SBjniK1Wa-36e4oJmwCzJKw/w148-h131/antes.png" width="148" /></a></div><br /></li><ul><li>comprender el objetivo final</li><li>acordar con la o las personas que convocan que realmente quieren generar participación grupal y aceptar opiniones del resto del grupo</li><li>diseñar las actividades y tiempos aproximados para lograr el objetivo</li><li>colaborar en la convocatoria, incluyendo (si es necesario) la explicación de la dinámica de la reunión</li><li>(mi sugerencia) asegurar que las personas invitadas sientan que pueden NO participar. Esto muchas veces implica un énfasis en que la no-participación es <b>positiva</b> si la persona invitada no siente conexión real con el tema.<br /><br /></li></ul><li>Durante la reunión<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2rQEv-AZ7caMloMmiGz16Cbw83cK50Ju6FCy9NdxpDwsuM4JzThA3LrGf1NqNRwgf-leNGm1--39voNHHofoPnggbrcX2gOMUH9GIwsBp-upQP-uQKBc7_-8vSsBi7E3VugLRYbjo7SgwVgUMuHOovphdTPI5PxspaMRGl0y4KZdKmnSvZhD8G7w7/s814/durante.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="590" data-original-width="814" height="154" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2rQEv-AZ7caMloMmiGz16Cbw83cK50Ju6FCy9NdxpDwsuM4JzThA3LrGf1NqNRwgf-leNGm1--39voNHHofoPnggbrcX2gOMUH9GIwsBp-upQP-uQKBc7_-8vSsBi7E3VugLRYbjo7SgwVgUMuHOovphdTPI5PxspaMRGl0y4KZdKmnSvZhD8G7w7/w212-h154/durante.png" width="212" /></a></div><br /></li><ul><li>Asegurar acuerdos mínimos de trabajo (respeto por todas las ideas, confianza en la inteligencia colectiva, apertura a escuchar posiciones contrarias)</li><li>Explicar la dinámica y tiempos generales</li><li>Guiar a través de cada una de las actividades, manteniendo los tiempos previstos</li><li>Asegurar la participación de todas las personas (para esto se suele trabajar en grupos pequeños y luego hacer puesta en común; canalizar ideas por escrito o diagramas, además de hablando; variar tipos de actividad para mantener el interés, etc)</li><li>Mantenerse tan neutral como sea posible (porque somos humanos, finalmente) sobre el tema en discusión. Cuando facilitamos, no participamos ni opinamos sobre el tema, y en cambio mantenemos el foco sobre la dinámica del grupo.</li><li>Inspeccionar la interacción de las personas y adaptar el plan (que no debe ser demasiado estricto) para asegurar el mejor resultado posible.</li><li>Asegurar la captura de elementos importantes del proceso y de las decisiones finales. Puede ser en formato de fotos, videos, audio, documentos, diagramas, etc.</li><li>Lograr un cierre ordenado de la reunión, con una instancia mínima de reflexión sobre el funcionamiento general, oportunidades de mejora para próximas reuniones, posibles consecuencias o necesidades posteriores, etc.<br /><br /></li></ul><li>Después de la reunión<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh27mNVxZjb1QImiKKExgDxyajz2GUPdhWIys_cL3Zlg5izjp5G5mdgAlquT0WVtMJ8D6Gjk2XmatZuhXqd0vG2EZA1vq3H1gsSVUPkuHfd-RVeSSdjZUSk71Y0Lh-dClXO2EaHDnzgm6V0oYyKmEh32P21VS-4ZWbKwwE9okqxJEAXN2AYiU09eTNa/s497/despues.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="428" data-original-width="497" height="137" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh27mNVxZjb1QImiKKExgDxyajz2GUPdhWIys_cL3Zlg5izjp5G5mdgAlquT0WVtMJ8D6Gjk2XmatZuhXqd0vG2EZA1vq3H1gsSVUPkuHfd-RVeSSdjZUSk71Y0Lh-dClXO2EaHDnzgm6V0oYyKmEh32P21VS-4ZWbKwwE9okqxJEAXN2AYiU09eTNa/w159-h137/despues.png" width="159" /></a></div><br /></li><ul><li>Realizar una retrospectiva de la reunión con las personas que la convocaron, más allá del feedback del resto de las participantes.</li><li>Compilar y preparar los contenidos generados durante la reunión para compartirlo con las personas participantes y otras que necesiten tener información del tema.</li><li>Evaluar la necesidad de próximos pasos</li></ul></ul><div><br /></div><div>En el contexto de <b>Scrum</b>, estas mismas responsabilidades se aplican a los eventos dentro del Sprint: Planning, Review y Retrospective.</div></div><div><br /></div><p></p><p></p><blockquote><b>¿Y la Daily Scrum?</b> Como Scrum Master <b>no</b> es nuestra responsabilidad "facilitar" la Daily. Este evento es de y para Developers. Por supuesto, <i>podemos</i> <i>colaborar</i> en el inicio para que estas personas encuentren su propio formato y estilo hasta que les resulte útil. Más allá de eso, no deberíamos influir en el tema, más allá de evaluar con ellas si están teniendo o no problemas de coordinación, manteniendo el foco en el objetivo del Sprint y encontrando oportunidades de <a href="https://www.codeandbeyond.org/2018/07/colaboracion-real-lo-que-mas-cuesta.html">colaboración real</a>. Si alguna de estas cosas no sucede, <i>puede</i> que la Daily no esté funcionando por completo, pero siempre será mejor buscar motivos sistémicos menos evidentes que tratar de ajustar una pieza mecánica, como el <i>formato</i> de la Daily.</blockquote><p></p><p>Para profundizar más en el tipo de actividades que podemos utilizar en la Facilitación, veremos un modelo y algunos ejemplos en el siguiente artículo: el Diamante de Toma de Decisiones Participativa de Sam Kaner.</p><p><br /></p><div><br /></div><div><br /></div><div><br /></div><p></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-36576040964862397212020-07-15T20:11:00.003-03:002020-07-15T20:12:03.575-03:00Eventos de Scrum: el SprintEl Sprint es el ciclo principal de Scrum. Es la misma idea que en otros marcos es llamada Iteración, y en el caso de Scrum, su mayor importancia es que todo lo que Scrum describe está contenido <i>dentro</i> del Sprint.<div><br /></div><div>También es el "timebox" principal que regula todos los demás.</div><div><br /></div><div>La idea de TimeBox se utiliza en Scrum para el Sprint y todos sus eventos internos, y es lo que me gusta llamar una "restricción creativa". A primera vista parece una limitación, pero nos ayuda a mantener uno de los valores, que es el FOCO. Una vez que decidimos cuánto va a durar el Sprint de nuestro equipo, no podemos cambiarlo, y eso nos obliga a tener que aprender a entregar y organizarnos dentro de ese límite.</div><div><br /></div><div>Según la <a href="https://www.scrumguides.org/">Guía de Scrum</a>, el Sprint puede durar un máximo de un mes, aunque en la práctica ya son muy pocos los equipos que mantienen Sprint de un mes, que suena a una eternidad. La duración más popular es la de dos semanas, pero es usual que los equipo más maduros prefieran el Sprint semanal.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRyAV7-hGavOoPbHiarKL-iWY3phCXCyiLCuLHdOLuOffXc4VR5NO-uI-5d-1k9mVNapuzvG8jnqR4gnD-6kz0knKgD6-UP1sI2FUIE2J_eDqNGmyVI2USN74s7JbgtU8AwIC862fRd5I/s1450/Sprint+Basic.png" style="margin-left: 1em; margin-right: 1em;"><img alt="Diagrama de un Sprint" border="0" data-original-height="1107" data-original-width="1450" height="488" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRyAV7-hGavOoPbHiarKL-iWY3phCXCyiLCuLHdOLuOffXc4VR5NO-uI-5d-1k9mVNapuzvG8jnqR4gnD-6kz0knKgD6-UP1sI2FUIE2J_eDqNGmyVI2USN74s7JbgtU8AwIC862fRd5I/w640-h488/Sprint+Basic.png" title="Diagrama de un Sprint" width="640" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">La condición inicial para poder iniciar un Sprint es tener el Product Backlog listo para planificar el trabajo de todo el Sprint. Esto implica que al menos los Items del Product Backlog (o PBIs) más prioritarios estén lo suficientemente <a href="https://www.codeandbeyond.org/2020/03/scrum-product-backlog.html#Refinement">refinados</a>.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">La duración del Sprint es la que afecta a la vez el <b>timebox máximo</b> de cada uno de sus eventos interiores. Pero lo más importante es recordar siempre que <b>todo sucede dentro</b> del Sprint. Desde el punto de vista de Scrum, <b>nada sucede fuera del Sprint</b>.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><h2 style="clear: both; text-align: left;">Preguntas frecuentes acerca de los Sprints</h2><h3 style="text-align: left;">¿Nunca se puede cambiar la duración del Sprint?</h3><div><font color="#ff0000">Sí, es posible hacerlo, pero con mucho cuidado. </font></div><div><br /></div><div>El motivo no debería ser circunstancial. Lo que <b>no vale</b> es cambiar arbitrariamente, agregando o quitando días por cualquier circunstancia, ni decidiendo en cada Sprint cuánto va a durar.</div><div><br /></div><div>Personalmente encuentro solamente dos motivos para cambiar (en <i>algún </i>momento de la vida de un producto):</div><div><ul style="text-align: left;"><li>Que el equipo intentó con una duración muy corta y no le resulta sostenible. Por ejemplo, intentaron Sprints de una semana y descubrieron que algunos temas técnicos o internos hacen que les resulte demasiado difícil entregar un producto funcionando al final de cada semana. En ese caso, luego de analizarlo en una Retrospectiva, podrían decidir decidir cambiar a Sprints de dos semanas (de ahí en adelante, sin seguir variando todo el tiempo).<br /><br /></li><li>De forma similar, si el equipo comenzó con Sprints de dos o tres semanas y durante una Retrospectiva deciden que ya están lo suficientemente maduros como para hacer Sprints más cortos y así aumentar la frecuencia del feedback, podrían reducirlo (nuevamente, es importante que estén seguros de que será sostenible, para no tener que volver atrás).</li></ul></div><div class="separator" style="clear: both; text-align: left;">En cualquiera de los dos casos, es importante que antes de cambiar la duración, tanto el motivo como la decisión sea comunicada a los stakeholders principales, más allá del Equipo Scrum, porque para quienes asistan a la mayoría de las Sprint Review, ese cambio de frecuencia es importante.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><h3 style="clear: both; text-align: left;">¿Se puede cancelar un Sprint antes de que termine?</h3><div><div><font color="#ff0000">Sí, es posible hacerlo, pero con mucho cuidado.</font></div><div>(No, no es <i>déjà vu</i>, la respuesta es <b>la misma</b> que la anterior. 😄)</div></div><div><br /></div><div>Después de más de 10 años trabajando con Scrum, recuerdo presenciar un solo caso de cancelación, y era porque la compañía acababa de ser adquirida por otra, y no se sabía si el producto continuaría existiendo.</div><div><br /></div><div>Los únicos motivos para cancelar un Sprint es que su Objetivo se vuelva totalmente obsoleto, por un cambio de negocio, mercado o tecnología tan enorme que cambia todo el contexto. Esto sucede muy raramente. Aunque la idea puede venir de cualquiera, la responsabilidad de cancelarlo (comunicándolo a todos los demás) es únicamente del Product Owner.</div><div><br /></div>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-36921333855369466142020-03-06T14:05:00.001-03:002020-03-06T14:05:21.547-03:00Scrum: Incremento de Producto<br />
<blockquote class="tr_bq" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;">
</blockquote>
<br />
En el <a href="https://agilemanifesto.org/iso/es/manifesto.html">Manifiesto por el Desarrollo Ágil de Software</a>, hoy más conocido como el Manifiesto Ágil, hay 4 valores y <a href="https://agilemanifesto.org/iso/es/principles.html">12 principios</a>, uno de los cuales dice:<br />
<blockquote class="tr_bq">
<i>El software funcionando es la medida principal de progreso.</i></blockquote>
En Scrum, ese principio está representado por el <b>Product Increment.</b> Es importante notar que Scrum ya no habla de <i>software</i>, pero la definición del incremento en la Scrum Guide dice (mi traducción):<br />
<blockquote class="tr_bq">
<i>El incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los previos. Al final del Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe estar en condición de ser utilizado y cumplir con la definición de "Terminado" del Equipo Scrum.</i></blockquote>
Podríamos decir que en Scrum, la principal medida de progreso es el <b>Incremento de Producto</b> funcionando.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDdXRamEvEAZXqdToThUANGQNkaoJxfT-2uu-FuNyrmjfVWCXTcIWyWT7kIrHoEJV-LiQhCphw8IMTRzhpVBkFTPkoAXbCIYIBUHwsONXbWXDLF9YQPL4QjobA6-NjQHti7MFhEeQufC4/s1600/Product+Increment.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="120" data-original-width="121" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDdXRamEvEAZXqdToThUANGQNkaoJxfT-2uu-FuNyrmjfVWCXTcIWyWT7kIrHoEJV-LiQhCphw8IMTRzhpVBkFTPkoAXbCIYIBUHwsONXbWXDLF9YQPL4QjobA6-NjQHti7MFhEeQufC4/s1600/Product+Increment.png" /></a></div>
Este incremento es entonces, una versión actualizada y funcionando del producto que se entrega al final del Sprint (agregando valor sobre los incrementos previos).<br />
<br />
El Product Owner es quien tiene la responsabilidad de decidir si ese incremento se libera al mercado (se pasa a producción, se pone en marcha o su equivalente de acuerdo al tipo de producto), más allá de que sea usable.<br />
<br />
Que el Incremento deba estar "terminado" significa que debe poder ser liberado sin trabajo adicional del Scrum Team.<br />
<br />
<blockquote class="tr_bq">
<b>Atención</b> </blockquote>
<blockquote class="tr_bq">
La Guía Scrum no especifica qué sucede con esfuerzo adicional <i>fuera</i> del equipo para entregar el producto a su público objetivo. Por ejemplo, en muchas organizaciones el equipo entrega un producto de software terminado, pero para pasarlo a producción el esfuerzo de otras áreas puede ser enorme. La comunidad ágil alienta a trabajar en reducir esa brecha, por ejemplo, a través de prácticas de <b>DevOps</b> (que NO es un rol ni un área, sino un estilo de colaboración entre desarrollo y operaciones).</blockquote>
<h2 id="DoD">
La Definición de Terminado</h2>
La <b>DoD</b> (del original en inglés, Definition of Done) es creada por el Scrum Team com una manera de evaluar si su trabajo en un ítem del Product Backlog ó en el Incremento está completo.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYeoX3HPAuq3go47yJX9M0uZptJpAbSSqhYn-pZ_UZM6TkeoVACg0NG8bYKW2i0lD1iCXb5YsGIDbChhmmzMNsC1IUTous5Mk92jS_QrclK_XwL91So1tXfxl6BQrc1tkG4CP2w4_f2b4/s1600/DoD.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Definición de Terminado" border="0" data-original-height="169" data-original-width="169" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYeoX3HPAuq3go47yJX9M0uZptJpAbSSqhYn-pZ_UZM6TkeoVACg0NG8bYKW2i0lD1iCXb5YsGIDbChhmmzMNsC1IUTous5Mk92jS_QrclK_XwL91So1tXfxl6BQrc1tkG4CP2w4_f2b4/s1600/DoD.png" title="Definición de Terminado" /></a></div>
El objetivo de esta definición es brindar <b>transparencia</b> sobre el nivel de calidad que se considera suficiente para entregar el Incremento de Producto.<br />
<br />
La definición es dinámica, y a través de los Sprints será <b>inspeccionada</b> y <b>adaptada</b>, en colaboración entre el Scrum Team y los Stakeholders.<br />
<br />
Es importante que el Development Team tenga esta definición en cuenta a la hora de determinar cuánto comprometer durante la Sprint Planning. Una buena Definición de Terminado balancea el nivel de calidad esperado con el esfuerzo requerido.<br />
<br />
Es común que la definición varíe mucho entre diferentes equipos, ya que depende mucho del tipo de producto, el contexto y la madurez en diferentes aspectos.<br />
<br />
Cuando múltiples equipos trabajan sobre el mismo producto, usualmente colaboran para tener una Definición de Terminado mínima, compartida por todos, sobre la que cada equipo puede agregar sus propias condiciones.<br />
<br />
<h3>
Tips</h3>
En mi experiencia, es preferible comenzar con una definición humilde pero alcanzable, y trabajar con el Scrum Team en seleccionar qué prácticas pueden elevar el nivel de calidad del producto, priorizándolas. Es usual que esas prácticas tengan una curva de aprendizaje, que hace que el equipo deba inicialmente invertir más esfuerzo en cada ítem.<br />
<br />
La buena noticia es que las prácticas de calidad, una vez que tienen impacto, ahorran esfuerzo en la medida en que el producto se vuelve más estable y el equipo las incorpora como propias. En el momento en que el equipo ya está acostumbrado a esa nueva práctica, puede agregar la condición correspondiente como parte de la Definición de Terminado, y comenzar con la adopción de la próxima práctica de calidad que sea más prioritaria.<br />
<br />
Para ayudar a pensar en posibles ítems de la Definición de Terminado de un equipo, en Kleer creamos una <a href="http://guiasagiles.org/#Definici%C3%B3nDeTerminado">guía ágil</a> y las <a href="https://www.kleer.la/es/recursos">DoD Cards</a>, con ejemplos y sugerencias.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEid3Fo0wISJ4MkdeCKpArEHwXgVFyLKQ-H6yFCpIIGSugsRFODhit6aTD0mZfKdVDrHsj1znDezLBV3dcb9vZzR_4OzsmFs_1eNBv1Zw-7d8Zit-ceBq60fKX6A9W-DlVqLXYCnif99_4E/s1600/DoD+Kards.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="DoD Cards" border="0" data-original-height="187" data-original-width="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEid3Fo0wISJ4MkdeCKpArEHwXgVFyLKQ-H6yFCpIIGSugsRFODhit6aTD0mZfKdVDrHsj1znDezLBV3dcb9vZzR_4OzsmFs_1eNBv1Zw-7d8Zit-ceBq60fKX6A9W-DlVqLXYCnif99_4E/s1600/DoD+Kards.jpg" title="DoD Cards" /></a></div>
<br />Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-80514859044467694002020-03-05T17:46:00.002-03:002020-03-05T17:46:30.188-03:00Scrum: Sprint BacklogEl Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY6HAPQiPiIc2f5ydmDKGxIAhX1OJqGbj9GsRworIt_eWGsVFxdlphICjX4ZYu5ASPHhNxD-H1LGMxKhHcSBVsScL_o-z7H0-4tfycEtcKepiD3IvXI9p998hlPt-DrGI2Oo869CGgiWQ/s1600/Sprint+Backlog.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Sprint Backlog" border="0" data-original-height="250" data-original-width="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY6HAPQiPiIc2f5ydmDKGxIAhX1OJqGbj9GsRworIt_eWGsVFxdlphICjX4ZYu5ASPHhNxD-H1LGMxKhHcSBVsScL_o-z7H0-4tfycEtcKepiD3IvXI9p998hlPt-DrGI2Oo869CGgiWQ/s1600/Sprint+Backlog.png" title="Sprint Backlog" /></a></div>
Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.<br />
<br />
La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.<br />
<br />
Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.<br />
<br />
El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera <b>transparente</b>.<br />
<br />
También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible <i>al menos un elemento</i> de mejora decidido en la última retrospectiva.<br />
<br />
Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCF5uoOKr7fyFVCUfGJjSno0rt1-B53O1KHRG91vLncrNZkIAY9UYh2-EO-rqh2YmS6__TtJnLieyAlrFMA2SZ3fkGewEbiJAbEMQJfogQKKfTbTyNvHfZYzHFjQzqHYOR5disGEZBhRg/s1600/Daily.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="504" data-original-width="1048" height="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCF5uoOKr7fyFVCUfGJjSno0rt1-B53O1KHRG91vLncrNZkIAY9UYh2-EO-rqh2YmS6__TtJnLieyAlrFMA2SZ3fkGewEbiJAbEMQJfogQKKfTbTyNvHfZYzHFjQzqHYOR5disGEZBhRg/s640/Daily.png" width="640" /></a></div>
<br />
El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.<br />
<br />Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-26107320416004552682020-03-04T17:53:00.002-03:002020-07-15T19:19:06.047-03:00Scrum: Product BacklogPara poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-dr16BMBuWQiPNrW9GvEXxDwGRI4goBxBo4-1AZkxevmxWZCBoOuY1E9XWaocvB1TzP4aJowwmH2YVD5O754uvp19U_hhz9FTwc5zUH0MfscatDv31KMZgVxgaqwPjJsWnNawGs49xms/s1600/Product+Backlog.png" style="margin-left: 1em; margin-right: 1em;"><img alt="Product Backlog" border="0" data-original-height="250" data-original-width="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-dr16BMBuWQiPNrW9GvEXxDwGRI4goBxBo4-1AZkxevmxWZCBoOuY1E9XWaocvB1TzP4aJowwmH2YVD5O754uvp19U_hhz9FTwc5zUH0MfscatDv31KMZgVxgaqwPjJsWnNawGs49xms/s1600/Product+Backlog.png" title="Product Backlog" /></a></div>
Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.<br />
<br />
Esa evolución se da a través de los Sprints, a medida que:<br />
<ul>
<li>Se pasan ítems al Sprint Backlog, durante la Planning.</li>
<li>Se agregan nuevos ítems que sean valiosos para el producto</li>
<li>Se eliminen ítems cuyo valor ya no es relevante</li>
<li>Se descompongan ítems grandes en otros más pequeños</li>
<li>Se cambian las prioridades de los ítems, al reconsiderar su valor actual</li>
</ul>
<div>
Una idea central es que el Product Backlog es la <b>única fuente de trabajo relativa al producto</b> para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.</div>
<div>
<br /></div>
<div>
Cuando un producto es muy grande, el esfuerzo <i>puede</i> distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.</div>
<div>
<br /></div>
<div>
El Product Owner es el responsable por su <b>contenido, visibilidad y priorización.</b><br />
<b><br /></b>
El Product Backlog sirve para responder a la pregunta <b>"¿qué es lo próximo a desarrollar?"</b> y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.<br />
<br />
Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.<br />
<br />
<div>
<h3><a href="#" id="#Refinement" name="Refinement">Refinamiento del Product Backlog</a></h3><div><br /></div>
</div>
Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:<div>
<ul>
<li>Con su valor establecido (y ordenados en consecuencia)</li>
<li>Divididos en los ítems más pequeño posibles</li>
<li>Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)</li>
<li>Detallados (suficiente como para que nada se bloquee en la Planning)</li>
</ul>
<div>
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:</div>
</div>
</div>
<div>
<ul>
<li>Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.</li>
<li>Evitar analizar ítems que pueden variar (o desaparecer)</li>
</ul>
<div>
La actividad de agregar estos detalles al Product Backlog no es un "evento" sino una tarea permanente del Product Owner, llamada <b>Product Backlog Refinement</b>, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2NCTYMW2wfnNP9FMqXuTOSO7GyeYq3EK4TJjJ07iH7AH42nrHHXDGxhDxqXTVzhlg8SBbDxYFZxZz53sJMqu8t5mIJUCbils8lQ0nW_dQVm4Y0DgtfAwRx_wX4gofu-9tad_szBHJHsk/s1600/Refinement.png" style="margin-left: 1em; margin-right: 1em;"><img alt="Product Backlog Refinement" border="0" data-original-height="1137" data-original-width="1600" height="454" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2NCTYMW2wfnNP9FMqXuTOSO7GyeYq3EK4TJjJ07iH7AH42nrHHXDGxhDxqXTVzhlg8SBbDxYFZxZz53sJMqu8t5mIJUCbils8lQ0nW_dQVm4Y0DgtfAwRx_wX4gofu-9tad_szBHJHsk/s640/Refinement.png" title="Product Backlog Refinement" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div>
<br /></div>
La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.<br />
<br />
Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.<br />
<br />Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se <i>fueron</i> del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).<br />
<br />
También es importante, en mi opinión, que las actividades de Refinamiento <b>no se conviertan en una Planning</b> <b>anticipada</b>. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.<br />
<br /></div>
Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-20308479751481819502020-02-26T18:53:00.000-03:002020-02-27T09:17:03.314-03:00La estructura de ScrumSiguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. <span style="font-size: large;">😁</span><br />
<br />
Scrum está compuesto, además de sus <a href="https://www.codeandbeyond.org/2020/02/pilares-y-valores-de-scrum.html">pilares y valores</a>, por una serie de artefactos, eventos y roles.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmKKEhnfHbHaBqs_l8cbruGAaC4Pq1cf4obz8vPH0mGWKbTjHdt3st65-ltaa83VwFwrRF4hcpzOW3BK-6EGJ7ISYIp9XnaIrJQtv5CSHlUAayLq0UCn21qZBlZzi26gqsBokHHEvMFlA/s1600/Scrum_Diagrams.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="La estructura de Scrum" border="0" data-original-height="1107" data-original-width="1450" height="488" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmKKEhnfHbHaBqs_l8cbruGAaC4Pq1cf4obz8vPH0mGWKbTjHdt3st65-ltaa83VwFwrRF4hcpzOW3BK-6EGJ7ISYIp9XnaIrJQtv5CSHlUAayLq0UCn21qZBlZzi26gqsBokHHEvMFlA/s640/Scrum_Diagrams.png" title="La estructura de Scrum" width="640" /></a></div>
<br />
<br />
<div style="background-color: yellow; border: 5px solid red; padding: 5%; text-align: center;">
<b>AVISO</b><br />
<b>Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.</b>
</div>
<br />
<hr />
<h2>
Artefactos -> Transparencia</h2>
<br />
Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.<br />
<h3>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
Product Backlog</h3>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.<br />
<br />
El orden en que están los ítems del Product Backlog <b>transparentan</b> la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjCseOFkcfdzc20K7oGKHCTLhFpk5ONhSvJqHyQrprUTVvoErWNKjyS0DKudO0F_9SPEO0ewgXtt8Nwbep6COR7e9C5DB-XK2YBZPReRZ7eJDLRe36NmThKNCvp0aqp0PL4mXm7UjX390/s1600/Product+Backlog.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Product Backlog" border="0" data-original-height="250" data-original-width="250" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjCseOFkcfdzc20K7oGKHCTLhFpk5ONhSvJqHyQrprUTVvoErWNKjyS0DKudO0F_9SPEO0ewgXtt8Nwbep6COR7e9C5DB-XK2YBZPReRZ7eJDLRe36NmThKNCvp0aqp0PL4mXm7UjX390/s200/Product+Backlog.png" title="Product Backlog" width="200" /></a></div>
<h3>
Sprint Backlog</h3>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.<br />
<br />
El Sprint Backlog <b>transparenta</b> el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoTpk8HiAsRhugL_iEz19NNv_SP13mKheRE-jfM9xf0Q_KaGPs7uXk9EZUC6OK5Vt9I6qnfn5eu1hipqIYDtenPJK9XMqWkoz_VjueuY5nURruIrshLBvXqFb95ZyUotoVFm06U1FNu8k/s1600/Sprint+Backlog.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Sprint Backlog" border="0" data-original-height="250" data-original-width="250" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoTpk8HiAsRhugL_iEz19NNv_SP13mKheRE-jfM9xf0Q_KaGPs7uXk9EZUC6OK5Vt9I6qnfn5eu1hipqIYDtenPJK9XMqWkoz_VjueuY5nURruIrshLBvXqFb95ZyUotoVFm06U1FNu8k/s200/Sprint+Backlog.png" title="Sprint Backlog" width="200" /></a></div>
<br />
<h3>
Product Increment</h3>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.<br />
<br />
Este Incremento <b>transparenta</b> de manera radical el estado del producto. Es una versión del producto <i>utilizable</i> y completa, independientemente de que se decida entregarlo o no a la audiencia final.<br />
<br />
Para asegurar esa usabilidad, el Incremento debe cumplir con la <b>Definition of Done</b> (definición de terminado) que el equipo tiene acordada.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjrt52N3x-GplPXvFHYAEWKxnsV3lVdHMgQU4Ux-Uyz7eOvoZUycv4F0PE8sO6fqwu_-_pc9WbuPiTDOGNDn5z8XMwhonYn68zugG4aOm9IJ3Hedh3Y47iSAAvKZJbIKJcmHHdSFR28CE/s1600/Product+Increment.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Product Increment" border="0" data-original-height="250" data-original-width="250" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjrt52N3x-GplPXvFHYAEWKxnsV3lVdHMgQU4Ux-Uyz7eOvoZUycv4F0PE8sO6fqwu_-_pc9WbuPiTDOGNDn5z8XMwhonYn68zugG4aOm9IJ3Hedh3Y47iSAAvKZJbIKJcmHHdSFR28CE/s200/Product+Increment.png" title="Product Increment" width="200" /></a></div>
<br />
<hr />
<h2>
Eventos -> Inspección y Adaptación</h2>
Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.<br />
<br />
<h3>
Sprint</h3>
El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.<br />
<br />
Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5ZiteMSGAqgY5xynApYPa16VRVrfPy21819a1AaFtkxXZ6BlJo3pS75iYiL9fREzISPKsC4tMzlipl7GVGelBOQbj3ehPb-sggAPBWXT6MfKwcER5cHF7jkI_0GNI0hwpmZ-1cutLXSo/s1600/Events.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Eventos de Scrum" border="0" data-original-height="1099" data-original-width="1438" height="488" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5ZiteMSGAqgY5xynApYPa16VRVrfPy21819a1AaFtkxXZ6BlJo3pS75iYiL9fREzISPKsC4tMzlipl7GVGelBOQbj3ehPb-sggAPBWXT6MfKwcER5cHF7jkI_0GNI0hwpmZ-1cutLXSo/s640/Events.png" title="Eventos de Scrum" width="640" /></a></div>
<br />
<h3>
Sprint Planning</h3>
Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información adicional de cómo desarrollarlos, se convierten en el Product Backlog.<br />
<br />
En la Planning el equipo <b>inspecciona</b> las expectativas de corto plazo sobre el producto y <b>adapta</b> su estrategia para lograr un resultado concreto.<br />
<br />
<h3>
Daily Scrum</h3>
Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para <b>inspeccionar</b> cómo avanza hacia el objetivo del Sprint y <b>adaptar</b> sus planes para alcanzarlo.<br />
<br />
El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.<br />
<br />
<h3>
Sprint Review</h3>
Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para <b>inspeccionar</b> el Product Increment, de manera de poder <b>adaptar</b>, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.<br />
<br />
<h3>
Sprint Retrospective</h3>
La "Retro" es una oportunidad para que el equipo se auto-<b>inspeccione</b>, y <b>adapte</b> su manera de trabajar, mejorando de manera continua.<br />
<br />
Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.<br />
<br />
<br />
<hr />
<h2>
Roles</h2>
<div>
<br /></div>
<div>
Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.</div>
<div>
<br /></div>
<div>
La suma de las personas cubriendo estos <b>tres roles</b> en un equipo es lo que se llama Scrum Team (o equipo Scrum).</div>
<div>
<br /></div>
<div>
Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados <b>Stakeholders</b>, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.</div>
<div>
<br /></div>
<h3>
Development Team</h3>
Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjYcJhP0eVsGczTJFNLQi6C4IXISlJW4V3UXqn20Ef_v7oclxtV6m_q6f4K9M4yHtH9zEVieU5mCcqx4P6hyiwoG9VdQOIXxz_0O5fWv9jsdCfiI2x4t1v-R7ZI0V5Wtv6sMtRaKCOMVg/s1600/Dev+Team.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="200" data-original-width="381" height="104" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjYcJhP0eVsGczTJFNLQi6C4IXISlJW4V3UXqn20Ef_v7oclxtV6m_q6f4K9M4yHtH9zEVieU5mCcqx4P6hyiwoG9VdQOIXxz_0O5fWv9jsdCfiI2x4t1v-R7ZI0V5Wtv6sMtRaKCOMVg/s200/Dev+Team.png" width="200" /></a></div>
<br />
<h3>
Product Owner</h3>
Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZjTXeAg-vw2hetqEtlP0XglIOyJfoP5FoYXrPqGRFveVCQ5zomI_mlrQc4keXFrwQuI7xdQX4uzdwvzN8VlY_UFfEFUs7Y3g1CmSwv7gTOmTuf5MuwVLSyhKG0AdgqsJpfmhlf92tbGk/s1600/Product+Owner.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="200" data-original-width="200" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZjTXeAg-vw2hetqEtlP0XglIOyJfoP5FoYXrPqGRFveVCQ5zomI_mlrQc4keXFrwQuI7xdQX4uzdwvzN8VlY_UFfEFUs7Y3g1CmSwv7gTOmTuf5MuwVLSyhKG0AdgqsJpfmhlf92tbGk/s200/Product+Owner.png" width="200" /></a></div>
<br />
<h3>
Scrum Master</h3>
Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLm3Uy6qyPzz-oP4rV-sRwKHnVI9EIVFYAaOXz3-K8DzXsS9n96p_tEbtAWC1fNLmQK60AlZ1pahS_wAb97AlA4kTLLJA_ElztbhXIOiY8eUoTJHbH4UPV8QnVe4x7NaYL6P8q5z1Inuk/s1600/Scrum+Master.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="200" data-original-width="200" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLm3Uy6qyPzz-oP4rV-sRwKHnVI9EIVFYAaOXz3-K8DzXsS9n96p_tEbtAWC1fNLmQK60AlZ1pahS_wAb97AlA4kTLLJA_ElztbhXIOiY8eUoTJHbH4UPV8QnVe4x7NaYL6P8q5z1Inuk/s200/Scrum+Master.png" width="200" /></a></div>
<br />
<br />Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-35501869581858124382020-02-25T14:53:00.001-03:002020-02-27T09:13:53.447-03:00Pilares y Valores de ScrumUna contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"<br />
<br />
La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.<br />
<br />
<h2>
Procesos de Control Empírico</h2>
<br />
Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.<br />
<br />
No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:<br />
<br />
<ul>
<li><b>V</b>olatilidad</li>
<li><b>I</b>ncertidumbre</li>
<li><b>C</b>omplejidad</li>
<li><b>A</b>mbigüedad</li>
</ul>
<br />
De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.<br />
<br />
<h2 id="pilares">
Pilares de Scrum</h2>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2X9GpDZzi5nP9jW9bCa0BzQzo2Pg1QX5zjRN6Loz90X1qtR6OlSg9NMz36s-lnEfi9UIsK0CdxbS2j2QfvYKaSS1DBY5GxCPFoQ5MVzT1GbD1_da_6bb_QjfmlLnoFKoOyiLJLve78Zc/s1600/Scrum+Plllars.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt=" Transparencia, Inspección y Adaptación" border="0" data-original-height="474" data-original-width="1600" height="185" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2X9GpDZzi5nP9jW9bCa0BzQzo2Pg1QX5zjRN6Loz90X1qtR6OlSg9NMz36s-lnEfi9UIsK0CdxbS2j2QfvYKaSS1DBY5GxCPFoQ5MVzT1GbD1_da_6bb_QjfmlLnoFKoOyiLJLve78Zc/s640/Scrum+Plllars.png" title=" Transparencia, Inspección y Adaptación" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Transparencia, Inspección y Adaptación</td></tr>
</tbody></table>
<div>
Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?</div>
<div>
<br /></div>
<div>
La<b> transparencia</b> en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.</div>
<div>
<br /></div>
<div>
En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que <b>inspeccionarán</b> junto a los clientes o "negocio", entendiendo:</div>
<div>
<ul>
<li>Decisiones acertadas o no</li>
<li>Hipótesis de negocio comprobadas o no</li>
<li>Calidad del producto</li>
<li>Estado actual frente a un contexto volátil</li>
<li>Comprensión correcta entre todos, en un entorno ambiguo</li>
</ul>
</div>
<div>
Basados en este aprendizaje, el equipo y sus clientes <b>adaptan</b> su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.</div>
<div>
<br /></div>
<div>
Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.</div>
<div>
<br /></div>
<div>
Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.</div>
<div>
<br /></div>
<h2 id="valores">
Valores de Scrum</h2>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpwa0a3KrdCLPIyZTo8ANXZmbn-dJ1fN-qOom8tQ5vhcuKeVEdNyarDup0LqfgRxAjLYbexldBxLTc5_Oouzp4rxWacOQZqc6uqwWbAR2LQMEMs9lmFU5HgSDe8hF4_fPnA56c_RHdrHg/s1600/Scrum_Values_.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Compromiso, Coraje, Foco, Apertura, Respeto" border="0" data-original-height="378" data-original-width="1600" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhpwa0a3KrdCLPIyZTo8ANXZmbn-dJ1fN-qOom8tQ5vhcuKeVEdNyarDup0LqfgRxAjLYbexldBxLTc5_Oouzp4rxWacOQZqc6uqwWbAR2LQMEMs9lmFU5HgSDe8hF4_fPnA56c_RHdrHg/s640/Scrum_Values_.png" title="Compromiso, Coraje, Foco, Apertura, Respeto" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: 12.8px;">Compromiso, Coraje, Foco, Apertura, Respeto</span></td></tr>
</tbody></table>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div>
Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención <b>detrás</b> del marco de trabajo, y permiten entender mejor el porqué de cada pieza.</div>
<div>
<br /></div>
<div>
Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:</div>
<div>
<br /></div>
<h3>
Compromiso (commitment)</h3>
<div>
Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.</div>
<div>
<br /></div>
<div>
En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.</div>
<div>
<br /></div>
<div>
La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades <i>fuera</i> de su equipo.</div>
<div>
<br /></div>
<h3>
Coraje (courage)</h3>
<div>
Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.</div>
<div>
<br /></div>
<div>
En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.</div>
<div>
<br /></div>
<div>
Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.</div>
<div>
<br /></div>
<h3>
Foco (focus)</h3>
<div>
Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".</div>
<div>
<br /></div>
<div>
Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.</div>
<div>
<br /></div>
<h3>
Apertura (openess)</h3>
<div>
Algo abierto es algo expuesto y evidente.</div>
<div>
<br /></div>
<div>
En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).</div>
<div>
<br /></div>
<div>
La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de <b>inspección</b> y <b>adaptación</b>.</div>
<div>
<br /></div>
<h3>
Respecto (respect)</h3>
<div>
Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.</div>
<div>
<br /></div>
<div>
En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.</div>
<div>
<br /></div>
<div>
Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.</div>
<div>
<br /></div>
<div>
<br /></div>
<h2>
¿Y cuál es la respuesta?</h2>
<div>
Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.</div>
<div>
<br /></div>
<div>
Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.</div>
<div>
<br /></div>
<div style="text-align: center;">
<b>Scrum no es un modelo <i>predictivo</i>, es un modelo <i>adaptativo</i>.</b></div>
<div style="text-align: center;">
<br /></div>
<div>
Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:</div>
<div>
<ul>
<li>¿El producto agrega valor?</li>
<li>¿Estamos más cerca de resolver el problema?</li>
<li>¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?</li>
</ul>
</div>
<div>
Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.</div>
<div>
<br /></div>
Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-70983519212683832132020-02-24T16:08:00.001-03:002020-07-15T20:12:56.787-03:00¿Qué es Scrum y para qué se usa?Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "<a href="https://www.kleer.la/es/publicamos/scrum">Proyectos Ágiles con Scrum</a>" que escribimos con mi amigo <a href="https://martinalaimo.com/es/blog">Martín Alaimo</a>. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><span style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><a href="https://scrumguides.org/"><img alt="Scrum Guides (portada)" border="0" data-original-height="947" data-original-width="1160" height="261" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaWFmmmj5Ha4Qo1S5bZM3F-n3RyC1_4lOHMcOCjhz76iCMUyh85zmY7SGEgiFBjLkuJuY8LCtMICzqaOPkho2osNTZtii7WwZ-PXdNA_5W_7RVrJbddZIfEMC4ARf7S6POzumzaBi55dQ/s320/scrum-guides.png" title="Scrum Guides" width="320" /></a></span></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="https://scrumguides.org/">Sitio de la Guía de Scrum</a></td></tr>
</tbody></table>
<h2>
¿Qué es Scrum?</h2>
<div>
<br /></div>
Según la <a href="https://scrumguides.org/">Scrum Guide</a> (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):<br />
<blockquote class="tr_bq">
Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.</blockquote>
Me gusta esa definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.<br />
<h3>
</h3>
<h3>
Un marco de trabajo...</h3>
<br />
Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco <i>intencionalmente incompleto</i>.<br />
<br />
Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.<br />
<br />
Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, <b>si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas</b>.<br />
<h3>
</h3>
<h3>
...en el que las personas...</h3>
<br />
Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una <i>herramienta de management,</i> al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimALd5SG6nfQ7gO9QDX33AX0L2f1edOz-yrjetBUYgTY8DhEjEzxR-F9kru7biURWwKnNJaVx1TTXOnk22TII4cgOiAy9nCg9lnXwy7GqUgfCrUi-ebGtFO9OETYpUmvAphX_SPVX8TAE/s1600/Scrum_Team.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="311" data-original-width="931" height="106" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimALd5SG6nfQ7gO9QDX33AX0L2f1edOz-yrjetBUYgTY8DhEjEzxR-F9kru7biURWwKnNJaVx1TTXOnk22TII4cgOiAy9nCg9lnXwy7GqUgfCrUi-ebGtFO9OETYpUmvAphX_SPVX8TAE/s320/Scrum_Team.png" width="320" /></a></div>
<h3>
</h3>
<h3>
...abordan problemas adaptativos complejos, mientras entregan productos...</h3>
<br />
Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.<br />
<br />
Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.<br />
<br />
Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.<br />
<br />
<h3>
</h3>
<h3>
...del mayor valor posible de manera productiva y creativa</h3>
<br />
El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese <i>problema adaptativo complejo</i>.<br />
<br />
La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.<br />
<br />
Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU5un9LfOoHn03TsCZNwq-9ubTaqK6ENzkbHkyaZ6g4oltPOR-Hhy8qesjepKHfP1L5cyZayhqhmWiDuF3OsicPIsAt53W0TiS64l4X_JENexl_iZr7nPa7vx9sUZ6weooztfht8WMMzw/s1600/Scrum+Diagrams.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1131" data-original-width="1467" height="246" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU5un9LfOoHn03TsCZNwq-9ubTaqK6ENzkbHkyaZ6g4oltPOR-Hhy8qesjepKHfP1L5cyZayhqhmWiDuF3OsicPIsAt53W0TiS64l4X_JENexl_iZr7nPa7vx9sUZ6weooztfht8WMMzw/s320/Scrum+Diagrams.png" width="320" /></a></div>
<br />
<br />
<h2>
Otras características</h2>
Una a frase adicional que destaca otras características de Scrum es que "<b>es un marco de trabajo liviano, simple de comprender, pero difícil de dominar</b>".<br />
<br />
Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere <b>menos supervisión</b> y <b>más delegación</b> de responsabilidades.<br />
<br />
Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.<br />
<br />
Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.<br />
<br />
<br />
<h2>
Hacia adelante</h2>
Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:<br />
<br />
<i>(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)</i><br />
<br />
<ul>
<li><a href="https://www.codeandbeyond.org/2020/02/pilares-y-valores-de-scrum.html#pilares">Pilares</a>: Transparencia, Inspección y Adaptación</li>
<li><a href="https://www.codeandbeyond.org/2020/02/pilares-y-valores-de-scrum.html#valores">Valores</a>: Compromiso, Coraje, Foco, Apertura y Respeto</li>
<li><a href="https://www.codeandbeyond.org/2020/02/la-estructura-de-scrum.html">Estructura general</a></li>
<ul>
<li>Artefactos: <a href="https://www.codeandbeyond.org/2020/03/scrum-product-backlog.html">Product Backlog</a>, <a href="https://www.codeandbeyond.org/2020/03/scrum-sprint-backlog.html">Sprint Backlog</a>, <a href="https://www.codeandbeyond.org/2020/03/scrum-incremento-de-producto.html">Product Increment</a></li>
<li>Eventos: <a href="https://www.codeandbeyond.org/2020/07/eventos-de-scrum-el-sprint.html">Sprint</a>, Planning, Daily Scrum, Review, Retrospective</li>
<li>Roles: Development Team, Product Owner, Scrum Master (y stakeholders)</li>
</ul>
<li>y las pocas reglas que los vinculan: </li>
<ul>
<li><a href="https://www.codeandbeyond.org/2020/03/scrum-incremento-de-producto.html#DoD">Definition of Done</a></li>
<li><a href="https://www.codeandbeyond.org/2020/03/scrum-product-backlog.html">Refinement</a></li>
</ul>
</ul>
<br />
<br />Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-12300160563774749452018-09-14T15:36:00.001-03:002018-09-14T15:37:51.252-03:003 elementos para una Arquitectura más Ágil<p>Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.</p>
<p>Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:</p>
<p><strong>Arquitectura incremental</strong></p>
<p>Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.</p>
<p>IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="aa01.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_tF5VNezPItTVAS1WpqIbuHwomZ1yPFqtW0AGVQHNZTR3zAYvhlgU6IE7Sx4cZACzyNWCcXtwcriZQNnGEbvBt3CnFUBFKqSXQSYEVB2j56Kj1QJ_D47XIPL1MXdxNpWdGILTnQhUhBk/s0/aa01.png" alt="Arquitectura Incremental en Scrum" width="529" height="430" border="0" /></p>
<p><strong>Validación continua</strong></p>
<p>Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.</p>
<p>Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="aa02.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyFG7N-1oMVR6v6LgY3aXpKZ1KNaUGJFh6qbgVDX_0kQaFf5Nyv0yeTWxTanQXf3vBf4k9B-edD9G1u-tkU4XHePqtvg-fmvc3y2NDzmNNHgwUe0dtwcj-GFrhD3n3n37yxa16ybKxLPY/s0/aa02.png" alt="Validación Continua" width="599" height="311" border="0" /></p>
<p><strong>Demasiado importante para dejárselo a los Arquitectos</strong></p>
<p>Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.</p>
<p>Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.</p>
<p>Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.</p>
<p>Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="aa03.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiebumn4ZUc8nxXFWvtm-s_gG3ngldZjwy-82DXuQkrXi6cuut0f_oKNDd_c9Sxh0WTRaAj2kMpz1Z9e61LFVp2jcTKWaPGilRukXvsA0RXIm-JhrSxZWs-vw78T6-14p-zfa4tNXBexac/s0/aa03.png" alt="Arquitectura Colaborativa" width="599" height="299" border="0" /></p>
<p> </p>
<p><strong>Continuando la discusión</strong></p>
<p>Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:</p>
<ul>
<li>El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.<br />(<a href="http://kl.la/Agile-Arch">Original en inglés</a>, en el Architecture Journal; ó <a href="https://www.dropbox.com/s/ho52huc71ewe6tz/Arquitectura%20en%20el%20Ciclo%20de%20Vida%20Agil.pdf?dl=0">versión en español</a>, actualizada en 2013)</li>
<li>Mi libro en progreso, <a href="https://leanpub.com/agileArchitecture">Agile Software Architecture</a>.</li>
<li>Mi <a href="https://www.kleer.la/es/categoria/software/cursos/46-agile-architecture-workshop">Agile Architecture Workshop</a>, que doy varias veces al año en distintas ciudades de América Latina <br />(cuando hay fechas programadas aparecen a la derecha)</li>
<li>Otros libros relacionados de colegas varios: </li>
<ul>
<li><a href="https://amzn.to/2xbEgbK">Building Evolutionary Architectures</a>, de Rebecca Parsons, Neil Ford y Patrick Kua</li>
<li><a href="https://amzn.to/2xhAPQf">Lean Architecture</a>, de James Coplien y Gertrud Bjørnvig</li>
</ul>
</ul>
<p> </p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-5116060794041123362018-07-06T12:17:00.001-03:002018-07-06T12:17:39.541-03:00Colaboración real: lo que más cuesta lograr en los equipos<p>Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:</p>
<ul>
<li>Trabajan en iteraciones (o sprints)</li>
<li>Planifican al inicio</li>
<li>Revisan al final</li>
<li>Hacen retrospectivas (a veces) y tratan de mejorar</li>
</ul>
<p>En muchos casos también tienen su reunión diaria (la <em>daily standup</em> o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.</p>
<h2>Antipatrón 1: cascada iterativa</h2>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="cascada.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqJcmkmv_ub_TU8MJ4XMbutPQav3pj-1zNjT5QPXzDmbFy8hpt_e3bjgKBLi00hj1nKeFlpq6jeAiJwy1GFoUdL91fjE714-_QU9RIoM-ISAZ-PBcdJFEsbRQKFTNuvLz67UyE8kXZeX4/s0/cascada.png" alt="Cascada Iterativa" width="397" height="98" border="0" /></p>
<p>Se nota al sincronizar que los miembros del equipo tienden a <em>esperarse</em> entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...</p>
<p>Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.</p>
<p>Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.</p>
<h2>Antipatrón 2: sobre-especialización</h2>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="especializacion.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0w6HX9Ynx0bHNjyajaHHi6J4EzYXpKnjs14EeCJNdiBp629Jo9hV7yc64HE1whatCBXHgWy_pZR8Xm9rJF3VIstiUo_h3OLU3fNv5zwGFWCDnkqf1iW_U_BvynyA7JJzr9ADPqIDHOEc/s0/especializacion.png" alt="Especialización" width="400" height="139" border="0" /></p>
<p>También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.</p>
<p>En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.</p>
<h2>La magia de trabajar de a pares</h2>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="pares.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2veRqQHMxPyIqMGbgaOdaG96R_jJk9PfwEjda8ZuOsroy7C_tBDL8hdHQ3LBNDFO8eD7leoHwmF2fOIjhGm3bSMpd7Zd84l7YCqnktGFuurYtNSjkgfby3xzqmqB8TFP9DQaojL5a860/s0/pares.png" alt="Pares" width="400" height="230" border="0" /></p>
<p>Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.</p>
<p>Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:</p>
<ul>
<li>Tratar de terminar cuanto antes lo que tiene más valor</li>
<li>Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos</li>
<li>Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.</li>
<li>Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.</li>
</ul>
<h2>¿Todo hay que hacerlo de a dos?</h2>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="solos-y-pares.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJ8KfPJVdOjWB81oo7ogTidaSU-I-5B0TQqPuEBqMGNfhVF69wffyaZbcuRRaEStoO6Oy_lD50zYuwxkbVFwfzQfdUbpDg3qY6oP0X0CDBOGvM_Re_Hb6ahkMUAsQ6_XZiq4YZ2f4dDBE/s0/solos-y-pares.png" alt="Solos o de a pares" width="398" height="117" border="0" /></p>
<p>No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.</p>
<p>Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.</p>
<h2>Colaboración real en equipos</h2>
<p>Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.</p>
<p>Lo que busca un equipo ágil es aplicar el <a href="https://es.wikipedia.org/wiki/Principio_de_Pareto">principio de Pareto</a> a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.</p>
<p>En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".</p>
<p>Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-67209940457565458482018-04-22T13:18:00.001-03:002018-04-22T13:18:08.564-03:00Literatura Potencial al Aire Libre<p><a href="https://www.dropbox.com/s/yxa416u0655wdxv/Literatura%20Potencial%20al%20Aire%20Libre.pdf?dl=0"><img style="float: right;" title="LiteraturaPotencial.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0-TvRpvW7cgG1I5wTrC6qyDkmF0cKnA7c9_Qr2AwrfFtThHsCYUlx-Z5amIgZBUkWKapzMoH_05SZb3Zca7kLuwBK04mfnbrJutdBakHAb2rSWaQKHbfAZnXtjF8fI3QZumFVNaeIo24/?imgmax=1600" alt="Literatura Potencial al Aire Libre" width="200" height="238" border="0" /></a>Durante la reciente edición 2018 del <a href="http://www.agileopencamp.com.ar/">Agile Open Camp</a>, en Bariloche, Argentina, presenté una charla relámpago (21 slides de 20 segundos cada uno; 7 minutos en total) que titulé “Restricciones para la Creatividad” y en la que contaba sobre el Oulipo, el “<em>Ouvroir de littérature potentielle</em>” que en los años '60 fundaron en Francia escritores de diferentes orígenes, dedicado a explorar las posibilidades de restricciones auto-impuestas, surgidas sobre todo de las matemáticas y sus derivados (como la música o el ajedrez) para desencadenar procesos creativos.</p>
<p>Debajo queda la presentación, aunque son sólo imágenes. Pero más importante que eso, para mi, es el libro que tiene el mismo título que este post, resultado del taller que realizamos más tarde, durante una sesión del Open Space.</p>
<p>Los asistentes escribieron varios Haiku, y luego comenzaron cuatro cuentos, algunos de los cuales fueron finalizados días más tarde. El librito es una compilación de esos trabajos, más una breve introducción que recupera (con notas adicionales) parte de la charla relámpago.</p>
<p>Gracias a Marta Bendomir, Tommy Christie, Marcela Pelz y María Thompson por participar del taller y del libro, y gracias a Manuel Mandrafina Thompson que colaboró en el cierre de uno de los cuentos.</p>
<p>El libro puede descargarse en forma libre y gratuita <a href="https://www.dropbox.com/s/yxa416u0655wdxv/Literatura%20Potencial%20al%20Aire%20Libre.pdf?dl=0">desde aquí</a> (o desde la imagen de tapa más arriba).</p>
<p><iframe src="//www.slideshare.net/slideshow/embed_code/key/ctWTTZfwfwZsaQ" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" width="595" height="485" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" allowfullscreen=""> </iframe></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-85274830909729631532018-01-26T09:43:00.001-03:002018-02-06T08:50:25.666-03:00Espacios de Trabajo para Equipos Ágiles<p>Este es un tema recurrente con muchas organizaciones a las que ayudo. Como el foco principal del paradigma ágil es la colaboración, muchas veces llega un momento en que ellos notan que sus espacio de trabajo no son ideales para lo que intentan lograr.</p>
<p> </p>
<h2>Espacios frágiles</h2>
<p><img style="float: right;" title="cubiculos.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1NQP6NoR-S-wUZDB5V2zhO8R266sSquuwixUFBFKoIFU_beNFMCbYmTjDVUtaXdb5hUjnzSR9TfTzBmOsVs5HGul5D3J1rwur16gJ8IMtzfsa4ic1TvX82TX3RWb5J54ummDAU7c8SU0/?imgmax=1600" alt="Cubículos" width="278" height="311" border="0" />Los espacios de trabajo más nocivos que me encuentro suelen incluir desde cubículos hasta oficinas individuales a puerta cerrada. Y aclaro que he trabajado en lugares así, aunque nunca fue mi preferencia. Durante un tiempo -hace muchos años- me tocó una oficina privada, alejada por un pasillo largo del equipo que me tocaba liderar. Al principio me sentí inocentemente importante, pero pronto me di cuenta de que esa distancia no nos beneficiaba en nada.</p>
<p>Algunas variantes de los cubículos son los espacios semi-abiertos con escritorios con divisiones más bajas, que permiten verle los ojos a la persona de enfrente, aunque no alientan una colaboración más allá e una pregunta o conversación esporádica.</p>
<p>Y no sólo los espacios físicos generan fricción. Muchos espacios virtuales también lo son. Muchas de las llamadas "herramientas de colaboración" me resultan consistentemente un impedimento a la conversación cara a cara. A riesgo de controversia, no he visto nunca un equipo que mejore su comunicación (pero si montones que definitivamente empeoraron) por usar Jira, Sharepoint u otras monstruosidades que están más diseñadas para calmar al management que para que la gente se auto-organice.</p>
<h2> </h2>
<h2>Espacios con "Onda Ágil"</h2>
<p><img style="float: right;" title="Heroes.jpg.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5RUxxXH9f3d7eFqcPKwE5EerJzXhhIrsUA4wNXMf1cyDdCkoSbkzW9FEEpJzgkCee_mq_ydhE2DCh6AkVZaB0Wc-owWiGIF6vRng3fwn5nBvCdiaJkrTxaBYbxucL-ckcJOw80oEDKck/?imgmax=1600" alt="Héroes" width="279" height="210" border="0" /></p>
<p>Muchas organizaciones, al sentir que la gente se entusiasma con la agilidad, quieren crear lugares atractivos para atraer talento que espera determinadas características laborales que no son tan fáciles de transmitir a simple vista. Así que recurren al folklore y no muy extrañamente, atraen a los estereotipos a los que se dirigen, lo que no siempre da resultado.</p>
<p>Clásicos de ese estilo son las metegoles (o futbolines, según la región), las paredes ploteadas con íconos y slogans sobre creatividad, innovación y talento, aunque frecuentemente esos y otros valores están en las paredes pero no se sienten en el día a día. En algunos extremos (que creo bien intencionados) se ven exaltaciones a los super-héroes, los rock-stars o ninjas. Como si colaborar fuese tratar de ir solo contra todo, inmolándose por alguna causa esquiva.</p>
<h2> </h2>
<h2>¿Espacios realmente ágiles?</h2>
<p>Mis consejos para quienes quieren realmente generar un ambiente de colaboración y dinamismo van siempre en el mismo sentido: empezar por no definir todo, sino dejar lo máximo posible a criterio de los equipos que usarán el lugar.</p>
<p>Para eso, realmente suele ser preferible contar con espacios abiertos, pero como pueden ser ruidosos, se puede recurrir a elementos que la gente pueda usar para crear sub-espacios flexibles y reconfigurables.</p>
<p><img style="float: right;" title="EspacioAgil.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEja9pSDJE4lRINFx622rlAQ3xI9V709i41Kew5sfVe63CtjljuLfVJHWoU1WPVcyK3WagRGboSbHfHJDvFBKUFigJT2tlfpfTbsP_9waxwV4kaZrE8-jxqmWz8lw1VhxkqFEyC1qLeNPEY/?imgmax=1600" alt="Espacio Kleer" width="343" height="257" border="0" />Algunos de los elementos que prefiero (por experiencia, como materia mínima para que los equipos decidan después):</p>
<ul>
<li>Mesas pequeñas, con patas no intrusivas, donde al menos se pueda trabajar de a dos. O livianas o con rueditas.<br /><br /></li>
<li>Tomas de corriente a granel, sobre las paredes. Y que los equipos puedan poner sus (inevitables) extensiones por donde quieran. Si los cables se tornan molestos o peligrosos, ellos deberían encontrar la mejor solución, no un "arquitecto".<br /><br /></li>
<li>Pizarras o bastidores fáciles de mover (con rueditas o livianos) pueden servir como separadores, aislantes acústicos y también como soporte para radiadores visuales.<br /><br /></li>
<li>Paredes libres (también pueden ser ventanas o paneles de vidrio), sin inscripciones, emblemas ni slogans previos. El uso de las paredes para pegar tableros, indicadores, información necesaria para el equipo, es vital para la comunicación osmótica. Los pizarrones de diferente tipo, sobre todo si son móviles, son un buen recurso para discusiones y diagramas efímeros.<br /><br /></li>
<li>Buenas sillas. Pensando que los trabajadores del conocimiento usamos sobre todos nuestro cerebro y nuestro trasero, tener buenas sillas (de nuevo, móviles) es una excelente inversión para cuidar la salud y comodidad de los equipos.</li>
</ul>
<p>Sobre todo, si queremos promover un ambiente de autonomía y creatividad, demos los elementos básicos y dejemos que los equipos se apropien. Lo que no significa dejarlos a la deriva. Se puede explícitamente pedirles que determinen un plan, tal vez con un presupuesto básico y posibles extensiones iterativas.</p>
<p>Varias veces vi que se diseñan espacios incluyendo áreas de "esparcimiento" para los equipos, donde se incluyen equipos de videojuegos, mesas de ping-pong o instrumentos musicales. Pero este nuevamente es per-determinar qué es lo que ellos querrán, en lugar de preguntarles. Tal vez terminen poniendo la consola de juegos, pero ellos elegirán cuál prefieren y cómo instalarla. O tal vez prefieran otra cosa, como un espacio para cocinar o para hacer yoga.</p>
<p>En definitiva, al pensar espacios ágiles, tenemos que mantener sus principios: flexibilidad, transparencia, diversidad.</p>
<p>Si alguno tiene interés en compartir los espacios que generaron, pueden mandarme fotos, y veo cómo compartirlas.</p>
<p> </p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-6723558297242960092017-08-03T08:10:00.001-03:002017-08-03T08:11:27.507-03:00Cómo escribir tu propio intérprete (o compilador)<p><img style="float: right;" title="Interpreter-in-go.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBV9RKn0RNugkvszKHhKTkdpowSCLTO7iUxNM3CwoM4i72UgwUxolh6mhgwoh-ylxUpKMpp04y4T1Vz9W8Yf_Ltbv5lJ9O02J0tdjz5yrNG5eF3qo38VUq3CG1ZNHOkxVUrkZ90eRmeAs/?imgmax=1600" alt="Interpreter Book" width="150" height="185" border="0" /></p>
<p>Suelo escuchar varios podcast mientras me muevo por Buenos Aires u otras ciudades en mi trabajo. Uno de los que sigo desde hace años es el de <a href="https://www.hanselminutes.com">Scott Hanselman</a>, que es quizá una de las personas que más me impactó dentro de lo que se conoce como la "comunidad Microsoft".</p>
<p>Scott, más allá de seguir trabajando para Microsoft en el grupo de ASP.NET y herramientas de Azure, es un tipo inquieto que mantiene varios podcasts e iniciativas, y sobre todo valoro su constante esfuerzo por lograr una industria más inclusiva, recibiendo a a gente de toda edad, raza, identidad u orientación sexual, religión o ideario.</p>
<p>Pero basta de elogios al amigo Scott. El tema que me atrajo especialmente en éste último podcast fue que entrevistaba a Thorsten Ball, quien auto-publicó el libro "<a href="https://interpreterbook.com/">Writing An Interpreter In Go</a>", que trata básicamente de eso: recorre todos los pasos de escritura de un intérprete. En su caso del lenguaje Monkey que él diseñó para el libro mismo, y que es bastante similar a JavaScript o un montón de otros lenguajes de la familia de las llaves {}.</p>
<p>Más allá de que es un tema interesante, me gustó que la manera en que lo hace es utilizando lo más básico de Go, sin más que la librería standard, construyendo desde cero el parser y el lexer, y sin usar ninguna librería particular. Y por supuesto, utilizando TDD.</p>
<p>Es un libro que recorre en mayor detalle el camino constante del <a href="https://twitter.com/ajlopez">Maestro Ángel Java López</a>, que como puede verse en <a href="https://github.com/ajlopez">su cuenta de GitHub</a> escribe este tipo de intérpretes o compiladores todo el tiempo.</p>
<p>¿Por qué escribir un intérprete a esta altura? Básicamente porque las capacidades y el entendimiento de sus partes nos ayudan a ser mejores programadores en general, como llegado cierto punto un buen automovilista tiene que aprender de mecánica, o un rocker necesita aprender sobre ingeniería de sonido.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-80359749905814633442017-07-13T11:16:00.001-03:002017-07-13T11:16:28.290-03:00Codewars: jugar, practicar, codear<p><img style="float: right;" title="codewars.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxTUSKN7RCqv5XIsfdx_iv8WHVudLXQQAMZCA2l01qA8arCQKoIv1Me9uTMql9Sp-aH2itRdqv2eAHA9wfMI0ExMlJM_4nJwl8qmDYrad8JEZJkVPKY8TONYSx4unuCkepF-SQTo4xjGU/?imgmax=1600" alt="codewars" width="180" height="211" border="0" />Hace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo <a href="https://twitter.com/ajlopez">el Maestro</a>.</p>
<p>A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.</p>
<p><a href="https://www.codewars.com">Codewars</a> es básicamente un sitio de práctica. Está basado en la idea de <a href="http://www.codeandbeyond.org/2011/01/code-katas-la-practica-hace-al-maestro.html">Code Katas</a>, pero extendido a formas adicionales como el <a href="https://www.codewars.com/kumite">Kumite</a> (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.</p>
<p>Entre las características que más me gustaron es que hay:</p>
<ul>
<li>Diferentes niveles de dificultad</li>
<li>Tags que agrupan los ejercicios por temas, niveles, foco</li>
<li>Alto nivel de <em>gamification: </em>los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante</li>
<li>Foros y comentarios bien integrados</li>
<li>Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.</li>
<li>Y sobre todo, la chance de aprender y/o practicar en una <strong>variedad enorme</strong> de lenguajes:<br />(en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.</li>
</ul>
<p>Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.</p>
<p>Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden <a href="https://www.codewars.com/users/msalias">encontrarme en Codewars</a> y eventualmente podemos hacer un Kumite.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-74819878284783600052017-06-29T14:33:00.001-03:002017-06-29T14:33:10.817-03:00Katas de Arquitectura<p><img style="float: right;" title="" src="https://pbs.twimg.com/profile_images/706345034799403008/XuDsdFb5_400x400.jpg" alt="" width="200" height="200" border="0" /></p>
<p>Un año atrás mi amiga <a href="https://twitter.com/jeri4queen">Rox</a> (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.</p>
<p>Primero copio su consulta:</p>
<blockquote>
<p>Mañana tengo una sesión de kata de arquitectura con un equipo. El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.</p>
<p>Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.</p>
<p>Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.</p>
<p>¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?</p>
</blockquote>
<p>Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):</p>
<hr />
<p>¡Hola, Rox! </p>
<p><img style="float: right;" title="Tarot.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEapolaFFskSEh3-tpsA4AZN_L3DYYJgV3FrLpyunWdRz25q3wnBxNrbc1hHKO5cxGBKvbXDnLgr9pe7SAHkzjJOnFt96om-rxq2vjXZ8R8yw7b28dMDyYPZ_L0dMycEA0w_i8vUgrTz4/?imgmax=1600" alt="Tarot de Arquitectura" width="200" height="283" border="0" /></p>
<p>Te paso el material:</p>
<ul>
<li>Las <a href="https://www.dropbox.com/s/yboi3i8x9lsbubh/Katas%20Cards.pdf?dl=0">Katas de Arquitectura en español</a> [y aquí <a href="https://archkatas.herokuapp.com/">el sitio original</a> en inglés]<a href="https://www.dropbox.com/s/yboi3i8x9lsbubh/Katas%20Cards.pdf?dl=0"><br /><br /></a></li>
<li>Y mi <a href="https://www.dropbox.com/s/t67emyil3xj30k8/ArchiTarot.pdf?dl=0">Tarot de Arquitectura<br /><br /></a></li>
<li>[agrego también la <a href="http://guiasagiles.org/#SlicingPatterns">guía ágil de patrones de slicing</a> - que a su vez tiene el link a las tarjetas con los patrones]</li>
</ul>
<p> </p>
<p>Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).</p>
<p>Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. </p>
<p>Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:</p>
<h3>Contexto</h3>
<p>¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.</p>
<h3>Métrica </h3>
<p>¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.</p>
<p>Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. </p>
<h3>Decisión </h3>
<p>¿Cómo hacemos para lograr esa métrica?</p>
<p>Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-63233711373674554912016-05-31T22:11:00.001-03:002016-05-31T22:14:45.835-03:003 dudas sobre Extreme Programming<p>Esta semana una asistente a uno de mis talleres de <a href="http://www.kleer.la/es/categoria/productos/cursos/6-desarrollo-%C3%81gil-de-software">Desarrollo Ágil de Software</a> me envío estas consultas, que como acordamos, intento contestar aquí de manera abierta, para ella y para otros que puedan tener esas dudas.</p>
<blockquote>
<p><span style="color: #0433ff;">Hola Martín! </span></p>
<p><span style="color: #0433ff;">Saludos desde Lima. </span></p>
<p><span style="color: #0433ff;">Disfruté mucho el taller de Desarrollo de software ágil, ya lo estoy recomendando.... al pasar los días me surgieron unas preguntas que cuando tengas oportunidad por fa me escribes...</span></p>
</blockquote>
<p>Vale la pena aclarar que yo voy a dar mi opinión personal. Yo empecé a utilizar ideas de <a href="https://www.universalthread.com/ShowHeaderArticleOneItem.aspx?ID=38893">Extreme Programming</a> (XP) a fines de los '90 y a principios de los 2000 me convertí (se ve que no había mucho más para elegir) en XP Coach de varios equipos. En todo ese tiempo he juntado muchas ideas y dudas nuevas, pero trataré de aportar alternativas y vías de exploración, ya que no creo en que haya UNA respuesta para estos temas.</p>
<p> </p>
<blockquote>
<p><span style="color: #0433ff;">1- Una vez que se decide adoptar XP. El pair programming se aplica todo el tiempo? O se da cabida a espacios para programar individualmente y mob programming? </span></p>
</blockquote>
<p>Aunque en los orígenes de XP esa era la idea, en la práctica y a medida que ha pasado el tiempo la práctica se ha vuelto más pragmática. Recordemos siempre que a pesar del nombre, XP está basado en principios y valores que son los que buscamos, y las prácticas son solo un reflejo adaptable de ellos.</p>
<p>Cuando la solución más sencilla (recordemos que la Simplicidad es primordial en XP) es escribir el código de a uno, no vale la pena buscar un par. Los casos típicos son los que son triviales: construir otra pantalla, adaptador o función que es una variante particular de otras que ya están hechas.</p>
<p>Cuando el desafío es bajo y las tareas son de muy bajo riesgo, podemos obviar el par. Ahora, cuando nos encontramos realizando tareas repetitivas pero que pueden ser críticas, podemos al menos mantener un criterio de revisión de a pares. Lejos de la programación, en Kleer siempre hacemos revisión de a pares para propuestas o presupuestos.</p>
<p><a href="http://mobprogramming.org/">Mob Programming</a> es todavía una técnica relativamente experimental como práctica continua, pero en varias oportunidades en distintos equipos en los que trabajé pasamos de programar de a pares a tríos o cuartetos. Cuando uno pasa ese límite es difícil trabajar con un monitor usual y el salto a un proyector o una pantalla grande implica un reacomodamiento mayor. Un paso intermedio usual es realizar workshops de diseño en conjunto para definir componentes de arquitectura, refactorizaciones importantes a nivel de framework o para ensayar alternativas de diseño con todo el equipo.</p>
<p>En todos los casos lo que funciona es probar y aprender. Una de las premisas es que si no experimentamos en la búsqueda de mejores maneras de trabajar como equipo, siempre estaremos ocupados pero probablemente desperdiciando esfuerzo.</p>
<p> </p>
<blockquote>
<p><img style="float: right;" title="Feathers.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJwiqODhvlMj8SHPjj2BPG5uE28FzdeUc41U5_3WP0KAyk_6Oy6ivvW3TZxFD3rzFJYrMCevn42Xr2uZRhyphenhyphenG9mEj8jedvr07TaMdIA5DXFa5d8zaKd8lt0w0EJlI34jSeVYQ2cd4vg3ZA/?imgmax=1600" alt="Working Effectively with LEgacy Code" width="151" height="200" border="0" /></p>
<p><span style="color: #0433ff;">2- Se puede aplicar TDD o BDD a proyectos que ya han empezado de la manera tradicional (sin metodologia de desarrollo agil o casos de prueba?) o tiene que ser proyectos que aún no hayan arrancado? </span></p>
</blockquote>
<p>Claro que si. Lo más sencillo es usar TDD para código nuevo aunque la solución sea vieja. Un poco más complejo es construir la infraestructura de pruebas en el código antiguo. Para eso utilizamos una serie de técnicas especiales para romper dependencias fuertes en el código. La referencia canónica para esto es el excelente libro de Michael Feathers, <a href="http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Working Effectively with Legacy Code</a>.</p>
<p>Básicamente, mientras haces TDD para el código nuevo, vas necesitando desacoplar la parte del código viejo con el que hay que interactuar, y para eso hay que ir logrando desarmarlo e ir dejando algunas pruebas que nos ayuden en esa tarea.</p>
<p>Algo que si desaconsejo es generar proyectos de "refactorización pura". Cuando nos ponemos exquisitos en cuanto a la calidad del código sin tener en cuenta las necesidades reales de la organización o sus clientes, nos arriesgamos a entrar en un proyecto con objetivos poco claros. Mejor que eso es comprometernos a usar estas técnicas para mejorar el código relacionado con la funcionalidad que <strong>necesitamos</strong> modificar, y esa manera, con el pasar del tiempo, las partes del código que requieren más cambios (lo que de alguna manera demuestra que son más valiosas) irán mejorando y serán más fáciles de entender, probar y extender.</p>
<p> </p>
<blockquote>
<p><span style="color: #0433ff;">3- Algunas empresas no les agrada mucho el aplicar Pair Programming porque tienen la idea que es menos productivo y que así los programadores charlarán entre ellos y no programaron. ¿ Qué argumentos se pueden utilizar para cambiar esas ideas? Y Cómo hacer para que los programadores efectivamente no se pongan en ese plan (pudiera pasar) </span></p>
</blockquote>
<p>Lamentablemente todavía hay organizaciones que dejan pasar las oportunidades de mejorar porque se enfocan en que la gente (a a que suelen llamar <em>recursos</em>) cumple un horario haciendo lo que <em>suponen</em> que es su tarea.</p>
<p>Si pensamos que la tarea de un desarrollador de software es <strong>programar</strong>, y <strong>no hablar</strong>, casi seguro obtendremos como resultado código que hace lo que el programador interpreta de un documento, sin entender lo que hace, y sin preocuparse por que lo que hace agregue valor. Para un desarrollador en esas situaciones siempre recomiendo tratar de generar evidencias de que hay maneras mejores de trabajar, y en último lugar recuerdo siempre el dicho "si no puedes cambiar tu trabajo, cambia tu trabajo". No me parece bien tomarse livianamente la ida de que la organización "es así", porque en muchos casos vi gente desde las posiciones más humildes e inesperadas generar una ola de cambio. </p>
<p>Un buen desarrollador tiene que charlar con el resto del equipo y buscar soluciones apropiadas a las necesidades planteadas, y debe lograr entender el contexto de negocio y aportar su visión. Si limitamos a los desarrolladores a <em>programar</em> lo que otros le indican sin nada más, llegaremos siempre a soluciones mediocres o pobres. De la misma manera, si el equipo no entiende y no está conectado con los problemas que tiene que resolver, su motivación será obviamente más baja, y eso no lo compensa trabajar de a pares o no. </p>
<p>Al revés, si el equipo está conectado con el negocio, al trabajar de a pares encontrarán mejores soluciones que trabajando solos. El principal problema de trabajar solo para un desarrollador es la facilidad para perder el foco o bloquearse en detalles menores, cosas que casi no suceden al trabajar de a pares.</p>
<p>En resumen, para mi un argumento fundamental es si queremos "cantidad de código" o "buenas soluciones".</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-71671268331939102782016-05-16T23:51:00.001-03:002016-05-16T23:51:45.166-03:00El Kyū-Dan de la Integración Continua<p><img style="float: right;" title="belts.jpg" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaAPV9PiL97Jh8NRSk9hz79Z4tHxZL-3CMZlIorPGCOVqbO59698BaOthNdjeVmZ4lP6U0gWKKJYJz23s63xKWj8qeO7J7gvybv4_RU50FsKgHm9DU5-6H-XWuV-rTnnwdgIjIoRKM_zQ/?imgmax=1600" alt="Cinturones de Judo" width="300" height="225" border="0" /></p>
<p>En algún momento del 2014, tuve una consulta de mi amigo <a href="https://twitter.com/sebis">Sebis Henzenn</a>, que generó (estaba lejos y tenía un rato) un mail con una explicación bastante larga de lo que se me ocurrió en ese momento como una metáfora aproximada de los pasos de aprendizaje respecto a prácticas relacionadas con Integración Continua y sus derivaciones.</p>
<p>El mensaje quedó guardado unos años, pero lo recordé recién hablando con otro amigo, <a href="https://twitter.com/grubhart">Edson Chávez</a>, de Kleer Perú, donde estoy en este momento.</p>
<p>Así que aquí va mi elucubración de esa vez, que no sufrió mucho cambios en el ínterin. Sólo aclararía que no es una categorización exhaustiva, sino un recorrido posible, que espero que le sirva a alguien para formular sus planes al respecto.</p>
<p>Aquí el texto original:</p>
<blockquote>
<p>Mi recomendación es empezar por el build server, e ir evolucionando. Por ejemplo:</p>
<p><strong>Cinturón blanco:<br /></strong>- instalás Team City (o Jenkins, o el que te guste -salvo TFS que yo no recomendaría).<br />- empezás haciendo que cada equipo aprenda a configurar su proyecto (es importante que sepan hacerlo ellos)<br />- lo básico es que en cada commit el proyecto compile, por lo menos<br />- que se acostumbren a no tener el proyecto en rojo NUNCA. Si queda en rojo, arreglarlo antes de seguir con nada.</p>
<p><strong>Cinturón amarillo:<br /></strong>- pueden empezar a hacer tests (si no los hacen) y correrlos en el build en cada commit.<br />- de nuevo: nunca dejarlo en rojo, y aprovechar los arreglos para entender más lo que los demás están haciendo y nivelar la calidad de las pruebas.</p>
<p><strong>Cinturón naranja:<br /></strong>- empezar a hacer TDD y ATDD, y elevar el número de pruebas<br />- seleccionar alguna manera de medir code coverage y hacer que el build falle si ni se alcanza el 1% (pruebas mínimas)<br />- cada tanto medir el coverage promedio de la solución e ir subiendo el límite casi hasta ahí (incrementalmente)<br />- cada vez que se reporta un incidente o bug (en testing o producción), no puede arreglarse si no se escribe la prueba primero que demuestra el problema, y se da por resuelto una vez que se corrige la aplicación para que pase ese test</p>
<p><strong>Cinturón verde:<br /></strong>- empezar a ejecutar analizadores estáticos, y que el build server muestre el informe.<br />- concentrarse en los problemas más importantes; cuando ya no existen en la solución, hacer que rompan el build<br />- seguir con el problema más importante, y así sucesivamente; alcanza con eliminar un tema o dos por sprint</p>
<p><strong>Cinturón azul:<br /></strong>- empezar a versionar junto al código migraciones de bases de datos, configuraciones y scripts de instalación de componentes o librerías<br />- hacer que si el build server compiló con éxito y ejecutó todas las pruebas y validaciones, genere desde cero un entorno nuevo de testing</p>
<p><strong>Cinturón marrón:<br /></strong>- trabajar en conjunto con el equipo responsable de despliegue para que valide y adopte los scripts y métodos de generación de ambientes<br />- lograr que el build server genere en cada commit un ambiente de prueba desde cero, y otro incremental<br />- lograr que si se detecta un problema en el ambiente incremental, se pueda volver a la versión anterior de la aplicación con el script de reversión</p>
<p><strong>Cinturón negro:<br /></strong>- cada vez que un desarrollador hace un commit que pasa todo el pipeline de pruebas y validaciones en csda uno de los ambientes de prueba, potencialmente puede llegar a producción de manera automática, aunque se opte por decidir manualmente el momento de despliegue<br />- trabajar en el diseño de la solución para que soporte el desplliegue sin interrupciones de servicio (hot deploy)</p>
<p><strong>Cinturón rojo:<br /></strong>- cada vez que un desarrollador hace un commit, llega a producción sin interrupción de servicio</p>
<p> </p>
<p>Cada uno de esos saltos puede llevar de <strong>1 a 9 meses</strong>, dependiendo del equipo, el proyecto, y de dónde arrancar en cada parte, pero creo que te das una idea. :)</p>
</blockquote>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-21576354992861108602015-07-06T19:45:00.001-03:002015-07-06T19:45:02.764-03:00Untrusted: como perder una noche de sueño<p>Como a todo nerd, me pierden los desafíos de código. :)</p>
<p>Ya perturbé la salud mental de algunas amigas y amigos con Ruby Warrior, pero los amigos de <a href="http://devchat.tv/js-jabber">JavaScript Jabber</a> (un podcast sobre JS muy recomendable) me enviciaron con <a href="http://alexnisnevich.github.io/untrusted/">Untrusted</a>, un juego para ir resolviendo pistas en JS, que además tiene un atractivo adicional y es que cada nivel tiene una musiquita sintética muy pegadiza.</p>
<p>Como suele ocurrir en estos casos, Untrusted tiene una pantalla dividida, en este caso con "el juego" a la izquierda, donde tenemos que buscar una salida, y el código a la derecha (el verdadero juego) donde tenemos que ir tocando el código en JS que arma ese nivel para poder superarlo. Lo divertido es que las soluciones son triviales en cuanto a código, pero exigen pensar como <em>hackear</em> la construcción del nivel para poder escaparse.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="untrusted.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNrANz-znkiqODjIKNON2pgpwr9G1Ye29mxss8m5Og5aae_ktLpm1vO2_B8e7iSuG3z0pVY68Lwiw4746ibhycPuVnZa0YB4for7bhrVvjZIDVdV8Cy-IYoOKpKxL7JM0f-YF5ICly2Zg/?imgmax=800" alt="Pantalla de Untrusted" width="600" height="270" border="0" /></p>
<p>Si pierden muchas horas de sueño, ¡no digan que no les avisé!</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-21579519784123418012015-05-19T12:37:00.001-03:002015-05-19T12:37:47.262-03:00Story Mapping en acción<p>En el <a href="http://www.codeandbeyond.org/2015/05/story-mapping-de-la-incepcion-hacia-el.html">artículo anterior</a> hablamos del objetivo general del Story Mapping, cómo realizar la convocatoria y otras características generales. Como prometí, esta vez voy a entrar en mayor detalle en la mecánica de la construcción.</p>
<blockquote>
<p><strong>Aviso</strong>: después de facilitar muchos talleres con esta actividad uno desarrolla ideas y tácticas propias, así que es importante destacar que voy a describir la manera en que <strong>yo veo</strong> el Story Mapping, que puede no coincidir con la de otros. La mayor parte está tomada de Jeff Patton, pero hay agregados personales que surgen de mi aprendizaje continuo practicando esto, sobre todo en América Latina, que puede cambiar el contexto cultural.</p>
</blockquote>
<h2>Cúentame tu vida</h2>
<p>El primer paso de esta actividad es charlar sobre el problema que queremos resolver, pidiendo a los involucrados que cuenten la historia detrás. Usualmente dejo que esta parte sea bastante libre, y a medida que ellos cuentan los detalles, voy anotando en papeles algunos detalles como personajes, acciones, lugares, etc.</p>
<p>Voy a dejar para más adelante el tema de personajes y técnicas específicas para usarlos en el contexto del diseño del producto, y por ahora vamos a concentrarnos en la historia de alto nivel. Como ejemplo, vamos a tomar el clásico sistema de ventas, porque creo que es algo bastante común para todos los que desarrollamos software, y aunque puede haber algunas diferencias menores entre países, es un dominio relativamente conocido y sencillo de entender.</p>
<p>Supongamos entonces que de la narración de los involucrados sobre cómo es el proceso, aprendemos que: "<em>hay un cliente que llega y realiza un pedido, para lo que hay que buscar los productos en el depósito y preparar la entrega mientras se le realiza una factura, que debe pagar.</em>"</p>
<p>Podemos preguntar algunos detalles más, y finalmente aislamos ciertas actividades principales a partir de esa historia, y algunos detalles para cada una. No voy a entrar mucho en los detalles del ejemplo, que están elegidos para dar una idea del flujo. Podríamos terminar con una serie de actividades de primer orden y un segundo nivel de actividades como el que se ve aquí:</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="Actividades.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4Ty3j61lTKV75MSXoD9eKYrhdi-TAYJH-JsucUJ0JTDQMW0vPdfAKH7RvyXNXrRBEoeOhuoaVup3tl9Db2T6Ih3Q6g0amus0TYwkeyNT_3xfolXVPsz0qvGbnn3Bfz2RSh0J4lro4NQw/?imgmax=800" alt="Actividades principales" width="601" height="124" border="0" /></p>
<p>Algo que tratamos de mantener es que leyendo las notas de más arriba y agregando algunos conectores en el medio, podemos reconstruir la historia original: "llega un pedido, se busca en el inventario, se factura y luego se cobra".</p>
<p>La segunda línea agrega algunos detalles o partes de cada actividad principal. El Pedido, por ejemplo, tiene productos y condiciones, el Inventario requiere chequear si hay suficiente para un pedido, entregarlo, en algún punto requerirá reposición, etc.</p>
<h2>El demonio está en los detalles</h2>
<p>A partir de este "espinazo", podemos empezar a entrar en los detalles de cada una de esas secciones, hacia abajo, para entender el panorama completo. Eventualmente podemos llegar a algo como:</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="Detalles.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMr_EmnRzw7G-l_YvsvQHaGVSHrjmfuPWa3qn6PNYKLAKocnzJ3knv437vLb0mcpqIFvP1QGPKCX1MKb-J3LWjqGUmxiRzrV-O_zu2Qz7tg-cnKIZgeReP2lRZvkA4Eo0cvhCcK7vINek/?imgmax=800" alt="Detalles de la historia" width="601" height="493" border="0" /></p>
<p>Como se ve, en un primer nivel tratamos de cubrir todas las características que creemos necesarias, sin importar todavía el orden o valor de cada una.</p>
<h2>Entregas y esqueletos caminando</h2>
<p>El siguiente paso es -ahora si- comenzar a priorizar. Lo que vamos a tratar de hacer es ver qué es lo imprescindible de cada columna para una primer entrega que sea valiosa, desde el punto de vista de habilitarnos a usar la solución y obtener algún resultado. Es probable que podamos incluso saltear alguna columnas para la primer entrega.</p>
<p>Y como un valor que buscamos siempre con estas técnicas es maximizar el aprendizaje, usualmente buscamos una entrega anterior a la primera "oficial", de carácter interno, que solemos llamar Walking Skeleton (esqueleto caminante), y que debería permitirnos verificar que cumplimos el circuito que queremos recorrer (la solución ya camina) aunque todavía no podríamos exponerlo al público (le falta carne).</p>
<p>Una vez que encontramos ese esqueleto posible, podemos avanzar, agregando lo mínimo indispensable para llegar a la primer entrega que haríamos a nuestro público. Obviamente, esto asume que cuando construyamos realmente el Walking Skeleton lo que aprendamos no nos haga replantear toda la situación. Si es de esperar que comprendamos mejor y tengamos que hacer algunos retoques a nuestro plan.</p>
<p>En la figura se ve un posible Walking Skeleton y una primer entrega (R1 o release 1):</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="WS-R1.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMG-KGd1ZVjz79eifG2G5mxwus17TE41LznoFcXvRq7-QoKswpFW3mDy8b9gS5SG8DA2HbYQm5nbZkhVsFuJb3AqP5D4xKT_iQ9E1746pItde-es0jmkz1cPu7p-pWp_QAsTNqxPORbX4/?imgmax=800" alt="Walking Skeleton y R1" width="601" height="299" border="0" /></p>
<p>Por supuesto podríamos discutir si en este ejemplo las características elegidas alcanzan o no, pero supongamos que entre todos los involucrados en el ejercicio de Story Mapping (responsables del negocio, roles operativos, gente de tecnología, procesos, etc) nos hemos puesto de acuerdo en que el esqueleto es suficiente para aprender lo que necesitamos y probar el circuito completo, y que agregando lo mínimo podemos tener una primer versión valiosa, que en este caso nos permitirá tomar pedidos para entregar en el momento, facturarlos y cobrar en efectivo y cheque (que por alguna razón es necesario para arrancar).</p>
<p>Como vemos, esta primer entrega es muchísimo más pequeña que lo el alcance total que imaginábamos, pero mediante este ejercicio encontramos qué es lo mínimo que nos permitirá empezar a usar la solución tempranamente, en una fracción de lo que involucraría construir toda la funcionalidad imaginada.</p>
<p>Este es un tema clave en el desarrollo ágil, y como vemos, el Story Map nos permite tener una visión global, para que el foco de corto plazo en el backlog de producto no nos haga perder de vista el objetivo final.</p>
<p>En uno o dos artículos más voy a profundizar en alternativas, el uso del Story Map a lo largo del proyecto y algunos consejos a la hora de facilitar la actividad. Por supuesto, si tienen consultas o comentarios, pueden avisarme a través de <a href="https://twitter.com/martinsalias">Twitter</a>, idealmente con el hashtag #StoryMap. Nos vemos.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-46444876652777816882015-05-05T09:57:00.001-03:002015-06-26T12:04:45.294-03:00Story Mapping: de la Incepción hacia el Backlog de Producto<p><a href="http://www.amazon.com/gp/product/1491904909/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1491904909&linkCode=as2&tag=martinsalias-20&linkId=GKY5V3TRCTOWZAIT"><img style="float: right;" title="" src="http://ecx.images-amazon.com/images/I/512lpmXOSZL._AA160_.jpg" alt="" width="" height="" border="0" /></a></p>
<p>Tiempo atrás publiqué una serie de artículos sobre la práctica de <a href="http://www.codeandbeyond.org/2014/11/incepcion-agil-los-backlogs-los-trae-la.html">Incepción Ágil</a> que tuvieron bastante éxito y generaron varios comentarios y preguntas, entre otras, acerca de otra práctica relacionada, que a veces algunos incluyen como parte de la Incepción: <strong>User</strong> <strong>Story Mapping</strong>.</p>
<p>Esta técnica para analizar un proyecto (completo o un sub-proyecto) fue nombrada y documentada originalmente por <a href="https://twitter.com/jeffpatton">Jeff Patton</a>, primero en <a href="http://www.agileproductdesign.com/blog/the_new_backlog.html">un artículo de su blog</a>, y posteriormente en su libro "<a href="http://www.amazon.com/gp/product/1491904909/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1491904909&linkCode=as2&tag=martinsalias-20&linkId=GKY5V3TRCTOWZAIT">User Story Mapping</a>" (pueden ver la tapa a la derecha), ambos inmensamente recomendables.</p>
<p>Conocí los detalles de esta práctica por primera vez alrededor de 2008 o 2009, y comencé a usarla en algunos proyectos míos o de organizaciones a las que estaba ayudando, y después de usarla al menos una docena de veces, comprendí mejor cómo aprovecharla y cómo facilitar su construcción, y se convirtió en una pieza clave para mi en el inicio de proyectos ágiles.</p>
<p>Lo que quiero hacer en este artículo es recorrer qué es un Story Map, cómo se genera, cómo se usa posteriormente y cuáles son sus beneficios. En algunos posteriores entraré en detalle sobre la mecánica de la reunión, las alternativas y conceptos subyacentes.</p>
<h2>¿Cómo y cuándo?</h2>
<p><img style="float: right;" title="story-mapping.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk9tm3j5M6MEeF16KN52FiHBD23qT8aXA5SRfo_h21Zoh0EMecjdtV37vxE5GjC4tIoXbPETm9UIjrvS0LZdgXjwDpuLwaIzX10iM2p85_lBvYlgEUUlq1FWdk8MkHbfthd1DoCmXzOC4/?imgmax=800" alt="Trabajando en conjunto" width="149" height="132" border="0" /></p>
<p>Como en el caso de la <strong>Incepción Ágil</strong>, el <em><strong>Story Mapping</strong></em> se realiza al inicio de un proyecto, o una nueva fase, típicamente en formato taller. Algunas veces se realiza como parte final de la <strong>Incepción</strong>, aunque para mi es bueno entenderlo como momentos diferentes.</p>
<p>La <strong>Incepción</strong> trata de poner el foco en asegurar que todos los involucrados acuerdan un objetivo común, ciertas características y restricciones del producto, y deciden en conjunto <strong>qué</strong> van a construir.</p>
<p><em><strong>Story Mapping</strong></em> es una actividad que nos permite entrar en detalle estratégico sobre cómo construirlo, entender qué es lo fundamental, poner foco en la entrega temprana y entender cómo ir incrementando el valor frecuentemente.</p>
<p>Lo que tienen en común ambas prácticas, que para mi son complementarias, es el tipo de convocatoria: en ambos casos queremos contar durante toda la actividad con gente de negocios a nivel directivo y a nivel operativo, operaciones, procesos, infraestructura, desarrollo, seguridad, etc. Queremos tener representados a la mayor cantidad posible de sectores involucrados en el proyecto del que vamos a hablar, para tener una perspectiva amplia.</p>
<p>También, como en el caso de la <strong>Incepción</strong>, más allá del entregable (el <em>Story Map</em>) lo más valioso son las conversaciones durante el ejercicio. No deja de sorprenderme al facilitar encuentros de este tipo en diferentes organizaciones (desde micro-emprendimientos hasta corporaciones) cómo surgen discusiones que nunca se habían tocado antes a pesar de estar trabajando en el tema en cuestión durante muchísimo tiempo.</p>
<p>Dependiendo de la complejidad y la importancia del proyecto, la actividad puede durar desde 2 o 3 horas, hasta un día completo. En proyectos críticos he facilitado frecuentemente un día completo de <strong>Incepción</strong> y otro día completo de <strong><em>Story Mapping</em></strong>.</p>
<p>Entre uno y otro puede pasar un tiempo, porque a veces la Incepción sirve para confirmar qué tipo de proyecto tenemos que realizar (cuanto más temprano la hagamos, mejor, porque tenemos menos cosas decididas de antemano), y podemos tomarnos un tiempo para tener identificado al equipo de trabajo y saber quiénes deberían estar presentes para construir el <em><strong>Story Map</strong></em>.</p>
<p> </p>
<h2>¿Qué queremos lograr?</h2>
<p>En los próximos artículos voy a entrar en detalles, pero para cerrar éste, quiero mostrar el resultado final y explicar cuál es la expectativa.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto;" title="story-map.jpg" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjakaVWViRPrYwz4QIph-FyATBLgMut7JR6h4OTW786RbmLunFT8XvoSxTwuliIS-8_BlK03EwSqL9AoWS7wh0vnDUtkX-o4zcGLWPkLpHmm7tkucnpfURoXpO5ETwWM4-HO52NXB0aaMk/?imgmax=800" alt="Story Map final" width="600" height="261" border="0" /></p>
<p> </p>
<p>La imagen muestra un mapa de un proyecto real. La imagen no tiene nitidez suficiente para leer lo que está escrito en las notas, que es algo específico y particular de este proyecto, pero que no importa para explicar el resultado.</p>
<p>Lo que se ve en la primer fila, en las notas celestes, como cabeceras de cada columna, son las <strong>Actividades Principales</strong> del proyecto, en el orden en que fluyen en "la historia" contada por los diferentes participantes de la actividad. Hacia abajo de cada <strong>Actividad</strong> hay <strong>Detalles</strong> sobre cómo se realiza esa actividad, en muchos casos como alternativas o pasos que pueden ser o no opcionales.</p>
<p>Las líneas azules que cortan transversalmente el mapa (en dos tajadas finas, inicialmente) son las <strong>Entregas</strong> planificadas, cada una con el mínimo de funcionalidad necesaria para cumplir con el propósito de la solución. Como puede notarse, esas dos primeras entregas son muy pequeñas respecto al total del alcance esperado (el conjunto total de notas debajo de los encabezados celestes). Sin embargo, las dos entregas planificadas concentran el más alto valor de negocio, porque destraban problemas importantes y habilitan nuevas posibilidades. Esto suele suceder en casi todos los proyectos, siguiendo la <a href="http://es.wikipedia.org/wiki/Principio_de_Pareto">ley de Pareto</a>: aproximadamente el 20% del alcance da el 80% del valor de negocio de un proyecto.</p>
<p>Utilizando esta práctica, que detallaré más en los próximos artículos, podemos buscar ese mítico 20% y tratar de concentrarnos en tener el más alto valor rápidamente, que además nos permitirá tener un producto real funcionando y poder aprender de la experiencia concreta antes de seguir agregando funcionalidad en abstracto.</p>
<p>Actualización: podés encontrar el siguiente artículo de esta serie <a href="http://www.codeandbeyond.org/2015/05/story-mapping-en-accion.html">aquí</a>.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-49729965431859264262014-12-11T12:50:00.001-03:002014-12-11T12:50:28.483-03:00hack.summit() -> code(4).all<p><img style="float: right;" title="hack-summit.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWiBxhpl9Ytk5rM0IOGKXNojofyGFIKXC5WkIFR9wY8NxeLvfhEDWBMsEYdXIDW6w6jU0oEDAOG2gi-FhFswiNdwsNbb1MZ2k6sffJMc43KPspLJkoN-aTMqTFfiAe69m2r50JcYYPjrU/?imgmax=800" alt="hack.summit()" width="271" height="176" border="0" /></p>
<p>Este <a href="https://hacksummit.org/">evento virtual</a> es imperdible para cualquier nerd que se precie de tal.</p>
<p>Fue una conferencia totalmente en línea con celebridades del ambiente del desarrollo y alrededores, y todas las sesiones están grabadas para verlas cuando uno quiera.</p>
<p>Algunas de la personalidades que me resultan más interesantes (a mi) son:</p>
<ul>
<li>Kent Beck, el papá de XP y TDD</li>
<li>Ward Cunningham, corresponsable de XP e inventor de la Wiki</li>
<li>Rebecca Parssons, CTO de Thoughtworks</li>
<li>Scott Hanselman, dando pelea desde dentro de Microsoft</li>
<li>Bram Cohen, inventor de BitTorrent</li>
<li>Gilad Bracha, co-autor de la spec de Java y creador de Newspeak</li>
<li>Scott Chacon, CIO de Github</li>
<li>Tim O'Reilly, de O'Reilly Media</li>
<li>Orion Henry, fundador de Heroku</li>
</ul>
<p>y unos cuantos más.</p>
<p>Espero que lo disfruten.</p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-87206642726334667242014-12-08T12:23:00.001-03:002015-06-23T19:15:03.814-03:00Incepción Ágil: la pregunta del millón<p><img style="float: right;" title="Cost.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOg-NGxb2mAjjf0xcKcRTsPN07b3keN84zum_Y_KjHqp_pwJvqqPvF0pDdXjGZq_8krS2oLypghUKPRJggrDw8uF6dvVKwVJjT5oLsKgBC_bnVUvhdguD7ybrmCOotwBiaD3FUspXuvdY/?imgmax=800" alt="¿Cuánto cuesta?" width="250" height="250" border="0" /></p>
<p>¡Llegamos a la última actividad de la Incepción!</p>
<p>¿Parece largo? En realidad muchas de las actividades pueden regularse para que avancen rápido ó podemos llegar a saltear algunas si tenemos menos tiempo. Eso es parte de la decisión del facilitador. Mi recomendación es tratar de recorrer las 10 actividades, aunque sea dedicándole 20 a 30 minutos en promedio a cada una, para que entre en una mañana o una tarde.</p>
<p>En la última actividad vamos a tratar de tener una estimación de MUY alto nivel sobre el costo del proyecto. Casi nunca llegamos a un número, sino a un nivel de inversión, como para responder dudas como (dependiendo del tipo de proyecto y organización):</p>
<ul>
<li>¿Podemos encarar esto con el presupuesto que ya teníamos?</li>
<li>¿Necesitamos conseguir un inversor?</li>
<li>¿Qué chances hay de que el proyecto se auto-financie a partir de X entrega?</li>
<li>¿Hace falta conseguir aprobación presupuestaria del Gerente del Área? ¿Del Directorio?</li>
</ul>
<p>Para poder llegar a alguna conclusión de ese tipo, lo que hacemos en grupos es una "lista de compras", en la que incluimos todos los costos importantes que pueden incidir, como:</p>
<ul>
<li>Costo del equipo (si son internos y tenemos que costearlos, o si debemos contratar)</li>
<li>Equipamiento, espacio físico, licencias de software, suscripciones</li>
<li>Homologaciones, certificación o auditorías necesarias</li>
<li>Espacio físico o instalaciones necesarias durante el proyecto</li>
</ul>
<p>Nuevamente, cada grupo presenta su lista, y se discute en conjunto hasta lograr una versión unificada. No es importante ponerle valores, más allá de una estimación muy gruesa para llegar a entender el nivel de presupuesto, pero esa lista será el punto de partida para empezar a elaborar el presupuesto definitivo cuando el proyecto arranque realmente.</p>
<p>Y con eso finalizamos el proceso de la Incepción. Dejo una foto de otro taller. </p>
<p><img title="InceptionSV.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSKJ95gd0WCInPBpc-67U_AKlXw7nkqTkCgoBX13dyCz3Zp69MEPkR3GJNXGat0f4UV7KrQ6sEsLvJqHvDZ17ubCcwAp4kTMLvsm3UCiXXIgUx6re3qSgg2oarFnPwcnoyOnXmpUEObs8/?imgmax=800" alt="Inception en un Taller" width="600" height="385" border="0" /></p>
<p><iframe src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/209129478&color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false" width="100%" height="166" scrolling="no" frameborder="no"></iframe></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-60879105179647217022014-12-06T15:21:00.001-03:002015-06-23T19:14:29.971-03:00Incepción Ágil: hablemos de prioridades<p><img style="float: right;" title="Trade-Off.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWiAHk5SBSh0q6qIBnNZycBK3AI7rDFNOJN6rETrLJlwjiIcehuXnhewz9q3xsUkfVakJSte4nrmSiP5if1eBcF7qIWH2sy6xJIfYvgO8ZHQOMdwp5ZkfJoJjJMmJyAfnvwpKKUUN0c6k/?imgmax=800" alt="Balance de Prioridades" width="249" height="250" border="0" /></p>
<p>Como mencionamos antes, sabemos que nuestra Incepción va a darnos una idea general, pero que el proyecto va a ir mutando y adaptándose en el tiempo para lograr el mejor resultado posible.</p>
<p>Si embargo, podemos tratar de seleccionar algunas restricciones tempranas que nos ayuden a pensar si los cambios o novedades que aparezcan nos están alejando o no de la idea inicial. Y podremos en ese momento decidir que no es un problema, o incluso re-evaluar estas prioridades, pero lo bueno es tener más elementos para evaluar esas decisiones.</p>
<p>Para esta actividad los equipos se dividen en grupos nuevamente y piensan en una lista de requisitos no-funcionales o preocupaciones transversales al proyecto, como por ejemplo:</p>
<ul>
<li>Costo de operación del producto final</li>
<li>Mantenibilidad</li>
<li>Time-to-market (cuanto antes tengamos algo, mejor)</li>
<li>Interoperabilidad</li>
<li>Equipo propio (o local)</li>
<li>Seguridad o Confidencialidad</li>
<li>Tiempo de respuesta</li>
<li>Cumplimiento de regulaciones</li>
<li>Cobertura desde múltiples dispositivos</li>
</ul>
<p>...o muchos otros, desde características de calidad, temas de mercado, cuestiones internas o lo que nos preocupe.</p>
<p>Lo importante es que cada grupo quede con los 5 a 10 temas que les parecen más importantes tener en cuenta.</p>
<p>El siguiente paso es priorizarlos. Para eso prefiero una variante que aprendí de <a href="twitter.com/acyment">Alan</a> y <a href="twitter.com/berariel">Ariel</a>, que es seleccionar entre todos los que queremos priorizar, y a continuación elegir un participante por cada uno de los atributos a priorizar, que se pone de pie con una hoja de papel en la mano con el nombre de ese atributo. Esas personas se ponen en fila, y el resto, mirándolos de lado, de manera de verlos a todos, va intercalando con ellos, haciendo que se muevan hacia adelante o atrás en la fila, hasta que llegamos a un acuerdo.</p>
<p>Idealmente, al llegar al orden final, tomamos una foto de todos sosteniendo su cartel bien visible.</p>
<p>Esta actividad es más divertida con ese componente físico, y tiene también el valor testimonial de la foto con mucha gente involucrada, que perdura y queda para el equipo de proyecto. Muchas veces al ver las personas que participaron en esa priorización el mensaje es reforzado.</p>
<p>Insisto: esas prioridades no son inamovibles, pero tenerlas como filtro nos permite tener las discusiones necesarias a tiempo, y nos da contexto.</p>
<p><iframe src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/209129354&color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false" width="100%" height="166" scrolling="no" frameborder="no"></iframe></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-74707206754253435232014-12-05T08:55:00.001-03:002015-06-23T19:13:48.924-03:00Incepción Ágil: estimación global<p><img style="float: right;" title="Tamagno.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiarRdOSgIwIi1dxCton1mv_uOMp0iY0LETCmRWzxTvgc1Uru19jQEyO-zukqIHSlV0q0rF4eogellOuBH-iEXlxzxumJhzoB8WRRnKe8DCjTs9HBx61gRzdz5q3NH6-Vez2Vg-nZVU0Sg/?imgmax=800" alt="Tamaño" width="249" height="250" border="0" /></p>
<p>Ahora que ya tenemos una idea general del alcance, el tipo de solución a construir, y los riesgos principales que anticipamos, podemos empezar a pensar qué tan grande será el proyecto.</p>
<p>Nuevamente dividimos equipos (recordemos que lo ideal es combinar gente diferente a lo largo de la Incepción) y cada grupo hace una estimación de alto nivel, teniendo en cuenta:</p>
<ul>
<li>¿Cuánta gente necesitamos en el equipo? ¿Cómo debería estar compuesto?</li>
<li>Si vamos a ejecutar con Scrum, podemos pensar quienes serían el Scrum Master y el Product Owner</li>
<li>Dado ese equipo que imaginamos ¿Cuánto tiempo duraría el proyecto?</li>
</ul>
<blockquote>
<p>Aquí cabe una aclaración: el equipo final <strong>deberá revisar</strong> la estimación, pero como estamos pensando un proyecto ágil, lo importante es que sabemos que en el tiempo que pensemos no esperamos resolver necesariamente todo el alcance, si no lo más valioso del alcance, por lo que aceptamos que no sabemos el detalle total. Es importante que todos los participantes comprendan que <strong>no están tomando una decisión, </strong>sino realizando un ejercicio para analizar lo que el proyecto implica. </p>
</blockquote>
<ul>
<li>Podemos pensar alternativas de equipos y fases, e incluso alternativas de solución, para diferentes extensiones de proyecto.</li>
</ul>
<p>Al finalizar, y una vez que cada grupo expuso su estimación, se discuten y seleccionan las mejores alternativas, para usarlas como referencia, y probablemente tomemos un márgen de unas a otras.</p>
<p>El objetivo que buscamos es tener un rango general:</p>
<ul>
<li>¿será un solo equipo de 5~6 personas?</li>
<li>¿serán 4 equipos de 8~9?</li>
<li>¿podemos tener resultados en 6 semanas, 6 meses, 2 años?</li>
<li>¿tenemos una idea al menos general de qué es lo más valioso resolver en cada etapa?</li>
</ul>
<p>Aunque suene insistente, esto nos sirve para discutir si el proyecto es viable o no según estos parámetros, y eventualmente revisar algunos de los ejercicios anteriores. Como esto es una Incepción <strong>Ágil</strong>, sabemos que todo va a tener variaciones cuando el proyecto comience, y sobre todo cuando se entreguen los primeros resultados y el proceso de aprendizaje se potencie.</p>
<p><iframe src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/209129757&color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false" width="100%" height="166" scrolling="no" frameborder="no"></iframe></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0tag:blogger.com,1999:blog-2916789684329018597.post-12794237088312445302014-12-04T07:23:00.001-03:002015-06-23T19:13:12.589-03:00Incepción Ágil: manejo de riesgos<p><img style="float: right;" title="Miedos.png" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiF9Y0Q_nlHvtsoGcKkV5WJx08zr6WFFNqvvXdWkFQ1-zzWXYHZ_hdbXuo-GtonN5c8x97h_ePHcrQwR6sLsT-kL3WWrjYCQpFNyCkuA3QtEz0QAZ5aQb6gLd6UFn1eSlxNvE2DoRHMBsM/?imgmax=800" alt="Los Miedos" width="249" height="250" border="0" /></p>
<p>Llegamos a la actividad de la Incepción donde nos dividimos en grupos y nos ponemos todos el sombrero negro, pensando en todo lo que puede salir mal.</p>
<p>Trataremos de discutir todo lo que potencialmente podría quitarnos el sueño durante el proyecto, desde todos los puntos de vista. La gente de tecnología aportará riesgos de conocimiento del equipo, de complejidad tecnológica, de requisitos difíciles por distintos temas; la gente de seguridad pensará en las vulnerabilidades, potenciales brechas, criticidad de datos; la gente de negocio analizará costos, oportunidades, dependencias con otras áreas, necesidad de flexibilidad; y así diferentes actores expondrán miedos respecto al inicio, desarrollo, puesta en marcha, ejecución, mantenimiento y evolución del proyecto.</p>
<p>Al finalizar, cada grupo comparte los resultados y volvemos a tener una discusión abierta en la que tratamos de consensuar cuáles son los principales problema potenciales, y anotamos algunas de las medidas con las que podríamos mitigarlos.</p>
<p> </p>
<p><iframe src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/209113239&color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false" width="100%" height="166" scrolling="no" frameborder="no"></iframe></p>Martin Saliashttp://www.blogger.com/profile/18122086046496078782noreply@blogger.com0