lunes, agosto 24, 2020

No existen historias de usuario técnicas, ni de frontend, ni de backend etc, solo existen historias de usuario

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

5 comentarios:

  1. Me preguntaron sobre historias técnicas y de Mantenimiento en mis redes sociales, esta fue mi respuesta:

    Estimado 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

    ResponderBorrar
  2. En mi publicación en facebook me preguntaron sobre SISTEMAS BACKEND que no es lo mismo que una historia de usuario backend, respondí esto:

    Estimado 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

    ResponderBorrar
  3. 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.
    Me 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.

    ResponderBorrar
    Respuestas
    1. Hola, Comprendo tu contexto y lo he vivido

      no 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

      Borrar
  4. Buenos días Sr. Abad.

    Acabo 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?

    ResponderBorrar