Artigos

Dicas para escrita de histórias de usuário

No post anterior eu falei um pouco sobre a história das histórias de usuário, seu template e sua finalidade. Hoje falo um pouco sobre algumas dicas que juntei por aí sobre como escrever boas histórias.

Ao iniciar o seu backlog, escrevendo as suas primeiras histórias, comece com histórias que tenham alguma meta envolvida, algo que realmente entregue valor para o cliente. É muito interessante vermos como as coisas são nas universidades. No meu tempo (idoso mode: ON) quase que invariavelmente se ensinava a fazer um sistema de locadoras. Com poucas variações, a grande maioria das faculdades naqueles tempos faziam o mesmo. Nós, como inocentes aprendizes íamos ali, criando novos softwares começando, quase sempre, pelos cadastros, quando o que realmente entrega valor numa locadora é a função de locar. Cadastrar os clientes, as mídias, todo o resto é acessório para o ato de locar. Vejam o quanto isso é a inversão desse valor, o quanto estamos acostumados a entregar o que nos parece mais confortável do nosso ponto de vista. Para o cliente, o meu cliente como desenvolvedor, ter todos os dados daquele blue-ray é importante, mas o mais importante é a locação. Com isso, nasciam cadastros com campos sem necessidade, mesmo cadastros inteiros sem necessidade aparente. Começar pelas histórias que são importantes te dá a possibilidade de validar os acessórios.

Ao dividir as suas histórias, lembre-se que uma história é uma entrega de valor. Para que uma história atenda a isso, ela não pode ser algo que vai entregar somente uma camada do sistema. Histórias que alteram somente o visual, somente o banco, ou somente a regra de negócio devem ser observadas com muita atenção, buscando sempre a entrega de valor. Embora existam situações nas quais realmente uma mudança de design entregue valor por si só, muitas vezes já vi pessoas criando histórias somente para adicionar campos novos no banco de dados, sem uma explicação do porquê. Pense nas histórias como uma fatia de bolo e não como uma camada dele. Uma boa história de usuário vai entregar um pedaço de cada camada do bolo, tal qual uma fatia.

Outra dica muito importante é colocar os critérios de aceitação no cartão da história. Isso ajuda ao cliente a entender os limites da tarefa e ajuda o desenvolvedor a entender quando ele realmente a completou. Eles devem ser claros o bastante para que sejam entendidos pelos envolvidos. Os testes podem ser escritos em qualquer formato que os leitores concordem como sendo conveniente, cenários, tabelas-verdade, o que for interessante. O fundamental nesse momento é que os critérios nesse momento sejam testáveis, sejam validáveis de maneira simples. No fim das contas eles certificam que as história implementadas correspondem ao que o cliente necessita. Sempre que possível, automatize o processo de validação das histórias. Utilizando uma combinação de integração contínua e testes funcionais, algo como Jenkins e JUnit (para Java), os resultados podem ser realmente potencializados.

Embora todo o time, até mesmo o cliente possam escrever histórias e ajudar na formação do backlog, a responsabilidade por escrever as histórias, por gerenciar o backlog completo é o Product Owner, quando estamos falando de Scrum. Observe que o uso de Histórias de Usuário não é algo de uma única metodologia, mesmo quem costuma usá-las.

São trabalhadas e amadurecem à medida que a análise progride. Não se deve ter todo o backlog escrito no início do trabalho. Isso seria considerado um desperdício. Uma metodologia ágil, ao menos a maioria, prega que isso seria um desperdício, pois seria como tentar adivinhar tudo o que o software teria logo no início na coleta de requisitos. Ter um ou dois sprints ou ainda uma ou duas semanas bem detalhadas já é o suficiente para um bom andamento do ciclo de trabalho

Para finalizar, o que acontece com as histórias após terem sido feitas e validadas pelo cliente? Bom, caso você queira manter alguma rastreabilidade, para fins de nostalgia ou ajudar a se lembrar do que foi entregue pode manter uma cópia das histórias. Mas elas não foram pensadas para isso. Foram pensadas como uma ferramenta para execução do trabalho e não com fins de registro ou documentação. Assim, após a sua validação podem ser descartadas.

Bom, isso era um pouco do que eu tinha para falar sobre Histórias de Usuário/User Stories. Até o próximo post.

