User Stories – Descrição de requisitos que humanos entendem

Dentro da Engenharia de Software temos um sub-campo que é a Engenharia de Requisitos. A Engenharia de Requisitos é a “ciência” que estuda todas as formas de elicitar, analisar, validar, especificar e documentar requisitos, visando gerar insumos para a fase de projeto do software, coordenada por arquitetos de software ou analistas de sistemas, dependendo da empresa.

É nesta “fase de requisitos” que exploramos o quê, como e para quem iremos desenvolver as próximas funcionalidades do sistema. E no Scrum não é muito diferente disso, essa fase existe, embora distribuída em “pedaços”, no início de cada sprint, sendo executada durante a Sprint Planning.

Mas uma coisa que o Scrum não nos diz é: como organizar e/ou documentar as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com User Stories ou Histórias do Usuário: um artefato ágil para especificar requisitos.

Histórias do Usuário

Vamos partir aqui de algumas premissas básicas: toda funcionalidade que vamos desenvolver vai impactar a vida de no mínimo uma pessoa. Se não impacta a vida de ninguém, não deveria existir. O impacto pode ser grande ou pequeno, desde um botão que vai economizar 15 minutos de tarefas repetitivas ou um formulário que vai atender a uma norma legal do governo que poderia fechar a empresa.

Então sempre começamos com um “quem”.

Toda user story, como o próprio nome sugere, começa com um usuário. Este usuário é o ator principal da história, uma persona que todos no time conhecem e entendem como pensa, como age, quais são as “dores”, etc. É importante mapear essas personas que serão utilizadas antes de escrever user stories com elas.

A descrição de uma persona, e isso não faz parte da user story em si, pode ser como abaixo (exemplo da Umbler):

“Luiz é um desenvolvedor e também um empreendedor. Ele cria diversos projetos usando tecnologias como ASP.NET e Node.js e gosta de publicá-los em ambientes confiáveis e com preços razoáveis. O Luiz ocasionalmente tem amigos que o ajudam nestes projetos e quase sempre bola maneiras de rentabilizar os projetos. O Luiz prefere fazer deploy via Git ao invés de FTP por ser mais rápido e confiável, além de gostar de pagar apenas pelos recursos que consome no servidor ao invés de um fixo mensal.”

Eu poderia continuar escrevendo sobre essa persona, mas acho que você já deve ter entendido a ideia.

Assim, quando uma user story começa com “Enquanto Luiz…”, todo o time, que já conhece aquela persona (os mesmos podem ser apresentados antes da leitura de cada história) e já entende as motivações dela, tornando mais fácil tomar decisões futuras. Sempre que o desenvolvedor que estiver implementando uma funcionalidade que é “para o Luiz” estiver em dúvida sobre algo, ele sempre deve se projetar (através de empatia, jovem gafanhoto!) e pensar “se eu fosse o Luiz, como eu gostaria que isso funcionasse?”.

Ponto de vista do usuário

Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o que será desenvolvido.

Note que quem escreve as histórias do usuário é quem gerencia o produto: o Product Owner. Como alguém não-técnico e centrado no produto, cabe ao P.O. especificar “o quê” deve ser feito e “para quem”, mas não “o como”. A funcionalidade deve ser descrita a nível de usuário e a nível de negócio, jamais a nível de programação.

Um bom exemplo seria:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web.”

Um mau exemplo seria:

“Enquanto Luiz, eu gostaria de ter um formulário em React para criação de banco MongoDB, com os campos nome do banco, usuário e senha, que quando preenchidos iniciassem uma tarefa de criação de instância no datacenter 03 da Umbler e me retornasse os dados de acesso por email quando estivesse pronto.”

Um dos “mandamentos” é que o time deve se auto-gerenciar, eles devem decidir como cada funcionalidade deve ser desenvolvida. O P.O. sabe que MongoDB é uma demanda do mercado e que devemos ter isso em nosso catálogo de produtos pois temos muitos “Luizes” como clientes, mas se isso deve ser implementado com React, se deve ser assíncrono, em qual datacenter vai ficar, etc é com a galera técnica.

Sendo assim, sua história de usuário deve ser:

  1. sem detalhes de implementação;
  2. focada no que o usuário quer fazer;
  3. explicada do ponto de vista do usuário;
  4. curta e objetiva;

A motivação

O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para quê ela vai servir exatamente (do ponto de vista de ‘entrega de valor’)? O que isso vai impactar na vida dele?

