Anotación
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 ser originales. Pero un buen estilo de presentación y cierta integridad del proceso hacen que el libro sea muy útil.
La técnica clave del mapa de historia del usuario es la estructuración de ideas y declaraciones a medida que el usuario pasa por el proceso.
Al mismo tiempo, el proceso puede describirse de diferentes maneras. Puede crear pasos a medida que alcanza un valor clave, o simplemente puede tomar e imaginar el día laborable de los usuarios, cómo funciona usando el sistema. El autor se centra en el hecho de que los procesos deben ser establecidos, pronunciados en forma de historial de usuario en el mapa de proceso, que era el nombre del mapa de historia del usuario.
Quien lo necesita
Para analistas de TI y gerentes de proyectos. Lectura requerida. Se lee fácil y agradablemente, el libro es de tamaño mediano.
Retroalimentación
En su forma más simple, cómo funciona.
Un visitante llega a una cafetería, elige platos, hace un pedido, recibe comida, come, paga.
Puede escribir los requisitos que queremos del sistema en cada etapa.
El sistema debe mostrar una lista de platos, cada composición de plato, peso y precio, y poder agregar a la cesta. ¿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 generalmente no entienden lo que se necesita. Los artistas que no están involucrados en el proceso de creación de una idea no están involucrados en el resultado. Agile dice, así que centrémonos principalmente no en el sistema, sino en las personas, los consumidores, sus tareas y objetivos.
Hacemos personas, por empatía les damos detalles y por parte de las personas comenzamos a exponer historias.
El empleado de oficina Zahar se fue a almorzar y quiere comer algo rápido. ¿Qué necesita él? La idea es que probablemente quiera un almuerzo de negocios. Otra idea que quiere que el sistema recuerde es su preferencia, porque está a dieta. Otra idea Quiere tomar café de inmediato, porque está acostumbrado a tomar café antes de la cena.
Y todavía hay negocios (el carácter organizacional es un personaje que representa los intereses de alguna organización). El negocio quiere aumentar la factura promedio, aumentar la frecuencia de las compras, aumentar las ganancias. La idea es ofrecer platos inusuales de algún tipo de cocina. Otra idea: vamos a presentar el desayuno.
Las ideas pueden y deben concretarse, transformarse y diseñarse como una historia de usuario. Como empleado del centro de negocios Zakhar, quiero que el sistema me reconozca, para que reciba un menú basado en mis preferencias. Como camarero, quiero que el sistema me notifique cuándo acercarme a la mesa para que el cliente esté satisfecho con el servicio rápido. Y así sucesivamente.
Docenas de historias. ¿Más priorización y retraso? Jeff señala los problemas que surgen: la vinculación en pequeños detalles y la pérdida de la comprensión conceptual más la priorización de lo funcional crea una imagen desgarrada debido a la inconsistencia con los objetivos.
Ruta del autor: priorizamos no lo funcional, sino el resultado = lo que el usuario obtiene como resultado.
Un punto obvio no obvio: la sesión prioritaria no es realizada por todo el equipo, porque es ineficaz, sino por tres personas. El primero es responsable de los negocios, el segundo por la experiencia del usuario y el tercero por la implementación.
Seleccionamos un mínimo para resolver un problema de usuario (la solución mínima viable).
Detallamos las ideas de primera prioridad con la ayuda de una historia de usuario, bosquejamos diseños, restricciones y reglas comerciales en el mapa de historias de usuario contando y discutiendo con el equipo lo que las personas y las partes interesadas necesitan en cada paso del proceso. Las ideas restantes se dejan sin ensamblar, en la acumulación de oportunidades.
El proceso está escrito en forma de tarjetas de izquierda a derecha e ideas sobre las tarjetas en los pasos del proceso. Necesariamente, el camino de toda la historia debe ser pronunciado junto con el equipo para la apariencia de comprensión mutua.
La exposición de esta manera crea integridad para la coincidencia de procesos.
Las ideas que necesitas consultar. Ningún miembro del equipo se pone el sombrero de una persona y vive en la cabeza del día de la persona, resolviendo su problema. Es posible una variante cuando no ve los desarrollos, crea nuevas tarjetas y el equipo descubre alternativas.
Luego profundice para la evaluación. Tres personas son suficientes para esto. Responsable de la experiencia del usuario, desarrollador, probador con una pregunta favorita: "¿Qué pasaría si ...?".
En cada etapa, la discusión va en un mapa de los procesos del historial del usuario, lo que permite tener en cuenta la tarea del usuario para crear una comprensión.
¿Necesito documentación según el autor? Sí lo necesito Pero como notas, permitiéndonos recordar lo que acordamos. La participación de una persona del exterior nuevamente 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, no importa cuán ágiles sean las personas que no son profundas en la comprensión). Además, el estudio de solo una parte de las capacidades puede llevar a la necesidad de una alteración completa de todo el sistema. El autor señala el riesgo de elaboración excesiva en el caso cuando no han adivinado la idea.
Para eliminar riesgos, es necesario recibir rápidamente comentarios sobre el producto creado para minimizar el daño a la creación del producto "incorrecto". Hicieron un bosquejo de la idea, validado por el usuario, un bosquejo de los prototipos de interfaz, validado por el usuario, etc. (Por separado, se indica un poco cómo validar prototipos de programas). Los objetivos de la creación de software, especialmente en la etapa inicial, son la capacitación a través de la retroalimentación rápida; en consecuencia, el primer producto creado es un esquema que puede probar o refutar una hipótesis. (El autor se basa en el trabajo de Eric Rice, "Startup by Lean Methodology").
Un mapa de historia ayuda a establecer comunicación si la implementación es proporcionada por varios equipos. ¿Qué debería estar en el mapa? Lo que necesitas para apoyar la conversación. No solo la historia del usuario (quién, qué, por qué), sino también ideas, hechos, resumen de interfaces, etc.
Al dividir las tarjetas en el mapa histórico en varias líneas horizontales, puede dividir el trabajo en versiones: seleccione el mínimo, la capa de funcionalidad de construcción y arcos.
Contamos historias en el mapa del proceso.
El empleado vino a almorzar.
¿Qué quiere él? Velocidades de servicio. Para que su cena ya lo esté esperando en la mesa o al menos en una bandeja. Opa: un paso perdido: el empleado quería comer. Ingresó al sistema y eligió la opción de almuerzo de negocios. Vio el contenido calórico y el valor nutricional para mantener una dieta y no engordar. Vio fotos del plato para decidir si comería en este lugar o no.
Luego, ¿irá a almorzar y almorzar? ¿O tal vez almorzará en la oficina? Entonces el paso del proceso es la elección del lugar de la comida. Quiere ver el momento en que será entregado y cuánto costará elegir dónde pasar el tiempo y el esfuerzo: bajar o trabajar. Quiere ver el café ocupado para no empujarse en las filas.
Luego, el empleado vino al café. Quiere ver su bandeja, tomarla e inmediatamente ir a cenar. El café quiere aceptar dinero para ganar dinero en mantenimiento. Un empleado quiere perder un mínimo de tiempo en los asentamientos con un café, para no perder un tiempo precioso sin beneficio. Como hacerlo Pague por adelantado o viceversa después de realizar el mantenimiento a distancia. O paga en este momento usando un quiosco. ¿Cuál de estos es el más básico? ¿Cuántas personas están dispuestas a pagar con tarjeta de crédito por el almuerzo? ¿Cuántas personas confían en el almacenamiento del número de tarjeta para pagos repetidos de este comedor? Sin investigación de campo, no está claro si se necesitan pruebas.
En cada paso del proceso, debe proporcionar al menos alguna funcionalidad, para ello debe tomar como base a algún tipo de persona y elegir lo que es más importante para él (los mismos tres electores). Pasó la historia hasta el final = tomó una decisión viable.
El siguiente es el detalle. El cliente quiere ver la carga de trabajo del café para no forzar colas. ¿Qué es exactamente lo que quiere?
Mire el pronóstico cuántas personas habrá en 15 minutos, cuándo irá allí
Mire el tiempo promedio de servicio en un café y su dinámica con media hora de anticipación
Observe la situación y la dinámica del empleo de tablas.
Pero, ¿qué pasa si el sistema de pronóstico da un resultado incomprensible o deja de funcionar?
Mire a través de las líneas de video en el café, así como el empleo de mesas. Hmm, ¿por qué no hacerlo primero?
El autor señala un pequeño ejercicio para practicar: trata de imaginar lo que estás haciendo en la mañana después de despertarte. Una carta = una acción. Amplíe las tarjetas (en lugar de moler café, tome una bebida refrescante) para eliminar detalles individuales, teniendo en cuenta no la forma de implementación, sino el objetivo.
Para quién este libro es para analistas de TI y gerentes de proyectos. Lectura requerida.
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 ser desarrollado, en la segunda, para arreglar lo que se hizo en la primera, en la tercera, para arreglar lo que se hizo en la primera y segunda.
Prepare historias como pasteles, no escribiendo una receta para hacer, sino descubriendo a quién, por qué razón, cuántas personas tienen un pastel. Si desglosa la implementación, no se trata de la fabricación de pasteles, crema, etc., sino de la fabricación de pasteles pequeños terminados.
El desarrollo de software es similar a hacer una película cuando necesitas desarrollar y lamer cuidadosamente un guión, organizar una escena, actores, etc., antes de que comience la filmación.
Los recursos siempre serán escasos.
El 20% de los esfuerzos dan un resultado tangible, el 60% dice que no está claro que el 20% de los esfuerzos sean perjudiciales, por eso es importante centrarse en el aprendizaje y no desesperarse en caso de un resultado negativo.
Comunícate directamente con el usuario, siente en sus zapatos. Centrarse en algunos problemas.
Detallar y elaborar el historial para la evaluación es la parte más triste de scrum, hacer que las discusiones se pongan de pie en un modo de acuario (3-4 personas discuten en el tablero, si alguien quiere participar, reemplaza a alguien).