[livro] Histórias de Usuário – Por que e como escrever requisitos de forma ágil?

livro
Padrão

Talvez você já saiba, ou talvez não, mas eu e o Daniel escrevemos um livro sobre Histórias de Usuário (user stories).

Trata-se de um eBook gratuito, que se encontra atualmente na segunda edição e já foi baixado por mais de 2.000 pessoas.

Estamos recebendo ótimas criticas, e isto nos deixa muito motivados para seguir evoluindo o livro. Também estamos pensando em mais livros ligados a métodos ágeis.

Você pode nos sugerir temas para os próximos livros na seção de comentários deste post.

Para baixar o livro basta acessar o link http://historiasdeusuario.com.br e seguir as instruções de “pagamento”, (na verdade o livro custa um tweet ou um compartilhamento no facebook).

 

Alguns assuntos abordados no livro:

  • Por que escrever histórias de usuário?
  • Existe um padrão para escrever?
  • Como testar? BDD!
  • O conceito INVEST
  • Cartão, conversação, confirmação! O conceito 3C
  • Bugs também viram histórias de usuário?

Além de exemplos e dicas sobre próximos passos para quem quer se tornar um jedi em histórias de usuário.

Então é isto, baixa lá o livro e boa leitura! :)

 

Como criar um ambiente de aprendizagem em sua equipe?

Padrão

Palestra realizada no FISL 2013 sobre cultura de aprendizagem por Rafael Helm e Guilherme Elias.

Nesta palestra Rafael e Elias falam sobre algumas ações que empresas e equipes podem realizar para disseminar conhecimento entre as pessoas, criando assim um ambiente de aprendizagem e melhoria contínua.

Pratique para sempre

Padrão

karate-kidPraticar para evoluir é algo necessário na vida de qualquer pessoa. Desde criança, usamos a prática como forma de aprendizado e evolução, basta você puxar da memória para lembrar como foi necessário praticar até conseguir amarrar os cadarços de um calçado sozinho, sem precisar da ajuda dos pais.

Atletas chamam está prática de “treino”. Atletas treinam quase que diariamente, muitas vezes de forma exaustiva e repetitiva. Se você acha que o jamaicano Usain Bolt (recordista mundial e bi-campeão olímpico nos 100 e 200 metros), atingiu o alto nível através de talento e boa genética (sorte), então de uma olhada neste vídeo e veja como ele treina.

É bem provável que ainda hoje você vai precisar executar alguma tarefa que não se sente confortável, que ainda não praticou o suficiente. Alguém pode te ensinar algo, te dar uma introdução ou até uma explicação bem detalhada; você pode ler livros e fazer treinamentos, mas muitas vezes você só vai aprender de verdade praticando, tentando, treinando, refletindo sobre os erros e acertos, e praticando novamente.

No desenvolvimento de software praticar/treinar é algo mais do que necessário, é obrigatório, é fundamental. Durante toda sua carreira, você precisará passar por ciclos de aprendizado que somente serão concluídos se você praticar.

Não importa se você está aprendendo uma nova linguagem de programação, ou aprendendo TDD, ou aprendendo uma nova forma de escrever requisitos que pode ser através de user stories, ou uma nova forma de estimar requisitos através de user story points e planning poker ou outras formas de estimativa, ou um novo modo de trabalhar em equipe através de Scrum e eXtreme Programming. Não importa o que você está aprendendo, você vai precisar praticar, refletir, e praticar novamente para aprender de verdade.

Assim como no esporte quanto na vida, praticar/treinar dói. Mas acredite, se você insistir e perseverar a dor vai passar, e com o tempo aquela prática que antes te machucava vai se tornar algo agradável. Eu vejo muita gente começar a correr para perder peso, (mesmo odiando correr), mas com o tempo, através da prática gradativa o que antes era algo desconfortável rapidamente deixa de ser algo tão ruim, e mais a frente a pessoa começa a curtir o hábito da corrida, e muitas vezes até começa a acordar mais cedo para correr mais tempo e distâncias maiores.

“Não se preocupe com a perfeição – você nunca irá consegui-la.” (Salvador Dali)

Um ponto importante a ser considerado quando estamos praticando é trabalhar com baby steps, ou seja, pequenos passos de forma gradativa, buscando sempre acertar o próximo passo ao invés de alcançar a perfeição. Desta forma seu aprendizado vai passar por várias pequenas vitórias que vão motivá-lo, e quem sabe, sem perceber, alcançar a perfeição.