Estas e outras perguntas devem ser respondidas na motivação, que é a terceira e última parte da user story.

Muitas vezes quando estamos desenvolvendo não entendemos porque estamos desenvolvendo aquela feature. E quando isso acontece, geralmente não tomamos as melhores decisões sobre dúvidas que temos. Esta listagem deve ter uma busca no topo ou uma paginação? Esta tarefa deve ser síncrona ou assíncrona? Essa informação será buscada com texto-livre ou através de opções fixas?

A motivação costuma deixar isso tudo muito mais claro e ajudar a criar features que realmente entregam valor ao usuário. Como no exemplo abaixo:

“Enquanto Luiz, eu gostaria de poder criar instâncias de MongoDB na Umbler para usar em meus projetos web porque usando serviços de terceiros sai mais caro e a latência é alta.”

Aqui deixamos explícito que o usuário quer ‘MongoDB na Umbler’ porque isso seria mais barato e mais rápido para seus projetos web. Sendo assim, no momento da implementação desta funcionalidade (que confesso pode ser quebrada em tarefas menores, mas é apenas um exemplo), podemos inferir que nossa solução:

  1. não pode ser resolvida através de integrações (add-ons);
  2. tem de ter uma baixa latência (no mesmo datacenter que o projeto dele);
  3. deve ser cobrado na mesma moeda do país dele (as soluções atuais são em dólar);

Essa informação ajuda a nortear as decisões, bem como se aliarmos às informações da persona do Luiz, veremos que se ele gosta de Git, é provável que goste de fazer deploy do seu banco MongoDB via linha de comando também.

Alguns autores defendem que a motivação, o “por quê” da user story, é opcional. Embora eu entenda que em alguns casos até possa ser verdade, eu encorajo a você sempre tentar deixar isso o mais explícito possível, usando aquela “máxima” de “o óbvio sempre precisa ser dito”.

User Stories na prática

O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em post its, uma por post it. Algumas equipes costumam imprimir cards já com o esqueleto da user story nele, para não esquecerem nenhuma das três informações centrais e até mesmo com outros campos como o número de pontos daquela tarefa, por exemplo.

Segue um exemplo bem elaborado, que pode servir de inspiração:

User Story Card
User Story Card

Esses cards são muito práticos e podem facilmente ser combinados com técnicas como Kanban (incluindo com Trello), para organizá-los e Planning Poker, para estimá-los (um conceito chamado de Story Points). Uma ressalva aqui é quanto ao “tamanho” da história.

Algumas histórias ficam tão abrangentes que costumamos chamá-las de épicos. Devemos sempre quebrar épicos em histórias de maneiras que elas possam ser “digeridas” pelo time que vai implementá-la. Não existe uma regra clara que diferencia um épico de uma história, mas o bom senso ajuda bastante. Algumas dicas nesse sentido são:

  • se não cabe em uma sprint, é um épico;
  • se consigo quebrar em dois ou mais story cards, é um épico;
  • se no Planning Poker gerou muita divergência de pontuações é um épico;

E um último ponto digno de nota é: não subestime a utilidade de artefatos mais tradicionais da engenharia de requisitos. Vão ter projetos, em que um story card não vai ser o suficiente e você terá de ter um artefato de apoio como um mockup, um diagrama UML ou até um caso de uso. Enquanto que para muitos times e projetos user stories se encaixam como uma luva, para outros, você precisará de técnicas complementares ou até substituir essa técnica por uma mais tradicional. Então fique atendo, Scrum não é bala de prata!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Os 6 melhores livros para estudar metodologias ágeis

Vez ou outra eu recomendo livros que já li aqui no blog, geralmente relacionados à empreendedorismo, que é o que mais tenho lido nos últimos anos. Hoje resolvi falar de livros sobre uma outra paixão minha: gerenciamento ágil de projetos. Desde 2010, quando conheci e me especializei no uso de Scrum e outras metodologias ágeis que não parei mais de estudar e ensinar o assunto para outras pessoas.

Após algum treinamento ou palestra, sempre vem aquela pergunta: que livros você recomenda? Pois bem, aqui vão eles!

Os livros que eu recomendo são:

Clique nas capas para mais detalhes e para adquirir os livros. Não, eu não faço pirataria e não vou colocar (nem permitir nos comentários) livros para download que não sejam realmente gratuitos.

Boa(s) leitura(s)!

