Resumo
O livro apresenta um algoritmo narrativo para o processo de desenvolvimento, desde a ideia até a implementação, usando técnicas ágeis. O processo é dividido em etapas, e em cada passo são indicados os métodos aplicáveis. O autor observa que a maioria dos métodos não é original, não reivindicando originalidade. No entanto, um bom estilo de escrita e certa coerência do processo tornam o livro muito útil.
A técnica chave do mapa de histórias de usuário é a estruturação de ideias e metas ao longo do processo do usuário.
Nesse sentido, a narrativa do processo pode ser apresentada de várias maneiras. Pode-se organizar os passos conforme a obtenção de valor essencial ou simplesmente apresentar o dia de trabalho dos usuários, como ele transcorre enquanto utilizam o sistema. O autor foca que os processos devem ser apresentados e discutidos na forma de histórias do usuário no mapa do processo, o que originou o nome mapa de histórias de usuário.
Para quem isso é relevante
Para analistas de TI e gerentes de projeto. Leitura obrigatória. A leitura é fácil e agradável, com um tamanho médio.
Comentário
Na sua forma mais simples, assim é como funciona.
O visitante chega ao café, escolhe os pratos, faz o pedido, recebe a comida, come e paga.
É possível escrever as exigências sobre o que queremos do sistema em cada etapa.
O sistema deve mostrar uma lista de pratos, com a composição, peso e preço de cada um, e ter a opção de adicionar ao carrinho. Por que temos certeza dessas exigências? Na descrição 'padrão' de requisitos isso não está descrito, o que gera riscos.
Executores que não compreendem a necessidade costumam fazer o que não é necessário. Aqueles que não estão envolvidos no processo de criação da ideia, também não se envolvem no resultado. O Agile diz: vamos nos concentrar, antes de tudo, não no sistema, mas nas pessoas, em seus desejos, tarefas e objetivos.
Criamos personas, atribuímos detalhes para empatia e, a partir dessas personas, começamos a narrar histórias.
O funcionário do escritório, Zakhar, saiu para almoçar e quer uma refeição rápida. O que ele precisa? A ideia é que provavelmente ele queira um almoço executivo. Outra ideia é que ele deseja que o sistema memorize suas preferências, pois está de dieta. Outra ideia. Ele quer que tragam café imediatamente, pois está acostumado a tomar café antes do almoço.
E há também os negócios (o personagem organizacional — um personagem que representa os interesses de uma organização). O negócio quer aumentar o ticket médio, aumentar a frequência de compra e aumentar o lucro. A ideia é — que tal oferecer pratos incomuns de alguma culinária? Outra ideia — que tal introduzirmos cafés da manhã.
As ideias podem e devem ser concretizadas, transformadas e apresentadas na forma de user stories. Como funcionário do centro de negócios, Zakhar, eu quero que o sistema me reconheça, para que eu receba um menu levando em consideração minhas preferências. Como garçom, eu quero que o sistema me avise quando eu devo me aproximar da mesa, para que o cliente fique satisfeito com o atendimento rápido. E assim por diante.
Dezenas de histórias. E então, priorização e backlog? Jeff aponta os problemas que surgem: a ligação a pequenos detalhes e a perda de compreensão conceitual, além de priorização de funcionalidades que cria uma imagem fragmentada devido à descoordenação 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, mas não tão óbvio: a sessão de priorização não é realizada por toda a equipe, pois é 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.
Destacamos o mínimo necessário para resolver uma tarefa do usuário (solução viável mínima).
Detalhamos as ideias da primeira prioridade com a ajuda de user stories, esboços de design, restrições e regras de negócios no mapa de histórias de usuário por meio de narrativas e discussões com a equipe sobre o que é necessário para as personas e stakeholders em cada passo do processo. As outras ideias permanecem não analisadas, no backlog de possibilidades.
O processo é escrito na forma de cartões da esquerda para a direita, e as ideias nos cartões estão abaixo dos passos do processo. É essencial que o caminho de toda a história seja discutido junto com os membros da equipe para criar um entendimento mútuo.
O desenvolvimento dessa forma cria a integridade da conformidade com os processos.
As ideias recebidas precisam ser verificadas. Um membro da equipe não coloca o chapéu da persona e vive na mente da persona, resolvendo sua tarefa. Existe a possibilidade de que ele não veja as contribuições, criando os cartões novamente, enquanto a equipe descobre alternativas.
Em seguida, há uma detalhamento para avaliação. Para isso, são necessárias três pessoas: uma responsável pela experiência do usuário, um desenvolvedor e um testador com a pergunta favorita: 'E se...'.
Em cada etapa, a discussão gira em torno do mapa de processos da história do usuário, o que permite, mantendo em mente a tarefa do usuário, criar uma compreensão coesa.
É necessária a documentação, na opinião do autor? Sim, é necessária. Mas como anotações, permitindo recordar o que foi acordado. Envolver uma pessoa de fora requer mais discussão.
O autor não se aprofunda na questão da suficiência da documentação, enfatizando a necessidade de discussões. (Sim, a documentação é necessária, independentemente do que afirmem as pessoas com entendimento superficial sobre agile). Além disso, o desenvolvimento apenas de parte das funcionalidades pode levar à necessidade de uma completa retrabalho do sistema. O autor aponta o risco de um sobredesenvolvimento caso o conceito esteja errado.
Para mitigar riscos, é necessário obter feedback rápido sobre o produto que está sendo criado para minimizar os danos de criar um 'produto errado'. Esboçamos uma ideia — validamos com o usuário, esboços de protótipos de interface — validamos com o usuário, etc. (É mencionado separadamente como validar protótipos de software). Os objetivos de criação de software, especialmente nas fases iniciais, são o aprendizado por meio do recebimento de feedback rápido, sendo que o primeiro produto criado são esboços que podem provar ou refutar a hipótese. (O autor baseia-se no trabalho de Eric Ries 'The Lean Startup').
O mapa de histórias ajuda a estabelecer comunicações, se a implementação é garantida por várias equipes. O que deve haver no mapa? Aquilo que é necessário para apoiar a conversa. Não apenas user stories (quem, o que, por quê), mas ideias, fatos, esboços de interfaces, etc.
Dividindo os cartões no mapa de histórias em várias linhas horizontais, é possível separar os trabalhos em lançamentos — destacando o mínimo essencial, a camada de ampliação funcional e os acabamentos.
Expomos as histórias no mapa do processo.
O funcionário foi almoçar.
O que ele deseja? Velocidade de atendimento. Para que seu almoço já esteja à sua espera na mesa ou, pelo menos, em uma bandeja. Opa — passo perdido: o funcionário decidiu comer. Ele entrou no sistema e escolheu uma opção de almoço de negócios. Ele viu as calorias e a adequação nutricional para seguir a dieta e não engordar. Ele viu imagens do prato para decidir se comeria neste lugar ou não.
Em seguida, ele irá buscar o almoço e almoçar? Ou talvez ele receba o almoço no escritório? Então, o próximo passo do processo é escolher o local da refeição. Ele quer ver quando seu pedido será entregue e quanto custará, para decidir onde investir seu tempo e esforço — descer ou trabalhar. Ele quer ver a lotação do café, para não ter que enfrentar filas.
Em seguida, o funcionário entrou no café. Ele quer ver sua bandeja, para pegá-la e ir almoçar imediatamente. O café quer receber o pagamento, para lucrar com o atendimento. O funcionário quer gastar o mínimo de tempo possível no pagamento com o café, para não desperdiçar seu tempo precioso. Como fazer isso? Pagar antecipadamente ou, ao contrário, após o atendimento de forma remota. Ou pagar no momento utilizando um quiosque. O que disso é o mais essencial? Quantas pessoas estão dispostas a pagar o almoço com cartão de crédito? Quantas pessoas confiarão o armazenamento do número do cartão para pagamentos recorrentes nesta cantina? Sem uma pesquisa de campo, não está claro; é necessário testar.
Em cada etapa do processo, é preciso garantir alguma funcionalidade; para isso, é necessário tomar como base algum perfil e escolher o que é mais importante para ele (aquela famosa tríade de escolhas). Se completamos a história = fizemos uma solução viável.
Em seguida, vem a detalhamento. O cliente quer ver a lotação do café, para não ter que enfrentar filas. O que exatamente ele deseja?
Ver a previsão de quantas pessoas estarão lá em 15 minutos, quando ele chegar.
Ver o tempo médio de atendimento no café e sua dinâmica para os próximos 30 minutos.
Ver a situação e a dinâmica da ocupação das mesas.
E se o sistema de previsão oferecer um resultado estranho ou parar de funcionar?
Ver por meio de vídeo as filas no café, bem como a ocupação das mesas. Hum, por que não fazer isso em primeiro lugar?!
O autor sugere um pequeno exercício para praticar: tente imaginar o que você faz pela manhã ao acordar. Um cartão = uma ação. Amplie os cartões (em vez de moer café — beber uma bebida revigorante), eliminando detalhes individuais e focando não no modo de execução, mas no objetivo.
Para quem é este livro — para analistas de TI e gerentes de projeto. Leitura obrigatória.
Aplicativos
Discussões e tomadas 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 — corrigir o que foi feito no primeiro, e no terceiro — corrigir o que foi feito no primeiro e no segundo.
Prepare histórias como bolos — não descrevendo a receita, mas entendendo para quem, por qual motivo e para quantas pessoas será o bolo. Se for dividir a implementação, não separe em fazer as camadas, o creme etc., mas em fazer pequenos bolos prontos.
O desenvolvimento de software é parecido com a criação de um filme, onde é necessário elaborar e polir rigorosamente o roteiro, organizar o cenário, os atores e assim por diante antes do início das filmagens.
Recursos nunca serão suficientes.
20% dos esforços dão resultados significativos, 60% geram resultados incertos e 20% dos esforços são prejudiciais — é por isso que é importante focar no aprendizado e não desanimar em caso de resultado negativo.
Comunique-se diretamente com o usuário, coloque-se no lugar dele. Foque em alguns problemas específicos.
Detalhar e desenvolver a história para a avaliação é a parte mais tediosa do scrum; faça as discussões em pé, no modo aquário (na lousa discutem 3-4 pessoas, e se alguém quiser participar, ele substitui alguém).
Fonte: habr.com
