{"id":6231,"date":"2017-04-06T15:41:19","date_gmt":"2017-04-06T18:41:19","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=6231"},"modified":"2017-04-06T15:41:19","modified_gmt":"2017-04-06T18:41:19","slug":"user-stories-quebrar-ou-nao-quebrar-eis-a-questao","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2017\/04\/user-stories-quebrar-ou-nao-quebrar-eis-a-questao\/","title":{"rendered":"User Stories. Quebrar ou n\u00e3o quebrar? Eis a quest\u00e3o."},"content":{"rendered":"

Em muitos casos quando estamos em clientes, nos deparamos com uma situa\u00e7\u00e3o que pode gerar um certo desconforto em alguns Product Owners e at\u00e9 mesmo em algumas pessoas com foco no processo como Scrum Masters, Agile Coaches ou Gerentes de Projetos. Uma user story grande, que corre o risco de demorar a “gerar valor” por ficar dias e mais dias no ciclo de desenvolvimento. Nesse momento, surge a grande d\u00favida: devemos quebrar essa user story? Essa pergunta vem com uma s\u00e9rie de outros questionamentos, como por exemplo: “A user story quebrada vai gerar valor?”<\/em>, “A user story quebrada vai ser percept\u00edvel pelo cliente?”<\/em>, “Como vamos explicar um aumento de backlog aos sponsors do projeto?”<\/em>. Essas perguntas recaem sobre a decis\u00e3o, deixando-a mais dif\u00edcil de ser tomada, e com um peso grande sobre o colo do Product Owner, e de quem o estiver auxiliando no processo.<\/p>\n

Muitas dessas d\u00favidas talvez surjam por conta dos conceitos que temos desde o “lan\u00e7amento” do \u00e1gil. O conceito de “hist\u00f3ria do usu\u00e1rio”, algo que deve ser escrito pelo usu\u00e1rio, indicando na vis\u00e3o dele, uma necessidade para o produto ou projeto. Segundo Mike Cohn<\/a> argumenta em “User Stories”<\/a>, uma US deve ser pequena, com descri\u00e7\u00e3o simples de uma funcionalidade contada a partir da perspectiva da pessoa que solicitou, geralmente um usu\u00e1rio ou cliente do sistema. Por conta disso nos prendemos muito ao “usu\u00e1rio final”, o cliente, o carinha que est\u00e1 na outra ponta da feature, sem levar em conta todas as outras pessoas que tamb\u00e9m utilizar\u00e3o a feature (time de suporte, time de opera\u00e7\u00f5es, os pr\u00f3prios devs, por exemplo).<\/p>\n

Alguns j\u00e1 devem ter lido ou ouvido “User Stories devem ser INVEST”, e pra quem n\u00e3o leu\/ouviu, \u00e9 um acronimo criado por Bill Wake<\/a> em seu artigo “INVEST in Good Stories, and SMART Tasks”<\/a> e reproduzido tamb\u00e9m por Mike Cohn<\/a> em seu livro “User stories applied”<\/a>.<\/p>\n

S\u00e3o livros e artigos bem interessantes, e em um TL:DR, o que ele diz \u00e9 que boas user stories possuem alguns atributos desej\u00e1veis. S\u00e3o eles: Independent<\/em>, Negotiable<\/em>, Valuable<\/em>, Estimable<\/em>, Small<\/em> e Testable<\/em>. Aqui, o que gostaria de chamar aten\u00e7\u00e3o s\u00e3o para 3 itens: Valuable<\/em>, Estimable<\/em> e Small<\/em>. Lembramos sempre do “Valor”, mas esquecemos do Estim\u00e1vel e Pequena. N\u00e3o uma estimativa mais apurada de esfor\u00e7o, pontos ou dias, mas algo que possa ajudar um Product Owner, por exemplo, a priorizar um backlog sabendo de uma dura\u00e7\u00e3o pr\u00f3xima que o card ter\u00e1. E principalmente, pequena, de forma a ser entregue em poucos dias entregando valor mais cedo.<\/p>\n

Nos prendemos ao contexto de valor gerado pro usu\u00e1rio final, mas esquecemos que o valor \u00e9 relativo. Al\u00e9m de ser algo que deve ser ben\u00e9fico para outras pessoas dentro do processo, como o time de desenvolvimento, por exemplo. No caso de um card que vai gerar uma API que poder\u00e1 ser utilizada por outros times, isso n\u00e3o gera um valor para o projeto como um todo? User stories t\u00e9cnicas n\u00e3o s\u00e3o user stories? N\u00e3o devem entrar no backlog? Se formos pensar somente no “card escrito pelo usu\u00e1rio”, uma cria\u00e7\u00e3o de API n\u00e3o entraria no backlog.<\/p>\n

Ent\u00e3o, vamos pensar no seguinte caso: o time X est\u00e1 trabalhando num projeto novo, o lan\u00e7amento de um e-commerce e precisa desenvolver uma feature que dever\u00e1 receber um pagamento via cart\u00e3o de cr\u00e9dito, e ap\u00f3s confirmado o pagamento envie por e-mail um documento em pdf listando os itens da compra realizada. Algo como “Eu como cliente gostaria de usar meu cart\u00e3o para pagar a conta, e ao final quero receber no meu e-mail um pdf listando todos os itens comprados.”<\/em>. Se formos pensar nesse card, o “valor” geral s\u00f3 ser\u00e1 entregue quando o pdf chegar no e-mail do cliente, certo?<\/p>\n

Essa US por si s\u00f3, teria um tamanho consider\u00e1vel, levando em conta que: ser\u00e1 necess\u00e1ria uma integra\u00e7\u00e3o com algum gateway de pagamento, para processar a compra no cart\u00e3o de cr\u00e9dito, uma API de mensagens que fa\u00e7a a rotina de disparos de e-mail, e uma API geradora de docs capaz de gerar o arquivo PDF que o cliente espera. E tamb\u00e9m \u00e9 prov\u00e1vel que uma PoC, caso o time n\u00e3o tenha mexido com gateways de pagamento antes. Se formos pensar no tamanho dessa user story, ela poderia levar semanas para ser desenvolvida por completo, se considerarmos o “valor” esperado pelo cliente, o PDF no e-mail, dessa forma n\u00e3o se encaixaria no Estimable<\/em> e nem no Small<\/em>. Mas uma API de envio de mensagens pode ser usada pelo time de marketing, por exemplo. O gateway de pagamento tamb\u00e9m j\u00e1 pode ser utilizado por outros times. Da mesma maneira o gerador de PDF j\u00e1 tem valor para outras equipes dentro do projeto. Al\u00e9m de que uma PoC tamb\u00e9m serve para validar uma hip\u00f3tese, nos ajudando a mudar de rumo mais r\u00e1pido, caso o conceito n\u00e3o seja provado. O que tamb\u00e9m, se formos pensar, \u00e9 valor.<\/p>\n

Dessa forma, esse “\u00e9pico”, poderia ser quebrado como descrito acima, criando cerca de 4 US, que tamb\u00e9m geram valor sozinhas. Valor que provavelmente n\u00e3o ser\u00e1 entregue somente ao cliente final, mas sim aos times de opera\u00e7\u00f5es, marketing e suporte. Pensar no cliente externo \u00e9 muito bom, mas devemos tamb\u00e9m pensar no cliente interno, aqueles envolvidos que quase sempre s\u00e3o esquecidos.<\/p>\n

O conceito de valor \u00e9 interpretativo demais, al\u00e9m de ser vol\u00e1til e perec\u00edvel. Tendo isso em vista, devemos ter bastante cuidado ao deixar de quebrar uma user story por achar que ela n\u00e3o est\u00e1 gerando o devido benef\u00edcio, \u00e9 importante lembrar que outras pessoas dentro do fluxo podem se beneficiar de um card quebrado. Dessa forma, se levamos semanas para entrega de uma user story, estamos depreciando o que poderia ter sido entregue, por conta da volatilidade. Fatiar cards, entregando hist\u00f3rias mais r\u00e1pido auxilia numa gera\u00e7\u00e3o de valor acelerada com risco reduzido da solu\u00e7\u00e3o perecer.<\/p>\n

E voc\u00ea? Como lida quando o assunto \u00e9 a quebra de user stories dentro do seu time? Deixe sua opini\u00e3o a\u00ed nos coment\u00e1rios \ud83d\ude42<\/p>\n

\n\"Quero<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Em muitos casos quando estamos em clientes, nos deparamos com uma situa\u00e7\u00e3o que pode gerar um certo desconforto em alguns Product Owners e at\u00e9 mesmo em algumas pessoas com foco no processo como Scrum Masters, Agile Coaches ou Gerentes de Projetos. Uma user story grande, que corre o risco de demorar a “gerar valor” por … \u00bb<\/a><\/p>\n","protected":false},"author":52,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123,254,257,166,231,258],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6231"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/52"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=6231"}],"version-history":[{"count":4,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6231\/revisions"}],"predecessor-version":[{"id":6237,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6231\/revisions\/6237"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=6231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=6231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=6231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}