Guia do Scrum
Guia do Scrum

O Guia do Scrum

Download gratuito

Existe uma frase popular que diz: “O Scrum é um framework simples de entender, mas difícil de dominar”. Por que isso?

Estamos falando de um framework ágil, e não de uma metodologia de desenvolvimento de software como RUP, ou seja, não há uma receita pronta aqui, mas sim uma estrutura mínima a ser seguida em um eterno fluxo de construir-medir-aprender assim como o do Lean Startup. Há apenas esse livro gratuito, de 19 páginas, para ser estudado e praticado ad infinitum.

Este guia é a base para entender o básico do Scrum e deve ser usado, na minha opinião, como ponto de partida de qualquer equipe que queira se tornar ágil. No entanto, conforme a equipe avança e percebe a necessidade de mais ferramental e informações, entram os demais livros abaixo listados.

Aqui no blog tem um bom resumo dele, caso queira saber mais, neste post.

Scrum: A arte de fazer o dobro do trabalho
Scrum: A arte de fazer o dobro do trabalho

Scrum: A arte de fazer o dobro de trabalho na metade do tempo

Comprar na Amazon

O Scrum foi co-criado por Ken Schwaber e Jeff Sutherland. Esse sr. Jeff serviu como militar e mais tarde, durante vários anos, atuou como gerente de projetos em grandes empresas públicas e privadas incluindo o FBI, sendo que essas experiências foram adicionadas ao que mais tarde ele e sr. Ken chamariam de Scrum.

É um excelente livro que conta as aventuras de Jeff Sutherland na aeronática americana em meio à guerra do Vietnã e como isso influenciou seu modo de gerenciar projetos. Também conta como aprendeu os princípios do Lean, das artes marciais japonesas e como isso tudo influenciou seu modo de pensar e acabou originando o Scrum. Em meio às histórias das origens do Scrum, ele fala muito sobre princípios e conta cases de aplicações bem sucedidas, de software à jornalismo.

Sinceramente? É uma leitura prazerosa e rica, mas não ensina Scrum para ninguém, gosto de indicar pois ajuda a entender os princípios, o mindset que originou o Scrum.

Implementando o desenvolvimento Lean
Implementando o desenvolvimento Lean

Implementando o desenvolvimento Lean de software: Do Conceito ao Dinheiro

Comprar na Amazon

Outro excelente livro que li já tem vários anos, desta vez de Mary e Tom Poppendieck. A Mary é uma engenheira com algumas décadas de desenvolvimento nas costas, que fala muito bem sobre Lean Software Development, outra técnica adaptada da indústria japonesa Toyota para o mercado de software, assim como o Kanban e até mesmo o Scrum (em partes).

Assim como o livro “Scrum: a arte de fazer o dobro de trabalho na metade do tempo”, que citei logo acima, a autora se prende demais em contar cases de sucesso e acaba demorando para entrar no Lean em si. No entanto, é muito enriquecedor do ponto de vista de princípios.

Programação Extrema
Programação Extrema

Programação Extrema Explicada: Acolha as mudanças

Comprar na Amazon

De todos os livros que vou indicar aqui, este é o único que nunca li. No entanto, conheço a trajetória de seu autor principal, que hoje trabalha no Facebook como mentor dos desenvolvedores mais jovens, Kent Beck.

Este livro é indicado pois é a obra-prima de Kent Beck (com a ajuda de Cynthia Andres), um dos signatários originais do manifesto ágil, movimento que difundiu as metodologias ágeis pelo mundo, e criador também das metodologias TDD (Test Driven Development) e XP (Extreme Programming).

Apesar do XP ser uma metodologia “concorrente” ao Scrum (que é a minha favorita), há conceitos muito valiosos no XP que cobrem “furos” do Scrum, como Pair Programming, só para citar um exemplo. Vale a indicação.

SBOK
SBOK

Guia SBOK: Um guia para o conhecimento em Scrum

Download gratuito

A Scrum Study é uma empresa que dá cursos e aplica provas de certificação em Scrum (embora eu sugira fazer direto com a Scrum.org) e, o SBOK (Scrum Body of Knowledge), é o guia que eles criaram (em analogia ao PMBOK) para ajudar que profissionais consigam tangibilizar melhor a adoção do Scrum em seus projetos, uma vez que o Guia do Scrum original não ajuda muito neste ponto.

