DEV Community: Othoniel Cazares

Fallemos ágilmente

Othoniel Cazares — Mon, 31 May 2021 20:10:48 +0000

Todos en algún momento de nuestra vida ciertamente para algunos más recurrente que otros, pero todos hemos sentido el temor a la incertidumbre de lo que va a pasar en alguna situación dada, ya sea hablar con esa persona que te encanta, realizar una presentación en público o pedir ese asenso que tanto deseamos. A todos nos aterra dar un paso en la incertidumbre eso es normal como seres humanos desconfiamos de lo desconocido, esto se remonta a nuestros inicios como sociedad cuando evitábamos alejarnos de nuestra cueva hacia la oscuridad o que nuestra tribu nos exiliara y con justa razón en aquellos tiempos eso era sinónimo de una muerte segura y aun cuando la sociedad evoluciono y creo tecnología para evitar estos miedos primarios nuestro subconsciente todavía tiene arraigado este tipo de miedo a la incertidumbre y en los negocios no es diferente, los riesgos son altos pero ninguno de ellos están relacionados con una muerte segura y en el mundo de la agilidad si bien no queda exento de dudas, la agilidad trata de ver la incertidumbre de otra perspectiva.

A lo largo de mi carrera debo confesar que en muchas ocasiones evite las incertidumbres y como no, si cuando uno tiene la certeza las decisiones son mas llevaderas, pero si lo vemos desde el punto de vista ágil algo que aprendí a lo largo de mi trayectoria profesional y aplicado también a mi vida personal es fallar, sí fallar es una opción pero no me mal interpreten para crecer es necesario recorrer caminos complicados pero fallar sin sentido no es lo que buscamos, lo que buscamos en esta situación es fallar y fallar rápido para aprender y retomar el sendero del éxito o mejora. Por eso cuando inicias un proyecto incierto ya sea por la complejidad o con un equipo nuevo o con integrantes poco experimentados las iteraciones de la agilidad serán tu mejor aliado tomando siempre en cuenta de que debemos aprender y mejorar continuamente ante cualquier adversidad.

Imagínemos hipotéticamente por un segundo que ningún proyecto se llevara a cabo ya que evaluamos el riesgo y decidimos no realizarlo por que existe miedo a fallar o tenemos incertidumbre de lograrlo, realmente no existiéramos como sociedad ya que toda la humanidad esta llena de proyectos que han derivado en lo que somos ahora. Es cierto que hemos desarrollado técnicas para controlar riesgos que nos dan certeza para tomar decisiones o precisión para lograr grandes objetivos, pero sin duda debemos entender que riesgos siempre existirán y debemos si bien evitarlos o mitigarlos, pero si suceden debemos enfrentarlos y aprender de ellos por eso fallar es una opción y así el aprendizaje será garantizado.

Existe una frase de Henry Miller que dice “Todo crecimiento es un salto en la oscuridad, un acto espontaneo y no premeditado sin el beneficio de la experiencia”. Este es el riesgo que como profesionales en cualquier momento deberemos de tomar, lo ideal es estar preparados en todos los entornos para lograr nuestros objetivos y creo que debe prevalecer la máxima que dice la “La victoria favorece a los que se preparan” pero no dejemos de lado que cuando se nos presenten adversidades fallemos rápido, aprendamos y crezcamos como profesionales, equipo o individuos.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

Definición de listo y terminado (DoR y DoD)

Othoniel Cazares — Wed, 12 May 2021 13:36:05 +0000

A lo largo de nuestro viaje en el agilismo nos encontraremos con estos dos conceptos que pueden ser una guía que permita iniciar y medir el progreso, sin embargo, hay situaciones que pueden llevarnos a no practicar el agilismo si no tenemos cuidado con estas definiciones.

DoR (Definition of Ready)

DoR o Definición de Listo son los requisitos necesarios para poder escoger una historia de usuario para un determinado sprint, esta práctica se lleva a cabo en el refinamiento del producto backlog y ayuda al equipo en la decisión de que puede ser parte del sprint y que no. Pero también la definición de listo puede ser un precursor para dejar de ser agiles, esto es debido a que podemos utilizar la definición de listo como un requisito primordial para incluirlo en el sprint si este requisito es otra historia de usuario y esta debe ser culminada antes de iniciar otra y continuar con esta práctica regularmente podríamos estar practicando cascada en vez de agile.

La definición de listo será relativa a las necesidades de la empresa o la forma en que se trabaja ya que depende de las necesidades del flujo de trabajo en ocasiones las definiciones de listo podrán ser relativamente sencillas como un prototipo para algunos casos como realmente complejas para casos en los que se requieran cumplir con requisitos necesarios como los gubernamentales o legales según sea el caso específico.

DoD (Definition of Done)

DoD o la definición de terminado son los criterios formales que una historia de usuario deberá cumplir para que se determine que ha sido concluida, estas definiciones proporcionan transparencia al equipo a lo largo del flujo de trabajo ya que se conoce en todo momento que es lo que debemos alcanzar con esta tarea.

