Novos screenshots do Walls

Mais algumas imagens do gerenciador de projetos Scrum que estou escrevendo:

Walls: uma ferramenta de gerenciamento de projetos Scrum

Tasks no Walls

Como eu já havia relatado no primeiro post desse blog, meu interesse por metodologias ágeis surgiu quanto eu tentava escrever uma pequena ferramenta de gerenciamento de projetos. Então pareceu natural que no início dos meus estudos sobre Scrum eu quisesse ter minha própria ferramenta para gerenciar os novos projetos.

Sempre fui um pouco resistente a utilização da parede. Apesar do seu visual cool, o vento é um problema para quem trabalha no décimo andar. Por não querer recolher as User Stories desgarradas (e também por não gostar de montar quebra-cabeças), resolvi organizar as atividades na minha própria parede virtual de 17 polegadas imune a intempéries.

Então nos últimos dias do ano passado voltei ao bom e velho Ruby, não sem antes escolher um nome para o produto: Walls. Comecei do básico e aos poucos fui incrementando as funcionalidades. No momento, ela está ótima para as minhas necessidades: cria um produto, monta o Scrum Team, o Backlog, os Sprints, o Sprint Backlog, faz acompanhamento das tarefas e gera o Burndown. Como eu disse: o mínimo que um projeto Scrum precisa ter.

Ainda assim considero o Walls em estágio alfa, mas daqui a duas semanas liberarei uma versão para que pessoas em outros projetos possam testá-la. Quem tiver interesse em saber pode entrar em contato comigo.

Back in Black

Mais de um mês depois do último post, voltei à ativa. Nesse meio tempo, o ano novo chegou, a reforma gramatical me confundiu e um novo projeto nasceu. Sim, apesar de eu ter parado de escrever em português nas últimas semanas, o Ruby “bombou”. Então… de volta ao trabalho.

Humor: Scrum no mundo da música

Scrum e música podem parecer coisas completamente diferentes. Mas algumas vezes, pessoas extraordinárias pareceram ter o mesmo estalo que tiveram os autores do Manifesto Ágil. É o maravilhoso mundo da música Agile…

Rossini e o reuso

Todos sabemos que o reuso é um forte aliado no desenvolvimento ágil de software. Mas poucos sabem que no mundo da música ele também já foi muito adotado, e não estou falando de plágio.

A famosa ópera O Barbeiro de Sevilha foi composta em apenas 13 dias. Rossini conseguiu isso utilizando técnicas de reuso. Ele aproveitou trechos das óperas Aureliano, Sigismondo e Il signor Bruschino, todas de sua autoria, e assim conseguir terminar O Barbeiro de Sevilha em tempo recorde.

Apesar da façanha, a estréia da ópera foi um fracasso. Um gato pulou no palco em meio a uma ária delicada e uma corda de uma viola arrebentou. O espetáculo terminou em meio a gargalhadas e gritos. Apesar disso, o segundo “release” da ópera foi um sucesso, e hoje ela é uma das obras mais executadas no mundo.

Beatles e os itens prioritários

Quando começamos um novo Sprint, escolhemos os itens mais prioritários do Sprint Backlog. Os Beatles também seguiram a filosofia ao compor She loves you. Incrivelmente, essa música pula toda a introdução, e começa com… o refrão? Sim, sim, sim. Afinal de contas, o primeiro entregável deve conter as prioridades. Nada de enrolação, é música que vai direto ao ponto.

O Yeah, yeah, yeah também foi ridicularizado pelos críticos, mas se tornou a marca do rock’n'roll da época e apareceu muitas vezes em outras músicas dos Beatles e de outros artistas.

Beach Boys e os sprints

Muito antes de se falar em iterações, Brian Wilson, líder dos Beach Boys já adotava esse processo. Good Vibrations a primeira música da história a ser gravada em diferentes seções. A primeira parte foi gravada em fevereiro de 1966 e contém o conhecido refrão Good, Good, Good Vibrations. Mais tarde, de maio a junho do mesmo ano, mais partes foram gravadas.

Depois de vários meses de trabalho, 90 horas de gravações e US$ 50.000,00 gastos, a música foi completada. O resultado final tinha 3 minutos e 27 segundos. Essa música deveria estar no álbum Pet Sounds, mas acabou ficando de fora. O motivo da exclusão da música: Brian a considerava tão boa que destoaria do restantes do álbum.

Pet Sounds já foi considerado o melhor álbum de todos os tempos pela revista especializada MOJO. A Rolling Stones o deixou em segundo lugar. Então, que música é essa que é tão boa que não está nesse álbum? Vale a pena conferir.

Parte 2: Iniciando com Scrum

O post de ontem encerrou a segunda parte do blog, que deu uma introdução sobre o Scrum, e como iniciar um projeto a partir da construção do Project Backlog. Para manter a coerência do tema, recomendo a leitura em ordem cronológica dos posts:

