anotación
O libro é un algoritmo narrado para levar a cabo o proceso de desenvolvemento dende a idea ata a implementación mediante técnicas áxiles. O proceso exponse en pasos e en cada paso indícanse os métodos para o paso do proceso. O autor sinala que a maioría dos métodos non son orixinais, sen pretender ser orixinais. Pero o bo estilo de escritura e certa integridade do proceso fan que o libro sexa moi útil.
Unha técnica clave de mapeo de historias de usuario é estruturar ideas e actuacións a medida que o usuario avanza polo proceso.
Ao mesmo tempo, o proceso pódese describir de diferentes xeitos. Podes crear pasos a medida que consigas un valor clave ou simplemente podes tomar e imaxinar a xornada laboral dos usuarios a medida que pasa usando o sistema. O autor céntrase no feito de que os procesos teñen que ser esbozados, falados en forma de historia de usuario nun mapa de procesos, que é o que nos deu o nome de mapa de historias de usuarios.
Quen o necesita
Para analistas de TI e xestores de proxectos. Unha lectura obrigada. Doado e agradable de ler, o libro é de tamaño medio.
Comentarios
Na súa forma máis sinxela, así é como funciona.
Un visitante chega a un café, selecciona pratos, fai un pedido, recibe comida, come e paga.
Podemos escribir requisitos para o que queremos do sistema en cada etapa.
O sistema debe mostrar unha lista de pratos, cada prato ten unha composición, peso e prezo e poder engadir ao carro. Por que confiamos nestes requisitos? Isto non se describe na descrición "estándar" dos requisitos e isto crea riscos.
Os intérpretes que non entenden por que isto é necesario adoitan facer o mal. Os intérpretes que non están implicados no proceso de creación dunha idea non están implicados no resultado. Agile di: centrémonos principalmente non no sistema, senón nas persoas, nos consumidores, nas súas tarefas e obxectivos.
Creamos personaxes, dámoslles detalles para a empatía e comezamos a contar historias dende o lado da persoa.
O empregado da oficina Zakhar foi xantar e quere tomar unha merenda rápida. Que precisa? A idea é que probablemente queira un xantar de negocios. Outra idea é que quere que o sistema lembre as súas preferencias, porque está a dieta. Outra idea. Quere que lle traian café de inmediato porque está afeito a tomar café antes de xantar.
E tamén hai un negocio (un carácter organizativo é un personaxe que representa os intereses dunha organización). As empresas queren aumentar o cheque medio, aumentar a frecuencia de compras e aumentar os beneficios. A idea é - imos ofrecer pratos pouco comúns dalgunha cociña. Outra idea - imos presentar o almorzo.
As ideas poden e deben ser concretadas, transformadas e presentadas en forma de historia de usuario. Como empregado do Zakhar Business Center, quero que o sistema me recoñeza para poder recibir un menú en función das miñas preferencias. Como camareiro, quero que o sistema me avise cando debo achegar á mesa para que o cliente estea satisfeito cun servizo rápido. Etcétera.
Ducias de historias. O seguinte é a priorización e o atraso? Jeff sinala os problemas que xorden: atascarse en pequenos detalles e perder a comprensión conceptual, ademais de priorizar a funcionalidade crea unha imaxe irregular debido á incoherencia cos obxectivos.
O camiño do autor: non priorizamos a funcionalidade, senón o resultado = o que o usuario obtén ao final.
Un punto evidente non obvio: a sesión de priorización non a realiza todo o equipo, porque é ineficaz, senón tres persoas. O primeiro é responsable da empresa, o segundo da experiencia do usuario e o terceiro da implementación.
Seleccione o mínimo para resolver un problema de usuario (solución mínima viable).
Detallamos as ideas de primeira prioridade utilizando historias de usuario, bosquexos de deseño, restricións e regras comerciais no mapa de historias de usuarios contando e discutindo co equipo o que necesitan as persoas e as partes interesadas en cada paso do proceso. Deixamos as ideas restantes sen examinar no atraso de oportunidades.
O proceso está escrito en tarxetas de esquerda a dereita, con ideas en tarxetas debaixo dos pasos do proceso. É imperativo que o camiño a través de toda a historia se discuta xunto cos membros do equipo para garantir a comprensión mutua.
A elaboración deste xeito crea integridade no cumprimento dos procesos.
Hai que probar as ideas recibidas. Un non membro do equipo pon o sombreiro da persoa e vive o día da persoa na súa cabeza, resolvendo o seu problema. É posible que non vexa os desenvolvementos, creando cartas de novo, e o equipo descubra alternativas por si mesmo.
Despois hai detalles para a avaliación. Tres persoas son suficientes para iso. Responsable da experiencia de usuario, desenvolvedor, probador cunha pregunta favorita: "E se...".
En cada etapa, a discusión segue un mapa de procesos do historial do usuario, que permite ter presente a tarefa do usuario para crear unha comprensión coherente.
É necesaria a documentación en opinión do autor? Si, necesitoo. Pero como notas que che permiten lembrar o que acordaste. Implicar de novo a un alleo require discusión.
O autor non afonda no tema da suficiencia da documentación, centrándose na necesidade de debate. (Si, é necesaria documentación, por máis que a reclamen persoas que non teñan un coñecemento profundo do áxil). Ademais, a elaboración de só parte das capacidades pode levar á necesidade dunha reelaboración completa de todo o sistema. O autor sinala o risco de excesiva elaboración no caso de que a idea sexa errónea.
Para eliminar riscos, é necesario recibir rapidamente comentarios sobre o produto que se está a crear para minimizar o dano de crear o produto "incorrecto". Fixemos un esbozo da idea -validámolo co usuario, esbozamos prototipos de interfaces- validámolo co usuario, etc. (Por separado, hai unha pequena información sobre como validar os prototipos de programas). Os obxectivos da creación de software, especialmente na fase inicial, son aprender a través da recepción de comentarios rápidos; polo tanto, o primeiro produto creado son os bosquexos que son capaces de demostrar ou refutar unha hipótese. (O autor confía no traballo de Eric Ries "Startup using Lean methodology").
Un mapa da historia axuda a mellorar a comunicación cando a implementación se realiza en varios equipos. Que debería estar no mapa? O que necesitas para manter a conversa. Non só unha historia de usuario (quen, que, por que), senón ideas, feitos, bosquexos de interfaces, etc...
Ao dividir as tarxetas do mapa histórico en varias liñas horizontais, podes dividir o traballo en lanzamentos: resaltar o mínimo, a capa de funcionalidade crecente e arcos.
Contamos historias no mapa de procesos.
Un empregado veu xantar.
Que quere? Velocidades de servizo. Para que o seu xantar xa o agarda na mesa ou polo menos nunha bandexa. Vaia, un paso perdido: o empregado quería comer. Iniciou sesión e seleccionou a opción de xantar de negocios. Viu o contido calórico e nutricional para axudarlle a facer dieta e non engordar. Viu imaxes do prato para decidir se comería nese lugar ou non.
A continuación, irá xantar e cear? Ou quizais o xantar será entregado na súa oficina? A continuación, o paso do proceso é escoller un lugar para comer. Quere ver cando se lle entregará e canto custará, para poder escoller onde gastar o seu tempo e enerxía: baixar as escaleiras ou ir traballar. Quere ver o ocupado que está o café para non facer colas.
Entón o empregado chegou ao café. Quere ver a súa bandexa para poder collela e ir directamente a cear. O café quere aceptar cartos para gañar cartos co servizo. O empregado quere perder un mínimo de tempo nos asentamentos coa cafetería, para non perder un tempo precioso inútilmente. Como facelo? Pague por adiantado ou viceversa despois do servizo a distancia. Ou paga no lugar usando un quiosco. Que é o máis importante disto? Cantas persoas están dispostas a pagar o xantar cunha tarxeta bancaria? Cantas persoas confiarían nesta cantina para gardar o seu número de tarxeta para repetir pagos? Sen investigación de campo non está claro, é necesario facer probas.
En cada paso do proceso, cómpre proporcionar funcionalidade dalgún xeito; para iso cómpre tomar algunha persoa como base e escoller o que é máis importante para el (os mesmos tres selectores). Seguiu a historia ata o final = fixo unha solución viable.
A continuación vén o detalle. O cliente quere ver o ocupado que está o café, para non facer colas. Que quere exactamente?
Consulta a previsión de cantas persoas haberá en 15 minutos cando chegue alí
Consulta o tempo medio de servizo nun café e a súa dinámica con media hora de antelación
Consulta a situación e a dinámica de ocupación da mesa
E se o sistema de predición dá un resultado pouco claro ou deixa de funcionar?
Mira a través de vídeo as colas na cafetería, así como a ocupación das mesas. Hmm, por que non fai iso primeiro?
O autor sinala un pequeno exercicio para practicar: tenta imaxinar o que fas pola mañá despois de espertar. Unha carta = unha acción. Amplía as tarxetas (en lugar de moer café, bebe unha bebida revitalizante) para eliminar detalles individuais, centrándose non no método de implementación, senón no obxectivo.
Para quen é este libro: analistas de TI e xestores de proxectos. Unha lectura obrigada.
Apps
A discusión e a toma de decisións son eficaces en grupos de 3 a 5 persoas.
Escribe na primeira tarxeta o que hai que desenvolver, na segunda - corrixe o que fixeches na primeira, na terceira - corrixe o que se fixo na primeira e na segunda.
Prepara historias como bolos, non escribindo unha receita, senón descubrindo quen, para que ocasión e para cantas persoas é o bolo. Se desglosamos as vendas, entón non sería na produción de bolos, nata, etc., senón na produción de pequenos bolos preparados.
O desenvolvemento de software é semellante a facer unha película, cando hai que desenvolver e pulir coidadosamente o guión, organizar a escena, os actores, etc. antes de comezar a rodaxe.
Sempre haberá escaseza de recursos.
O 20 % dos esforzos producen resultados tanxibles, o 60 % dan resultados incomprensibles, o 20 % dos esforzos son prexudiciais; por iso é importante centrarse na aprendizaxe e non desesperarse en caso de resultado negativo.
Comuníquese directamente co usuario, sinte na súa pel. Concéntrase nalgúns problemas.
Detallar e desenvolver a historia para a súa avaliación é a parte máis triste de scrum, fai que as discusións se poñan de pé no modo acuario (3-4 persoas discuten no taboleiro, se alguén quere participar, substitúe a alguén).
Fonte: www.habr.com