• Nenhum resultado encontrado

Entendendo User Stories

N/A
N/A
Protected

Academic year: 2021

Share "Entendendo User Stories"

Copied!
10
0
0

Texto

(1)

Entendendo User Stories

Rodrigo Yoshima – Técnico em Processamento de Dados pela UNESP, bacharel em Administração de

Empresas pelo Mackenzie-SP, certificado em UML 2.0 pela OMG e também certificado Scrum Master, possui 14 anos de experiência em gestão e desenvolvimento de software em projetos de missão crítica para grandes indústrias, bancos e hospitais. É instrutor de processos e arquiteto da ASPERCOM.

Fonte: revista Mundo Java nº 32.

Muitas empresas buscam modelos ágeis para desenvolvimento de software e esta busca se deve principalmente à adoção e divulgação do Scrum como prática de gerenciamento de projetos aqui no Brasil. Um pilar muito importante para qualquer metodologia ágil é a ordem de construção das funcionalidades: no Scrum chamamos isso de "Product Backlog", no OpenUP chamamos isso de"Lista de Itens de Trabalho", na FDD chamamos isso de "Lista de Funcionalidades", no Extreme Programming a fila de construção não tem um nome definido, mas seriam as histórias que ainda não fazem parte da iteração corrente. De qualquer forma, em todas as metodologias ágeis nós trabalhamos com uma fila de construção composta por itens de trabalho. Uma das maneiras mais comuns de manifestar esses itens de trabalho é utilizar User Stories (ou histórias do usuário).

User Story é uma técnica leve e ágil que organiza o planejamento do projeto. Kent Beck cunhou este termo dentro da metodologia Extreme Programming. O princípio básico desta técnica é favorecer a comunicação. A comunicação"face-a-face" é a melhor maneira de especificar juntamente com os usuários o que o software deve fazer. Assim, a técnica fortalece o envolvimento dos usuários ou da área de negócios da empresa no desenvolvimento do projeto.

Na tabela 1 nós temos um exemplo de uma planilha com a Fila de Construção de um software baseado em User Stories. Este exemplo foi retirado do artigo "Entregue Software Funcionando! Gerenciamento de Projeto Ágil", da Mundo Java edição número 26. Nesta planilha, ordenamos as histórias, separando-as em iterações de acordo com o tamanho funcional de cada história (pontos) e na velocidade da equipe (quantos pontos a equipe consegue entregar dentro da iteração).

ID Funcionalidade Iteração Pontos

1 Entrada do pedido(simples) 1 8

2 Interface de transmissão de dados vendedor <-> ERP 2 2 3 Integração do pedido (vendedor -> ERP) 2 5 4 Entrada do pedido: cálculo de preços e impostos 3 5 5 Integração de dados de preços (ERP -> vendedor) 3 2 6 Integração de dados de impostos (ERP -> vendedor) 3 2 7 Entrada do pedido: vendas parceladas 4 3 8 Entrada do pedido: limite crédito 4 3

9 Consulta informações do cliente 5 3

10 Integração de clientes (ERP -> vendedor) 5 5

11 Consulta informações de produtos 6 5

12 Integração de produtos (ERP > vendedor) 6 1 13 Consulta notas fiscais e integração (ERP -> vendedor) 7 5

(2)

O que é uma User Story?

Segundo Kent Beck, o criador do conceito, uma Story é uma unidade funcional de planejamento visível para o usuário/cliente. Essa definição não é muito amigável para quem está iniciando na técnica, porém, é a melhor definição para as Stories. Olhe novamente a tabela 1. Esta lista é um conjunto ordenado de itens a fazer, sendo que cada item traz valor para o usuário/cliente. O usuário pode dar a sua opinião sobre o que é mais prioritário e o que deve ser entregue antes ou depois. Isso auxilia o próprio usuário a planejar as iterações e os releases. Além de uma planilha eletrônica é muito comum utilizarmos fichas pautadas para manifestar as Stories. Ficha pautada (lndex Card) são cartões em papel à venda em qualquer papelaria.