Referências:

A história de uma história

Dia desses escrevi aqui sobre as técnicas que mais usei para levantamento de requisitos. Naquela oportunidade citei que seria interessante um post mais específico para falar sobre o meu método preferido, as user stories, ou histórias de usuário.

A minha predileção por esse método se dá pela sua simplicidade. Estamos falando de papéis coloridos pregados em uma parede e em linguagem natural, aquela que falamos no nosso dia-à-dia. Muito embora o modelo seja simples, alguns cuidados devem ser tomados para seu bom uso e garantir a sua efetividade.

Segundo o meu amigo Heitor Roriz, histórias de usuários…

“…provêem uma apresentação fácil de compreender e de forma concisa sobre uma determinada informação. São geralmente numa linguagem informal e contém o mínimo de detalhes, deixando os demais dados aberto à interpretação. Elas devem ajudar a entender o que o software deve englobar.”

Isso significa que as US (user stories/histórias de usuário) funcionam como um “nivelador de linguagem”, trazendo para o mesmo nível de entendimento o cliente, o cara de negócios, que pode não entender nada de programação e o desenvolvedor, o cara que vai resolver aquele problema usando o conhecimento técnico. É muito interessante pois a US é um convite ao debate, à conversa. Ela é pequena e concisa de propósito, para que você tenha que discutir os detalhes com quem fez a solicitação e durante essa conversa novos tópicos possam surgir.

Um outro ponto importante é que elas devem ser acompanhadas por critérios de aceitação para ajudar a elucidar os comportamentos aonde as histórias pareçam ambíguas. Os critérios de aceitação seriam algo como os testes que indicam a quem for desenvolver quando a sua tarefa foi completada. Os critérios podem ser pequenos e simples, algo como uma regra de validação, ou mesmo mais complexos, dando origens a novas histórias.

Um modelo nos foi sugerido por Mike Cohn, dizendo que opcionalmente eu poderia ter a terceira cláusula (o porquê). Eu respeitosamente discordo, mas vamos falar disso mais adiante. O modelo proposto é o seguinte:

Como um [papel],
eu quero/desejo [objetivo/desejo]
então [benefício/razão]

Entendendo bem as partes, comecemos com o papel. Se você estudou um pouco de UML deve estar fazendo a relação na sua cabeça com o ator de um use case e está correto. Aqui estamos falando da pessoa que se beneficiará se essa história for desenvolvida. Isso é legal, pois como desenvolvedor você saberá com quem tirar suas dúvidas durante o desenvolvimento do produto. Nem sempre você terá funcionalidades que serão utilizadas somente por um único papel, ou mesmo por um papel tão simples que possa ser descrito de maneira sucinta. Nesses casos, o que é recomendado é o uso de personas, que nada mais é do que criar personagens com as características que um determinado perfil de usuário possui. Uma boa persona descreve algumas características básicas como:

  • Um nome, idade e um estilo de trabalho e vida definido
  • Um bordão para distingui-lo de outras personas
  • Atributos chave que afetam uso e expectativas do produto, serviço ou website
  • Tarefas frequentemente realizadas
  • Ferramentas e recursos utilizados
  • Pontos de atenção relevantes ao projeto

Usualmente não se criam mais do que 8 personas por projeto, dada a sua complexidade. É possível fazer algumas atualizações durante o projeto, mas isso é bem incomum. Enfim, não comece o seu projeto criando um punhado de personas, deixe que isso emerja da necessidade. Conforme você for escrevendo suas histórias, vai surgir em algum momento algum papel que precise de um pouco mais de atenção e talvez seja o momento de reunir o seu time e escrever seus personas. Ou sua equipe pode realmente se sentir mais confortável em saber quem vai usar o sistema desde o primeiro momento.

Por hoje é só, no próximo post, falarei algumas dicas de escrita para iniciar o seu backlog.

Spice girl manifesto