Scrum em 60 segundos Uma rápida introdução sobre Scrum

Os papéis no Scrum Como se divide a equipe no Scrum

Product Backlog: o ponto de partida Como criar um Product Backlog

Fuja dos detalhes Dicas para não trocar os pés pelas mãos

Mais sobre User Stories Dicas sobre como usar User Stories

E se você ainda não leu a primeira parte do blog, talvez queira fazê-lo antes de tudo:

Toda história tem um início Como eu descrobri as metodogias ágeis

A “crise do software” Por que usamos a Engenharia de Software?

A natureza do software Como o software se diferencia de outros produtos

A era dos processos Como os processos inunduram nossas vidas

O Manifesto Ágil A história da reação contra o que ia de encontro ao bom-senso

Abrindo a mente Uma crítica contra o conservadorismo

Mais sobre User Stories

A extrema importância do Product Backlog para o Scrum contrasta com sua aparente simplicidade. Nele estão contidos todos os requisitos que o cliente deseja para o produto, descritas de maneira abrangente e em sua própria linguagem. Como já foi visto, é possível utilizar User Stories para facilitar o levantamento e organização desses requisitos.

Tudo vai começar a partir de uma reunião para ouvir o cliente: quais seus problemas, como ele lida com isso hoje e o que ele espera ter para poder resolvê-los. Nessa fase, deve-se manter a concentração sobre “o quê” fazer ao invés de “como” fazer. Nenhum detalhe técnico deve ser discutido.

Aqui eu vejo duas formas de realizar essa reunião. Na primeira, algumas pessoas chave do Scrum Team devem participar. Elas darão idéias e começarão a ter noção mais exata sobre o que é o produto. Mais tarde, será preciso reunir tudo que foi discutido e repassar ao Scrum Team, para que sejam definidas as estimativas de prazo de cada User Story. Por fim, realiza-se um feedback junto ao cliente.

A segunda forma envolve todo o Scum Team durante a reunião. A vantagem é óbvia: tudo é discutido de uma só fez. As User Stories são escritas e priorizadas, em seguida o Scrum Team define as estimativas iniciais, e o cliente já fica sabendo de tudo no mesmo instante. A desvantagem: se você tiver muitas User Stories talvez não dê tempo de fazer tudo numa única reunião. Esse processo pode se arrastar ao longo de alguns dias e o foco será perdido. Também é possível que o Scrum Team precise de um tempo para estimar melhor uma User Story por causa de algum impasse tecnológico. Enfim, esse método funcionará melhor em projetos menores.

Mas de uma forma ou de outra, todos os assuntos discutidos no decorrer da reunião vão parar numa User Story. Por isso saber escrevê-las é essencial para o sucesso do projeto. E apesar de esse ser um assunto longo, cinco dicas simples podem melhorar consideravelmente a qualidade das User Stories. Algumas já discutimos, e listaremos novamente para enfatizá-las, pois são as mais importantes. Outras ainda não foram abordadas. Essas cinco dicas são:

Foque no cliente

Toda user Story deve ser escrita com as palavras do próprio cliente. A melhor maneira de fazer isso é deixar o próprio cliente escrevê-las. Se isso não puder ser feito, controle as regras do jogo: extraia a informação, formate numa pequena frase e pergunte ao cliente se foi aquilo que ele disse. Sempre lembrando que não se deve usar termos técnicos. “Criar índices clusterizados e os adicionar à tabela de compras” não quer dizer nada para o cliente (a não ser que ele seja um DBA). Troque para algo como “Melhorar a performance dos relatórios de compras”. Quer dizer o mesmo, mas tanto o cliente quanto o Scrum Team entenderão.

User Stories são Elevator-Friendly

Uma boa User Story deveria ser algo que você pudesse explicar em 30 segundos para um membro do Scrum Team (a não ser que o elevador no seu prédio seja muito rápido). Diga apenas o suficiente para ser entendido. Apenas tome cuidado para ao invés de escrever uma novela, escrever um Haikai.

Do tamanho certo

Como diria Goldilocks: nem muito grande, nem muito pequena. Uma User Story deve em torno de 40 horas de esforço estimado (uma semana). User Stories muito grandes serão difíceis de gerenciar, e podem consumir quase um Sprint inteiro. As muito curtas gerarão um grande overhead. E lembre-se: você vai querer dividi-la em tarefas. Então o meio-termo é o mais adequado.

É preciso testar

“A tela de vendas deve ser fácil de usar”. Parece tudo bem com esse User Story. Foi usada a linguagem do cliente. Mas como testá-la? Seria melhor mudar para “Um usuário iniciante deve ser capaz de iniciar e finalizar uma venda em 5 minutos”. Ou melhor ainda: “Dado um grupo de 10 usuários iniciantes, oito deles devem conseguir iniciar e finalizar uma venda em 5 minutos”.