Figura 1. Exemplo de User Story em ficha pautada.

Usar fichas pautadas não é um mito das metodologias ágeis! Eu uso e muitos projetos que tenho contato também estão utilizando Stories em cartões. O motivo para fugir de planilhas eletrônicas e ferramentas de gerenciamento de projeto é exatamente favorecer a comunicação "face-a-face" com o usuário sobre algo palpável e visível fisicamente. Geralmente nós colocamos os cartões fixados num espaço na parede da sala do projeto, onde todos podem ver. Visibilidade é um ponto-chave! Em todo momento você e a sua equipe estarão com as Stories logo à frente. Isso beneficia o foco nos objetivos da iteração e também facilita conversas com o cliente e entre a própria equipe.

Logicamente que falamos num "ambiente Extreme Programming", no qual outras práticas auxiliam uma comunicação rica com todos os envolvidos para o benefício do projeto. É importante que a equipe esteja toda junta num mesmo espaço físico, que não exista barreiras e facções dentro da equipe (divisões rígidas entre analistas, programadores, testers etc.) e também é importante que o usuário/cliente participe ativamente do projeto. Além disso, mais uma prática importante é suporte para este tipo de interação com o usuário/cliente: o contrato de escopo negociável (vide referência). Nós utilizamos artefatos leves como um cartão para que exista MUITA conversa quando aquele cartão for desenvolvido, focando o que é mais importante para o usuário sem ter discussões contratuais ou dissensões sobre controle de escopo. Uma User Story não é uma especificação formal, mas sim um convite a uma conversa rica que beneficia a todos no projeto.

Dois conceitos importantes também são defendidos por Kent Beck: o usuário/cliente é o responsável por escrever as histórias e elas devem ser estimadas rapidamente. O usuário se responsabilizar por manter as Stories é uma prática importante: com isso, o usuário passa a

(3)

participar mais ativamente, controlando a equipe técnica (os desenvolvedores) dentro do planejamento.

Sobre a estimativa, o peso funcional que você dá para uma Story é um importante parâmetro para o usuário/cliente tomar decisões sobre o rumo do projeto. Essa decisão é sempre baseada em retorno sobre investimento (ROI).

Figura 2. Um conjunto de Stories de um sofware de rede social.

Imagine o cenário descrito nas Stories da figura 2. Como o usuário é o responsável pelas Stories, ele geralmente sabe o valor de negócio de cada cartão. A base do planejamento ágil é tomar decisões a respeito do que entra na próxima iteração levando-se em consideração a capacidade de produção da equipe (conhecido como velocidade) e o valor de negócio agregado. Nesse exercício é imprescindível saber o tamanho funcional da história associado ao seu valor para os usuários.

Levando-se em consideração que a cada iteração que termina temos software funcionando para que o usuário/cliente use o que está sendo construído, esse contato com o sistema sempre muda a "cabeça" do usuário e novas Stories emergem ou podem ser descartadas (nem sempre mudanças são para aumentar o escopo). Criar histórias, quebrar histórias, fundir histórias, rasgar histórias, atribuir peso funcional e saber o valor de negócio é a base para o desenvolvimento ágil.

Existem algumas características sobre as histórias que permitem que elas sejam estimadas rapidamente. Urna User Story tem que ser funcionalmente pequena para que a equipe tenha segurança na sua estimativa. Se a história é grande demais será difícil estimá-la, assim é melhor quebrá-la em histórias menores. A equipe é responsável por estimar o esforço. Como podemos ver, a técnica é completamente relacionada com planejamento do projeto, sem precisar

(4)

de métricas dispendiosas e nem das famosas "gordurinhas" ou "pulmões" irracionais nas estimativas tradicionais.

Características de uma User Story - INVEST