O Guia SBOK tem vários pontos positivos e negativos: ele é muito útil ao discutir mais à fundo alguns conceitos pouco explorados no Guia do Scrum, levantar questões importantes e ensinar algumas novas técnicas de aplicação. Por outro lado, cria termos novos que não necessariamente (na minha opinião) enriquecem o Scrum, apenas complicam-o.

Enfim, é uma leitura muito boa que as vezes eu revisito para lembrar de algumas coisas.

Scrum e Métodos Ágeis
Scrum e Métodos Ágeis

Scrum e Métodos Ágeis: Um Guia Prático

Comprar na Amazon

E por último, mas não menos importante, o livro que eu escrevi sobre Scrum e Métodos Ágeis em 2016. Trabalho com Scrum desde 2010, principalmente como Scrum Master, o responsável por garantir e aperfeiçoar os processos dentro do time. Depois de tantos anos, Sprints e times diferentes, resolvi exteriorizar o que eu considero que funcionou nos times que eu trabalhei para complementar o Guia do Scrum, ou seja, não é um substituto ao Guia do Scrum, mas um adendo ao mesmo.

O Scrum fala por exemplo sobre fazer a Sprint Planning, mas não te diz como estimar as tarefas. Ele fala a Definição de Pronto, mas não te diz como criá-la. Fala sobre transparência no projeto, mas não te dá dicas de como alcançá-la. O meu livro procura preencher estas lacunas e só coloquei ele aqui por último na lista para não soar favoritismo. Mas eu realmente acho que ele é um bom livro. 🙂

5 técnicas para minimizar riscos de projetos oriundas do Scrum

Enquanto na função de gerente de alguns projetos, uma de minhas missões é minimizar ao máximo os riscos de cada um dos projetos. São vários os tipos de riscos inerentes a projetos de software, tais como:

  • risco de estourar o prazo;
  • risco de estourar o orçamento;
  • risco de não obter o retorno do investimento (ROI);
  • riscos tecnológicos;
  • riscos de pessoal;
  • etc

Obviamente não existe uma maneira de gerenciar um projeto 100% à prova de riscos e por isso me empenho o máximo que posso ao mesmo tempo que me preparo para imprevistos. As metodologias ágeis, e especialmente o Scrum (assunto principal do meu livro), foram criados exatamente para lidar com as incertezas dos projetos, ao contrário de metodologias mais tradicionais que tentam planejar tudo, em todos os detalhes, antecipadamente ao início do desenvolvimento.

Muitos gerentes mais tradicionais enxergam métodos ágeis como um risco a ser evitado, entendem que é mais seguro continuar do jeito tradicional de gerenciar projetos. No entanto, é exatamente o contrário. Sendo um processo iterativo e ágil, o framework Scrum inerentemente minimiza o risco ao abraçar as incertezas e inclui-las na pauta dos projetos. No artigo de hoje vou listar as práticas do Scrum que facilitam o gerenciamento eficaz de risco:

  1. Flexibilidade de escopo
  2. Feedback regular
  3. Empoderamento do time
  4. Transparência
  5. Entrega iterativa

Vamos lá!

Flexibilidade de escopo

Você sabia que os pinheiros mais antigos não são os mais fortes? São os mais flexíveis. Quando acontecem as tempestades, os primeiros pinheiros que quebram são aqueles que não se torcem ao vento, que não se adaptam, que tentam se manter rígidos e impassíveis em qualquer situação.

Da mesma forma, a flexibilidade de escopo  reduz o risco do projeto em relação ao ambiente externo. Tendências aparecem. Clientes desaparecem. Crises acontecem. O mercado muda. Você tem de ser o mais resiliente possível se quiser se manter no “jogo”.

O risco é, em grande parte minimizado em Scrum, devido à flexibilidade de adicionar ou modificar requisitos em cada iteração durante o ciclo de vida do projeto. Isso permite que a organização possa responder às ameaças ou oportunidades do ambiente de negócios e as necessidades imprevistas, sempre que surgirem, geralmente com custo baixo de gerenciamento.

Feedback regular

Você sabe o que significa a palavra feedback? Retroalimentação. Ou seja, “alimentar de volta”. Do ponto de vista de gerência de projetos, você inicia o projeto “alimentando” (feeding) seu time com informações sobre o projeto e espera que, regularmente, você seja “retroalimentado” (feedbacked) sobre como anda o mesmo.

Ciclo de Feedback
Ciclo de Feedback