La definición de terminado debe estar ligada directamente con la calidad del producto de otra forma no estaremos alineados con los objetivos que deseamos lograr, una organización puede o no tener estándares organizacionales referentes a las definiciones de terminado, de contar con estos estándares el equipo deberá cumplir cabalmente con estas definiciones, de no contar con estos estándares el equipo deberá definir sus propias definiciones de terminado las cuales también deberán ser cumplidas con la intención de lograr un incremento que nos acerque historia a historia en cada iteración al objetivo.

Ahora que conocemos un poco más acerca de las definiciones de listo (DoR) y las definiciones de terminado (DoD) debemos tener en mente que estar herramientas nos deben de aportar una guía para concluir nuestras metas sin que estas sean restricciones que nos retrasen en la búsqueda de obtener resultados, debemos ser conscientes que las definiciones de listo nos deben ayudar en la estrategia para abordar el product backlog mas no debe restringir el avanzar ágilmente en el proyecto así como las definiciones de listo deben de aportar la calidad con la que el producto se caracterizará siendo entonces estas dos herramientas fundamentales para generar producto enfocado y altamente fiable.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

Ser Customer Centric

Othoniel Cazares — Wed, 21 Apr 2021 02:38:42 +0000

Lo podemos ver tanto en los pilares del manifiesto ágil donde nos dice “Colaboración con el cliente sobre negociación contractual” así como el primer principio del mismo manifiesto el cual se cita de la siguiente manera “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”, la agilidad tiene en alto aprecio hacia el cliente ya que es él, el único que puede dar pie a que cosas grandiosas sucedan por eso hoy quiero hablar un poco acerca de la agilidad enfocada en el cliente.

No quiere decir que sea una novedad ver la agilidad de esta forma de hecho siempre ha sido el principal objetivo del desarrollo de productos el contar con la aprobación del cliente. Antes de continuar hay que definir los distintos tipos de clientes que podemos tener, por un lado podemos contar con clientes que desean desarrollar su negocio con lo cual para nosotros el éxito de el cliente se traduce en el éxito de nosotros mismos, por otra parte, tenemos a los usuarios que son por así decirlo los clientes finales que de una forma u otra sus decisiones repercuten en el flujo de cualquier proyecto de manera significativa.

Hoy en día vemos más y más la preocupación por las empresas de entender las necesidades de sus clientes a nivel de consumo o servicio y esto no debe ser diferente al momento de crear productos relacionados con el mundo de las tecnologías de información, una vez que contamos con las necesidades del cliente la comunicación con este debe ser constante para recapitular en el trayecto de ser necesario y entregar una ventaja competitiva que se traduce en un beneficio colectivo de la relación que entablamos de cliente y prestador de servicio o producto.

Es por esto que es necesario abrazar las necesidades de nuestros clientes como propias para lograr la sinergia que nos lleve a ambas partes al éxito de lo contrario estaríamos lidiando con un proyecto como si fuera un mal matrimonio en el cual las soluciones no se dan y se crean mas problemáticas que no permitirán avanzar a ninguna de las dos partes y los objetivos quedaran en el olvido, recuerda que todos en algún momento somos clientes y deseamos ser atendidos de forma que podamos cubrir nuestras necesidades por lo tanto la empatía deberá se la primera forma de abordar la relación dando pie a una relación en la cual te será más sencillo aportar valor a las necesidades de tu cliente.

Es importante también mencionar que ser customer centric muchas veces va más allá de solo satisfacer al cliente, ya seas project o product manager, business analyst o product owner es tu obligación encontrar la forma de aportar a la visión del cliente con la cual este pueda alcanzar o preferentemente superar las expectativas siempre con el enfoque de lograr el éxito categórico del cliente.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

¿Eres un superhéroe ágil?

Othoniel Cazares — Sat, 10 Apr 2021 00:49:03 +0000

Se han preguntado como nacen los super héroes, seguramente todos hemos sido fan de algún superhéroe aun hoy en la actualidad este tema es recurrente debido a las entregas de los estudios cinematográficos que han hecho parte de este mundo fantástico aun si no conocías este universo le has dado la oportunidad simplemente por mero entretenimiento.

Como nacen los superhéroes

Sin duda alguna hemos sido testigos de cómo nuestros grandes superhéroes se convirtieron en lo que son, como Bruce Wayne se convirtió en Batman, como fue el origen de Superman, la forma en que Tony Stark se convirtió en Ironman entre muchos otros superhéroes y todos tienen algo en común, todos surgieron de un ambiente caótico o un suceso realmente terrible y es así como en la ficción también en nuestro día a día podemos encontrar héroes y específicamente en nuestro entorno Superhéroes Ágiles.

¿Como creas un Superhéroe Ágil?

Recuerden que podemos entrenar nuestra mente y cuerpo para cualquier situación y el agilismo no es diferente a cualquier otra disciplina, podemos tomar cursos, leer cientos de libros y tomar bastantes certificaciones y entender todo referente al mundo ágil pero de ninguna manera nos hará un superhéroe ágil si no encontramos nuestro origen como la leyenda del agilismo, el génesis de un superhéroe ágil se encuentra en la dificultad que radica cambiar el paradigma tradicional y convertirlo en un entorno propicio para que todas las cualidades de agilismo surjan y es debido a esto que podemos hacer la analogía del superhéroe ya que la experiencia dictara el éxito de tu carrera.

Y es bastante cierto que las historias hacen que se grabe en tu memoria cualquier experiencia, es por eso que el storytelling es tan popular y en el caso del agilismo estamos propensos a aprender por el síndrome postraumático que dejan las problemáticas con las que te enfrentaras en los proyectos que participes porque seamos sinceros los proyectos no son fáciles, podremos tener una formula pero no siempre se aplicará al cien por ciento, deberás hacer ajustes conforme se vayan presentando obstáculos todo esto de la mano de las mejores practicas del agilismo que son el mindset base para afrontar y conquistar esos proyectos complicados.

¿Qué hay de los villanos?

Por otra parte, también existen los villanos del agilísmo, si también existen, son aquellos que no descifran el valor del mindset ágil y en ocasiones implementan marcos de agilidad como si estuvieran implementando waterfall siempre siendo rigurosos con las reglas y no teniendo la flexibilidad a la hora de afrontar problemáticas que salen del guion. En definitiva estos villanos logran incrementar el tiempo del proyecto junto con los costos ocasionando un entorno caótico donde los superhéroes suelen emerger.

En conclusión no basta con conocer de que trata ser ágil ni tampoco tener una docena de certificados de marcos agiles, el agilísimo debe ser una revelación que te lleve a afrontar las problemáticas de la manera que aporte valor en todos los aspectos y eso solo te lo da la experiencia, así que no importa si es un proyecto pequeño o uno inmenso trata de aplicarlo día a día y veras que las problemáticas te darán ese síndrome postraumático que llamo experiencia ágil y que te convertirá en el superhéroe que estas destinado a ser.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

VUCA: ¿Qué es?, cómo nos afecta y cómo aprovecharlo.

Othoniel Cazares — Tue, 23 Mar 2021 04:44:24 +0000

¿Sabes que es un entorno VUCA?

Este termino acuñado por la milicia estadounidense y que ahora se utiliza en el entorno empresarial nos define la nueva situación de las empresas conforme al futuro de las mismas, VUCA son las siglas para Volatility (Volatilidad), Uncertainty (Incertidumbre), Complexity (Complejidad) y Ambiguity (Ambigüedad) y definen los nuevos entornos de negocio que nos proporcionan temas como la globalización y la manera que los mercados se adaptan ella. Como también la forma actual en que se desarrollan los negocios y nos proporciona un panorama incierto en bastantes aspectos para lo que debemos tomar medidas adecuadas para convertir en ventaja competitiva el entorno VUCA al cual no enfrentemos.

V de volatility

La volatilidad refiere a la dinámica cambiante que se encuentra constantemente manifestándose a una velocidad que no permite definir procesos estáticos que solventen soluciones oportunas
De igual forma tiene que ver la economía globalizada y que nos presenta nuevos retos ya que el campo en el que la empresa se desarrollará se vera afectado por el conjunto de acciones que suceden en el entorno global, aunado a la transformación digital que día con día nos aporta más actores en el juego haciendo un mercado competitivo además de altamente volátil.

U de Uncertainty

La incertidumbre se manifiesta como la escasa previsibilidad con la que las empresas pueden enfrentarse a las situaciones que se presentan, ya que las situaciones imprevistas son mas comunes en la actualidad lo que hace complicado elaborar planes estratégicos que nos proporcionen certeza. Hoy en día no se puede utilizar el pasado como referencia para pronosticar el éxito en el futuro por lo que es necesario utilizar nuevas formas para adaptarse a este entorno incierto.

C de complexity

Al encontrarnos con industrias globalizadas cada vez es más complicado encontrar soluciones a las nuevas situaciones que se nos presentan, de la misma manera en que es difícil comprender las relaciones entre los miembros del equipo haciendo compleja la administración interna de las organizaciones. El motivo común es debido a la falta de lideres con las habilidades necesarias para enfrentar las problemáticas que se dan en estos entornos y que faciliten la toma de decisiones que impulsen al equipo en la dirección correcta.

A de Ambiguity

La ambigüedad se presenta por la falta de claridad que nos provocan los factores anteriores, hoy en día cada decisión tiene repercusiones ambiguas y ahora estamos hablando de que dada decisión conlleva una serie de repercusiones desconocidas e incontrolables las cuales deben de ser analizadas a conciencia, de manera oportuna y con una extrema precisión para desarrollar un plan estratégico que solvente a tiempo las repercusiones generadas.

¿Cómo enfrentamos un entorno VUCA sin fallar en el intento?

Lo primero a tomar en cuenta es contar con el liderazgo adecuado para afrontar las diversas situaciones el cual debe de contar con una amplia visión sobre el futuro para afrontar la volatilidad, capacitarse y estar siempre informado para mitigar la incertidumbre, entender que las tareas cortas y sencillas puedan dar claridad ante la complejidad y abrazar la agilidad para poder estar preparado y afrontar con una gran capacidad de reacción los constantes cambios que provocan la ambigüedad, todo esto para poder dar la mayor certidumbre posible.