Como você já deve ter notado, User Stories é uma técnica leve para que os clientes e usuários efetivamente direcionem o desenvolvimento. Os clientes e usuários é que estão no controle do projeto. A equipe simplesmente desenvolve as histórias que foram atribuídas à iteração corrente. O uso de fichas pautadas é indicado para favorecer as mudanças e o diálogo. Sobre essas mudanças, na minha experiência, vejo que os usuários "sentem menos dor" ao rasgar uma ficha pautada do que apagar ou alterar uma especificação com dez páginas. Em desenvolvimento de software, TUDO sempre muda. Especificações nunca podem ser tomadas como válidas até que se provem verdadeiras por meio de software funcionando.

Mike Cohn escreveu uma das literaturas mais importantes sobre User Stories (vide referências). Na sua obra, ele também citou Bill Wake sobre as características de uma Story. Basicamente Stories devem ser: independentes, negociáveis, ter valor para os usuários (value), estimadas, pequenas (small) e testáveis (nos termos em inglês, chegamos ao acrônimo INVEST).

Apesar de ser difícil em alguns casos, busque ter histórias independentes uma das outras. Se existe muita dependência entre histórias inevitavelmente você terá problemas para planejar e estimar o projeto. Isso está retratado exatamente nas figuras 1 e 2, sobre a história "Consultar, Escrever e Apagar Recados".

Figura 3. Quebrando histórias, mas gerando dependências.

Veja a figura 3. Conforme citado, histórias são quebradas ou agrupadas constantemente, de acordo com o que ocorre no planejamento e conforme a vontade dos usuários. Neste caso, a história "Consultar, Escrever e Apagar Recados" foi quebrada em "Consultar e Escrever Recados" e "Apagar Recados". Isso pode ter sido feito simplesmente porque o usuário achou que apagar

(5)

recados não tem tanto valor de negócio e pode ser desenvolvido nas últimas iterações. Porém, este tipo de quebra incluiu uma dependência. A história "Apagar Recados" não pode ser desenvolvida antes de "Consultar e Escrever Recados", já que para apagar também é necessário consultar. Se você parar para pensar, o peso funcional três também só faz sentido se "Apagar Recados" vier depois de "Consultar e Escrever Recados". Este caso é bem simples, porém, em sistemas mais complexos, algumas dependências não são tão óbvias. Lute para deixar as histórias as mais independentes possíveis uma das outras.

Outra dica é evitar histórias do tipo "Manter Recados". Vocês devem estar se questionando porque na figura 3 coloquei "Consultar, Escrever e Apagar Recados". Para histórias e casos de uso é indicado evitar usar "Manter", "Gerenciar" e outros afins. Prefira escrever no cartão exatamente o que a história faz, sem dar margens para interpretações ambíguas. Não tem problema algum o nome da história ou caso de uso ser grande!

Outra característica importante é que histórias são negociáveis. Vamos repetir mais uma vez: histórias não são especificações formais. Uma história simplesmente é a descrição sucinta de determinada funcionalidade. O cartão da história simplesmente é um lembrete dizendo que você deve discutir esse assunto com o usuário em momento oportuno (quando a história for implementada). Nós tomamos algumas decisões quando estimamos a história e discutimos mais quando a história está para ser implementada. Nessas conversas podemos enriquecer a história escrevendo no cartão algumas decisões tomadas, podemos criar novas histórias e até mudar histórias existentes. Tudo é fruto de negociação e descobrir "onde está o ouro".

Figura 4. Uma história com anotações e pendências após a estimativa.

“Onde está o ouro” versus “Eu quero tudo”

Você que está lendo este artigo pode ficar frustrado imaginando que o contrato de escopo negociável é o "calcanhar de Aquiles" para adotar o desenvolvimento iterativo de fato. Realmente é muito difícil e arriscado firmar o esforço num contrato de escopo fechado utilizando Stories da maneira que estou descrevendo aqui. É fato que a maior parte do mercado brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo, bancos, telecom, indústrias etc.). O contrato de escopo fechado promete "previsibilidade" no desenvolvimento de software, porém esta forma de contratação parte de duas premissas muito duvidosas: 1 — o cliente sabe exatamente o que quer; 2 — a equipe sabe estimar exatamente o esforço de construção.

(6)

