25 Mar

Desafio dos 50

Sempre gostei de ler. Mas, na época da escola minha paixão pela leitura foi ameaçada. Tinha de ler livros chatos que não me interessavam. Tempos depois me vinguei e fui ler somente aquilo de que gostava. Livros sobre a história do Brasil, tecnologia, poesias e tudo mais. Porém, apesar de sempre ler bastante, nunca fiquei satisfeito com meus hábitos de leitura. Sempre achei que podia ler mais e melhor.

Foi daí que no fim do ano de 2013 me surgiu a ideia de fazer algo que me desafiasse a incrementar o hábito de leitura. E assim surgiu a ideia de ler 50 livros no ano. Mas 50 livros? Parece coisa a bessa, não é? Pois é, minha meta em 2014 é ler 50 livros no ano, 1 livro por semana. Não é um desafio de velocidade. É um experimento para a criação de um hábito. O hábito de ler todos os dias. Para tornar essa experiência mais divertida e proveitosa decidi compartilhar a evolução do desafio e as lições aprendidas. Logo abaixo você pode conferir os 2 primeiros vídeos do desafio. O primeiro vídeo fala sobre minhas expectativas, enquanto que o segundo vídeo fala sobre o processo que utilizo para ler 1 livro por semana e os resultados que já obtive nas primeiras 2 semanas de janeiro de 2014. Confira!

Vídeo 1 – Desafio dos 50 #1

Vídeo 2 – Desafio dos 50 #2 – O PROCESSO

20 Mar

Dojo de Requisitos

Dojo de Requisitos

524430-1440x900-Dojo800

O que é?
Dojo (pronunica-se dôjo) é o espaço físico onde se treinam artes marciais japonesas. Neste local o praticante desenvolve suas habilidades e técnicas. Similarmente, um Dojo de Requisitos é o encontro de profissionais para praticar e desenvolver habilidades e técnicas na captura de requisitos. Utilizando conceitos e práticas de um dojo, um problema de negócio é declarado e os participantes elicitam requisitos. O objetivo de um dojo não é declarar um vencedor, mas sim praticar e aperfeiçoar as habilidades do praticante. E, aí? Vamos praticar?

