Hola a todos
Luego de este magistral post de mi gran amigo Lucho Salazar
El extraño caso de las historias de usuario técnicas (clic aqui)
Solo queda pendiente esta aclaración:
"No existen las historias de usuario técnicas, ni de frontend, ni de backend, ni de certificación, etc., solo existen las historias de usuario y ya"
Espero esta imagen ayude a superar tanta confusión al respecto.
Saludos ágiles
Jorge Abad
Me preguntaron sobre historias técnicas y de Mantenimiento en mis redes sociales, esta fue mi respuesta:
ResponderBorrarEstimado Ernesto Cardenas para construir un producto se requiere esfuerzo en la parte funcional y en la parte tecnica...
en la parte funcional.. en el mundo de XP y Scrum se ha encontrado que es muy util el trabajo con Historias de usuario, estas dentro de si tienen tareas tecnicas que deben ser ejecutadas para ser construidas
en la parte tecnica, ya sea la construccion de habilitadores, la remoción de deuda tecnica, la conexion de servidores, la ejecución de refactor de algun componente, etc. son temas técnicos que indiscutiblemente deben visibilizarse pues es TRABAJO y DEMASIADO IMPORTANTE, Y RADICALMENTE SON DE VALOR (muchos PO creen que eso no deberia cobrarse). Como tal ese trabajo no son historias de usuario son temas técnicos.. que se escribirán como un técnico escribe un requerimiento técnico.. ahora bien si tu decides escribir eso.. en formato de historias de usuario. allá usted... pero eso no es una historia de usuario.. es un componente técnico...
Adicional, que he observado, que si existe un trabajo técnico a desarrollar, es bueno:
- partirlo en tareas pequeñas de máximo 1 día
- hacerle pruebas
- ponerle criterios de aceptación
pero por que tenga la estructura anterior.. no lo hace de "usuario" .. un usuario no te pedirá.. reescribir una clase.. te pedirá a lo sumo mejorar el rendimiento técnico de una funcionalidad y esto será un criterio de aceptacion de la historia de usuario
Pero indudablemente coincido contigo.. el trabajo tecnico debe visualizasre en el backlog
un abrazo y un gusto discrepar contigo
----
ver áca https://www.facebook.com/groups/1709096819395423/?post_id=2395432387428526&comment_id=2395456757426089&reply_comment_id=2395657310739367
En mi publicación en facebook me preguntaron sobre SISTEMAS BACKEND que no es lo mismo que una historia de usuario backend, respondí esto:
ResponderBorrarEstimado Guino Henostroza justo habla de un sistema de backend, por lo que esas historias de usuario que consecuencia tendran:
-componente batch (por ejemplo)
-acceso a datos,
- pruebas de componente,
-pruebas de integracion etc...
hay varios puntos a ressaltar:
- Scrum y XP no todo son historias de usuario
- en un backlog de producto hay temas tecnicos y funcionales
- si vas a usar historias de usuario es por que te estas refiriendo a una necesidad de usuario
- las personas y equipos se ven forzados por jira a llamar todo historias de usuario para que se vea su trabajo, pero si hay algo tecnico se hara algo tecnico requerido
- tu que eres experto en el mundo de testing sabes que hacer pruebas no es hacer una historia de usuario. es hacer pruebas
----
Hace algún tiempo escribi sobre historias de usuario para sistemas backend, este es el post: http://www.lecciones-aprendidas.info/2016/02/historias-de-usuario-de-sistema-una.html
un post sobre historias de usuario de sistemas backend escrito por Mike Cohn Writing User Stories for Back-end Systems-clic aquí-
----
Ver en conversacion en facebook acá https://www.facebook.com/groups/1709096819395423/?post_id=2395432387428526&comment_id=2395513787420386&reply_comment_id=2395649760740122
Interesante su perspectiva y la verdad hasta hace muy poco coincidía 100% con su forma de ver las historias de usuario,pero los puntos de vista son tan diversos como la vida misma.
ResponderBorrarMe pregunto cómo aplicar esa filosofía en un proyecto donde hay varios equipos (que obviamente comparten el mismo backlog) y donde uno de esos equipos se especializa en el "back-end". Por supuesto cada equipo tiene historias asignadas, lleva el progreso de su Sprint y tiene métricas independientes. Las tareas no se les puede asignar puntos (al menos no en Jira) y a pesar que es una funcionalidad no hay forma de medir por separado el esfuerzo de cada equipo sin definir historias separadas para cada uno. No digo esté de acuerdo con el primer enfoque pero a veces no todo es blanco o negro.
Hola, Comprendo tu contexto y lo he vivido
Borrarno todo es blanco o negro.. es cierto.. todo tiene un contexto.. tambien es cierto.. pero no podemos por ese optica corromper los conceptos o mezclarlos.
me voya explicar
un usuario nunca pedira una mediacion, una cola mq, un servicio rest, un web service, pedira que se haga una transaccion y con seguridad pasara por el bus de servicios.
Por lo tanto, hay un lenguaje tecnico mucho mejor para pedir esos requerimientos tecnicos.
Ahora miremos varios matices.
- lo mejor que puede suceder es que tengas equipos cross-funcionales que no esten especializados por dominio o herramienta.. te lo sugiero.. hazlo.. se que hay resistencia.. pero comienza con un experimento... y este es un enfoque end-to-end que agradecera el usuario
- sino haces lo anterior, vas a crear muchas dependencias tecnicas de los equipos y creas un escenario de "casca-agile" (combinacion de cascada y agil), donde el software entregado por un equipo, no es algo que pueda ser usado por el cliente final por lo que no es potencialmente liberable y usable (lo que es una de las caracteristicas que amamos de scrum). Pero aun en este escenario de Casca-agile, se genera valor en ciclos largos (3 o 4 sprints) pero no tan largos como los de cascada.
Te sugiero ver esta explicacion en este video - https://youtu.be/nRnA3yn3gyc?t=1785
Buenos días Sr. Abad.
ResponderBorrarAcabo de encontrarme con su bloh, de más esta decir, me parece genial, su forma deexplicar es muy amena y concisa, lo cual hace que sea un placer leerle sin sentirse abrumado.
No obstante, tengo una duda en relación a la parte de HU técnicas.
Como justificar, según la metodología que el team development debe detener un momento, su creación de "valor" para atender temas netamente técnicos tales como, refactorizar algún componente que no fue desarrollado según los estandares de desarrollo (reglas de codificación, nomenclatura, orden, performance)?
Esta pregunta la hago desde la siguiente perspectiva, como parte del equipo de desarrollo, observo que hay alguna parte del sistema que fue codificado, probado y entregado, pero, observo que aunque no es notable en vista, el proceso desarrollado esta dejando hilos de procesador abiertos, los cuales a futuro de no manejarse incrementaran los costes de procesamiento y el performance de la aplicación, como se puede respetar el marco de trabajo, bajo ese escenario?