Actividad E5 – Story Map

Que partes del articulo de Jeff Patton “how to slices it” podrían servirles en su trabajo actual. (5 puntos)

http://agileproductdesign.com/writing/how_you_slice_it.pdf

Anuncios
Acerca de

Soy uno de los siete fundadores de FDV Solutions. Como CEO de la compañía, ejecuto la estrategia general de FDV Solutions y la supervisión de las distintas áreas de negocios y gerentes que me reportan: Ventas y Marketing, Operaciones, Administración y Finanzas, y Recursos Humanos. Además tengo un rol activo en las distintas acciones institucionales de la empresa, siendo representante de la misma en diversas cámaras e instituciones, como la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI). Soy graduado en la Carrera de Ingeniería en Informática, y cuento además, con un posgrado en comercialización para ingenieros del Instituto tecnológico de Buenos Aires (ITBA). Actualmente estoy finalizando un máster en Ciencias Cognitivas de la Universidad de Buenos Aires y soy docente universitario en dicha casa de estudios. Soy también Fundador de Proyecto Nahual (www.nahual.com.ar), una iniciativa que busca la inclusión social y la inserción laboral a partir de la capacitación tecnológica en programación y testing de software. Participo además activamente de la Comisión de Inclusión de CESSI.

Publicado en Sin categoría
10 comments on “Actividad E5 – Story Map
  1. Jorge Smulevici dice:

    Me parece muy útil para incorporar al trabajo del día a día y más aun cuando se trabaja con entregas incrementales la forma de trabajo con tarjetas y métodos gráficos como Story Map. Me parece aún más importante, como explica el artículo, describir los requerimientos desde el lado del usuario y que valor le aporta al mismo antes que dar detalles técnicos de la implementación o tomar requerimientos dejando de lado que aportan.
    De esta manera se tiene una perspectiva más clara de como priorizar el trabajo y que incluir en las primeras entregas.

  2. Juan Dausa dice:

    La charla inicial en donde se discute y se prioriza el backlog inicial me parece espectacular. Actualmente estoy participando en un proyecto en el cual sabemos cual es el fin, pero no tenemos ni la menor ni de que ni de cuando vamos a hacer para lograrlo. Me parece que la discución inicial es excelente porque brinda al grupo de desarrollo una concepción del proyecto que leyendo un documento sería muy difícil de obtener. Además les da a los clientes la posibilidad de ver y opinar sobre la planificación, decrementando la posibilidad de que los proyectos se cancelen en los primeros meses por falta de interés. Creo que esta herramienta sería muy útil en mi trabajo para orientar al equipo de desarrollo.
    Saludos, Juan.

  3. iangrigiani dice:

    Actualmente trabajo en un lugar muy influenciado por la política y donde tenemos que trabajar con comunicadores y otras personas que no son desarrolladores. Hay un parrafo en el texto que me pareció fundamental (a la hora de armar el paso inicial)
    “Before you begin, you need to choose a good cross section of folks to participate in reating the model. While the model could be prepared by one person, I wouldn’t ecommend it. Having a mix of people will help increase understanding of the software hroughout the team”
    Sería fundamental para nosotros poder armar los primeros pasos con gente de todas las partes involucradas, tanto para aprender el contexto como para entender los motivos de ciertas decisiones

  4. Rob Herman dice:

    Me sentí muy identificado en la introducción del artículo, en donde uno planifica etapas tempranas geniales, con retorno de valor inmediato, pero el producto terminado en una de esas etapas todavía no resuelve los problemas del cliente, y lo termina dejando de usar.

    En mi trabajo puedo aplicar estas técnicas tanto para productos propios de la empresa, como para soluciones a medida para clientes (especialmente para los casos en donde el cliente nos presenta una cantidad de requerimientos que derivan en un “transbordador espacial”).

    En mi opinión el paso 5 es clave, y algo que uno omite muchas veces (creo que los pasos anteriores, en menor medida quizá uno los aplica más comunmente). Si uno identifica todos estos quiebres de lógica, luego es más facil dentificar eslabones de funcionalidades vitales faltantes al diagramar una etapa.

  5. Es una muy buena herramienta para identificar las funcionalidades que están incluidas en el producto a desarrollar, dividirlas en tareas pequeñas y ver las relaciones entre ellas definiendo la importancia de cada una para poder priorizarlas en base a ello (utilizando diferentes criterios muy claros en el gráfico) y asi definir etapas que realmente ofrezcan un valor adecuado para el cliente y los usuarios.

    Ademas me parece muy bueno que se involucre a las personas interesadas en el proyecto en este proceso a modo de aclarar cosas que no estén del todo resueltas y generar nuevas dudas y así todos los integrantes del equipo y otros interesados estén bien informados acerca del proyecto y sepan en que están trabajando.

    El artículo me pareció muy útil a modo de resumir y nombrar los principales objetivos de story mapping. En el trabajo no suelo aplicar esta herramienta pero no voy a dudar en hacerlo, por mas que haya proyectos avanzados me parece bueno adaptar esta herramienta para etapas avanzadas (aunque tempranas) a modo de asegurarme que se esta siguiendo el camino correcto.

    Saludos!

  6. Daniel Mugica dice:

    Hay varias partes importantes tratadas en el artículo.
    Lo primero es extender y apoyar el comentario hecho por iangrigiani dado que trabajamos en el mismo lugar. Nuestro trabajo incluye a gente de áreas muy diversas, con diferentes tipo de conocimiento y diferente forma de trabajar, requiriendo muchas veces lo mismo pero queriendo obtenerlo desde otra perspectiva. En consecuencia sería más que importante contar con gente de todas las áreas involucradas al comenzar, eso nos permitiría varias cosas importantes, desde el consenso y la obtención de información con diferentes puntos de vista. La cantidad de trabajo disminuiría y sería mucho más prolija, quedando cada área con una sensación de conformidad mayor.
    A su vez lo anterior se relaciona muchísimo con los requerimientos y la forma de obtener los mismos, dado que sería mucho más claros y completos, priorizando y refinando el backlog de manera mas correcta.
    Por último el paso tres (place cards in sequential order) me parece una buena metodología para visualizar la criticidad del trabajo a realizar rápidamente, lo que permite a su vez que todos entiendan rápidamente la situación y posteriormente puedan dar un opinión o ideas.

  7. Verónica D'Alesio dice:

    En mi trabajo se utiliza una metodología propia, bastante tradicional y burocrática donde los requerimientos ya vienen conformados y priorizados por el cliente (con el soporte de un sector que no es desarrollo).
    Igualmente de forma interna podemos aplicar desde el step 2 en adelante para determinar las etapas/releases que se pueden ofrecer y armar la propuesta del plan de desarrollo (no contamos con la participación del cliente directo sino de un representante -o varios- que pertenecen a la empresa pero que se dedican al soporte directo al cliente/negocio).
    Creo que de todos los steps el que inmediatamente nos beneficiaria incorporar es el 5 pero no para identificar procesos, sino desagregando un feature poder identificar los distintos roles/perfiles según sus funcionalidades particulares, lograríamos identificar rápidamente las variantes y opciones (la situación que tenemos que sobre una misma “vista” se pide exponer distintas opciones y herramientas según el rol/perfil del usuario que accede, si bien esto se habla y vuelca en una minuta o documentación creo que al utilizar esta forma gráfica ahorariamos tiempo e idas y vueltas).

  8. Leandro Linich dice:

    Es difícil separar un punto en particular para ser utilizado por si mismo. El método en general me parece muy útil.

    Me quedo con la conclusión que resume toda la utilidad del mismo: “Incremental release may be one of the more valuable aspects of the various Agile development methodologies. An early release can help capture market share, generate early return on investment, and reduce money risked on software development. A strong early release can increase those benefits immensely. The model we’ve built can give you a better picture of your software’s features and help your organization construct the most useful and coherent early release possible”

  9. Marcelo Ruiz dice:

    En el lugar donde trabajo utilizamos mucho esta técnica con buenos resultados, así que voy a comentar las partes del artículo que me parece que son las más importantes:

    Creo que lo más importante tiene que ver con la participación de todas las personas involucradas, desde gente de negocio que tiene claro cómo funcionan sus procesos, usuarios finales que son los que se van a ver afectados por lo que vayamos a construir y gente técnica que tenga idea de qué es lo que se puede hacer. Esto otorga una perspectiva amplia para comenzar y no terminar haciendo algo que no sirva.

    Luego el tema de ir ordenando las tarjetas según la secuencia de uso y su frecuencia es muy importante para tener un conocimiento compartido de cómo funciona el negocio. Esto es muy útil, sobre todo para los desarrolladores que muchas veces codean sin saber para qué.

    Por último, lo más importante me parece que tiene que ver con ir dividiendo los releases de acuerdo a la importancia de los features. De esta manera en el primer reléase podemos obtener la funcionalidad mínima necesaria y con eso empezar a planificar.

    Algo que no se menciona en el artículo, o por lo menos no lo vi tan claro, es que luego de que el primer reléase está en calle podemos observar si el comportamiento es cómo lo esperábamos y eventualmente revisar los otros releases que habíamos planificado y reordenar los features. Para ello es necesario que el Story Map esté visible y sea trasladable. En nuestro caso lo tenemos en un afiche que puede ser transportado a una sala de reuniones. El hecho de usar postits para los features también nos ayuda a moverlos en el afiche.

    Lo último que quería mencionar es que el tema no se agota con el Story Map. Una vez definidos los releases y los features de cada uno, se debe seguir trabajando sobre ellos de manera de tener más detalle de cada uno. Para esto nos es muy útil realizar Workshops de Especificación. Esta es una idea que surge del libro Bridging the Communication Gap.
    http://www.acceptancetesting.info/key-ideas/specification-workshop/

    Les dejo una foto de un Story Map que hicimos en las oficinas del cliente
    http://postimg.org/image/l2whnho5p/

  10. Juan Manuel Agüero dice:

    A partir de la clase, y del artículo, empezamos a “cortar” las funcionalidades de lo van a ser los próximos dos servicios que estamos implementando en el trabajo.

    Del artículo, lo que mas nos serviría o sirve (ya que lo estamos usando) es lo que el autor llama “System span”. Esto es clave, ya que tenemos clientes reales a los que les vamos a presentar el servicio y tuvimos malas experiencias cuando les presentamos un “killer feature” pero descuidamos partes esenciales del flujo normal de trabajo.

    La parte en donde mas nos aporta tener un system span es en tener un buen ROI con respecto al tiempo que invertimos en el desarrollo.
    No podemos pasarnos un año entero desarrollando ya que perderíamos clientes, pero tampoco podemos entregar un producto que no resuelva todo el negocio de dicho cliente.

    Mediante los system span podemos tomar decisiones mas claras a la hora de qué implementar y qué dejar afuera.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: