The latest articles on DEV Community by Gustavo Sánchez (@happydevops_mx). https://dev.to/happydevops_mx https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F247172%2Fc373b953-648d-4c27-a423-b646a804721f.jpg https://dev.to/happydevops_mx en Gustavo Sánchez Thu, 02 Jan 2020 22:02:32 +0000 https://dev.to/happydevops_mx/user-stories-las-historias-epicas-no-son-malas-516f https://dev.to/happydevops_mx/user-stories-las-historias-epicas-no-son-malas-516f <p>Definir una actividad como épica es incomodo, las tareas épicas son los apestados del tablero de actividades. Nadie del equipo de desarrollo quiere atender una tarea de estas, son complejas, difíciles, mal documentadas o solo son una etiqueta que se les da a las actividades que el equipo no quiere atender nunca. Puede que llegue el product owner con una tarea en la reunión de planeación, esta no sea del agrado del equipo y en lugar de darle un tratamiento adecuado inmediatamente se cataloga como "algo épico", y como es una tarea épica se reducen las posibilidades de que esta se concluya o atienda alguna vez, quizá este como zombie en el backlog bastante tiempo antes de ser olvidada. El equipo de desarrollo debe atender tareas aunque sean complejas o difíciles, no hay excusa. Debes tener en cuenta lo siguiente cuando recibas una tarea de estas.</p> <h2> Una tarea épica es un montón de actividades que aun no se han registrado. </h2> <p>Todas las historias de usuario o actividades pueden ser divididas en unidades mas pequeñas. Hay que entender el problema a resolver detrás de una historia épica, luego trazar un plan para resolver el problema que estas implican. Debes hacer mapas de historia de usuario, modelos mentales o cualquier auxiliar que te permita generar un flujo de trabajo que concluya todas las actividades. Un análisis así puede tomarte a ti y a tu equipo un par de horas pero es vital para llegar a una solución.</p> <h2> El esfuerzo de una tarea épica puede no ser visible por los demás. </h2> <p>Muchas actividades que tienes en el proyecto son complejas y difíciles en el aspecto técnico. Los usuarios, project managers, stakeholders, product owners, analistas, etc. pueden no verlo del mismo modo. Por ejemplo: mientras que el pago con tarjeta de crédito en una historia de usuario puede verse como una actividad "rápida" de resolver, del lado técnico puede implicar un montón de actividades a realizar que pueden o no estar registradas en la historia misma, desde elegir un proveedor de pagos, probar la API, modificar la base de datos, hacer pruebas, hacer cambios en la infraestructura, tener reuniones con el área de seguridad informática. Todo eso no se va a ver, a menos que tu le des visibilidad en tu tablero de actividades. Esta bien que una historia épica tarde en moverse, esta mal no reflejar el esfuerzo que dedica tu equipo a resolverla.</p> <h2> Las tareas épicas son difíciles de contabilizar y auditar. </h2> <p>Si tienes una actividad demasiado tiempo en tu carril de items activos, hablamos de varios sprints, esto puede generar incomodidad y desconfianza aunque la estés atendiendo. Va a ser bastante difícil demostrar un avance, las conversaciones, los insumos y el seguimiento va a hacerse harto complicado, ni hablar de contabilizar el valor en story points de esta. ¿Te pidieron una estimación de cuando estaría lista esta tarea?, peor aun. Una tarea con muchos puntos es candidata a dividirse en tareas mas pequeñas, con una mayor de cantidad de tareas pequeñas el avance y la estimación de cuando estaría lista se vuelve visible. Si dividiste tu tarea épica en 20 tareas de mas o menos el mismo tamaño, llevas unas 12 tareas hechas con un progreso de 4 tareas por sprint podrías argumentar que la tarea estará lista en 3 sprints con confianza.</p> <h2> Las tareas épicas son "themes". </h2> <p>Un theme o tema en español son un conjunto de actividades referentes a un tema en especifico. Por ejemplo, la siguiente historia de la que hemos estado hablando.</p> <blockquote> <p><strong>Como</strong> cliente del portal.</p> <p><strong>Quiero</strong> poder pagar con tarjeta mis folios.</p> <p><strong>Así</strong> puedo ahorrar tiempo y no contactar a soporte para la activación de mis folios.</p> </blockquote> <p>Mas que una historia única es un conjunto de historias de usuario y actividades relacionadas que puedes llamar: Modulo de pagos con tarjeta. Todas las tareas técnicas que mencione, junto con las historias que van a surgir como: cancelaciones, pagos fraudulentos, cobros incorrectos o duplicados, promociones, ofertas, todas las historias del equipo de back office que va a dar seguimiento pueden ir etiquetadas con tu tema. Puedes conservar la historia original para el seguimiento o definitivamente eliminarla. Eso ya queda a tu elección.</p> <h2> Conclusiones. </h2> <p>Las tareas épicas o con muchos puntos son tareas medio crudas que no han sido tratadas adecuadamente, estas requieren de trabajo adicional para sacarlas a flote. Las tareas de este tipo no son malas, lo malo es que no les des el cuidado que requieren.</p> historiasdeusuario userstories epics userstoriesmapping Gustavo Sánchez Thu, 12 Dec 2019 16:55:26 +0000 https://dev.to/happydevops_mx/kanban-mi-primer-reunion-de-retrospectiva-1k3n https://dev.to/happydevops_mx/kanban-mi-primer-reunion-de-retrospectiva-1k3n <p>Esta semana tuve mi primer reunión retrospectiva bajo el marco de trabajo de Kanban, cabe aclarar que las reuniones en Kanban no son explicitamente necesarias para el trabajo a diferencia de Scrum. Las reuniones retrospectivas tienen el propósito de evaluar el flujo de trabajo (estas pueden ser periódicas o no), el propósito es ver que es mejorable y que se hizo bien; obvio necesitas tener un periodo de recolección de datos, una actividad de análisis y conclusiones para poder mejorar el proceso de trabajo del área. En el caso de mi primer reunión no existieron métricas que comparar porque no hay iteraciones anteriores, aun sin esta actividad la reunión me dio una nueva perspectiva acerca de mi trabajo personal y el de mi equipo que a continuación te comparto.</p> <h2> A los demás les interesa el progreso de tus actividades. </h2> <p>El tablero de actividades es publico y digital, es accesible por otras personas de la empresa, rara vez tiene comentarios de gente no relacionada por lo que yo tenia la idea de que a nadie le importaba un carajo excepto al área de desarrollo, me equivoque. En la reunión donde estaban todos los involucrados, el director del área, el product owner/analista de negocios, y la gente de soporte se hablo acerca del seguimiento que dan de las actividades, si bien no comentan, están pendientes del progreso. Los registros de estatus les fueron útiles para poder estimar cuando una actividad esta próxima a ser terminada o cuando van a ser requeridos para intervenir, por ejemplo: notificar a clientes que una corrección esta próxima a ser liberada o realizar algún tipo de prueba o validación.</p> <h2> El carril de detenidos es fundamental. </h2> <p>Me alegro darme cuenta que el carril de detenidos fue tomado con entusiasmo, no se vio como un pretexto para no trabajar o como incompetencia tener varias actividades que no se mueven, al contrario. Cuando los externos vieron que actividades se detenían consultaron la actividad para ver si podían ayudar a que progresara o solo tener en cuenta que no se esta trabajando en ello. Se terminaron los correos, conversaciones o platicas de "como va" cierta actividad. El tablero se esta convirtiendo en un radiador de conocimiento y un medio pasivo de comunicación del trabajo.</p> <h2> Esta bien tener una actividad varios días en tu WIP , esta mal no documentar el ##progreso. </h2> <p>En este periodo de trabajo con Kanban varios programadores mantuvieron sus actividades durante varios días, es posible que las actividades no haya sido divididas en unidades de trabajo mas pequeñas, lo se. No hubo problema ni comentarios al respecto. El comentario al respecto fue: no supimos si te atoraste en algo o necesitabas ayuda. Las tareas que no reportan estatus pueden verse como trabajo detenido. Notificar el estatus de trabajo al menos una vez al día es fundamental si trabajas con actividades grandes o complejas. Lo ideal seria dividir la actividad principal en sub actividades pero esto es subjetivo, depende del estilo de trabajo de cada programador, personalmente prefiero dividir una tarea grande en varias pequeñas o crear actividades relacionadas. Este es mi estilo, mis compañeros no lo comparten, el punto es documenta tu avance con unas pocas lineas de texto diario, es super valioso y no te quita tiempo.</p> <h2> La discusión siempre es sobre el flujo de trabajo no sobre las personas. </h2> <p>Uno de mis mayores temores antes de la reunión es que esta derivara en criticas sobre personas en lugar de criticas sobre el flujo, afortunadamente no fue el caso. La discusión siempre se mantuvo en que hicimos bien y que podemos mejorar. Si bien se hicieron comentarios con nombres de personas y casos, solo fueron anecdoticos y no pasaron a mayores. La reunión giro a tratar de responder las siguientes preguntas:</p> <ol> <li>¿Que se hizo bien?</li> <li>¿Que se puede mejorar?</li> </ol> <h2> Conclusiones. </h2> <p>Nuestra primer retrospectiva sentó un antes y un después en nuestra manera de trabajar. No podemos verlo como una victoria aun, ya que aun faltan muchas cosas como la planificación, mantenimiento del backlog, recolección de métricas, etc. . Kanban va de mejorar cada día, ningún marco de trabajo es perfecto y siempre habrá rango de mejora.</p> kanban retrospectiva