No desenvolvimento de software eu vejo uma onda bacana de coding dojo acontecendo dentro de empresas, universidades e eventos, acho isto ótimo. Os coding dojos proporcionam um ambiente saudável de aprendizado, já que a troca de experiências entre os participantes é o ponto forte da atividade, e para pessoas como você que querem aprender e praticar, isto, vamos combinar, é uma enxurrada de motivação.

E você, já praticou hoje? ;)

Minha equipe / empresa quer adotar Metodologias Ágeis. Quais os benefícios?

Padrão

O principal? Uma mudança de atitude na organização. Ter pessoas que estão interessadas em mudar e melhorar. E neste ponto, as empresas começam a encontrar e buscar um perfil profissional com características de trabalho em equipe, atitude, pessoas focadas em melhorar continuamente. Em colaborar.

O grande ponto é criar mecanismos nas organizações que ajudem na fomentação, criação e realização de mudanças. E que estas mudanças ocorram pela equipe de trabalho. Não por alguma gerência específica ou consultores externos. Através de ciclos curtos de revisão e adaptação, as equipes podem validar se a mudança foi válida ou se uma nova estratégia precisa ser definida. Falhar faz parte do processo de aprendizado. Seu contexto é diferente do contexto de outras empresas. Copiar nem sempre é opção.

As empresas que não possuírem um ambiente propício para mudanças vão em breve ver uma série de pessoas deixando e buscando empresas que valorizem isto. Ser infeliz no ambiente de trabalho não é mais uma opção.

Se a organização criou mecanismos de mudança, é agora hora de ensinar as pessoas do poder que elas tem. Criar autonomia. Com isto, as empresas terão braços de inovação crescendo, pouco a pouco. Um ritmo de trabalho começa a ser formado. As pessoas começam a achar normal sair da zona de conforto e buscar resolver problemas internos e a trabalhar harmonia e colaboração com toda a equipe.

E aqui tem outro detalhe. As pessoas que não entrarem neste ritmo de mudanças e melhoria contínua, de querer ajudar e focar no trabalho em equipe, serão levadas a se retirarem da organização. De forma natural. Elas deixam de ter a identidade do time. Vão acabar por buscar uma organização compatível com as suas expectativas de dedicação (envolvimento / comprometimento). Não é que tenha algo errado. Afinal, como dizia Deming, a mudança não é obrigatória, afinal de contas, sobreviver é opcional.

No final o sistema se ajusta como um todo. E a atitude positiva é o que vai valer.

Em resumo? Melhorar continuamente. Através deste caminho, as empresas se tornarão  “organizações em contínuo aprendizado“. A criação de conhecimento se torna meta. Ou melhor ainda, um hábito. Definir um ritmo para que este aprendizado possa ser discutido e evoluído. Aí se tem reuniões de retrospectiva e outras dinâmicas que permitem as equipes terem alinhamento e reflexão. A melhoria de comunicação vai minimizar riscos, conflitos e aumentar a possibilidade de sucesso da organização olhando a evolução da sua cultura.

Aproveite o caminho, e saboreie as mudanças!

Qual a melhor estimativa usada em ambientes Ágeis?

Padrão

03082012TrenaFotoMarcosSantos009

Qual funciona melhor, qual é mais precisa?

E a minha resposta é ao mesmo tempo nenhuma e todas. O ponto não é este.

O que seu time deve buscar em uma reunião de estimativa não é uma certeza, mas sim conseguir entender que o time está alinhado e aprendendo sobre o negócio. Em uma brincadeira com planning poker, onde os números possíveis são 1,2,3,5,8,13… se uma pessoa indica o número 1 e outra pessoa indica o número 13, você tem um momento para discussão, para nivelar conhecimento ou conhecer um risco que estava “escondido” no sistema.

Todas as técnicas funcionam para guiar o time e criar um padrão… conforme o time evolui em conhecimento de negócio e tecnologia, a tendência é a estimativa funcionar melhor e ajudar o time a visualizar questões que estejam “fora de padrão”.

O principal benefício dos exercícios de classificação/estimativa é gerar discussão e basear o conhecimento das pessoas sobre as funcionalidades a serem desenvolvidas.

E se você precisa estimar algo que é nebuloso? Você vai precisar seguir no conceito do 3C, para poder conhecer mais sobre a funcionalidade e possivelmente adicionar Spikes no planejamento, assim poderá experimentar e aprender mais sobre algo antes de fazer a definição da funcionalidade por completo.

A reunião da manhã – melhoria contínua

Padrão

8135229928_de131d8c4d

