Abstracto
El libro es un algoritmo narrado para llevar a cabo el proceso de desarrollo desde la idea hasta la implementación utilizando técnicas ágiles. El proceso se presenta en pasos y en cada paso se indican los métodos para el paso del proceso. El autor señala que la mayoría de los métodos no son originales, sin pretender serlo. Pero el buen estilo de escritura y cierta integridad del proceso hacen que el libro sea muy útil.
Una técnica clave del mapeo de historias de usuario es estructurar ideas y actuaciones a medida que el usuario avanza en el proceso.
Al mismo tiempo, el proceso se puede describir de diferentes maneras. Puede crear pasos a medida que logra un valor clave, o simplemente puede imaginar la jornada laboral de los usuarios a medida que utilizan el sistema. El autor se centra en el hecho de que los procesos deben describirse, hablarse en forma de una historia de usuario en un mapa de procesos, que es lo que nos dio el nombre de mapa de historia de usuario.
Quien lo necesita
Para analistas de TI y directores de proyectos. Una lectura obligada. Fácil y agradable de leer, el libro es de tamaño mediano.
retirada
En su forma más simple, así es como funciona.
Un visitante llega a una cafetería, selecciona platos, hace un pedido, recibe comida, come y paga.
Podemos escribir requisitos para lo que queremos del sistema en cada etapa.
El sistema debe mostrar una lista de platos, cada plato tiene una composición, peso y precio y poder agregarlo al carrito. ¿Por qué confiamos en estos requisitos? Esto no se describe en la descripción "estándar" de los requisitos y esto crea riesgos.
Los artistas que no entienden por qué esto es necesario suelen hacer lo incorrecto. Los artistas que no participan en el proceso de creación de una idea no participan en el resultado. Agile dice: centrémonos principalmente no en el sistema, sino en las personas, en los consumidores, sus tareas y objetivos.
Creamos personajes, les damos detalles para generar empatía y comenzamos a contar historias desde el lado de los personajes.
Zakhar, empleado de oficina, fue a almorzar y quiere tomar un refrigerio rápido. ¿Qué necesita? La idea es que probablemente quiera un almuerzo de negocios. Otra idea es que quiere que el sistema recuerde sus preferencias, porque está a dieta. Otra idea. Quiere que le traigan café de inmediato porque está acostumbrado a tomar café antes del almuerzo.
Y también está el negocio (un personaje organizacional es un personaje que representa los intereses de una organización). Las empresas quieren aumentar el cheque promedio, aumentar la frecuencia de las compras y aumentar las ganancias. La idea es ofrecer platos inusuales de alguna cocina. Otra idea: introduzcamos el desayuno.
Las ideas pueden y deben concretarse, transformarse y presentarse en forma de historia de usuario. Como empleado del Zakhar Business Center, quiero que el sistema me reconozca para poder recibir un menú según mis preferencias. Como camarero, quiero que el sistema me avise cuando acercarme a la mesa para que el cliente quede satisfecho con un servicio rápido. Etcétera.
Decenas de historias. ¿Lo siguiente es la priorización y el trabajo pendiente? Jeff señala los problemas que surgen: estancarse en pequeños detalles y perder la comprensión conceptual, además de priorizar la funcionalidad, crea una imagen irregular debido a la inconsistencia con los objetivos.
El camino del autor: no priorizamos la funcionalidad, sino el resultado = lo que el usuario obtiene al final.
Un punto obvio que no es obvio: la sesión de priorización no la realiza todo el equipo, porque es ineficaz, sino tres personas. El primero es responsable del negocio, el segundo de la experiencia del usuario y el tercero de la implementación.
Seleccionemos el mínimo para resolver un problema de usuario (solución mínima viable).
Detallamos las ideas de primera prioridad utilizando historias de usuarios, bocetos de diseño, restricciones y reglas comerciales en el mapa de historias de usuario al contar y discutir con el equipo lo que las personas y las partes interesadas necesitan en cada paso del proceso. Dejamos las ideas restantes sin examinar en la acumulación de oportunidades.
El proceso está escrito en tarjetas de izquierda a derecha, con ideas en tarjetas debajo de los pasos del proceso. Es imperativo que el camino a lo largo de toda la historia se discuta junto con los miembros del equipo para garantizar el entendimiento mutuo.
La elaboración de esta manera crea integridad en el cumplimiento de los procesos.
Es necesario poner a prueba las ideas recibidas. Alguien que no es miembro del equipo se pone el sombrero de la persona y vive el día de la persona en su cabeza, resolviendo su problema. Es posible que no vea los desarrollos, vuelva a crear mapas y el equipo descubra alternativas por sí mismo.
Luego están los detalles para la evaluación. Para ello son suficientes tres personas. Responsable de experiencia de usuario, desarrollador, tester con una pregunta favorita: “¿Y si…”.
En cada etapa, la discusión sigue un mapa de procesos del historial del usuario, que permite tener en cuenta la tarea del usuario para crear una comprensión coherente.
¿Es necesaria la documentación en opinión del autor? Si, lo necesito. Sino como notas que te permitan recordar lo acordado. Involucrar nuevamente a un extraño requiere discusión.
El autor no profundiza en el tema de la suficiencia de la documentación, centrándose en la necesidad de discusión. (Sí, se necesita documentación, sin importar cómo la afirmen las personas que no tienen un conocimiento profundo de Agile). Además, la elaboración de sólo una parte de las capacidades puede llevar a la necesidad de una reelaboración completa de todo el sistema. El autor señala el riesgo de una elaboración excesiva en el caso de que la idea sea errónea.
Para eliminar riesgos, es necesario recibir rápidamente comentarios sobre el producto que se está creando para minimizar el daño de crear el producto "incorrecto". Hicimos un boceto de la idea - la validamos con el usuario, esbozamos prototipos de interfaz - la validamos con el usuario, etc. (Por separado, hay un poco de información sobre cómo validar prototipos de programas). El objetivo de la creación de software, especialmente en la etapa inicial, es aprender mediante la recepción rápida de comentarios, por lo que el primer producto creado son bocetos que pueden probar o refutar una hipótesis. (El autor se basa en el trabajo de Eric Ries “Startup utilizando metodología Lean”).
Un story map ayuda a mejorar la comunicación cuando la implementación se lleva a cabo en varios equipos. ¿Qué debería estar en el mapa? Lo que necesitas para mantener la conversación. No solo una historia de usuario (quién, qué, por qué), sino ideas, hechos, bocetos de interfaz, etc.
Al dividir las tarjetas en el mapa histórico en varias líneas horizontales, puede dividir el trabajo en lanzamientos: resalte lo mínimo, una capa de funcionalidad creciente y arcos.
Contamos historias en el mapa de procesos.
Un empleado vino a almorzar.
¿Qué es lo que quiere? Velocidades de servicio. Para que su almuerzo ya le esté esperando en la mesa o al menos en una bandeja. Vaya, un paso en falso: el empleado quería comer. Ingresó y seleccionó la opción de almuerzo de negocios. Vio el contenido calórico y nutricional para ayudarle a hacer dieta y no ganar peso. Vio fotografías del plato para decidir si comería en ese lugar o no.
A continuación, ¿irá a almorzar y cenar? ¿O tal vez le entregarán el almuerzo en su oficina? Luego el paso del proceso es elegir un lugar para comer. Quiere ver cuándo se lo entregarán y cuánto le costará, para poder elegir dónde gastar su tiempo y energía: bajar las escaleras o ir a trabajar. Quiere ver qué tan ocupado está el café para no tener que hacer cola.
Entonces el empleado llegó al café. Quiere ver su bandeja para cogerla e ir directo a cenar. El café quiere aceptar dinero para ganar dinero con el servicio. El empleado quiere perder un mínimo de tiempo en los acuerdos con la cafetería, para no perder un tiempo precioso inútilmente. ¿Cómo hacerlo? Pague por adelantado o viceversa después del servicio de forma remota. O pague en el acto mediante un quiosco. ¿Qué es lo más importante de esto? ¿Cuántas personas están dispuestas a pagar el almuerzo con tarjeta bancaria? ¿Cuántas personas confiarían en esta cantina para almacenar su número de tarjeta para pagos repetidos? Sin investigación de campo no está claro, se necesitan pruebas.
En cada paso del proceso es necesario proporcionar de alguna manera funcionalidad, para ello es necesario tomar como base a alguna persona y elegir lo que es más importante para ella (los mismos tres selectores). Seguí la historia hasta el final = encontré una solución viable.
Luego vienen los detalles. El cliente quiere ver qué tan ocupado está el café para no tener que hacer cola. ¿Qué quiere exactamente?
Ver el pronóstico de cuántas personas habrá en 15 minutos cuando llegue
Consulta el tiempo medio de servicio en una cafetería y su dinámica con media hora de antelación
Ver la situación y dinámica de ocupación de mesas
¿Qué pasa si el sistema de pronóstico da un resultado poco claro o deja de funcionar?
Observa a través de vídeo las colas en la cafetería, así como la ocupación de las mesas. Hmm, ¿por qué no hacer eso primero?
El autor señala un pequeño ejercicio para practicar: intenta imaginar lo que haces por la mañana después de despertarte. Una carta = una acción. Amplíe las tarjetas (en lugar de moler café, beba una bebida vigorizante) para eliminar detalles individuales, centrándose no en el método de implementación, sino en el objetivo.
¿Para quién es este libro? Analistas de TI y directores de proyectos. Una lectura obligada.
Aplicaciones
La discusión y la toma de decisiones son efectivas en grupos de 3 a 5 personas.
Escriba en la primera tarjeta lo que necesita desarrollarse, en la segunda, corrija lo que hizo en la primera, en la tercera, corrija lo que se hizo en la primera y en la segunda.
Prepare historias como si fueran pasteles: no escribiendo una receta, sino averiguando quién, para qué ocasión y para cuántas personas es el pastel. Si desglosamos las ventas, no se trata de la producción de pasteles, nata, etc., sino de la producción de pequeños pasteles preparados.
El desarrollo de software es similar a hacer una película, cuando es necesario desarrollar y pulir cuidadosamente el guión, organizar la escena, los actores, etc. antes de comenzar el rodaje.
Siempre habrá escasez de recursos.
El 20% de los esfuerzos producen resultados tangibles, el 60% dan resultados incomprensibles, el 20% de los esfuerzos son perjudiciales; por eso es importante centrarse en aprender y no desesperarse en caso de un resultado negativo.
Comunicate directamente con el usuario, siéntete en su lugar. Concéntrese en algunos problemas.
Detallar y desarrollar la historia para su evaluación es la parte más aburrida del scrum, hacer que las discusiones se mantengan en modo acuario (3-4 personas discuten en la pizarra, si alguien quiere participar, reemplaza a alguien).
Fuente: habr.com