O feedback regular é útil para diversas situações e estados do projeto, como ajudar a manter o foco no objetivo final, corrigir deficiências nos processos e especialmente no caso de gerenciamento de riscos, ele reduz as expectativas relacionadas com o risco. Isso é útil tanto nos casos em que o projeto está indo bem, quanto no caso contrário, afinal, é melhor saber que há algo de errado o mais cedo possível, e não no dia anterior à entrega, certo?

Sendo iterativo, o framework Scrum dá ampla oportunidade para a obtenção de feedback e definição de expectativas ao longo do ciclo de vida do projeto. Isso garante que os stakeholders do projeto, bem como o time, não sejam pegos de surpresa por má comunicação relacionada aos requisitos, por exemplo.

Empoderamento do time

Existe um vídeo muito famoso na Internet em que um gerente de projeto do Spotify apresenta a cultura de engenharia deles, que é uma evolução do Scrum em conjunto de uma série de técnicas ágeis. Em dado momento no vídeo, ele cita um gráfico de “alinhamento x autonomia” e como isso afeta os resultados obtidos enquanto um time.

alinhamento-x-autonomia
alinhamento-x-autonomia

Dê pouco alinhamento e pouca autonomia e você será aquele “gerentão” 1.0 que manda e a equipe tem de obedecer (isso ainda funciona no século XXI?), mesmo sem saber porque está trabalhando no projeto. Dê pouco alinhamento e muita autonomia e sua equipe desperdiçará tempo e dinheiro da empresa pois não trabalhará em um objetivo comum. Dê muito alinhamento e pouca autonomia e sua equipe ficará frustrada, pois apesar de saber o objetivo, você ainda quer mandar no dia-a-dia deles e, bem, pessoas inteligentes não gostam disso.

Então o que sobra?

Muito alinhamento, para que todos saibam qual é o objetivo, o que deve ser feito. Mas o “como deve ser feito”, deixe para o time decidir (alta autonomia). Entre tantas responsabilidades que dar poder ao time tira dos ombros do gerente está o das estimativas de software. Deixar para o time estimar o tempo de desenvolvimento cria estimativas mais precisas, aumenta o engajamento e reduz os riscos, permitindo uma entrega oportuna de incrementos do produto.

Transparência

Lembra do que falei sobre a importância do alinhamento no tópico anterior? Para garantir que o time esteja sempre alinhado, e não apenas na reunião de planejamento do projeto, é vital que exista transparência no projeto. Nas decisões, nas métricas, nos objetivos, no andamento, etc. Dentre muitos benefícios de uma gestão transparente do projeto está a redução dos riscos não detectados inicialmente e a resolução proativa de muitos problemas.

O princípio de transparência do Scrum, em torno do qual o framework Scrum é construído, garante que os riscos sejam detectados e comunicados no início, levando a um melhor tratamento e mitigação de riscos. Além disso, quando as Reuniões Diárias do Scrum são realizadas, os impedimentos que um time está enfrentando atualmente, podem ser considerados um risco para outros projetos e times no futuro, e eles devem ser tratados e registrados de forma que não se repitam.

Entrega iterativa

O método de desenvolvimento de software mais tradicional de todos é o Cascata (Waterfall). Ele possui esse nome pois é um método composto por fases bem definidas, onde cada uma acontece de uma vez, em ordem linear, do início ao fim do projeto, ou seja, do levantamento de requisitos até à implantação no cliente. Como você deve saber, existem projetos de software que duram anos e empregam dezenas ou até centenas de desenvolvedores. Qual a chance de uma especificação de software feita há anos atrás ainda representar a realidade do cliente hoje? Ou a realidade do mercado?

O que acontece na prática é que não temos como prever o futuro diante das incertezas da construção de software moderno, principalmente web e mobile. Se começarmos a definir “no detalhe” como o software será daqui há alguns anos, estaremos apenas chutando, na melhor das hipóteses.

Entregar o projeto iterativamente, em ciclos curtos de algumas semanas, gera valor e valida o andamento do projeto com o cliente a cada iteração, reduzindo significativamente os riscos do mesmo, tanto para você, quanto para seu cliente.

Afinal, gerenciar riscos de projetos não é exatamente isso, que todos se saiam bem sucedidos ao final do mesmo? Ou você ainda tem aquele mindset que o Manifesto Ágil condena de ficar se defendendo atrás de um contrato?

Deixe nos comentários a sua opinião!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!