Há muito mais a falar sobre as User Stories. Isso foi apenas o início. Para mais informações, talvez você queira ler esse livro: User Stories Applied.

a estrela d’alva se tirou
jamais clareava
negras árvores nos azulados

Guimarães Rosa

Fuja dos detalhes

Clientes querem absolutamente tudo. Inicie um projeto, comece o levantamento de requisitos, e uma avalanche de funcionalidades vai cair sobre você. Esse problema não se trata apenas de uma escolha entre um ou outro processo de desenvolvimento. Tudo que acontece durante o ciclo de vida de um projeto está intimamente ligado com a maneira como decidimos trabalhar. Quando você opta pela rigidez dos processos tradicionais em cascata ou com iterações longas, todos têm que se precaver.

A especificação deverá ser fechada antes de tudo. Caso o cliente esqueça de dizer que quer algo, por mais simples que seja, isso implicará num grande custo futuro. Isso faz como que ele seja forçado a pedir tudo que deseja de uma só vez. Mas, no início do projeto, as coisas talvez ainda não estejam claras. Então muitas funcionalidades serão solicitadas apenas para se ter certeza de que, “se” ela for necessária no futuro, ela estará lá.

Essa paranóia levará a uma enxurrada de opções e configurações que nunca serão usadas. Porém, ninguém vai arriscar deixá-las de fora, porque o processo não permite que elas sejam implementadas numa fase posterior, pelo menos não sem um grande custo. Além disso, os contratos penalizam mudanças durante o andamento do projeto.

[Inovação] aparece quando dizemos não à 1000 coisas para termos certeza que não estamos seguindo o caminho errado ou tentando fazer coisas demais. Nós estamos sempre pensando em novos mercados para entrar, mas somente dizendo não para isso que você pode se concentrar no que realmente importa.

Steve Jobs, A Semente de Inovação da Apple

Mas em se trantando de Scrum, a premissa é exatamente a contrária: nada de detalhes no começo. O foco deve estar sobre o problema do cliente. Por isso, o cliente deve entender como funciona o mecanismo de iterações que será usado. Talvez ele não saiba o que é um Sprint, mas deve entender que em algumas semanas verá uma versão demo do seu produto, funcionando. Uma versão que pode ser testada e analisada.

A partir do momento em que o cliente ver que não precisa mais esperar uma dúzia de meses para ver algo “de verdade”, vai deixar de se preocupar tanto com os detalhes no começo. Essa primeira tentativa de quebrar o paradigma será a mais difícil, mas é a crucial para o sucesso do Scrum.

Product Backlog: o ponto de partida

O Product Backlog é o ponto de partida do Scrum. Basicamente, ele é uma lista onde todos os requisitos do produto estão ordenados de acordo com sua prioridade. Uma maneira interessante de construir o Product Backlog, é fazê-lo utilizando o ponto de vista do cliente, como se fosse uma User Story do Extreme Programming.

A regra mais importante aqui é ignorar os detalhes. Enquanto conversa com o cliente, mantenha seu foco no negócio. O que é preciso ser feito para resolver o problema em questão? A emissão de um bilhete, a autorização de uma venda, O registro de um atendimento.

Sabemos que os detalhes podem fazer aquela diferença entre o sucesso e o fracasso. Por isso somos loucos por detalhes: que vendedores têm permissão para liberar o desconto de 7,5%? Em que situações o atendente deve repassar os chamados para o setor B? Como o horário de verão influi na compra de uma passagem para Toronto durante o solstício? Nesse momento, isso simplesmente não importa. Concentre-se nos problemas mais importantes, e deixe o resto para depois.

Não se preocupe em prever todos os casos e fluxos alternativos nesse momento. Apenas escreva o que se deve fazer por enquanto. Daqui a duas ou três semanas, quando você tiver o primeiro demo do seu programa, use-o. Veja se funciona e o que é preciso aperfeiçoar. Os detalhes se revelarão nesse momento. É como andar numa estrada, você saberá que buracos tapar porque será neles que você sempre cairá.

Quase me cansei da atitude “entre nos detalhes imediatamente” depois de tomar algumas aulas de desenho. Se começar a desenhar os detalhes imediatamente pode ter certeza que o desenho será uma droga. De fato, você está perdendo completamente o ponto.

Você deve começar pegando as proporções corretas da cena toda. Então rascunha os grandes objetos na sua cena, indo até os menores. O rascunho deve ser bem vago nesse ponto. Então pode proceder sombreando, o que consiste em dar volume à vida. Você começa com apenas três tons (claro, médio, escuro). Isso dá um rascunho de tons. Então, para cada porção do seu desenho reavalia três tons e os aplica. Faça isso até os volumes aparecerem (requer múltiplas iterações)…