Eu sou um cara casado. De casamento já se vão oito ótimos anos de vida juntos. Mas nos conhecemos antes disso, mais ou menos uns cinco anos antes. Somando tudo posso dizer que temos uma excelente convivência, uma vida compartilhada por assim dizer a pelo menos treze anos. Ainda assim, não posso dizer que a conheço completamente. Não sei de todos os seus anseios ou vontades, de todos os seus desejos e existem muitos momentos em que ela diz uma coisa querendo dizer outra. Embora isso possa parecer um lamento, é só um fato, que eu aceitei e levo a nossa relação tendo isso em mente. Mas é bem interessante de se pensar que pessoas que dormem e acordam juntos, que compartilham suas vidas de maneira tão intensa não sejam capazes de compreender as vontades um do outro por completo, não é mesmo?

Se mesmo com toda essa intimidade eu aceito o fato do desconhecido, porque você exige do seu cliente algo diferente quando vai iniciar um projeto? Sério, o paralelo não é tão distante. Vocês mal se conhecem, são pessoas em última instância, não empresas. E são desejos/necessidades de pessoas que precisam ser traduzidos em requisitos de software. O mal entendimento desses desejos e vontade pode sim decretar o sucesso ou o fracasso de um projeto. Assim como em casa eu uso várias técnicas para entender o que minha esposa espera de mim, aplico o mesmo pensamento no trabalho.

Outro problema, é a distância entre o desenvolvedor e o cliente. A começar pelo idioma. Enquanto o desenvolvedor entende profundamente o que acontece dentro do software é bem incomum ver esse mesmo profissional entendendo o que acontece no lado do negócio. Mais incomum ainda é ver o contrário, pessoas de negócio que entendem como o software funciona. Assim, esses profissionais falam idiomas diferentes e sua compreensão fica defasada por conta disso.

Só para fins de curiosidade, o título desse post veio de um treinamento de Kanban, ministrado pelo próprio David Anderson, no qual ele disse que mais do que o manifesto ágil, precisávamos agora de um manifesto spice girl. Vendo o espanto dos alunos, ele explicou: So tell me what you want, what you really really want… enfim, entender o problema, a necessidade, é metade da solução.

A seguir eu alguns métodos que usei em algum da minha vida. Não os estou julgando (ainda)…

Questionários
Uma técnica bem antiga, no qual o analista redige questionários e os entrega aos usuários chave do sistema. Muito útil com equipes mais tímidas ou para captar o máximo de respostas de todos os membros da equipe.

Entrevistas
Quanto os questionários se mostram muito frios, uma investigação mais profunda se faz necessária. Marcar entrevistas com os usuários, isolados ou em grupo, pode ajudar a esclarecer diversos pontos que outros métodos deixaram em aberto.

Observação
Nada mais simples do que, ao se automatizar algum processo, observá-lo e ver como o mesmo ocorre, sem depender da narração de outra pessoa. Nós temos o hábito de suprimir etapas, acreditando que são óbvias, ou que estão subentendidas no que já foi dito. Para evitar assunções, veja por você mesmo.

Análise de documentos
Verificar como as informações são registradas atualmente nos permite mapear muito de como o sistema deve ser e inferir quais mecanismos e processos o sistema deve ter para que possa atender àquela necessidade. Reconheço que usei muito dessa técnica no passado.

Essas quatro técnicas foram das que mais usei quando o assunto era automatizar/informatizar um processo que já existia, ou fora dos computadores ou mesmo dentro, em planilhas ou sistemas isolados, integrando tudo. Poderia usar a palavra “simples” para descrever esses sistemas, afinal, buscavam “somente” transformar o processo atual em algo mais dinâmico e seguro. Muito embora ainda exista demanda para esse tipo de sistema, a maior parte dos trabalhos que chegam até mim na última década está bem longe disso. As pessoas chegam com novidades, apps, webapps, enfim, soluções para coisas que não existem no mundo real. Esse novo tipo de aplicação exige uma nova abordagem. Mais do que buscar entender como um processo funciona, agora precisamos validar como o processo foi imaginado para entender se tudo é como se pensou. Assim, seguem os que uso nesse tipo de situação:

Brainstorming
O bom e velho “toró de parpite”. Aqui buscam-se todas as ideias possíveis e mais tarde nós a validaremos e pensaremos em qual rumo tomar. A proposta é muito simples: gerar o maior número de insights sobre o problema que o nosso aplicativo quer resolver.

