Abstrato
O livro é um algoritmo narrado para realizar o processo de desenvolvimento desde a ideia até a 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 o bom estilo de escrita e alguma integridade do processo tornam o livro muito útil.
Uma técnica fundamental de mapeamento de histórias de usuários é estruturar ideias e desempenhos à medida que o usuário avança no processo.
Ao mesmo tempo, o processo pode ser descrito de diferentes maneiras. Você pode construir etapas à medida que atinge um valor-chave ou pode simplesmente imaginar o dia de trabalho dos usuários durante o uso do sistema. O autor foca no fato de que os processos precisam ser delineados, falados na forma de uma história de usuário em um mapa de processos, que é o que nos deu o nome de mapa de histórias de usuário.
Quem precisa
Para analistas de TI e gerentes de projetos. Uma leitura obrigatória. Fácil e agradável de ler, o livro é de tamanho médio.
recordação
Na sua forma mais simples, é assim que funciona.
Um visitante chega a um café, seleciona os pratos, faz um pedido, recebe a comida, come e paga.
Podemos escrever requisitos para o que queremos do sistema em cada estágio.
O sistema deverá mostrar uma lista de pratos, cada prato tem composição, peso e preço e poder adicionar ao carrinho. Por que estamos confiantes nesses requisitos? Isto 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 fazem a coisa errada. Artistas que não estão envolvidos no processo de criação de uma ideia não estão envolvidos no resultado. Agile diz: vamos nos concentrar principalmente não no sistema, mas nas pessoas, nos consumidores, em suas tarefas e objetivos.
Criamos personas, damos detalhes para empatia e começamos a contar histórias do lado da persona.
O funcionário do escritório Zakhar foi almoçar e quer fazer um lanche rápido. O que ele precisa? A ideia é que ele provavelmente queira um almoço de negócios. Outra ideia é que ele queira que o sistema lembre de suas preferências, pois ele está de dieta. Outra ideia. Ele quer que lhe tragam café imediatamente porque está acostumado a tomar café antes do almoço.
E há também um negócio (um personagem organizacional é um personagem que representa os interesses de uma organização). As empresas querem aumentar o cheque médio, aumentar a frequência das compras e aumentar os lucros. A ideia é oferecer pratos inusitados de alguma culinária. Outra ideia é apresentar o café da manhã.
As ideias podem e devem ser concretizadas, transformadas e apresentadas na forma de uma história de usuário. Como funcionário do Zakhar Business Center, quero que o sistema me reconheça para que eu possa receber um menu baseado nas minhas preferências. Como garçom, quero que o sistema me avise quando devo me aproximar da mesa para que o cliente fique satisfeito com o atendimento rápido. E assim por diante.
Dezenas de histórias. O próximo passo é a priorização e o backlog? Jeff aponta os problemas que surgem: ficar atolado em pequenos detalhes e perder a compreensão conceitual, além de priorizar a funcionalidade cria uma imagem irregular devido à inconsistência com os objetivos.
O caminho do autor: Priorizamos não a funcionalidade, mas o resultado = o que o usuário obtém no final.
Um ponto óbvio e não óbvio: a sessão de priorização 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.
Vamos selecionar o mínimo para resolver um problema do usuário (solução mínima viável).
Detalhamos as ideias de primeira prioridade usando histórias de usuários, esboços de design, restrições e regras de negócios no mapa de histórias de usuários, contando e discutindo com a equipe o que as pessoas e as partes interessadas precisam em cada etapa do processo. Deixamos as ideias restantes sem serem examinadas no acúmulo de oportunidades.
O processo está escrito em cartões da esquerda para a direita, com ideias em cartões abaixo das etapas do processo. É imperativo que o percurso de toda a história seja discutido em conjunto com os membros da equipe para garantir o entendimento mútuo.
A elaboração desta forma cria integridade no cumprimento dos processos.
As ideias recebidas precisam ser testadas. Um não membro da equipe coloca o chapéu da pessoa e vive o dia da pessoa em sua cabeça, resolvendo seu problema. É possível que ele não veja a evolução, criando cartões novamente, e a equipe descubra alternativas para si.
Depois há o detalhamento para avaliação. Três pessoas são suficientes para isso. Responsável pela experiência do usuário, desenvolvedor, testador com pergunta favorita: “E se...”.
Em cada etapa, a discussão segue um mapa de processos do histórico do usuário, o que permite manter em mente a tarefa do usuário para criar um entendimento coerente.
A documentação é necessária na opinião do autor? Sim, preciso disso. Mas como notas que permitem lembrar o que você combinou. Envolver novamente uma pessoa de fora requer discussão.
O autor não se aprofunda no tema da suficiência de documentação, focando na necessidade de discussão. (Sim, a documentação é necessária, não importa o quanto as pessoas que não têm um conhecimento profundo de ágil a reivindiquem). Além disso, a elaboração de apenas parte das capacidades pode levar à necessidade de um retrabalho completo de todo o sistema. O autor aponta o risco de elaboração excessiva no caso em que a ideia está errada.
Para eliminar riscos, é necessário receber rapidamente feedback sobre o produto que está sendo criado para minimizar os danos da criação do produto “errado”. Fizemos um esboço da ideia - validamos com o usuário, esboçamos protótipos de interface - validamos com o usuário, etc. (Separadamente, há um pouco de informação sobre como validar protótipos de programas). Os objetivos da criação de software, principalmente no estágio inicial, são o aprendizado por meio do recebimento de feedback rápido; portanto, o primeiro produto criado são esboços capazes de provar ou refutar uma hipótese. (O autor se baseia no trabalho de Eric Ries “Startup usando metodologia Lean”).
Um mapa histórico ajuda a melhorar a comunicação quando a implementação é realizada entre várias equipes. O que deveria estar no mapa? O que você precisa para manter a conversa. Não apenas uma história de usuário (quem, o quê, por quê), mas ideias, fatos, esboços de interface, etc.
Ao dividir os cartões no mapa histórico em várias linhas horizontais, você pode dividir o trabalho em lançamentos - destaque o mínimo, uma camada de funcionalidade crescente e arcos.
Contamos histórias no mapa do processo.
Um funcionário veio almoçar.
O que ele quer? Velocidades de serviço. Para que o almoço já esteja esperando por ele na mesa ou pelo menos na bandeja. Ops, passo perdido: o funcionário queria comer. Ele fez login e selecionou a opção de almoço de negócios. Ele viu o conteúdo calórico e nutricional para ajudá-lo a fazer dieta e não ganhar peso. Ele viu fotos do prato para decidir se comeria naquele lugar ou não.
Em seguida, ele irá almoçar e jantar? Ou talvez o almoço seja entregue em seu escritório? Depois a etapa do processo é escolher um local para comer. Ele quer ver quando será entregue e quanto custará, para poder escolher onde gastar seu tempo e energia - descendo ou indo para o trabalho. Ele quer ver o quão movimentado o café está para não se acotovelar nas filas.
Então o funcionário veio ao café. Ele quer ver sua bandeja para poder pegá-la e ir direto jantar. O café quer aceitar dinheiro para ganhar dinheiro com serviços. O funcionário quer perder um mínimo de tempo em acordos com o café, para não perder um tempo precioso inutilmente. Como fazer isso? Pague antecipadamente ou vice-versa após o atendimento remotamente. Ou pague na hora em um quiosque. Qual é a coisa mais importante sobre isso? Quantas pessoas estão dispostas a pagar o almoço com cartão do banco? Quantas pessoas confiariam nesta cantina para armazenar o número do seu cartão para pagamentos repetidos? Sem pesquisa de campo não está claro, são necessários testes.
Em cada etapa do processo, você precisa fornecer funcionalidade de alguma forma, para isso você precisa tomar alguma pessoa como base e escolher o que é mais importante para ela (os mesmos três seletores). Segui a história até o fim = fiz uma solução viável.
Em seguida vem o detalhamento. O cliente quer ver o quão movimentado está o café, para não se acotovelar nas filas. O que exatamente ele quer?
Veja a previsão de quantas pessoas estarão daqui a 15 minutos quando ele chegar
Veja o tempo médio de atendimento em um café e sua dinâmica com meia hora de antecedência
Veja a situação e a dinâmica de ocupação das mesas
E se o sistema de previsão der um resultado pouco claro ou parar de funcionar?
Veja através de vídeo as filas no café, bem como a ocupação das mesas. Hmm, por que não fazer isso primeiro?!
O autor aponta um pequeno exercício para praticar: tente imaginar o que você faz pela manhã ao acordar. Uma carta = uma ação. Amplie os cartões (em vez de moer café, beba uma bebida revigorante) para retirar detalhes individuais, focando não no método de execução, mas no objetivo.
A quem se destina este livro: analistas de TI e gerentes de projetos. Uma leitura obrigatória.
Aplicativos
A discussão e a tomada de decisões são eficazes em grupos de 3 a 5 pessoas.
Escreva no primeiro cartão o que precisa ser desenvolvido, no segundo - corrija o que você fez no primeiro, no terceiro - corrija o que foi feito no primeiro e no segundo.
Prepare histórias como bolos - não escrevendo uma receita, mas descobrindo para quem, para que ocasião e para quantas pessoas o bolo se destina. Se desagregarmos as vendas, não seria na produção de bolos, natas, etc., mas na produção de pequenos bolos prontos.
O desenvolvimento de software é semelhante a fazer um filme, quando você precisa desenvolver e aprimorar cuidadosamente o roteiro, organizar a cena, os atores, etc. antes do início da filmagem.
Sempre haverá escassez de recursos.
20% dos esforços produzem resultados tangíveis, 60% dão resultados incompreensíveis, 20% dos esforços são prejudiciais - por isso é 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 desenvolver a história para avaliação é a parte mais enfadonha do scrum, fazer as discussões ficarem em pé no modo aquário (3-4 pessoas discutem no quadro, se alguém quiser participar ele substitui alguém).
Fonte: habr.com