Seth Godin fala duas coisas que eu acho muito legal. Uma delas é porque perguntar porque? E a outra é sobre a qualidade das nossas perguntas. Nós crescemos e evoluímos e cada vez mais aprendemos a perguntar de forma especializada, sobre como está o tempo hoje.

Melhoria contínua será um processo muito melhor e simples se aprendermos a fazer perguntas diferentes, além de perguntar sobre o tempo durante a manhã.

Além de melhorar a qualidade das perguntas, precisamos estar presentes no local dos problemas, para poder ver de perto e sugerir melhorias, com o devido contexto. Estar presente no Gemba, e poder trabalhar com o conceito de Genchi Genbutsu é o que precisamos.

Mas o objetivo é falar de melhoria contínua e sobre uma prática da Fastcap, sobre a reunião da manhã para puxar melhoria contínua.

Prática simples, que busca criar uma cultura de aprendizado, diário, e que permite as pessoas exercitarem inovação, permite as pessoas trabalharem em equipe, melhorando o sistema e o ambiente de trabalho como um todo.

Na sua empresa, como sua equipe exercita a melhoria contínua?

Cartão, Conversação e Confirmação! O conceito 3C.

Padrão

3879260297_dfc867d531
Fichas de papel, cartões de papel ou index cards, são uma excelente forma de manter a vista novas ideias para um produto de software. E a melhor característica delas é o espaço limitado. Hein?

Sim.

Você não vai conseguir colocar toda informação necessária na ficha. E isto é bom, pode acreditar.

Em 2003 quando eu estava estudando eXtreme Programming, ouvi uma história do Ron Jeffries sobre 3C. E desde então eu aplico e ensino isto, pelo valor que esta prática agrega no dia a dia de um projeto.

O conceito do 3C é baseado em iniciar com a escrita de uma ideia em um cartão, para que possamos lembrar. O cartão é o primeiro C. E ele leva ao próximo, gerando um “lembrete para a conversação”.

Que é o que precisamos gerar, conversas. O objetivo com isto é validar as ideias, com pessoas que podem ajudar no tópico. O melhor nestas conversas é criar exemplos que ajudem a validar a mesma. Estes exemplos acabam virando depois cenários de aceitação da história. Se é um cálculo, exemplos de cálculos. Através deste processo, criamos um “cartão executável“. E este é o nosso segundo C. Ah, um cartão normalmente possui um documento auxiliar, onde o requisito em questão é documentado seguindo os padrões que a equipe utiliza.

Estas conversas ajudam o time a identificar alguns atributos para os cartões, exemplo?
– senso de valor
– prioridade
– risco associado
– qualquer-atributo-que-o-time-consiga-ver-valor.

O terceiro C é sobre confirmação. Através das conversas com o time e clientes poderemos entender como validar o cartão e confirmar que o que temos definido é o necessário para “fazer acontecer“. E então é isto que precisamos buscar, confirmação! E dos nossos clientes! Eles irão confirmar sua ideia e ajudar a mesma a crescer.

O que mais sobre cartões?


Jessica Hagy do site Indexed, que conheci por indicação da minha irmã. Você encontra o livro da Jessica na Amazon.

O negócio é o seguinte: um cartão pode fazer muito por você. Até mesmo ajudar você a manter uma conversa com seus clientes. Tente e teste!

O que é Agilidade? Revisitando o conceito… (por Daniel Wildt)

Padrão

daniel-wildt-small

No dia 26 de junho de 2010, o Rafael Helm publicou aqui mesmo no Pingos de Agilidade o que era para mim Agilidade. O Rafael pediu para eu mandar em uma frase.

E eu mandei: Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua.

Só que como todo desenvolvedor Clean Code, tudo pode ser refatorado. :-)

E nesta declaração, se eu for refatorar, como já vi o @KlausWuestefeld fazer com os valores do eXtreme Programming, chegando no Learning and Coolness, entendo que atitude e foco em entrega fazem o resto acontecer.

Vejamos:

Trabalho em equipe não é opcional. Você nunca vai ser melhor do que uma equipe em sinergia. Não quer uma equipe? Pense em um par, pense nos benefícios de ter conhecimento navegando e se tornando algo consciente e consistente entre as pessoas que fazem parte da equipe.

Melhoria contínua também não é opcional. Se sua equipe não melhora, ela sempre vai piorar. Simplesmente não se consegue “manter” a qualidade porque conforme o aumento da base de código, prazos, decisões mal feitas no projeto, novos problemas relacionados a modularidade e outros aspectos no desenvolvimento de software vão ficar mais visíveis. Então melhorar continuamente é algo que se faz sempre.