Se você já trabalhou em dois ou três projetos de software, sabe perfeitamente que essas premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu gerente colocar 50%, 100% e até 150% de "gordura" ou "pulmão" no valor da proposta para o cliente. E esse é o resultado: tentar forçar a "previsibilidade" num contrato de escopo fechado gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como verdade absoluta e dizem: "Eu quero tudo!!!", não se importando se a solução vai resolver os problemas ou não.

Na verdade, um projeto de software tem uma peculiar característica de "constante investigação". Ken Schwaber chama isso de "inspeção e adaptação". Em termos mais práticos, o dia-a-dia de uma equipe de desenvolvimento de software é "checar se estamos no caminho certo e ajustar o rumo sempre que necessário". Desenvolvimento de software é um processo criativo de pesquisa, então, especificações pactuais "gordas" que "apodrecem" no nosso controle de versão nos ajudam pouco para o sucesso do projeto. Em projetos de software bem-sucedidos é comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que não podem ser ignorados e a outras possibilidades de solução ou "atalhos" que devemos aproveitar. Dentro do desenvolvimento iterativo, esses problemas e atalhos se tornam muito claros.

O cliente "querer tudo" sem dar margem para conversa não é saudável para nenhum projeto. Ao invés disso, o cliente deveria participar ativamente do projeto para "querer o melhor" e auxiliar a equipe de desenvolvimento a encontrar "onde está o ouro". Muitas literaturas citam a regra de Pareto sobre um projeto de um software: 20% das funcionalidades agregam 80% do valor do software, isto é, todo software possui um pequeno conjunto de funcionalidades que resolverão praticamente todos os problemas dos usuários. Podemos considerar que uma boa equipe de desenvolvimento de software é aquela que sabe descobrir quais funcionalidades fazem parte desses 20% mais importantes! Para isso, nós utilizamos as Stories com um sentimento de experimentação e fugimos de "especificações lavradas em cartório" que temos que seguir. Stories devem ter um enfoque informal, devem ser discutidas, devem ser fáceis de criar, priorizar, manusear e descartar (uma ficha pautada é perfeita para isso!).

Acredito que muitas empresas ainda vão demorar bastante para mudar sua visão sobre desenvolvimento de software. É impressionante a falta de sentido que existe na contratação de grandes projetos de software com contratos de escopo fechado: o cliente acaba pagando ao fornecedor por um software que não vai resolver de fato seus problemas de negócio e ainda por cima arca com 50%, 100%, 150% de "gordura" embutida na proposta.

User Stories evoluem o software “organicamente”

Comentei várias vezes aqui a importância do próprio usuário escrever e ser responsável pelas histórias. Numa equipe de desenvolvimento ágil, o usuário ou cliente está sentado no banco do motorista e dirige o desenvolvimento utilizando Stories. Encare as histórias como pedidos de criação ou alteração feitos pelos usuários. Eles podem pedir novas funcionalidades,

(7)

alterações e até remoções de funcionalidades já existentes dentro do processo iterativo. Com isso, o software evolui do nada em direção à melhor solução em constante inspeção e adaptação. O desenho da figura 5 nos mostra o cliente à esquerda passando as histórias para a equipe que incorpora essas solicitações no software (logicamente para isso temos muita conversa). Note como o software vai crescendo "organicamente" conforme as histórias são implementadas sob ordem do cliente dentro do desenvolvimento iterativo. Ao fim de cada ciclo, o usuário vê o resultado ($$$) da incorporação das suas histórias no software, direcionando a criação das novas histórias para a próxima iteração.

