Anotação
O livro é um algoritmo narrado para conduzir o processo de desenvolvimento da ideia à implementação usando técnicas ágeis. O processo é apresentado em etapas e em cada etapa são indicados os métodos para a etapa do processo. O autor ressalta que a maioria dos métodos não é original, sem pretender ser original. Mas um bom estilo de apresentação e alguma integridade do processo tornam o livro muito útil.
A principal técnica do mapa da história do usuário é a estruturação de idéias e declarações à medida que o usuário passa pelo processo.
Ao mesmo tempo, o processo pode ser descrito de diferentes maneiras. Você pode criar etapas à medida que alcança o valor-chave, ou pode apenas imaginar e imaginar o dia útil dos usuários, como ele funciona usando o sistema. O autor concentra-se no fato de que os processos precisam ser declarados, pronunciados na forma de histórico do usuário no mapa do processo, que era o nome do mapa da história do usuário.
Quem precisa
Para analistas de TI e gerentes de projeto. Leitura obrigatória. É fácil e agradável de ler, o livro é de tamanho médio.
Comentários
Na sua forma mais simples, como funciona.
Um visitante chega a um café, escolhe pratos, faz um pedido, recebe comida, come, paga.
Você pode escrever os requisitos que queremos do sistema em cada estágio.
O sistema deve mostrar uma lista de pratos, cada composição, peso e preço e poder adicionar à cesta. Por que estamos confiantes nesses requisitos? Isso não está descrito na descrição "padrão" dos requisitos e cria riscos.
Artistas que não entendem por que isso é necessário geralmente não sabem o que é necessário. Os artistas que não estão envolvidos no processo de criação de uma ideia não estão envolvidos no resultado. Segundo o Agile, vamos nos concentrar principalmente não no sistema, mas nas pessoas, nos consumidores, em suas tarefas e objetivos.
Nós criamos pessoas, por empatia, damos a elas detalhes e, por parte das pessoas, começamos a contar histórias.
O funcionário do escritório, Zahar, foi almoçar e quer uma refeição rápida. Do que ele precisa? A ideia é que ele provavelmente queira um almoço de negócios. Outra idéia que ele quer que o sistema se lembre é a sua preferência, porque ele está de dieta. Outra ideia. Ele quer tomar café imediatamente, porque está acostumado a tomar café antes do jantar.
E ainda há negócios (o caráter organizacional é um personagem que representa os interesses de alguma organização). A empresa quer aumentar a conta média, aumentar a frequência das compras, aumentar os lucros. A idéia é oferecer pratos incomuns de algum tipo de cozinha. Outra idéia: vamos apresentar o café da manhã.
As idéias podem e devem ser concretizadas, transformadas e projetadas como uma história de usuário. Como funcionário do centro de negócios Zakhar, quero que o sistema me reconheça, para receber um menu com base em minhas preferências. Como garçom, quero que o sistema me notifique quando abordar a tabela para que o cliente esteja satisfeito com o serviço rápido. E assim por diante
Dezenas de histórias. Priorização e backlog adicionais? Jeff aponta os problemas que surgem: a ligação em pequenos detalhes e a perda de entendimento conceitual, além da priorização do funcional, cria uma imagem rasgada devido à inconsistência com os objetivos.
Caminho do autor: priorizamos não o funcional, mas o resultado = o que o usuário obtém como resultado.
Um ponto óbvio não óbvio: a sessão prioritária não é realizada por toda a equipe, porque é ineficaz, mas por três pessoas. O primeiro é responsável pelos negócios, o segundo pela experiência do usuário e o terceiro pela implementação.
Selecionamos um mínimo para resolver um problema do usuário (a solução mínima viável).
Detalhamos as idéias da primeira prioridade com a ajuda de uma história do usuário, esboçamos projetos, restrições e regras de negócios no mapa das histórias do usuário, contando e discutindo com a equipe o que as pessoas e as partes interessadas precisam em cada etapa do processo. As idéias restantes são deixadas desmontadas, na lista de oportunidades.
O processo é escrito na forma de cartões da esquerda para a direita e idéias sobre os cartões nas etapas do processo. Necessariamente, o caminho de toda a história deve ser falado em conjunto com a equipe para o surgimento de entendimento mútuo.
A exposição dessa maneira cria integridade para a correspondência de processos.
As idéias que você precisa verificar. Nenhum membro da equipe coloca o chapéu de uma pessoa e vive na cabeça do dia da pessoa, resolvendo seu problema. Uma variante é possível quando ele não vê os desenvolvimentos, criando novas cartas e a equipe descobre alternativas.
Em seguida, faça drill down para avaliação. Três pessoas são suficientes para isso. Responsável pela experiência do usuário, desenvolvedor, testador com uma pergunta favorita: "What if ...".
Em cada estágio, a discussão segue um mapa dos processos de histórico do usuário, o que permite manter a tarefa do usuário em mente para criar um entendimento.
Preciso de documentação de acordo com o autor? Sim, eu preciso disso. Mas, como notas, nos permite lembrar o que combinamos. O envolvimento de uma pessoa de fora novamente requer discussão.
O autor não se aprofunda no tópico da suficiência da documentação, enfocando a necessidade de discussão. (Sim, é necessária documentação, não importando o quanto as pessoas que não entendem o ágil). Além disso, o estudo de apenas parte dos recursos pode levar à necessidade de uma alteração completa de todo o sistema. O autor aponta o risco de elaboração excessiva no caso em que ainda não adivinhou a ideia.
Para remover riscos, é necessário receber rapidamente feedback sobre o produto criado para minimizar os danos à criação do produto "errado". Eles fizeram um esboço da ideia - validado pelo usuário, um esboço dos protótipos da interface - validado pelo usuário etc. (Separadamente, é indicado um pouco como validar protótipos de programas). Os objetivos da criação de software, especialmente no estágio inicial, são o treinamento por meio de feedback rápido; portanto, o primeiro produto criado é um esboço que pode provar ou refutar uma hipótese. (O autor conta com o trabalho de Eric Rice, “Startup by Lean Methodology”).
Um mapa da história ajuda a estabelecer a comunicação se a implementação for fornecida por várias equipes. O que deve estar no mapa? O que você precisa para apoiar a conversa. Não apenas a história do usuário (quem, o quê, por que), mas idéias, fatos, descrição das interfaces, etc.
Dividindo os cartões no mapa histórico em várias linhas horizontais, você pode dividir o trabalho em lançamentos - selecione o mínimo, a camada de criação de funcionalidades e arcos.
Contamos histórias no mapa do processo.
O funcionário veio almoçar.
O que ele quer? Velocidades de serviço. Para que seu jantar já esteja esperando por ele na mesa ou pelo menos em uma bandeja. Opa - um passo perdido: o funcionário queria comer. Ele entrou no sistema e escolheu a opção de almoço de negócios. Ele viu o conteúdo calórico e o valor nutricional para manter uma dieta e não engordar. Ele viu fotos do prato para decidir se ele iria comer neste lugar ou não.
Em seguida, ele vai almoçar e almoçar? Ou talvez ele vá almoçar no escritório? Então a etapa do processo é a escolha do local da comida. Ele quer ver o tempo em que será entregue e quanto custará escolher onde gastar tempo e esforço - para ir para baixo ou trabalhar. Ele quer ver o café ocupado, para não empurrar as filas.
Em seguida, o funcionário veio ao café. Ele quer ver sua bandeja, pegá-la e imediatamente ir jantar. O café quer aceitar dinheiro para ganhar dinheiro com manutenção. Um funcionário quer perder um tempo mínimo em assentamentos com um café, para não perder um tempo precioso sem benefícios. Como fazer isso? Pague antecipadamente ou vice-versa após a manutenção remota. Ou pague no momento usando um quiosque. Qual destes é o mais básico? Quantas pessoas estão dispostas a pagar com cartão de crédito para o almoço? Quantas pessoas confiam no armazenamento do número do cartão para pagamentos repetidos nesta sala de jantar? Sem pesquisa de campo, não está claro se é necessário testar.
Em cada etapa do processo, você precisa, pelo menos de alguma forma, fornecer funcionalidade, para isso é necessário ter como base algum tipo de pessoa e escolher o que é mais importante para ele (os mesmos três eleitores). Passou a história até o fim = tomou uma decisão viável.
Em seguida é o detalhe. O cliente deseja ver a carga de trabalho do café, para não empurrar nas filas. O que exatamente ele quer?
Assista à previsão de quantas pessoas estarão em 15 minutos, quando ele irá para lá
Assista o tempo médio de serviço em um café e sua dinâmica por meia hora à frente
Observe a situação e a dinâmica do emprego de tabelas
Mas e se o sistema de previsão fornecer um resultado incompreensível ou parar de funcionar?
Assista através das linhas de vídeo no café, bem como o emprego de mesas. Hmm, por que não fazer isso primeiro?
O autor aponta um pequeno exercício para a prática: tente imaginar o que você está fazendo de manhã depois de acordar. Uma carta = uma ação. Amplie os cartões (em vez de moer café - tome uma bebida refrescante) para remover detalhes individuais, levando em foco não o modo de implementação, mas o objetivo.
Para quem este livro é para analistas de TI e gerentes de projeto. Leitura obrigatória.
Aplicações
Discussão e tomada de decisão são eficazes em grupos de 3 a 5 pessoas.
Escreva no primeiro cartão o que precisa ser desenvolvido, no segundo - para consertar o que foi feito no primeiro, no terceiro - para consertar o que foi feito no primeiro e no segundo.
Prepare histórias como bolos - não escrevendo uma receita para fazer, mas descobrindo a quem, por que motivo, quantas pessoas têm um bolo. Se você interromper a implementação, não na fabricação de bolos, cremes, etc., mas na fabricação de pequenos bolos acabados.
O desenvolvimento de software é semelhante a fazer um filme quando você precisa desenvolver e lamber cuidadosamente um script, organizar uma cena, atores etc., antes do início das filmagens.
Os recursos sempre serão escassos.
20% dos esforços dão um resultado tangível, 60% afirmam que não está claro que, 20% dos esforços são prejudiciais - é por isso que é importante focar na aprendizagem e não se desesperar em caso de resultado negativo.
Comunique-se diretamente com o usuário, sinta-se no lugar dele. Concentre-se em alguns problemas.
Detalhar e elaborar o histórico para a avaliação é a parte mais triste do scrum, tornar as discussões em pé no modo aquário (3-4 pessoas discutem no quadro, se alguém quiser participar, ele substitui alguém).