É a continuidade do processo de questionar aquilo que está sendo feito e buscar sempre melhorar, faz parte da atitude.

E é o que sobra e ao mesmo tempo faz a diferença. A atitude da equipe perante os obstáculos e como ela encara as situações de planejar novas funcionalidades para um produto, como ela encara o feedback ao cliente depois de um problema na operação do produto. Ou ainda como cada pessoa que faz parte da equipe vê a resolução de um defeito.

Se eu foco na entrega de software, quero garantir que o trabalho será o melhor possível, pois ninguém quer ter que trabalhar a noite ou final de semana ajustando algum problema de produção, causado na liberação de versão.

Então focar em entrega exige busca por qualidade, exige melhoria contínua. Só que sem atitude e foco em entregar aquilo que o cliente precisa, pensando em simplicidade, nada ocorre.

Exige aprender novos truques, em buscar novos conceitos como DevOps e Continuous Delivery.

A Importância do Aceite

Padrão

404150851_cd5bcb1ac2

Ao final de cada ciclo de trabalho (no scrum chamado de sprint), é indicado que o time realize uma demonstração das novas funcionalidades desenvolvidas. Esta demonstração é realizada pelo time para o próprio time. Importante lembrar que o cliente pode fazer parte do time (cliente presente).

Para uso efetivo do tempo do time, é aconselhável que o solicitante de uma funcionalidade, seja cliente interno ou externo, já tenha tido a oportunidade de validar a funcionalidade antes da revisão da sprint. Ou seja, sempre que o time entender que terminou uma funcionalidade o cliente é chamado para aceitar a mesma.

Geralmente neste processo o cliente vai passar alguns feedbacks, sejam eles positivos ou negativos, ou até mesmo indicar que a funcionalidade ficou completamente fora do que ele esperava.

No caso do feedback ser positivo, nós teremos segurança que vamos entregar software funcionando de verdade. Comemore!

No caso do feedback ser “tá quase lá”, você terá oportunidade de ajustar e evoluir a funcionalidade antes de colocá-la em produção.

E no caso do feedback ser negativo, do tipo “não é nada disto, vocês não entenderam o que eu pedi”, comemore também, pois como o Daniel Wildt sempre fala: 

A única certeza que temos é que vamos falhar, então precisamos falhar rápido.

Imagine se você só descobrisse que construiu uma funcionalidade totalmente diferente do que o cliente esperava no dia em que o software entrou em produção, ou em um treinamento com toda equipe do seu cliente. Seria terrível!

Por isto, criar a cultura de Aceite dentro de seu time pode ser uma prática muito saudável, e sem contraindicações, pois todo mundo ganha, a empresa, o time e o cliente.

 

Importante: Pedir para o cliente validar uma tarefa não substitui de forma alguma o processo de testes. A ideia aqui não é propor que o cliente faça testes buscando quebrar a funcionalidade, afinal de contas nosso time deve ser composto por desenvolvedores profissionais, que sabem testar software. O objetivo de buscar o aceite do cliente é verificar se ficou tudo de acordo com o esperado. Normalmente este processo não leva mais do que alguns minutos.

 

Uma alternativa interessante para criar a cultura do aceite no time pode ser criar no kanban uma fila chamada “Aguardando Aceite”, onde os cartões prontos na visão do time serão posicionados, e somente após aceite do cliente estes serão movidos para a fila “Pronto”.

Um fator importante para este processo funcionar é o cliente ou solicitante das demandas estar disponível para realizar aceites das tarefas prontas periodicamente, caso contrário estaremos apenas criando um gargalo.

Este processo trará uma maior segurança ao time, uma vez que os cartões considerados prontos pelo time realmente estarão prontos de verdade já que o cliente os aceitou durante a sprint.

Se no seu cenário for impossível aproximar o cliente, mesmo que por skype, considere então buscar o aceite pelo menos da pessoa que realizou a análise da funcionalidade. Isto já vai trazer um ganho significativo de qualidade, o que vai elevar a moral e a coragem do time.

Agilidade? (por Bruno Pedroso)

Padrão

104084236_640

Agilidade é reconhecer o processo de software como uma atividade inerentemente criativa, valorizando os aspectos humanos e utilizando abordagens adaptativas (ao invés de preditivas) na busca do equilíbrio entre ação (pragmatismo) e reflexão (aprendizado) ao longo do projeto.

Bruno Pedroso é coach de projetos e coordenador da área técnica da SEA tecnologia.