Como funciona?
O Dojo de requisitos utiliza algumas regras simples.

  • Utilizamos histórias de usuários guiadas por testes de aceitação.
  • Baby Steps. Passos simples e sem complicação.
  • Pair Analysis. Elicitação de requisitos em dupla. Cada dupla tem um piloto e um co-piloto. Os dois trabalham na mesma história de usuário, sendo que o piloto é que escreve.
  • Enquanto escrevem a história de usuário, piloto e co-piloto explicam o que estão fazendo.
  • Quando vai ser?
    Dia 29 de março de 2014. Começa às 9h e termina às 13h.

    Onde vai ser?
    Instituto Infnet na Rua São José 90 – Auditório – 2o. Andar – Centro do Rio de Janeiro

    Quanto custa?
    1 quilo de alimento. Todo alimento coletado será doado a instituição apoiadora do Infnet.

    Onde me inscrevo?
    O Dojo de Requisitos é limitado a 20 pessoas. E, para tal, você precisa ser inscrever pelo site Eventbrite no seguinte link: http://bit.ly/1cFeuif

    10 Mar

    BABOK 3 – Direto das trincheiras

    10650311_l

    Sempre achei esse negócio de Corpo de Conhecimento (BoK – Body of Knowledge) algo inusitado. Primeiro que ler um BoK não é algo tão prazeroso quanto a leitura de um poema de Mário Quintana. BoK me cheira a enciclopédia. Não tem início, meio e fim. E não é incomum quem o ache frio e as vezes desconexo. É por essas e outras que a minha mente vivia atormentada com perguntas do tipo:

    — Mas, por que cargas d’água escrever um BoK? Por que escrever algo que dá tanto trabalho e no fim das contas não ensina ninguém, pelo menos na prática, a ser um bom profissional?
    Read More

    07 Feb

    Ferramenta #1: Organizando e priorizando requisitos com User Story Mapping

    Organizar e priorizar requisitos requer boa dose de determinação e paciência. Sem falar no trabalho de lidar com diferentes interesses do time de negócios e o time de desenvolvimento. Como então organizar os requisitos de forma que essa organização seja clara e transparente para a organização? Como organizar requisitos de forma que suas dependências e prioridades possam ser claramente visualizadas pelo time? Como priorizar e conseguir conformidade no trabalho realizado? Bem, vamos ver uma técnica bem interessante que você pode utilizar no dia a dia.

    A técnica se chama User Story Mapping, ou em português Mapa de Estórias de Usuários. Essa técnica foi criada por Jeff Patton.

    Material necessário

    . Uma folha de flipchat
    . Blocos de postits
    . Canetas

    Antes de iniciar

    O trabalho de levantamento, organização e priorização de requisitos envolve product owners, usuários especialistas, desenvolvedores, analistas de negócios e outros. Convide pessoas do lado do negócio e pessoas de tecnologia. O ideal é convocar até 12 pessoas para essa atividade. Mais que isso o resultado não será tão produtivo.

    Lembre-se que esta será uma sessão de muito brainstorming. e o tempo gasto pode variar muito. E isso varia em função do tipo de solução e pessoas envolvidas. Mas, inicialmente você pode prever uma tarde para um levantamento inicial. Caso haja necessidade você poderá repetir a sessão.

    Começando…

    Para começar vamos relembrar o que é uma user story. Uma user story é…

    . uma breve descrição da necessidade do cliente
    . descrição do produto
    . descrição do comportamento da solução
    . um requisito de alto nível

    Veja abaixo um exemplo.

    posit-exemplo

    O exemplo acima utiliza uma estrutura simplificada. Veja abaixo um exemplo mais completo que pode ser utilizado na criação das user stories.

    Como [Tipo de usuário], eu quero [ação, tarefa, etc.] para que eu possa [alcançar um objetivo].

    Exemplo: Como vendedor, eu quero incluir pedido para que eu possa aumentar o faturamento.

    Você pode criar seu próprio modelo de user stories. Mas não esqueça dos princípios básicos de uma user story.

    . Uma ou duas sentenças no máximo
    . São estimáveis
    . Podem mudar

    Vamos ao passo a passo para a criação do User Story Mapping. Está pronto?

    1 – Desenhe a figura abaixo onde o eixo y representa a criticidade e o eixo x a sequência de uso.

    usm1

    2 – Escreva as user stories. Aqui todo o time participa. Cada user story deve ser escrita em um post-it diferente. A medida que as user stories são criadas os participantes devem fixá-las na folha de flipchart ou na parede. É importante notar aqui que esta é uma sessão colaborativa, portanto, todos participam. Permita que cada participante tenha seu bloco de post-it e que cada escreva suas user stories. Evite que apenas uma pessoa fique responsável pela criação das user stories enquanto os demais ficam assistindo. Essa atividade é puro brainstorming.

    Dicas para escrever user stories:

    . Você pode optar por um modelo mais simples de user story. Se for o caso comece a descrição com um verbo. Exemplo: Incluir pedido
    . Pense no que as pessoas fazem e não no que a solução deve fazer.

    pst1

     

    3 – Escreva o usuário que executará cada user story. Aqui no nosso caso o VENDEDOR é o usuário que executará a user story INCLUIR PEDIDO.

    pst2

     

    4 – Defina a frequência de ocorrência para cada user story. Repare que aqui o time precisa pensar em cada user story como uma funcionalidade da solução. E, como toda funcionalidade, ela é executada de tempo em tempo. E é justamente esse tempo que você definir para cada uma delas. Você pode usar a tabela de frequência de ocorrência abaixo como referência.

    . Se a user story acontece a cada hora, ela terá peso 5
    . Se a user story acontece diariamente, ela terá peso 4
    . Se a user story acontece semanalmente, ela terá peso 3
    . Se a user story acontece mensalmente, ela terá peso 2
    . Se a user story acontece trimestralmente, ela terá peso 1

    E assim por diante.

    pst3

     

    5 – Atribua um valor para cada user story. Lembre que quem coloca valor na user story é o product owner. É ele quem dirá o quanto aquela funcionalidade é importante para ele. Você pode utilizar a tabela abaixo como referência.

    . Se o valor é alto, então o peso é 3
    . Se o valor é médio, então o peso é 2
    . Se o valor é baixo, então o peso é 1

    pst4

     

    6 – Atribua uma pontuação para cada user story. Utilizando os valores de frequência de ocorrência e valor calcule a pontuação conforme de acordo com a seguinte fórmula: pontuação = frequência + valor. Essa pontuação nos ajudará mais a frente na priorização das user stories.

    pst5

     

    7 – Ordene as user stories em ordem cronológica. Pense agora como se estivesse contando uma história. E nessa história você precisa levar em consideração a ordem em que as user stories são executadas. Por exemplo, primeiro o usuário precisa realizar os cadastros, depois o usuário inclui o pedido, depois fatura e assim por diante. Ordene as user stories colocando uma do lado da outra na horizontal. Algo bem interessante pode ocorrer neste momento. Pode ser que o time descubra que alguma user story está faltando. E este é um dos benefícios dessa ferramenta. Com a ordenação você identifica os gaps na solução e evita surpresas no futuro. O time de desenvolvimento pode ajudar a identificar vários desses gaps.

    usm2

     

    8 – Priorize as user stories. A priorização será feita levando em consideração a pontuação calculada no passo 6. Arrume as user stories de cima para baixo, ou seja, as de maior criticidade para as de menor criticidade, porém, procurando manter a ordem cronológica das mesmas.

    usm3

     

    9 – Identifique as quebras de fluxos. Essa identificação é na verdade uma atividade de agrupar user stories em segmentos ou gupos. Talvez você esteja se pergunta: mas para que serve essas quebras de fluxo? Por exemplo, elas servem para identificar quais unidades de negócio vão ser afetadas a medida que o time de desenvolvimento vai enregando partes da solução. Ajuda também a visualizar se a solução já pode ser colocada nas mãos do cliente e assim por diante. Identifique as quebras de fluxo traçando linhas verticais. Não se esqueça de identificar cada fluxo.

    usm4

     

    10 – Defina as releases. Para identificar as releases você deve traçar linhas horizontais agrupando assim blocos de user stories. No exemplo abaixo foram definidas três releases e o que cada uma delas vai entregar de valor para o cliente.

    usm5

    Finalizando

    O produto final dessa atividade de organização e priorização de requisitos utilizando User Story Mapping inclui…

    . Visão geral da solução
    . Funcionalidades
    . Tipos de usuário
    . Prioridade do backlog
    . Definição das releases
    . Cooperação do time de negócios com o time de desenvolvimento

    E muito mais.

    Mas, porque um mapa? Mais do apenas uma lista de requisitos ou uma lista de user stories, uma mapa permitirá…

    . Visualizar o fluxo ou cadeia de valor
    . Visualizar o relacionamento de user stories mães com suas user stories filhas
    . Confirmar se falta alguma user story
    . Fornecer um contexto útil para priorização
    . Planejar releases que entregam valor para o cliente

    Follow

    Get every new post delivered to your Inbox

    Join other followers: