Scrum

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.

Estruturando a retrospectiva

Recentemente em um dos meus últimos trabalhos como coach precisei recomendar um modelo inicial para as retrospectivas. É claro que o ScrumMaster precisa pensar em maneiras diferentes para evitar que essa cerimônia importantíssima caia na monotonia, mas a primeira, para que se descubram os sabores (ou dissabores) de uma retrospectiva, pode ser o ponto mais importante de uma equipe ágil.
Acredito que o primeiro ponto que preciso tocar aqui é porque fazemos retrospectivas. Numa visão Lean mais xiita poderíamos pensar que tudo que não agrega valor ao produto, por consequência ao cliente, não deveria estar presente no processo. Mas se dermos uma rápida olhada ao que diz o último (mas não menos importante) princípio por detrás do manifesto poderemos observar:

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Veja, faz parte do conceito de ser ágil pensar em maneiras de melhorar o como fazemos nossas coisas. Para mim, na verdade, o centro de “ser ágil” reside na evolução constante. Perceba que usei a palavra “constante” e não cíclica. Isso significa dizer que a evolução deveria ocorrer a todo momento. No instante em que se identifica um ponto de melhoria esse deveria então ser testado e tratado para que quem sabe no futuro faça parte do processo. Mas em um status inicial, equipes precisam de ferramentas para sistematizar sua melhoria. Mais do que isso, podemos dizer até que precisam de ferramentas para se disciplinar, tornar essa cerimônia um hábito e a partir daí sim buscar a evolução contínua. Até lá retrospectivas são muitas necessárias.

Tendo estabelecido o porque, vamos para o como. Muito do que eu falo sobre retrospectivas vem do livro da Diana Larsen e Esther Derby (Agile Retrospectives – making good teams great) pois sempre gosto da ideia de ter timeboxes definidos para cada atividade. De novo, isso disciplina e ajuda as pessoas a manter-se no foco. Assim elas dividem a retrospectiva em fases, como descrito à seguir:

ciclo_retrospectiva

Gosto muito dessa imagem pois tira um pouco da superficialidade de quem somente ouviu sobre a técnica proposta por elas e passamos a ver o ciclo completo. Isso ajuda muito a entender que mesmo retrospectivas, que ocorrem em ciclos, tratam de evolução contínua, pois o ciclo de melhorias nunca para. Assim, o que temos são cinco fases dentro da retrospectiva em si e mais outras que devemos ficar atentos no espaço entre uma retrospectiva e outra.

Set the stage

Momento no qual se explica como procederemos durante a retrospectiva, quais serão suas fases, quanto tempo cada uma levará, se serão necessários alguns acordos de trabalhos (work agreements). É o momento de colocar todos na mesma página para garantir a boa fluidez dessa cerimônia.

Gather Data

A fase da coleta de informações. Você deve criar mecanismos ou ambientes nos quais as pessoas se sintam seguras em relatar os fatos que ocorreram na última iteração. Você pode fazê-lo no momento da retrospectiva mas também pode ser feito de maneira contínua, ao longo do desenvolvimento. Pode ser usada uma técnica chamada timeline, onde você coloca em algum ponto do escritório um quadro que representa o seu ciclo (por exemplo, duas semanas, com um espaço para cada dia) e os membros da equipe vão até esse quadro e o preenchem com os eventos que acontecem no momento em que acontecem. Todo o fato que tiver impacto sobre o desenvolvimento deve ser relatado. Caso queira coletar os dados durante a retrospectiva, pode-se usar outras técnicas descritas no livro, como MAD/SAD/GLAD ou Plus/Deltas.

Generate Insights

Se a fase anterior era só para relatar o que aconteceu, nessa fase a ideia é ter ideias. Não tem ideia boba, a única indicação é que todos trabalhem para resolver os problemas mais do que para defender um ponto de vista. Após os presentes apresentarem suas ideias podemos passar para a próxima fase.

Decide what to do

Uma vez que sabemos o que aconteceu, que tivemos algumas ideias de como resolver, chegou a hora de pensar em quais dessas ideias podem virar ações concretas, coisas que podemos fazer para resolver o problema (ou melhorar o que estamos fazendo) já na próxima iteração. Perceba que aqui já não cabem mais abstrações, precisamos de ações que possam ser executadas por alguém, dentro do espaço de tempo que temos entre as retrospectivas. A técnica dos 5W2H pode ajudar a sistematizar essa fase.

Close the retrospective

Encerre relatando a todos as decisões tomadas, quem as executará, quais foram os problemas tratados e quando será a próxima retrospectiva.

Agora algumas dicas gerais

O foco da retrospectiva é a busca por soluções para problemas e melhorias no processo. Não é uma disputa de egos entre qual ideia é a vencedora ou mesmo que eu devo participar em todas as discussões, caso se deva escalonar em times maiores. O foco de todos os envolvidos deve ser sempre a melhoria do processo.

Outra dica importante é se criar um pequeno cronograma que pode ser apresentado no começo, na fase de preparação do ambiente. O próprio livro tem um exemplo.

cronograma_retrospectiva

Por último, mantenha o foco da equipe. Equipes grandes tendem a perder o foco em retrospectivas muito longas, portanto use os timeboxes a seu favor.

Espero que isso os ajude nas suas próximas retrospectivas.

Agile Tour 2014 – Missão cumprida!

LogoAgileTour2014Foi uma grande felicidade para mim. Esse foi o ano em que mais cidades tiveram o Agile Tour passando por elas. Em cada uma pude ver as pessoas felizes em receber um evento que fala de tecnologia, mas especialmente de pessoas e como trabalhar para que todas elas se sintam melhor em local de trabalho.

Iniciamos em Curitiba, depois São Paulo e então Campinas. Na sequência viajamos pelo interior do Paraná, para Cascavel e finalmente minha terra, Maringá. Outras cidades nos pediram eventos e vamos com certeza, com a força da comunidade (#AgilePower) fazer de 2015 um ano épico.

Em nome de toda a equipe organizadora, vai o meu muito obrigado a todos os participantes, palestrantes e patrocinadores que fizeram desse evento o grande sucesso que foi.

Todas as fotos, vídeos, grades e tudo o mais pode ser encontrado no site do evento.

Achamos um bug, o que fazer?

green_bug
Esse é mais um daqueles posts que eu vou só defender uma idéia. Não tenho a menor intenção de proclamar, como sempre, o que é certo ou errado. Deixo para vocês decidirem, depois de estudar um pouco o assunto, não só através dessa postarem, mas através de outras fontes também.

A história começa com a implantação de uma metodologia ágil, seja ela qual for. Todo o ciclo de desenvolvimento ágil se baseia na entrega de valor, através da entrega contínua e adiantada de software funcionando a nossos amados clientes. Tudo na mais alta qualidade, como todo profissional deve fazer. Acontece que nem sempre tudo ocorre como queremos. Como somos seres humanos, passíveis de erros, esses refletem no nosso trabalho e por conseguinte, em nosso código-fonte.

Mas como fazer? Aliás, quando fazer? Devemos contar o esforço desse nosso retrabalho como parte da nossa velocidade, ou como não estamos entregando valor algum novo ao cliente, não poderíamos contabiliza-los?

Em uma das empresas com as quais trabalhei, a consultoria que lá prestou o serviço antes de mim, instruiu o time de desenvolvimento a não contar os bugs. Afinal, em princípio esse trabalho não representa uma entrega de valor ao cliente, certo? Se pensarmos bem, os bugs em geral são trabalhos que, como não foram bem feitos no passado, voltaram para atrapalhar o presente e portanto são responsabilidade do time de desenvolvimento. Confesso que por muito tempo eu concordei com essa visão monocromática da coisa. Mas um dia me mostraram a luz e hoje vou partilhar com vocês.

Quando estive estudando a fundo os métodos ágeis, em especial o Scrum, descobri que eles são mais do que métodos para gestionar projetos ou equipes. Eles são modelos para gestão do conhecimento. Eles fomentam a colaboração entre os membros do time, entre os times e principalmente entre time e cliente. Todos partem do princípio que ninguém sabe o todo de um projeto e ao assumir isso, constroem o conhecimento dando um passo de cada vez. Lindo não? Um passo de cada vez, assim como é difícil planejar anos a frente por que muita coisa pode acontecer em nossas vidas, nós como seres únicos, imagine muitos de nós interagindo e criando pensando num objetivo comum, o projeto em questão. Cada pessoa que se soma ao time é um acréscimo infinito de complexidade. São novas idéias, novas habilidades, mas também novos egos, novas dificuldades. Em um cenário dessa complexidade, imaginar que se possa planejar mais do que algumas poucas semanas é um sonho muito distante. Por isso planejamos de maneira iterativa e incremental.

Esclarecida a parte do planejamento, vamos falar um pouco sobre as métricas que regem o nosso trabalho. Sim, somos ágeis e usamos métricas. Porque? Simples, vivemos no mundo real, das corporações, no qual os gestores precisam de métricas para avaliar se estamos indo bem ou mal em determinado projeto. Mas quais métricas são justas para o time e a gestão? Quais métricas fazem sentido? A coisa toda em cima dos bugs é que diretamente eles não agregam valor ao produto. Afinal não adicionam nada de novo e é algo que em algum momento alguém deixou de fazer certo, portanto devemos fazer certo agora, algo como pagar pelo débito que existe no projeto. Mas nem sempre é assim. Muitas vezes, muitas vezes mesmo, as empresas de software tem baixa retenção de funcionários/colaboradores e isso obviamente envolve os desenvolvedores. Assim a equipe que hoje mantém um produto pode quase nem ter mais alguém que faça parte da equipe original. Portanto puni-los fazendo com que suas métricas sejam desmotivantes não é o caminho.

Mas então, o que fazer com os bugs?

Simples, corrija-os. Mas e as estimativas? E os esforços? Respondo perguntando: a correção de um bug demanda esforço? Vai gastar tempo dos seus desenvolvedores? Poxa meu filho, se isso não vai se resolver magicamente, se as pessoas terão que gastar seu tempo e trabalho para resolver aquilo então isso merece uma estimativa de esforço. Não caia na armadilha de confundir métrica de esforço com valor de negócio. Realmente um bug não acrescenta valor nenhum ao negócio, ao produto e isso é fato, mas certamente vai demandar esforço do seu time.

Portanto, ao encontrar um bug, coloque-o no topo do seu backlog e lembre-se, ele vai te custar tempo, portanto deve ter a sua medida, em story points, homens-hora, pontos de função, o que seja. Embora realmente não isso não vai aumentar em nada o valor do seu produto.

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