Figura 5. O cliente direcionando e a equipe incorporando histórias no software. Muitas equipes com as quais tenho contato têm dificuldade em compreender a criação de software dessa maneira orgânica e crescendo de dentro para fora. Elas têm dificuldade em compreender um design emergente. Algumas equipes acostumadas com processo de desenvolvimento cascata realmente acreditam em muitas fases dentro do desenvolvimento que são dependentes uma das outras. Como exemplo, algumas equipes acham que o banco de dados deve ser modelado antes de pensar nas funcionalidades e processos. Outras equipes acreditam que todos os requisitos devem ser levantados antecipadamente, ou que TODA a arquitetura deve estar no lugar antes de começar a desenvolver. Porém, com a tecnologia e com as ferramentas que temos nas mãos atualmente, não é necessário ter fases dependentes para produzir o software. Isso é a base para o tão falado desenvolvimento iterativo. Com uma simples história na mão e um mínimo de decisões arquiteturais é possível entregar software funcionando para o usuário, nem que seja uma única tela. A partir deste ponto, novas histórias são incorporadas, evoluindo as decisões, o design e a arquitetura da aplicação.

(8)

Stories acompanham testes de aceitação

O simples nome de uma User Story na maioria das vezes é muito pouco para se direcionar uma implementação. Quando um usuário escreve no cartão uma história "Criar o Perfil na Rede Social" os objetivos desta "Solicitação" devem estar claros. O que o cartão representa deve estar claro!

Uma das dúvidas mais freqüentes para quem tem o primeiro contato com User Stories é “Onde está a especificação? Onde estão os requisitos?”. Se citamos aqui que uma Story nada mais é que uma solicitação de construção ou alteração do sistema, que outros subsídios temos para implementar essa solicitação?

Algumas dessas dúvidas são respondidas por meio dos critérios de aceitação da Story. Para deixar claro para os usuários e definir para o desenvolvimento o que uma história representa, critérios de aceitação são essenciais. Critérios de aceitação são os parâmetros definidos pelo usuário que dizem quando aquela Story está PRONTA. Isso é importante para os desenvolvedores, pois fornecem critérios objetivos para saber quando uma Story está finalizada, sem margem para relativismos.

Assim como a própria Story, os critérios de aceitação preferencialmente devem ser escritos pelos usuários no verso do cartão.

Geralmente os critérios de aceite são capturados e aprofundados quando a Story vai ser desenvolvida, porém isso não é regra. Também capturamos critérios de aceite ao estimar a história, ao planejar a iteração e até ao criar o cartão. A qualquer momento podemos colocar critérios no verso dos cartões para se lembrar de características que vão se transformar em testes de aceitação.

Figura 6. Critérios de aceite no verso do cartão.

Veja a figura 6. Note que os critérios tornam claros os testes de aceitação que validam se a Story está pronta. Ao mesmo tempo, os critérios declaram objetivamente o que "Criar o Perfil na Rede Social" significa na "cabeça" dos usuários sem margens para dúvidas ou má interpretação. Quando esta Story estiver pronta, a demonstração da funcionalidade para os usuários sempre se baseará nos critérios de aceitação acordados. Mas e se os usuários ao verem

(9)

essa funcionalidade rodando nos questionarem sobre o"Álbum de Fotos"que deve existir no perfil? Opa! Isso não está definido nos critérios de aceite e nem constou nas conversas sobre a história. Seria uma nova história! Veja a figura 7.

Figura 7. Nova Story "Subir e Remover Fotos do Álbum" e seus critérios de aceite.

Na figura 7 criamos mais uma história evitando "manter/gerenciar...". Veja como fica mais claro declarar que a história significa "Subir e Remover Fotos do Álbum". "Manter Álbum" é um termo genérico demais que pode gerar muitas dúvidas com relação ao que o cartão significa.

Onde está a especificação do projeto?

Outra razão de utilizarmos fichas pautadas é que as histórias são simplesmente descartadas depois que são incorporadas no sistema. No fim da iteração, todos os cartões implementados e aceitos pelo usuário vão para o lixo. Como a história nada mais é que uma alteração programada que muda o estado do sistema (ver artigo nas referências), depois que ela cumpriu seu papel ela não tem mais propósito algum. Muitos outros artefatos leves também são descartados depois que cumpriram seu propósito (vide meu artigo "Modelagem Ágil", MundoJava 27).

Porém, nós precisamos ter a falada especificação para saber o que o sistema faz, certo? Essa especificação formal auxiliará nas construções futuras, principalmente para correções e evoluções. Sim! Nós precisamos ter um registro, uma especificação funcional, algo que valide se o sistema está se comportando da maneira esperada.