Funciona do grande para o pequeno. Sempre.

Patrick Lafleur, Getting Real: Ignore details early on

Usando uma User Story

Uma User Story pode ser a melhor ferramenta para essa fase do Scrum. Ele vai lhe ajudar a ter a mesma visão do cliente. Ao escrever uma User Story, todos os itens devem ser descritos com a terminologia do cliente, evitando o uso do jargão técnico. Por exemplo, ao invés de descrever um item como “Criar uma classe que implemente o login na aplicação e trate as exceções”, escreve apenas “O usuário deve se autenticar no sistema”.

Os papéis no Scrum

No Scrum, os papéis na equipe diferenciam-se de outras metodologias por seguirem uma estrutura pouco hierarquizada. Por isso, o Scrum Team não inclui nenhum dos papéis tradicionais da engenharia de software, como programadores, designers, testadores e arquitetos. Todos no projeto trabalham juntos para completar as tarefas que formam um Sprint. Essa visão faz com que os membros da equipe tornem-se uma parte importante e principalmente, responsável, pelo resultado final do trabalho.

Scrum Team

Um Scrum Team deve ter entre 5 e 9 pessoas, embora muitas vezes se trabalhe com equipes ainda menores, envolvendo apenas 3 pessoas. Esse número reduzido de pessoas tem se mostrado, através da experiência prática, o ideal em termos de gerenciamento e resultado.

Como não existem níveis hierárquicos, os próprios membros do Scrum Team elaboram a maneira como trabalharão e como as tarefas serão distribuídas. Qualquer tarefa pode ser feita por qualquer membro do grupo. Obviamente, nada impede que um membro em particular se torne especialista em algum campo.

Product Owner

O Product Owner é a ponte entre o cliente e o Scrum Team, especificando o que o Scrum Team deve fazer do ponto de vista do negócio. Para isso, o Product Owner usa o Product Backlog, uma lista com todos os requisitos do produto ordenados por quão prioritários eles são para o cliente.

Por causa do caráter negocial do papel, o Product Owner geralmente é alguém ligado ao marketing, um usuário-chave do produto em questão, ou em alguns casos, o próprio cliente. Apesar disso, ele deve conhecer razoavelmente as três pontas que forjam o produto: o negócio, a engenharia e o marketing.

Ao longo do projeto, o Product Owner pode repriorizar os itens do Product Backlog. Entretanto, visando seu interesse na finalização dos itens mais prioritários, ele assume o compromisso de não fazer nenhuma mudança nas prioridades durante o andamento de um Sprint. Isso significa que quando o Scrum Team inicia um Sprint, ele permanece obcecadamente focado em completar todas as suas tarefas.

Scrum Master

O Scrum Master é uma combinação de treinador, supervisor, e facilitador. Ele irá garantir que durante o andamento do Sprint, o Scrum Team não saia do caminho planejado. O Scrum Master também faz parte do Scrum Team, e eles se encontram todos os dias durante uma breve reunião, a Daily Scrum.

O Scrum Master deve proteger o Scrum Team para que eles sejam perturbados o mínimo possível durante um Sprint. Por isso, ele filtra reuniões com pessoas que não pertencem ao Team e repassa para a equipe apenas o mais importante. Ele também tem uma visão aqui-e-agora do trabalho. Seu foco é sempre manter o Scrum Team nas melhores condições possíveis de trabalho para atingir os objetivos do Sprint. Remover obstáculos ao bom andamento do projeto é uma de suas funções.

Um gerente de projetos ou um líder técnico tipicamente exercem o papel de Scrum Master, embora qualquer outra pessoa também o possa. O importante é que essa pessoa seja alguém que entenda a filosofia do Scrum, e possa conduzir o Scrum Team através de seus princípios.

Scrum em 60 segundos

Scrum é um processo ágil de desenvolvimento de software. Nele, o progresso se dá através de uma série de iterações com duração de duas semana a um mês chamadas de Sprints.

Scrum é ideal para projetos sujeitos a mudanças repentinas ou com requerimentos emergenciais. O trabalho a ser feito no Scrum é listado no Product Backlog, que é uma lista de todas as funcionalidades desejadas no produto. No início de cada Sprint é realizada a Sprint Planning Metting, durante a qual o Product Owner prioriza o Product Backlog e o Scrum Team seleciona as tarefas que eles podem completar durante o próximo Sprint. Essas tarefas são movidas do Product Backlog para o Sprint Backlog.

Todos os dias durante o Sprint, é realizada uma breve reunião chamada de Daily Scum, que ajuda o time a se manter nos trilhos.

No final de cada Sprint, o time demonstra as funcionalidade que completaram na Sprint Review Meeting.

Graficamente, o Scrum se parece com isso: