He leído: User Stories Applied de Mike Cohn

Comprar User Stories AppliedSi piensas que la gestión de requisitos es clave para que un proyecto triunfe estás en lo cierto. El problema siempre es el mismo, como conseguir que los requisitos se conviertan en algo útil. Las metodologías ágiles abordan el problema de la gestión de requisitos de una manera diferente. Muchos confunden este enfoque diferente y ágil con una ausencia total de gestión de requisitos.

En este libro Mike Cohn deja claro que use la metodología que uses, la gestión de los requisitos es un área vital. Las historias de usuario están ganando adeptos a gran velocidad como herramienta de gestión de requisitos ágil. Aunque las historias de usuario buscan la máxima simplicidad, la gestión de requisitos es un área llena de complejidades.

En este libro Mike Cohn aborda todos los temas fundamentales relacionados con la gestión de los requisitos de un proyecto siempre desde el punto de vista de las historias de usuario como pieza central de esta gestión. Leyendo este libro aprenderemos a distinguir las buenas historias de las no tan buenas, a identificar y modelar los diferentes roles de usuarios de una solución, a determinar las historias presentes en el proyecto y su prioridad mediante diferentes técnicas ágiles, a escribir condiciones de aceptación para las historias que faciliten su testeo y a estimar las historias y usar esas estimaciones para establecer costes y tiempos de desarrollo. Además, como es construmbre en los libros de este extraordinario autor, todos los temas se exponen mediante ejemplos e historias que hacen la lectura muy amena.

La gestión clásica de requisitos falla por una cuestión fundamental: es terriblemente pesada y costosa de llevar a cabo. Y además es sumamente aburrida. En consecuencia raro es el proyecto que cuenta con una gestión explicita de requisitos. Mediante las técnicas ágiles expuestas por Mike Conh en este libro haremos de nuestra gestión de requisitos una tarea llevadera.

Las técnicas explicadas en el libro son susceptibles de ser utilizadas en cualquier metodología y especialmente recomendables en las metodologías ágiles. El libro incluye un capitulo dedicado a explicar como usar las historias de usuario en un marco de trabajo Scrum y además incluye un excelente capitulo resumen sobre Extreme Programming, metodología en la surgen las historias de usuario.

Este libro es la pareja de baile perfecta para otro libro del mismo autor que ya comente con anterioridad en este blog: Agile Estimating And Planning. Pocos libros han impactado tanto en mi visión de la gestión de proyectos como estos dos.

Un consejo, no perdáis de un momento y compradlos. Si seguís este consejo, lo que si os puedo asegurar es que los vais a devorar, son dos libros extraordinarios.

5 comentarios sobre “He leído: User Stories Applied de Mike Cohn”

  1. De lectura obligada, estes o no directamente implicado en la toma de requerimientos. Ambos son excepcionales y bastante sencillos de leer (aunque sea en Ingles ya que no estan traducidos). Curios autor que usa siempre caracters feminos a todos los protagonistas, perdon todas las protagonistas, de sus historias. una reibindicacion bien entendida.

    Uno de los puntos que para mi son de reseñar es que se refiere a aagil en el mas amplio de los conceptos si referirse a una metodologia agil especifica, XP, Scrum, etc.

  2. Gracias por tu aportación a la lengua cervantina, pero no es de hombres tirar la piedra y esconder la mano, tampoco de bien criados. Se te pasaron más faltas «a aagil», «feminos» entre otros, sin mencionar los acentos. Hay mucho que mejorar, si. Pero tu estas lejos de poder predicar con el ejemplo.

  3. Buenas:

    Tb acabo de leer el libro. Resulta sin duda sencillo, los ej. son amenos e ilustrativos. El método de modelado y gestión de los requerimientos que sugiere tiene muchos aspectos positivos. Pero, a mi manera de ver, resulta algo simplista: me quedan muchas dudas sobre como implementarlo en la realidad… Detallo a continuación mis principales incógnitas.

    La estimación/planificación se funda únicamente sobre las user-stories. Pero, entre esas user-stories echo en falta cosas importantes, y me temo que la planificación obtenida resulte entonces errónea.
    Observad la «Part IV: An Example». No aparecen requerimientos tan importantes como los relativos a: la arquitectura de la información, el sistema de navegación, el look&feel, etc. Tampoco se estiman: el trabajo de carga de contenidos, el set-up de los entornos de trabajo (PRE, PRO, etc.), el deployment, la elección del hosting, etc.

    En fin, me parece que el método está muy bien. Pero, estos otros requerimientos y estas otras cuestiones que acabo de ejemplificar, ¿cómo encajan? Si alguien puede ayudarme en este sentido estaría muy agradecido.
    Quizás el punto de vista expresado es cercano a la experiencia del desarrollador; pero algo lejano del equipo de arquitectura de la información y/o user-experience que también forma parte de un proyecto. ¿No os parece? ¿Conocéis algún libro con sugerencias para dejar satisfechos tantos a los ingenieros como a la gente de comunicación?

    Un saludo y gracias

  4. @Marco:

    Piensa que el tipo de requisitos que tu sugieres son más bien requisitos no funcionales. Estos se tratan o bien como restricciones de una historia o como historias no funcionales (que no se agendan en un sprint específico).

    En cualquier caso, nada impide que cuando una historia de usuario incluye temas como experiencia de usuario, se introduzcan tareas especificas de este aspecto del desarrollo cuando la historia se divide en tareas.

    También es cierto que en las metodologías ágiles existe el concepto de sprint cero. Seria durante ese sprint donde se establecen las bases del desarrollo: por ejemplo diseñando una arquitectura, seleccionando tecnología, construyendo una guia de estilo y usabilidad para la interfaz de usuario etc…

    La verdad es que no conozco documentación especifica sobre el tema y que como integrar las actividades de diseño de interfaz en Scrum es un tema recurrente. Supongo que no hay una receta para esto y que cada equipo tiene que encontrar su camino.

    ¡Un saludo!

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *