Resumen
El libro es un relato sobre el algoritmo del proceso de desarrollo, desde la idea hasta la implementación, utilizando técnicas ágiles. El proceso se desglosa en pasos y en cada paso se indican los métodos adecuados. El autor menciona que la mayoría de los métodos no son originales, sin pretender serlo. Sin embargo, un buen estilo de redacción y cierta coherencia en el proceso hacen que el libro sea muy útil.
La técnica clave del mapa de historias de usuario es la estructuración de ideas y la formulación de objetivos a lo largo del proceso vivido por el usuario.
Se puede exponer el transcurso del proceso de diferentes maneras. Se pueden organizar los pasos a medida que se alcanza un valor clave, o simplemente representar un día de trabajo de los usuarios tal como se desarrolla utilizando el sistema. El autor enfatiza que los procesos deben narrarse y contarse en forma de historias de usuario en el mapa del proceso, lo que dio lugar al nombre de mapa de historias de usuario.
¿A quién le interesa esto?
Para analistas de TI y gerentes de proyectos. Lectura obligatoria. Es fácil y agradable de leer, y el libro tiene un tamaño moderado.
Reseña
En su forma más simple, así es como funciona.
El visitante llega a la cafetería, elige los platos, hace el pedido, recibe la comida, come y paga.
Se pueden escribir los requisitos que queremos del sistema en cada etapa.
El sistema debe mostrar una lista de platos, con la composición, peso y precio de cada uno, y tener la capacidad de añadir a la cesta. ¿Por qué estamos seguros de estos requisitos? En la descripción 'estándar' de requisitos esto no está descrito y eso genera riesgos.
Los ejecutores que no entienden por qué es necesario, suelen hacer lo que no se necesita. Los ejecutores que no están involucrados en el proceso de creación de la idea, tampoco están involucrados en el resultado. Agile dice que debemos enfocarnos primero en las personas, en los consumidores, sus tareas y objetivos, no en el sistema.
Creamos personas, les damos detalles para empatizar y comenzamos a narrar historias desde la perspectiva de las personas.
El empleado de oficina, Zajar, salió a almorzar y quiere hacer una pausa rápida. ¿Qué necesita? La idea es que probablemente quiera un almuerzo de negocios. Otra idea es que quiere que el sistema recuerde sus preferencias, ya que está a dieta. Otra idea. Quiere que le traigan café de inmediato, porque está acostumbrado a beber café antes del almuerzo.
Y hay otro negocio (orgsonazh: un personaje que representa los intereses de alguna organización). El negocio quiere aumentar el ticket promedio, incrementar la frecuencia de compra y aumentar las ganancias. La idea es ofrecer platos inusuales de alguna cocina. Otra idea es introducir desayunos.
Las ideas se pueden y deben concretar, transformar y presentar en forma de user story. Como empleado del centro de negocios, Zajar, quiero que el sistema me reconozca para recibir el menú que tenga en cuenta mis preferencias. Como camarero, quiero que el sistema me avise cuándo debo acercarme a la mesa para que el cliente esté satisfecho con el servicio rápido. Y así sucesivamente.
Decenas de historias. ¿Luego priorización y backlog? Jeff señala los problemas que surgen: atorarse en pequeños detalles y perder la comprensión conceptual más la priorización de funciones crea una imagen fragmentada debido a la inconsistencia con los objetivos.
El camino del autor: priorizamos no la funcionalidad, sino el resultado = lo que el usuario obtiene al final.
Punto obvio no obvio: la sesión de priorización no se lleva a cabo con todo el equipo, ya que no es efectivo, sino con tres personas. El primero se encarga del negocio, el segundo de la experiencia del usuario y el tercero de la implementación.
Destacamos lo mínimo para resolver una tarea del usuario (solución mínima viable).
Detallamos las ideas de la primera prioridad mediante user stories, bocetos de diseño, limitaciones y reglas de negocio en el mapa de historias de usuarios a través de la narración y discusión con el equipo sobre lo que se necesita para los personajes y stakeholders en cada paso del proceso. Las demás ideas las dejamos sin desglosar, en el backlog de posibilidades.
El proceso se escribe en forma de tarjetas de izquierda a derecha, y las ideas en las tarjetas bajo los pasos del proceso. Es imprescindible discutir todo el camino de la historia junto con los miembros del equipo para fomentar la comprensión mutua.
El trabajo de esta manera crea una integridad que corresponde a los procesos.
Las ideas obtenidas necesitan ser verificadas. Un miembro del equipo se pone el sombrero del personaje y vive en su mente durante un día, resolviendo su tarea. Existe la posibilidad de que no vea los avances, creando las tarjetas desde cero, mientras el equipo descubre alternativas.
Luego se realiza un desglose para la evaluación. Para esto, se necesitan tres personas: el responsable de la experiencia del usuario, un desarrollador y un probador con su pregunta favorita: “¿Y si…?”.
En cada etapa, la discusión se centra en el mapa de procesos de la historia del usuario, lo que permite, manteniendo en mente la tarea del usuario, crear una comprensión integral.
¿Es necesaria la documentación según el autor? Sí, es necesaria. Pero como notas que permiten recordar de qué se acordó. Involucrar a alguien del exterior nuevamente requiere discusión.
El autor no profundiza en la suficiencia de la documentación, haciendo hincapié en la necesidad de discusiones. (Sí, se necesita documentación, independientemente de lo que digan quienes no comprenden en profundidad el enfoque ágil). Además, abordar solo parte de las posibilidades puede llevar a la necesidad de rehacer todo el sistema. El autor señala el riesgo de una sobreelaboración si no se acierta con la idea.
Para mitigar riesgos, es necesario recibir rápidamente retroalimentación sobre el producto en desarrollo para minimizar el daño de crear un producto “incorrecto”. Se hace un esbozo de la idea: se valida con el usuario, se esbozan prototipos de la interfaz: se valida con el usuario, etc. (Se menciona brevemente cómo validar prototipos de software). Los objetivos de crear software, especialmente en la etapa inicial, son aprender a través de la obtención de retroalimentación rápida, por lo que el primer producto creado son esbozos que pueden probar o refutar una hipótesis. (El autor se basa en el trabajo de Eric Ries “El Startup Lean”).
El mapa de historias ayuda a establecer comunicaciones si la implementación se lleva a cabo por varios equipos. ¿Qué debe incluir el mapa? Lo que se necesita para apoyar la conversación. No solo historias de usuario (quién, qué, por qué), sino ideas, hechos, esbozos de interfaces, etc.
Al dividir las tarjetas en el mapa de historias en varias líneas horizontales, se pueden separar los trabajos en lanzamientos: resaltar el mínimo necesario, la capa de expansión funcional y los detalles adicionales.
Repasamos las historias en el mapa del proceso.
El empleado llegó para el almuerzo.
¿Qué quiere? Velocidad de servicio. Que su comida ya esté en la mesa o, al menos, en la bandeja. Oops, un paso perdido: el empleado decidió comer. Ingresó al sistema y eligió una opción de almuerzo de negocios. Vio las calorías y la correspondencia con el valor nutricional para seguir una dieta y no engordar. Vio imágenes del plato para decidir si comería en ese lugar o no.
¿Luego se irá a recoger su almuerzo y comer? ¿O tal vez le entregarán el almuerzo en la oficina? Entonces, el siguiente paso del proceso es elegir el lugar para comer. Quiere ver el tiempo de entrega y cuánto costará, para decidir dónde gastar su tiempo y energía: bajando o trabajando. Quiere ver la ocupación del café, para no tener que esperar en colas.
Luego, el empleado llegó al café. Quiere ver su bandeja para recogerla y dirigirse a comer. El café quiere recibir dinero para ganar en el servicio. El empleado quiere perder el mínimo de tiempo en los pagos en el café, para no desperdiciar valioso tiempo sin beneficio. ¿Cómo hacerlo? Pagar por adelantado o, por el contrario, después del servicio de forma remota. O pagar en el momento a través de un quiosco. ¿Cuál de estas es la más importante? ¿Cuántas personas están dispuestas a pagar con tarjeta bancaria por su almuerzo? ¿Cuántas personas confiarán en almacenar su número de tarjeta para pagos recurrentes en esta cafetería? Sin una investigación de campo, no está claro, necesitaríamos una prueba.
En cada paso del proceso, es necesario proporcionar alguna funcionalidad; para ello se debe tomar como base alguna persona y elegir qué es más importante para ella (esa misma triada de elegidos). Se completó la historia = se creó una solución viable.
A continuación, viene la especificación. El cliente quiere ver la ocupación del café, para no hacer fila. ¿Qué es lo que quiere concretamente?
Ver la previsión de cuántas personas habrá en 15 minutos, cuando él llegue allí.
Ver el tiempo promedio de atención en el café y su dinámica para media hora más adelante.
Ver la situación y la dinámica de ocupación de las mesas.
¿Y si el sistema de pronóstico da un resultado confuso o deja de funcionar?
Ver a través de video las colas en el café, así como la ocupación de las mesas. Hmm, ¿por qué no hacerlo en primer lugar?!
El autor menciona un pequeño ejercicio para practicar: intenta imaginar qué haces por la mañana después de despertarte. Una tarjeta = una acción. Agrupa las tarjetas (en lugar de moler café, toma una bebida energizante) para eliminar los detalles individuales, enfocándote no en el método de ejecución, sino en el objetivo.
Para quién es este libro: para analistas de TI y gerentes de proyecto. Imprescindible para leer.
Aplicaciones
Las discusiones y la toma de decisiones son más efectivas en grupos de entre 3 y 5 personas.
Escribe en la primera tarjeta lo que debe ser desarrollado, en la segunda, corrige lo que hiciste en la primera, y en la tercera, corrige lo que se hizo en la primera y en la segunda.
Prepara las historias como pasteles: no escribiendo la receta, sino averiguando para quién, con qué motivo y para cuántas personas es el pastel. Si divides la implementación, no lo hagas en la elaboración de capas, crema, etc., sino en la creación de pequeños pasteles terminados.
El desarrollo de software es similar a la creación de una película, donde es necesario elaborar y pulir cuidadosamente el guion, organizar la escena, los actores, etc., antes de comenzar el rodaje.
Siempre faltarán recursos.
El 20% de los esfuerzos produce resultados significativos, el 60% produce resultados inciertos, y el 20% de los esfuerzos es perjudicial; por eso es importante enfocarse en el aprendizaje y no desanimarse ante un resultado negativo.
Comunica directamente con el usuario, ponete en su lugar. Enfócate en algunos problemas.
La elaboración y desarrollo de la historia para la evaluación es la parte más tediosa de scrum; haz que las discusiones sean de pie en modo acuario (en la pizarra discuten 3-4 personas; si alguien quiere participar, reemplaza a alguien).
Fuente: habr.com