Prototipação
Existem diversos tipos de protótipos. Desde usando ferramentas, frameworks até mesmo o bom e velho papel e caneta. Sério, isso já me salvou em algumas situações. O nível de realidade que se vai usar aqui depende somente do nível de abstração que seu cliente e você conseguem suportar. Enquanto existem pessoas que conseguem entender alguns rabiscos no papel e imaginar como a partir daquilo surgirá um aplicativo, muitos outros têm dificuldade e precisam de um detalhamento mais próximo do resultado final. Cabe ir avaliando isso ao longo do levantamento de requisitos.

Use cases
Como eu já ouvi gente batendo forte em use cases eu sou obrigado a citá-los aqui. Sim, eles são bons e são necessários. Eu acho bobo voltar àquele debate sobre a documentação, mas só para mencionar, sim, existem documentos que são necessários e precisam ser atualizados, mesmo na visão do mais fundamentalista dos agilistas. A parte boba disso é acreditar que isso (ou o oposto) se aplica a todo e qualquer documento. Tendo isso como posto, já tive processos complexos que precisaram não só de um use case, mas também de um diagrama de sequência para ficar claro para todo mundo. Depois que a tarefa foi cumprida o documento foi desprezado, mas para a sua execução esses documentos foram de vital importância.

e finalmente User Stories!
Como eu gosto muito desse modelo, eu vou deixar aqui só um gostinho, deixo para um outro post falar mais sobre o assunto. O que eu preciso dizer de imediato é que é uma das formas mais simples de coleta de requisitos, trabalhando com uma língua que desenvolvedor e cliente conseguem entender, dividindo o trabalho em unidades que agreguem valor ao produto/projeto, definindo critérios claros de validação para que todos os envolvidos saibam sem sombra de dúvida que o trabalho foi concluído.

Conclusão
Sem o menor preconceito, já usei todas as técnicas acima, umas mais ou menos, sempre buscando entender o que meu cliente precisava. Um bom desenvolvedor vai ter sempre uma boa caixa de ferramentas preparada para usar a certa no momento mais propício. Entender o problema é metade da solução.

Tem-gente-que-nao-sabe-pedir

A sabedoria de Musashi

Estamos no Japão feudal, um tempo e local onde as pessoas buscavam fazer aquilo que lhes era atribuído buscando a máxima perfeição, tanto nos seus modos como em seus resultados. Muita coisa podemos aprender de lá. Nesse época, vivia por lá um homem chamado Miyamoto Musashi. Ele era um samurai.
Dentre diversos ensinamentos que esse sábio nos deixou, muitos podem ser aplicados a coisas do nosso cotidiano, inclusive, por que não, no desenvolvimento de equipes e pessoas de alto desempenho. Vou citar alguns aqui, extraídos do livro “Os cinco anéis”.

“There is nothing outside of yourself that can ever enable you to get better, stronger, richer, quicker, or smarter. Everything is within. Everything exists. Seek nothing outside of yourself.”

O paralelo que podemos fazer desse ensinamento seria que muitas vezes, pessoas, organizações, equipes buscam soluções mirabolantes e demandam que pessoas externas àquele grupo venham para lhe dizer obviedades. Ouça seu time, faça retrospectivas, sessões de brainstorming, a solução para seus problemas pode estar escondida dentro daquele cara mais tímido da sua equipe.

“Do nothing that is of no use”

Evite o desperdício. Desperdício em todas as suas formas. Mapeie o sua cadeie de valor e encontro as etapas em seu trabalho que realmente agregam valor ao seu processo produtivo. Reuniões inúteis, estoques sem propósito, processo sobrecarregados, defeitos, tudo isso é desperdício e deve ser evitado.

“You can only fight the way you practice”

Ou no português claro e atual, cada um no seu quadrado. É impossível para alguém opinar com propriedade sobre algo que não conhece ou mesmo que conhece apenas superficialmente. Só é possível dar testemunho (novamente, com propriedade) de algo que se viveu. Se me propor a falar sobre as experiências de outros certamente soará falso e minha credibilidade se porá a perder. É importante entendermos que um time deve ter dentro de si todas as habilidades necessárias para completar suas tarefas. Veja bem, o time, não o indivíduo. Aceitar que existem áreas de conhecimento que fogem ao meu domínio me permite aprender mais sobre elas e evitar problemas.

“To know ten thousand things, know one well”

Hoje muitas pessoas se gabam de seu conhecimento horizontal, conhecer muitas coisas mas todas de maneira superficial. Isso leva a diversas coisas das mais bizarras como um consultor, que foi treinado por uma consultoria, não fez cursos, não participou de eventos ou coisa semelhante e muito menos participa da comunidade para poder debater suas idéias. Tal “profissional” afirma coisas como que o papel do ScrumMaster deve ser rotativo, sendo trocado o papel entre os membros do time. Esse, entre outros absurdos, são apregoados por profissionais rasos, que não buscam aprofundar o conhecimento em nada e dizem conhecer tudo que há para se conhecer. Caso você queira ser um profissional com alto conhecimento horizontal isso não é negativo. Mas é importante que antes de se tornar um generalista, seja especialista em pelo menos uma! Escolha uma área que você realmente gosta e aprenda essa pra valer! Depois vá e amplie seus conhecimentos, mas não sem antes ser reconhecidamente um especialista em alguma área.

“You must understand that there is more than one path to the top of the mountain”

Não negue as outras linhas de pensamento. Já vi isso dezenas, se não centena de vezes. O cara aprende Java e começa a descer o pau em .NET, aprende Kanban e começa a malhar em Scrum. Acontece todo o momento, muito, por medo dos profissionais. Muitos profissionais, por medo da contestação partem para o ataque e começam a detonar os outros métodos. Como eu sempre digo, não é porque você descobriu o martelo que agora tudo se tornou prego.

Assim meus amigos, nem preciso o quanto sabedoria pode vir de onde se menos espera e quanto isso é aplicável em nosso cotidiano, especialmente num mundo tão “dogmático” como esse de gestão ágil de projetos.

Quando os rótulos não atendem às suas necessidades

ler-rotuloAntes de começar esse artigo, eu preciso esclarecer. Eu não pretendo que esse seja o compêndio definitivo tal qual um comparativo entre os principais métodos (ou frameworks, ou práticas) ágeis disponíveis hoje. Nem tampouco quer determinar se existe uma resposta definitiva para as suas preces em decidir qual é a melhor, ou ainda, qual dessas visões está correta. O objetivo aqui é mostrar o quanto queremos adaptar as soluções às nossas realidades, políticas e culturas, sem ao menos entender o porque de cada uma das propostas.
Continue reading

Serpenteando em direção à nenhum lugar em especial

Cinco comportamentos que muitas vezes vêm aglutinados, em cada um uma conspiração para levá-lo em direção a decepção:

Grandes sonhos: o objetivo não é impacto consistente ou um trabalho significativo, é um sucesso gigantesco, o se tornar uma a estrela e a capacidade de mudar o mundo. Não seria o suficiente para mil fãs de verdade, o grande sonhador quer um estádio lotado em cada cidade.

Maus hábitos de trabalho: Voando de projeto para projeto, à espera de inspiração para chegar, enrolando, não tendo aulas, repetindo os mesmos passos iniciais mais e mais …

Busca de atalhos: Por que se preocupar com o longo caminho quando você pode encontrar um caminho mais curto, mais rápido? Esquemas mirabolantes para ficar rico rápido, acesso privilegiado e a busca para obtê-lo agora mesmo.

Pensamento Loteria: Esta é uma variação do pensamento de atalho, mas envolve a ser escolhido. Uma pessoa, uma organização, um Mágico de Oz, que vai magicamente fazer tudo isso acontecer.

A falta de auto-consciência: a auto-ilusão de que seu material é, de fato, de classe mundial, e que os críticos, todos que você conseguiu interromper, estão errados.

Apenas por diversão, imagine alguém que abraça o oposto de todos os cinco destes comportamentos. Alguém focado em fazer o trabalho, o seu trabalho , sem descanso cada vez melhor, de enviá-lo, acumulando pequenas vitórias e ganhar um fã de cada vez. E fazer tudo isso com um olho treinado sobre o que significa fazer melhor.

Difícil imaginar uma melhor chance de fazer a diferença.

Vi esse texto no blog do Seth Godin e gostei tanto que o traduzi (porcamente) para cá. Você pode ler o original aqui.