Como organización no es suficiente con conocer que es un entorno VUCA y que los lideres emerjan con las cualidades antes mencionadas, también deberán tener en cuenta los siguientes puntos clave que sin duda son de gran utilidad para fortalecerse en este entorno:

• Primero que nada, necesitamos tener resiliencia para tener la capacidad de reaccionar a los retos que se nos presentan de forma inesperada.
• Requerimos de una visión de campo generalizada para poder entender todos los procesos.
• Enfrentar la situación con optimismo ya que si bien es un entorno caótico también suelen presentarnos oportunidades únicas.
• No olvidarnos del factor humano ya que son ellos los que aportan gran valor al negocio.
• Aceptar que el entorno ya cambio, ya no es estático y probablemente evolucionara en algo mas complejo, aceptarlo para convertirlo en una oportunidad es fundamental.

Recordemos que hoy mas que nada necesitamos adaptarnos a los nuevos retos para sacar el mayor provecho posible, así que es momento de entender donde estamos y que necesitamos para hacerlo posible, por eso identificar este concepto y trabajar para encontrar las oportunidades que nos brinde es una tarea que sin duda nos traerá más beneficios que problemáticas.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

Impacto real del retraso en un proyecto

Othoniel Cazares — Fri, 05 Mar 2021 02:26:56 +0000

Al hablar de proyectos hablamos también de riesgos que son parte de los mismos, ya sea un proyecto enorme o la planeación de tu día no estamos exentos de los riesgos que cualquier proyección conlleva. Debido a que cualquier estimación futura no nos da la certeza de que el resultado sea como lo imaginamos y es lógico ya que de otra forma estamos halando del arte de la adivinación y eso solo sucede en los espectáculos de magia.

Uno de los riegos más impactantes es el no cumplir con los tiempos establecidos. ¿pero cual es el impacto real de no cumplir en tiempo?

Veámoslo de la siguiente manera. A todos nos motiva el sentimiento de logro cuando todo marcha viento en popa y no le damos la importancia que merece cuando no sucede así, pero en realidad no debemos perder de vista este caso ya que el costo puede ser muy alto, recuerden que un proyecto requiere recursos ya sean materiales o humanos y si ya proyectaste tu éxito en un periodo de tiempo el no lograrlo implicará perdidas sustanciales conforme a lo planeado y si eres parte del equipo que dará la solución debes verlo de forma empática porque si el dinero saliera de tu bolsillo no quisieras tirarlo a la basura, nadie quiere eso pero en ocasiones no es tan fácil darnos cuenta.

En mi época de desarrollador tuve la oportunidad de ser parte de un equipo el cual era una constante no tomar en cuenta los riesgos de retraso que se presentaban y esto se propiciaba debido a que la empresa interesada en los proyectos no le parecía importar el despliegue de recursos invertidos ya que contaba con bastantes recursos y en ocasiones ni el tiempo, pero cuando las cosas se volvían urgentes era ahí cuando teníamos que pagar la factura. Este tipo de entornos propicia los caprichos que en ocasiones dañan más que no trabajar en absoluto, y a que me refiero con caprichos, en ocasiones pierdes de vista el valor que debe entregar un proyecto y terminas trabajando en funcionalidades que si bien no son del todo innecesarias si retrasas el “deadline” con la idea de que tienen que estar listas para terminar el objetivo que nos propusimos en el plan original y como ya sabemos la entrega de valor debe ser una constante en un proyecto de desarrollo ágil aún más de forma temprana y en esa situación estábamos faltando a ese objetivo fundamental.

Si esto lo trasladamos a nuestra vida cotidiana debemos ser consientes de que si queremos lograr objetivos personales y profesionales debemos tener en cuenta los riesgos del retraso por eso cuando se habla de no dejar para mañana lo que puedes hacer hoy es una llamada a la acción que siempre debemos tener presente. Piensa en, ¿Qué lograre el día de hoy?... Teniendo esto en mente todos los días tanto en tus objetivos personales como en los profesionales podremos minimizar los riesgos del retraso porque al final del día estos no solamente afectarán a terceros, sino que también repercutirán de alguna manera en tu propio trabajo o en tus metas proyectadas. En pocas palabras no quiero decir que sea el caso, es mas no creo que siendo parte de un equipo sea así, pero si deliberadamente eres precursor del retraso podrías terminar disparándote a los pies.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

¿Por qué es importante que el cliente se involucre en la elaboración del producto?

Othoniel Cazares — Tue, 26 Jan 2021 02:31:56 +0000

Se ha repetido hasta el cansancio la importancia del cliente en el desarrollo de un producto, lo vemos en el manifiesto ágil tanto en los valores como en los principios del mismo, sin embargo, todavía nos encontramos en algunos casos con la resistencia por parte del cliente o la tendencia a subestimarlo al momento de desarrollar el producto. Por esto a continuación veremos las tres razones importantes del porque es necesario que el cliente sea la parte central del desarrollo del producto.

El producto es tuyo.