A notícia estranha é que nós "agilistas" adoramos especificar! Nossa especificação é muito formal. Nossa especificação é muito completa e abrange todas as áreas do sistema. Nossa especificação é tão formal que até o próprio computador compreende. Nos dois últimos artigos que escrevi, "Requisitos Executáveis com FIT" (MundoJava 31) e "O ciclo ágil de um dia" (MundoJava 29), defendi o uso do Desenvolvimento Orientado a Testes (TDD) e o Desenvolvimento Orientado a Comportamento (BDD) como forma de especificação.

"Agilistas" fogem de longos documentos de especificação e preferem conversar "face-a-face" com o usuário para levantar requisitos. Porém, registramos essas decisões e esses requisitos por meio de testes automatizados (sejam unitários, funcionais ou testes de aceitação).

(10)

Com isso, nossa especificação acaba sendo executável e muitas vezes dentro do próprio código, correndo menos riscos de ficar defasada como geralmente ocorre com os longos documentos apartados do código.

De qualquer forma, também é possível aplicar a técnica de User Stories mesmo quando não se utiliza TDD ou BDD para ter especificações executáveis. Você usa as histórias para os usuários guiarem o desenvolvimento, dentro do planejamento iterativo do projeto, e ao desenvolver a Story você cria e/ou atualiza os artefatos e especificações que estão fora do código (casos de uso, diagramas, testes etc.). Não é em todo sistema que é possível aplicar especificações executáveis sobre testes automatizados, porém, devemos nos esforçar ao máximo para melhorar nossa cobertura de testes automatizados e vigiar para que não tenha muitas especificações defasadas ou inúteis no nosso repositório de projeto.

Conclusão

User Stories são pilares importantes para a adoção de métodos ágeis, principalmente porque auxiliam o cliente a participar ativamente do projeto com uma prática que fornece poder e liberdade. As maiores causas de falha dos projetos são: a falta de participação dos usuários e a adoção de processos de desenvolvimento que distanciam eles. Processos iterativos mostram seu maior valor com participação ativa dos usuários.

Referências

 COHN, MlKE (2004). Users Stories Applied for Agile Software Development.  BECK, KENT (2004). Extreme Programming Explained.

 SCHWASER, KEN (2004). Agile Project Management with SCRUM.

 CALÇADO, PHILLIP (2008). User Stories are Just Schedulable Change: http://fragmen-tal.com.br/2008/10/01/user-stories-are-just-schedulabie-change/

 IMPROVE IT. Sobre contrato de escopo negociável: http://www.improveit.com.br/xp/ praticas/contrato

Referências

Documentos relacionados

Na avaliação da relação entre a escolaridade dos avaliadores e notas atribuídas para os aparelhos, observou-se, de maneira geral que, quanto mais alta a

Workshop em que cada participante terá oportunidade de pôr em pratica o caso que preparou e aprender como melhorar.. Os participantes continuarão a ser apoiados através de

Tendo como parâmetros para análise dos dados, a comparação entre monta natural (MN) e inseminação artificial (IA) em relação ao número de concepções e

Os estudos originais encontrados entre janeiro de 2007 e dezembro de 2017 foram selecionados de acordo com os seguintes critérios de inclusão: obtenção de valores de

Mesmo com a maioria dos centenários apresentando elevado percepção qualidade de vida, viu-se que o nível de atividade física e a média de número passo/dia, foram inferiores

eringmaterialsabstracts Referenciais com resumos Cobre a literatura especializada em materiais de construção e suas aplicações como polímeros, cerâmicas e materiais

De acordo com estes resultados, e dada a reduzida explicitação, e exploração, das relações que se estabelecem entre a ciência, a tecnologia, a sociedade e o ambiente, conclui-se

Meio ambiente, direitos humanos, terrorismo, globalização são alguns assuntos que estão na ordem do dia no plano internacional e o Direito Internacional Público tem procurado