Creo que todos hemos escuchado la frase “Le salió el tiro por la culata”. Sabemos lo difícil que puede llegar ser el estar al tanto de un proyecto si tu foco está en el negocio y por lo general buscas el apoyo de expertos que transformen tus ideas en un producto tangible, pero nada más lejos de la verdad porque a pesar de que tienes a un equipo o empresa que respalde el desarrollo del producto el producto es tuyo, tú y nada más que tu sabe que es lo que requieres lograr, a donde quieres llegar o que ventaja competitiva te otorgará si es ejecutado de manera correcta por eso es necesario que te apropies de él y lo lleves a buen puerto si no quieres terminar con una escopeta que dispara por la culata.

Conoce los tiempos y las tempestades.

Saber cuándo tenemos el viento en popa y advertir la borrasca son cualidades que requerimos al momento de tener la intención de realizar un producto y esto se logra únicamente estando al tanto del proyecto, para conocer los tiempos y advertir los riesgos tanto para prevenirlos como para solucionarlos es una de las habilidades primordiales que solo suceden siendo parte activa del proyecto así que conviértete en el capitán que estas destinado a ser.

Cuida los centavos.

En cualquier proyecto un despliegue de recursos sin sentido no es lo más acertado aun cuando se tenga la solvencia suficiente para eso y más, ya que nos podrá repercutir en el mediano o largo plazo, como dice la frase “Un centavo ahorrado es un centavo ganado” y en base a esto es ideal estar al tanto de los recursos del proyecto para enfocarlos en lo que realmente nos dará un retorno de inversión en el tiempo adecuado.

En conclusión, sabemos lo complicado que puede llegar a ser el implicar a las partes interesadas en un proyecto, pero como líder ágil es tu responsabilidad encontrar la sinergia que derive en un ganar ganar para todas las partes interesadas en la elaboración de un producto o en un proyecto. Así que dale la importancia que merece el cliente e invítalo a desarrollar su visión que a fin de cuentas él y solo él sabe el valor que conlleva.

IG:@agile.rockstar
FB:@AgileRockstar
TW:[@ocazares ](https://twitter.com/ocazares

Ya utilizas Scrum pero… ¿Realmente practicas agilidad?

Othoniel Cazares — Wed, 13 Jan 2021 15:38:51 +0000

Si bien es cierto que usualmente asociamos el marco scrum con la agilidad debido a su popularidad difícilmente podemos asegurar que practiquemos la agilidad únicamente llevando a cabo las practicas sugeridas por Scrum y a continuación te diré por qué.

Por fin la empresa decide entrar en el trend de la agilidad y lo ha decidido de la manera habitual... Si con scrum.

Entonces comienza el viaje hacia la mejora continua y la entrega de valor que románticamente nos dicen los miles de artículos y libros de scrum que hemos leído o inclusive las certificaciones y estamos convencidos de que este es el camino para lograr la hegemonía del equipo y entregar toneladas de producto en el menor tiempo posible. Y es así como implementamos las ceremonias y artefactos del marco de trabajo con la convicción de que todo funcionará como por arte de magia, pero nada más alejado de la realidad.

Al implementar Scrum debemos tener en cuenta que un marco de trabajo no son más que sugerencias, pasos o reglas si no entendemos profundamente cual es la finalidad de la agilidad, la cual debe ser comprendida antes de decidir de qué forma o que herramientas utilizaremos.

La agilidad implica más que ceremonias y artefactos como lo indican sus pilares y principios, esta tiene como alcance mucho más que una simple organización del equipo, refiere a la importancia hacia el cliente, la necesidad de abrazar los cambios, darle su merecido lugar al equipo de trabajo y todo esto repercute en la entrega de producto funcional de manera temprana.

Pero no olvidemos un detalle importante que es el mindset, el cual se debe permear no únicamente con el equipo scrum sino también se debe sensibilizar a los clientes y personas interesadas en el producto para que tengan la disposición de avanzar al unísono con el equipo. Si no logramos esto de nada servirá utilizar scrum ya que no entregaremos producto de valor en un tiempo ideal para el negocio.

Es como cuando vemos cualquier deporte en conjunto y como espectador admiramos lo que logran en el terreno de juego, sin embargo, esos logros además de ser un esfuerzo colectivo de los jugadores, también requieren estrategas tanto a nivel de cancha como en niveles arriba en la jerarquía que al final de cuentas se encuentran involucrados al momento de buscar un objetivo en común, cada uno realiza esfuerzos enfocados en lograr el éxito trabajando siempre en unidad y con claridad.

Es de suma importancia ver al equipo como un todo y permitir que se den las interacciones necesarias para que el equipo sea empoderado no se trata de ordenar para ejecutar, sino que se debe dar guía para que la ejecución incite al equipo a crecer y alcanzar logros que si bien son personales aportan de manera sustancial al objetivo de todo el proyecto.

En conclusión, cuando hablamos de agilidad, no nos referimos a los marcos agiles, que si bien son una excelente herramienta para llevarla a cabo debemos enfocarnos en los pilares y principios que nos darán la pauta a seguir y terminaremos con un “way of work” que se ajuste perfectamente a nuestro proyecto y podría ser uno o una mezcla de diferentes marcos agiles.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

El verdadero valor en una historia de usuario

Othoniel Cazares — Wed, 30 Dec 2020 16:12:05 +0000

Uno de los conceptos mas utilizados en la agilidad son las historias de usuario, pero ¿en realidad comprendemos la utilidad de las mismas?... O simplemente las vemos como requerimientos para que el equipo se ponga manos a la obra lo más pronto posible.

Retomando la esencia de las historias de usuario estas nos ayudan a identificar los actores, los requerimientos y lo mas importante el valor que representan, si no te has dado cuenta de esto último es momento que identifiques de una vez y en lo sucesivo la importancia del “para”.

Una historia de usuario se compone de la siguiente manera:

Yo como < persona/usuario real >
Deseo < funcionalidad, hipótesis de solución del problema >
Para < problema que debe resolverse >

Y como en la agilidad estamos en una constante búsqueda de valor para el cliente se vuelve sumamente importante enfocar nuestra atención en la problemática que se desea resolver más que la forma de resolverla ya que de ahí radica lo que debemos entregar al cliente para otorgarle ventaja competitiva y que en ocasiones no le damos la importancia que requiere porque nos enfrascamos en un mundo de requerimientos que si bien se deben tomar en cuenta probablemente no tengan el mismo peso unos de otros y cometemos el error de terminar con historias de usuario que se enfocan en la funcionalidad y no otorgan al equipo el panorama valioso que representa para el producto.

Por esto es necesario tener claro el objetivo de cada requerimiento ya que ahí es sin duda donde debemos enfocarnos para que de esa manera sea representada la importancia de una historia y con ello obtener una singular facilidad a la hora de priorizar historias de usuario en nuestros proyectos.

Una vez que le demos la importancia debida a la parte donde se define él porque es valiosa tu historia de usuario evitaremos que quien se encarga de desarrollar el producto enfoque esfuerzos en funcionalidades vanas que no aportan categóricamente valor al producto y nublan el rumbo del mismo que en ocasiones es complicado retomarlo.

Así que hoy es momento de dedicarle mas tiempo a los “Para” de nuestros requerimientos y armonizar nuestro proyecto con funcionalidad valiosa en el momento indicado.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

Técnicas de priorización (RICE Parte 3)

Othoniel Cazares — Mon, 21 Dec 2020 04:54:21 +0000

Como parte de la serie de artículos de priorización que hemos estado exponiendo en las últimas semanas en esta ocasión veremos el método RICE el cual se basa en distintos factores que en conjunto tienen el objetivo conseguir una métrica que aporte valor y nos permita comparar objetivamente entre las actividades definidas de nuestro proyecto.

¿Que es RICE?

RICE es un acrónimo que refiere por sus siglas en ingles a Alcance (Reach), Impacto (Impact), Confidence (Confianza) y Esfuerzo (Effort) la cual desglosaremos a continuación.

REACH.- Este factor tiene como objetivo identificar a las personas afectadas por dicha funcionalidad o tarea a desarrollar en un periodo concreto. Por ejemplo, el numero de usuarios finales a los que afectara dicha mejora, tarea o funcionalidad.

IMPACT.- Ahora debemos determinar el impacto que nuestra mejora o funcionalidad generara en los usuarios que alcanzaremos, este índice ser un valor cualitativo que muestre congruentemente el impacto de la funcionalidad. Por ejemplo, podemos utilizar un rango del 1 al 10 donde 10 es un gran impacto, 5 sería un impacto medio y 1 un impacto bajo.

CONFIDENCE.- Ahora debemos determinar el nivel de éxito que consideramos pueda tener nuestra idea, mejora o funcionalidad, la cual puede ser una estimación para cuando no tengamos datos concretos que puedan determinar nuestro nivel de éxito.

EFFORT.- El esfuerzo refiere a los recursos que serán requeridos para llevar a cabo la actividad determinada, estos pueden ser: Personal, materia prima, trabajo necesario, inversión requerida, etc.

Ahora para determinar el índice emplearíamos la siguiente ecuación:

Indice=(RIC)/E

Indice=(Reach * Impact * Confidence) / Effort

Con esto podremos comparar el índice de prioridad de cada tarea para que de esta forma podamos mejorar nuestro proceso y generar valor al proyecto de manera efectiva, tomando en cuenta que entre mayor sea el índice más alto es el nivel de prioridad de dicha actividad.

A continuación, se ejemplifica de manera sencilla para entender un poco mejor cómo se comporta este tipo de estimaciones

Como podemos observar los datos son variables como conjunto, pero comparten algunos datos y se puede observar como el índice se dispara en algunos casos dándonos la certeza de que nuestra priorización es la adecuada.

Como conclusión para este tema de priorización y los tres métodos que hemos visto recomiendo ampliamente que se complementen las distintas técnicas de priorización ya que no es efectivo utilizar un solo factor ya que en muchos casos la complejidad va más allá y su impacto puede ser ampliamente comprendido si se utilizan diversas técnicas, si bien hemos visto técnicas como MoSCoW, WSJF y RICE existen mas opciones que podemos implementar que de seguro nos serán de gran utilidad al momento de priorizar por lo cual los invito a que le den un vistazo y si creen necesario que escriba acerca de un método en particular no duden en realizar sus comentarios.

IG:@agile.rockstar
FB:Agile Rockstar
TW:@ocazares

Técnicas de priorización (WSJF Parte 2)

Othoniel Cazares — Mon, 14 Dec 2020 22:37:34 +0000

Continuando con las técnicas de priorización empleadas en la gestión de proyectos la semana pasada hablamos de la técnica MoSCoW y esta semana hablaremos de la técnica WSFJ para continuar este tema, si bien existen bastantes técnicas de priorización iremos tratando de ver poco a poco las mas interesantes que nos darán la perspectiva necesaria para gestionar las prioridades de nuestro proyecto.

Como lo comentábamos la semana pasada hoy hablaremos de técnicas que nos ayuden a disminuir costos, una de ellas es WSFJ que es justamente con la que trataremos este artículo.

Weighted Shortest Job First (WSJF)

Esta técnica conocida como WSFJ nos permitirá priorizar nuestras tareas con un objetivo en mente que es el valor económico de las tareas o para ser mas claros que tareas nos representaran menor costo llevarlas a cabo. Esto es un tema de interés al momento de la gestión de proyectos ya que con ello podrás ajustarte a presupuestos reducidos o prevenir riesgos críticos que tengan que ver con los costos.

Ahora veamos en que consiste este método, el primer indicador que requerimos para realizar nuestra estimación es el “Costo por restraso o Costo of Delay” este indicador refiere al costo diario que tendremos de no realizar dicha tarea, si bien podemos realizar una estimación en base a costos exactos lo mas usual es utilizar puntos de estimación los cuales se determinaran por medio de otros elementos como son el valor de negocio, el tiempo crítico y reducción de riesgo o posibilidad de oportunidad. En este articulo no entraremos a fondo en estos temas ya que la finalidad es mostrar cómo funciona la técnica de priorización, pero si quieren saber un poco más de este tema siéntanse libres de dejar sus comentarios.

Una vez que tenemos el “Cost of Delay” tendremos que determinar el otro índice necesario para esta realizar la estimación que es el “Tamaño del trabajo o Job Size” este índice como su nombre lo indica refiere a la complejidad traducida en días, vaya, es la duración estimada que puede conllevar una tarea. Para determinar este indicador es necesario incluir al equipo que llevara a cabo la tarea como de ser posible también a los expertos en el área necesarios para que apoyen con una estimación lo mas acercada a la realidad.

Ahora bien, una vez contando con estos indicadores de cada tarea procederemos a aplicar la siguiente formula:

WSJF=Costo of Delay/Job Size

Con esto tendremos nuestros indicadores que nos ayudaran a priorizar las tareas, a continuación, lo veremos en forma de ejemplo:

Se cuenta con un product backlog de 3 tareas, la tarea A tiene un costo de retraso de $10 por cada día con una duración de 5 días, la tarea B tiene un costo de $5 y su duración es de 1 día y la tarea C que tiene un costo de $1 y una duración de 5 días también.

A simple vista uno pensaría que la tarea A es mucho mas prioritaria que el resto ya que cuesta mucho más estarla retrasando, además la complejidad es importante ya que nos lleva 5 días llevarla a cabo, veamos ese caso teniendo en cuenta que la tarea A es más prioritaria.

Una vez priorizada de esta manera nos damos cuenta que el costo de los primeros 5 días es de $16, recuerden que las demás tareas también se están retrasando al darle prioridad a la tarea A, esto quiere decir que nuestro costo disminuirá hasta el sexto día quedándonos de la siguiente manera:

Esto nos da un costo de $91 al finalizar nuestro proyecto, ahora si aplicamos la formula WSJF nuestra priorización quedaría de la siguiente forma.

Esto quiere decir según nuestro índice es mejor opción priorizar primero la tarea B ya que su índice es más alto por lo tanto nuestro proyecto quedaría priorizado de la siguiente manera:

Esto nos daría un costo de $76 minimizando en base a la simple formula de priorización, de aquí la importancia de esta técnica que nos puede ser bastante útil al momento de reducir costos en un proyecto.

Hasta aquí nuestra segunda entrega de técnicas de priorización espero les sean útiles al momento de aplicarlas a sus proyectos, la próxima semana continuaremos con la 3ra parte de la entrega que si bien estaba proyectado incluirla en esta semana considero que seria mas apropiado realizar las entregas por partes y sea de cierto modo mas claro y sencillo para todos ustedes.

IG:@agile.rockstar
FB:Agile Rockstar
TW:@ocazares

Técnicas de priorización (Parte 1)

Othoniel Cazares — Sat, 12 Dec 2020 18:06:24 +0000

Una parte fundamental en la gestión de proyectos ágiles es saber cómo priorizar las tareas que componen el proyecto, sabemos que existe constantemente la necesidad de utilizar metodologías para este fin por esa razón debemos conocer algunas técnicas que nos serán de utilidad a lo largo de la planeación de nuestro proyecto.

Un punto importante a considerar es a los stakeholder los cuales son los interesados en obtener valor del proyecto y en algunas ocasiones nos enfrentamos a la problemática en la cual los stakeholders no le dan la importancia que se debe a este punto o simplemente para ellos todo es prioritario, es nuestra obligación transmitir la importancia de priorizar las tareas para obtener el mayor beneficio aceptable en el menor tiempo posible.

En dado caso de que la responsabilidad recaiga mayormente en nosotros es fundamental utilizar alguna metodología de priorización, por lo tanto, a lo largo de estas semanas te estaré exponiendo algunas técnicas esenciales para esta tarea las cuales de seguro te serán valiosas en tu día a día.

MoSCoW

Esta semana iniciaremos con una de las técnicas mas populares en la industria y una de las dos que siempre debemos tener en cuenta como nuestras herramientas básicas a la hora de priorizar (La siguiente semana estaremos viendo la técnica RICE que es una de las dos fundamentales que debemos conocer).

MoSCoW se entiende básicamente como Must, Should, Could & Won’t que en español se entendería como Debo, Debería, Podría y No a lo que podemos asumir que tendremos tareas que debo estrictamente contemplarlas, tareas que debería contemplarlas pero no son contundentes para el optimo funcionamiento, tareas que podría incluir en el desarrollo pero no afecta el resultado si no las contemplamos y tareas que NO debemos contemplar por el momento en el desarrollo.

Ahora de nada sirve saber como catalogar las tareas si no entendemos realmente que tareas son totalmente relevantes y cuales no. Una manera de determinar que tareas se consideraran relevantes en el desarrollo próximo es hacernos las siguientes preguntas:

¿Mi proyecto puede funcionar sin determinada tarea?
¿Esta tarea agrega valor al proyecto?
En base a estas dos preguntas podemos determinar si es una tarea que “Debo” (Must) realizar. Supongamos que la tarea es primordial para el funcionamiento y agrega gran valor al proyecto, entonces definitivamente estamos hablando de un “Must”. En otro ejemplo supongamos que una tarea su funcionamiento es primordial para el proyecto, pero NO agrega valor al mismo estaremos hablando de una tarea “Should” ya que deberíamos trabajar en ella para continuar con el proyecto aunque NO nos aporte valor.

Ahora para determinar las tareas que seria un “Could” o que podríamos trabajar en ella tenemos que tener en cuenta las circunstancias, es decir, dependiendo de lo que queramos lograr es cuando podríamos echar mano de estas tareas, por ejemplo: Si tenemos una entrega para un MVP y queremos cautivar a nuestros stakeholders podríamos tomar en cuenta algunas tareas de esta sección ya que no aportan valor final a los stakeholders y no son funcionalidades criticas del sistema pero si logramos cautivar con alguna funcionalidad extra nos podría dar la continuidad que estamos buscando o algún otro beneficio que se esté planteando logra, otro ejemplo sería una mediación en este caso con el cliente a fin de un beneficio mutuo, es decir, si el cliente desea tener una funcionalidad que no es relevante pero nosotros podríamos dedicarle tiempo para logra alguna autorización de otro desarrollo o algún beneficio monetario entonces estaríamos considerando estas tareas como parte del desarrollo para lograr un fin.

Ahora las tareas que cataloguemos como “Wont” no quiere decir que son funcionalidades que vamos a deshacernos de ellas simplemente no son necesarias de momento ya que posiblemente no agregan valor al negocio en ese momento predeterminado, puede que en los meses venideros cobre valor y sea catalogada de nuevo como también existe la posibilidad de que el proyecto haya tomado un giro distinto y ya no sean requeridas algunas de estas tareas, esto solo el tiempo y la evolución del proyecto marcaran la pauta a seguir.

En conclusión esta técnica de priorización es muy efectiva para poner orden en el proyecto ya que se enfoca en las propiedades cualitativas de las tareas por lo cual la hace ideal para realizar una priorización inicial y con ello llevar un orden que permita iniciar el trabajo de manera adecuada, en nuestro próximo articulo hablaremos un poco de métodos de priorización enfocados en la reducción de costos los cuales nos ayudaran no solamente priorizar en base al valor y funcionalidad sino también nos permiten agregar valor a la gestión del proyecto.

IG:@agile.rockstar
FB:@AgileRockstar
TW:@ocazares

DEV Community: Othoniel Cazares

Fallemos ágilmente

Definición de listo y terminado (DoR y DoD)

DoR (Definition of Ready)

DoD (Definition of Done)

Ser Customer Centric

¿Eres un superhéroe ágil?

VUCA: ¿Qué es?, cómo nos afecta y cómo aprovecharlo.

¿Sabes que es un entorno VUCA?

¿Cómo enfrentamos un entorno VUCA sin fallar en el intento?

Impacto real del retraso en un proyecto

¿Por qué es importante que el cliente se involucre en la elaboración del producto?

Ya utilizas Scrum pero… ¿Realmente practicas agilidad?

El verdadero valor en una historia de usuario

Técnicas de priorización (RICE Parte 3)

¿Que es RICE?

Indice=(R*I*C)/E

Indice=(Reach * Impact * Confidence) / Effort

Técnicas de priorización (WSJF Parte 2)

Weighted Shortest Job First (WSJF)

WSJF=Costo of Delay/Job Size

Técnicas de priorización (Parte 1)

MoSCoW

Indice=(RIC)/E