o Mundo da Agilidade

Acabei de fazer uma apresentação sobre agilidade, e decidi compartilhar com vocês. O FOCO foi nos valores que o manifesto ágil listou, e não nas práticas, afinal esses valores que caracterizam um desenvolvimento ágil, e não práticas X, Y ou Z.

Apesar de falar sobre os VALORES, também falei sobre duas metodologias que considero muito boas que é o XP e o SCRUM.

Quebrando as regras – O líder criativo

Esses dias estive refletindo bastante sobre como deve se portar um líder de equipe diante das mais diferentes situações. Qual deve ser a postura de um líder criativo? Deve ser inspirador ou deve focar em mostrar que possui a situação sobre controle?

Decidi procurar referências em livros e uma amiga me indicou um bastante interessante. Se chama “The Leader’s Guide to Lateral Thinkin Skills“. O livro faz um paralelo bastante interessante sobre como se porta um líder clássico e um líder que está preocupado com inovação e com a disseminação do pensamento criativo. Dentre as principais diferenças entre esses dois tipos de líderes, vou citar algumas que me chamaram a atenção.

creative

Líder clássico: Dirige, desprende maior tempo em questões operacionais do dia-a-dia do que em novas estratégias, dá a direção e as ordens, desmerece idéias e iniciativas sem prévia análise, fechado à críticas, etc…

Líder criativo: Inspira, desprender maior tempo à procura de novas estratégias e parceiros, faz perguntas, pede sugestões e delega, encoraja todos tipos de iniciativas e frequentemente implementa idéias, encoraja críticas construtivas, etc…

Posto isto, fica evidente que o líder criativo possui um perfil mais vanguardista e está mais inclinado a aceitar e lidar melhor com os riscos chegando ao patamar onde o risco torna-se um aliado à inovação. O resultado desse relacionamento tão peculiar com os riscos (lembrando aqui a importância de ter a maioria deles sobre controle e identificados), o líder criativo aposta pela quebra de regras para promover a inovação dentro da sua equipe. Pra algumas pessoas, esse tema não é novidade, principalmente quem mergulhou de fato no mundo das metodologias ágeis, mas eu acho que é uma temática que deve ser sempre reiterada e que é crucial nos projetos em que se deseja inovar.

break the rules

A partir da quebra de regras de um negócio foi que se conseguiu um maior nível de inovação em determinado setor. Um bom exercício para tal é tentar identificar todas as regras intrínsecas ao seu modelo de negócio. Após haver mapeado um número razoável, pondere quais das regras parecem ser descartáveis e tente jogar com esse modelo retirando-a do contexto. Um bom exemplo para tal foi executado pela Heinz, a fabricante de ketchups. Enquanto a maioria dos molhos de tomate da concorrência nos EUA possuíam uma consistência mais líquida, o molho Heinz era mais espesso e exigia que o usuário tivesse que bater no fundo da lata pra conseguir extrair o conteúdo da embalagem. Havendo identificado essa particularidade, ao invés de mudar a fórmula do seu molho, a Heinz decidiu investir em uma estratégia de marketing onde se definia que o bom molho de tomate era o espesso. A campanha foi um sucesso e a Heinz hoje é uma das líderes no setor.

Existem N outros exemplos onde a quebra de regras foi crucial para a inovação. Será que vocês arriscam dar mais alguns exemplos? Como funciona o jogo de regras na sua equipe? Comenta aí!

Agile Restrospectives – Bom tutorial

Recentemente tenho quebrado a cabeça em como melhorar as retrospectivas em meu projeto. Após aproximadamente 2 anos, as retrospectivas tendem ao tédio e o time não consegue pensar em fatos diferentes de problemas com infra-estrutura e eventuais horas-extras.

Pensando nisso, decidi dar uma olhada no que está sendo feito em retrospectivas para tentar obter resultados diferentes e um plano de ação mais conciso. @estherderby é uma das referências quando se fala de Agile Retrospectives e no vídeo abaixo ela e uma companheira deram uma boa apresentação em como montar uma reunião de retrospectiva e o que fazer se você espera ter um resultado diferente. Mudar o foco é a palavra chave. Espero que vocês gostem.


Recently I have been struggling on how to improve Agile Retrospectives on my project. After nearly 2 years, retrospectives tend to boredom and the team cannot think of different facts otherwise than bad infrastructure and sparse extra working hours.

 

Thinking about that, I decided to have a look on what else I could be doing in a retrospective so that I could have a different output and a more concise action plan. @estherderby is one of the references when talking about Agile Retrospectives and in the video below she and a colleague give a nice presentation on how to set up a retrospective and what to do if you expec.t to have a different output. Changing the focus is the key point. I hope you guys enjoy.

Mapeando requisitos em projetos SCRUM – Uma proposta

As metodologias ágeis de gestão de projeto não estabelecem uma regra para o levantamento de requisitos no começo de cada iteração. De acordo com o SCRUM após as reuniões de Sprint Planning a equipe deve possuir um Sprint Backlog estimado e priorizado em conformidade com o que o Product Owner e a equipe do projeto acreditam que deve ser executado na Sprint atual. Durante essas reuniões, o time inteiro e o Product Owner são incitados a tirar dúvidas e levantar mais detalhes em relação a cada User Story que foi selecionada como escopo da Sprint, porém não há nenhuma recomendação sobre formas de propagar requisitos ou até mesmo descrevê-los.
Gravador
Como os próprios métodos ágeis pregam, devemos tentar fugir ao máximo de documentos e artefatos que pouco agregam ao time. Se no seu caso, as reuniões de Sprint Planning e conferências com o Product Owner são suficientes então nem continue lendo esse post. A nossa proposta é sugerir formas de manter esses requisitos na mente dos desenvolvedores e também trabalhar mais a fundo essas propostas, de forma a estimular a criatividade da própria equipe e disseminar o conhecimento dos requisitos.

A primeira técnica que já utilizei foi o famoso gravador de voz. Durante as reuniões com o cliente, levávamos um gravador MP3 para registrar todos os momentos com o Product Owner. O arquivo era posteriormente distribuído através do repositório da projeto. Os desenvolvedores e o Scrum Master sempre poderiam revisitar o arquivo de áudio e esclarecer possíveis dúvidas que surgem após um determinado tempo.
Apresentação dos Requisitos
A segunda técnica consiste em utilizar um membro da equipe para, após as reuniões de planning, criar uma apresentação com uma visão geral sobre cada requisito/user story e seus impactos. A grande vantagem dessa abordagem é a subsequente reunião que é feita após a definição desses requisitos. Todos os membros da equipe são encorajados a refinar os requisitos e a discutir de forma criativa as soluções que foram dadas aos problemas. Inclusive pudemos observar que a participação de engenheiros de teste foi bastante útil uma vez que eles são capazes de antecipar com maior critérios os fluxos secundários e os impactos de cada User Story no que já foi desenvolvido.

Existem várias outras possibilidades como o uso de vídeos, combinação de ténicas acima, uso de cartões e etc… O que realmente importa é garantir que  a todo momento todos os membros da equipe têm claro o que devem fazer e o que deve ser coberto ou não por cada estória a.k.a definição de pronto.

O que é Software Craftsmanship?

Por meio de um twitter de @lucabastos, terminei vendo uma apresentação de @sandromancuso & @activelylazy sobre essa nova onda rolando a algum tempo já, e terminei conhecendo por acaso esse movimento chamado de Software Craftsmanship.

Confesso que não conhecia ainda esse movimento mas pela apresentação que vi no slideshare me pareceu bastante interessante e já simpatizei de cara (inclusive depois de estudar um pouco o movimento eu assinei o manifesto, e no momento que assinei existia 213 brasileiros que já haviam assinado) .

Se formos traduzir literalmente Software Crafsmanship significa algo em como “Software Artesanal” e o movimento gira em torno de sermos melhores artesões.

Apesar do manifesto do Software Craftsmanship só ter sido criado em 2009, suas raízes vem desde 1999, com a publicação do conhecido livro Pragmatic Programmer, que trata sobre como ser um programador melhor, em diversos sentidos da palavra.

Uma definição de software craftsmanship é a seguinte:

It’s a lifestyle where developers choose to be responsible for their own careers and for improving their craft, constantly learning new tools and techniques. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development.

Figuras renomadas, como Robert C. Martin (ou Uncle Bob) que inclusive participou da criação do manisfesto ágil , apoiam o movimento. O próprio Uncle Bob escreveu:

The original torch of the Agile message has changed hands, and is now being carried by the Software Craftsmanship movement.

Segundo ele mesmo colocou, o movimento do software craftsmanship seria uma “extensão” do manifesto ágil, obviamente sem anular os pontos que foram citados no manifesto ágil. Dessa forma, vamos analisar o “manifesto do software artesanal”, que tem os seguintes valores:

Not only working software, but also well-crafted software;
Not only responding to change, but also steadily adding value;
Not only individuals and interactions, but also a community of professionals;
Not only customer collaboration, but also productive partnerships.

Muito legal esse manifesto, e como podemos perceber o ponto central por trás desses valores é sermos melhores programadores, e consequentemente nossos artesanatos serão bem melhores do que são hoje em dia. Além disso, é preciso parcerias onde possamos nos desenvolver, formando uma comunidade de artesãos de software capacitados.

@sandromancuso & @activelylazy em sua apresentação falaram das características do papel de artesão de software. Listei algumas aqui:

  • Nós controlamos nossas carreiras;
  • Artesão de software não é uma profissão comum daquelas que dá 18:00 e vamos pra casa;
  • Intolerância a código ruim;
  • Somos profissionais e somos pragmáticos;
  • Nós estamos continuamente aprendendo e interessados em aprender;
  • Nós nos importamos e somos orgulhosos do nosso trabalho 🙂

Para sermos melhores artesãos, é sempre preciso:

Criatividade, Visão Crítica, Base teórica e Habilidades Práticas;

Além disso, é preciso estar ligado no que Software Craftmanship NÃO É:

  • NÃO É um certificado
  • NÃO É um curso
  • NÃO É um livro

Software Craftmanship é ATITUDE!

Um projeto pode ser ágil sem SCRUM ou KANBAN?

Hoje em dia muito se fala sobre Scrum, Kanban, e estes conceitos estão realmente na moda atualmente. Primeiramente gostaria de dizer que não tenho nada contra o Scrum ou o Kanban, muito pelo contrário, uso Scrum a algum tempo e percebo no dia-a-dia os benefícios de tais práticas.

E então chegamos na palavra que eu queria chegar: Prática. Tanto o Scrum quanto o  Kanban e também o XP (eXtreme Programming) são práticas comuns (formas de fazer, de conduzir) comuns no mundo ágil. Muitas pessoas param por aqui quando estão falando sobre desenvolvimento ágil, mas uma pergunta importante precisa ser respondida: O que faz uma metodologia/prática ser considerada ágil? Nesse momento então chegamos ao ponto crucial que são os princípios e valores que estão por trás do que se considera ágil. Todas as práticas que se consideram ágeis é porque valorizam os pontos levantados no manifesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Sabendo agora que existem princípios por trás de determinadas práticas, podemos então responder a pergunta se um projeto pode ser ágil mesmo sem utilizar Scrum ou Kanban, e a resposta é ‘SIM’! Basta que estejamos ligados a esses princípios.

Sendo assim, o contrário também pode acontecer: Você pode “utilizar” Scrum, ter post-its na parede, dividir seu projeto em iterações (sprints), fazer Scrum Daily Meetings e ainda NÃO SER ÁGIL!

Então sabemos mais importante do que Scrum ou Kanban, são os principios e valores por trás dessas práticas. No próximo post vou tentar detalhar mais o manifesto ágil e explicar melhor esse texto que só tem 4 linhas mas é enorme.

O Desafio do Sprint Planning 2 no Scrum

Uma boa sprint começa com um bom planejamento!

Para quem não está familiarizado com o scrum, no fluxo normal  nós temos dois passos que iniciam a execução da sprint chamados “Sprint Planning 1” e “Sprint Planning 2” (representados na imagem acima pelos dois primeiros blocos de fundo verde).   No Sprint Planning 1, é onde acontece a escolha de quais itens de backlog (IBL) serão feitas na sprint. Nesta reunião é muito importante a presença do product owner pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido, na grande maioria das vezes ele que tem o conhecimento do negócio e que tem a visão mais acertada de onde quer que o produto/projeto chegue. Essa escolha das IBL’s é feita de pelo time todo, ou seja, todo o time tem que concordar que terão condições de implementar aquelas estórias escolhidas. Uma vez escolhidas as estórias que serão feitas na sprint, chega o momento da Sprint Planning 2

Na reunião de “Sprint Planning 2” todo o time concentra seus esforços em quebrar aquelas IBL’s (estórias) em unidades menores de trabalho que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its (nada contra, mas tenho pena das árvores 😛 vamos começar o movimento #RecyclePostIts). Bom, é nesse momento que acontece a explosão de tarefas, a sprint começa sem ter nenhuma tarefa a ser feita e na sprint planning 2 as tarefas são levantadas. A importância dessa fase do scrum é a seguinte: O que você levantar como tarefa aqui vai guiar seu desenvolvimento da sprint toda (e é claro que você pode lembrar/criar mais atividades no decorrer da sprint, mas essa visão inicial ajuda muito e já pode antecipar alguns problemas que poderiam acontecer).

É aí que aparece a pergunta: Mas como eu quebro as estórias em tarefas?  Qual a granularidade? E é justamente para tentar responder essas perguntas que eu vou tentar listar algumas dicas ou instruções de como quebrar as tarefas.

  • 1) Granularidade grossa: Uma das primeiras recomendações para a quebra de tarefas é sempre criar tarefas que possam ser feitas em 1 dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa com o objetivo que ela caiba em 1 dia de trabalho. O objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder visualizar o trabalho diário no burndown, que nesse caso vai se mover dia a dia, ao invés de ficar parado uns dias e depois se mover.
  • 2) Granularidade fina: O ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma tasks (lembrando que para que isso aconteça é preciso uma análise detalhada da estória a ser desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes, etc, etc, etc). Cada detalhe então vai virar uma task e isso facilita a vida de quem desenvolver a estória pois as tarefas já são quase que um guia e a finalização das tasks da estória simbolizaria que não falta mais NADA para aquela estória. Ex.: Se você sempre acaba a estória e vê que a equipe não fez uma validação javascript em um formulário, então na próxima sprint você já inclui a validação como uma tarefa (pois-it) a parte.
  • 3) Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas a relidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá por base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, junta mais coisa em um tasks só (que façam sentido estar junto obviamente). Caso a granularidade tenha sido muito grossa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais.

Bom, acredito que com essas coisas em mente vamos conseguir planejar melhor nossas sprints, e consequentemente finalizá-las melhor também! Você tem alguma dica a respeito da separação de tarefas no sprint planning? Deixa tua dica aqui como comentário 🙂 valeu!

Refactoring x Rework

Estava comentando sobre práticas ágeis com um amigo e disse que gostava muito de coisas como Design Evolutivo, KISS (keep it simple stupid), essa coisa de acolher as mudanças (embrace changes), e falei na palavra chave Refactoring. Pra que eu fui falar isso? 😛 Na mesma hora eu ouvi: “Refactoring ou Rework? para mim é  mesma coisa!“.

Desde aquele dia tive vontade de escrever um post falando sobre isso, e tentando explicitar as diferenças ( porque na minha cabeça é completamente diferente ). Apesar de soarem como coisas similares para algumas pessoas, e algumas outras pessoas até confundirem dizendo que estão fazendo refactoring quando estão fazendo rework e vice-versa, existem diferenças entre essas atividades.

Vamos começar com a definição do que é refactoring:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Como a própria definição já fala, a idéia do refactoring é modificar a estrutura interna (design) do código de forma a melhorá-la ou ajustá-la para algum comportamento que não tinha sido previsto anteriormente (embrace changes). O Refactoring se encaixa perfeitamente no mundo das práticas ágeis justamente porque a idéia do desenvolvimento ágil é se preocupar com o AGORA, então o design da aplicação vai ser feito pensando nas coisas que se conhecem hoje, e que são precisas hoje, e esse mesmo design evolui a medida que o conhecimento vai aumentando, ou que

as mudanças forem chegando . Esse é o famoso design evolutivo, que anda de mãos dados com o refactoring, pois o refactoring dá subsídio a evolução do design.

Só para ficar mais claro do que é design evolutivo e refactoring eu queria falar de como seria o oposto disso tudo. O oposto disso seria nós começarmos um projeto com uma tela

de login, e um usuário que loga e mostra a tela principal e no momento de fazer o design das classes eu já criar (isso mesmo, cedo assim)  diversos componentes do sistema, criar interfaces para meio mundo de coisa, criar classes abstratas que vão representar objetos que só vão ser criados daqui a 6 meses, ou 1 ano. Como você pode notar eu já teria uma “arquitetura” pronta desde o início do projeto, e isso pode acarretar algumas coisas como: 1) Aceitar mudanças vai ser tornar um problema maior do que o normal, pois você já preparou seu sistema para um determinado comportamento (mesmo sem te

r muito conhecimento, pois normalmente no inicio do projeto se tem pouco conhecimento a respeito do negócio/domínio); 2) Provavelmente algo do que você fez NUNCA será usado, e talvez ainda esse algo (NUNCA usado) seja causa de bug e de dificuldades no design da aplicação (mas novamente, mudar já se torna bem mais dificil pois já tem muita coisa pronta).

Bom, acredito que já está mais claro o que é refactoring e como ele está diretamente relacionado com agilidade e com desenvolvimento iterativo/incremental. Acredito que não preciso nem falar muito sobre Rework, mas como é o título desse post então vamos lá. Começando com a definição:

Rework is to rewrite or revise; To work over again.

A própria definição já diz muita coisa, é reescrever algo, refazer, fazer de novo. Aí você pode perguntar: mas no refactor você também não refaz? E eu respondo, isso mesmo, só que o propósito de refazer do refactoring é diferente, é melhorar e ajustar e não corrigir algo que foi feito errado. E é justamente aí onde entra o rework, se eu fiz alguma coisa errada, vou ter que fazer um rework para corrigir. Se criei algo de forma errada tenho que refazer (rework). Então vamos lá… Toda correção de Bug é um rework. Toda correção de um requisito é um rework. Isso tudo porque você está gastando tempo de novo com algo que teoricamente já devia estar bom. Se no seu refactoring você introduzir bugs, vc terá que fazer um rework do refactoring para corrigir esses bugs ( e isso sim é perder tempo/dinheiro). Vamos continuar…. Toda mudança de requisitos ou requisito novo que for impactar o design do sistema é rework ou refactoring? Refactoring, pois o requisito estava OK até a mudança ou até a chegada do requisito novo.

É isso aí, espero que tenha ficado mais explícita a diferença entre essas duas palavras tão parecidas.

Book Suggestion: eXtreme Programming Explained

Ter o Scrum como forma de gerenciar e acompanhar o desenvolvimento de um software é muito legal. Existem diversos conceitos interessantes de sprints, scrum master, sprint review, retrospective, product owner, etc.  Porém essas coisas estão inseridas no âmbito do gerenciamento e acompanhamento, e quando partimos para o lado mais “código” da coisa precisamos ter práticas, técnicas e princípios que possibilitem o desenvolvimento de forma diferente do que vinha sendo feito a muitos e muitos anos atrás (e ainda continua).

É aí que entra o eXtreme Programming Explained. Esse livrinho de cento e poucas páginas contém informações preciosas a respeito de novas formas de desenvolver software, tendo como preocupação principal um cenário aonde tudo pode mudar, os requisitos podem mudar (embrace change). Nesse livro Kent Beck fala sobre as formas que foram encontradas por ele e alguns companheiros de desenvolver software para o mundo real (o mundo onde as coisas continuamente mudam).

Logo no começo do livro, ele fala que programação extrema não traz nada de novo, ele apenas utiliza coisas que já conhecíamos no mundo do software e leva a níveis mais extremos (daí o nome :P). Por exemplo, se testar unitariamente o código é bom, vamos levar ao extremo, e então testar o código todo e o tempo todo (Test Driven Development). Se fazer revisão de código é uma coisa boa, vamos levar ao extremo e fazer revisão o tempo todo (Pair Programming). Se fazer a integração das partes do sistema e compilar o sistema como um todo é bom para antecipar problemas de integração, então vamos levar também ao extremo e fazer integração o tempo todo (Continuous Integration). Se trabalhar no design da aplicação para ficar o mais coerente e aderente a realidade é bom, então não vamos ter medo de fazer o tempo todo também (Simple Design and Refactoring). Se todos fazem parte da equipe não existe isso de um módulo ou parte do sistema ser de fulaninho, onde só ele modifica, e outra parte é de cicraninho, onde só ele que é o fera nessa parte que pode modificar. Nada disso, o código é de todos (Collective Ownership). Tudo isso sustentado por releases pequenos (Feedback Constante), o já conhecido jogo de planejamento (Planning Game) e testes de aceitação por parte do cliente (Customer Tests).

Essa imagem abaixo mostra as áreas descritas no livro, vale a pena dar uma conferida que é material de primeira.

Scrum Boards fora da parede

Times Ágeis Distribuídos? Parece uma coisa meio paradoxal, uma vez que metodologias ágeis pregam o time junto, unido, um ao lado do outro, de forma a reduzir ruídos de comunicação e até de forma a minimizar uma documentação extensiva (uma vez que estão todos juntinhos e sincronizados).

Sou a favor dessa proximidade física do time e entendo os benefícios, no entanto não podemos virar as costas para o movimento home-office ou mesmo para times distribuídos. Diversas empresas, como IBM, já adotaram home-office, e isso faz parte do dia-a-dia do desenvolvimento de software. Não é preciso nem comentar a respeito do desenvolvimento open-source, onde é praticamente todo distribuído, e ainda assim temos diversos casos de aplicações seguras, de qualidade e que são utilizadas em larga escala,  que foram desenvolvidas de forma distribuída.

Hoje em dia (e já a um bom tempo) temos diversas ferramentas que possibilitam esse desenvolvimento distribuído. Temos ferramentas para comunicação (email, msn, skype, etc…) , ferramentas para controle de versão/compartilhamento de arquivos/desenvolvimento paralelo  (svn, git, cvs, etc…), temos ferramentas de controle de bugs (mantis, trac, jira, etc…), e com o advento do scrum, hoje em dia também já temos ferramentas de scrum board (aquele quadrinho na parede cheio de post-it) on-line, que podem ser acessados pela web.

Como agora eu vou precisar trabalhar num time que utiliza scrum, e vou estar distante do resto do time, comecei a dar uma olhada em algumas ferramentas free de scrum board para começar a testar alguma.

Fiz uma pesquisa básica no velho google e achei algumas opções, mas procurei filtrar as que fosse de graça 😛 As opções que eu selecionei são as seguintes: Project Cards (esse aqui é integrado no eclipse, então não é bom pra gerentes e o povo que não usa eclipse) , FireScrum (bem legal, feito em flex, conheço a turma que trabalhou nele, disponibiliza um dashboard como o da figura ao lado) e SeeNowDo que eu vou falar um pouco mais adiante.

Bom, dentre esses o que me chamou mais a atenção foi o SeeNowDo, pelo simples motivo que oferecia tudo aquilo que eu procurava, gratuito, e rápido de utilizar. Ele oferece o dashboard do scrum (como cores diferentes para post-its de categorias diferentes), permite gerenciar múltiplos projetos, cadastro de sprints/estórias/tasks de forma simples e intuitiva, disponibiliza também o burndown chart das tasks cadastradas, e permite a transição das tarefas entre as colunas do quadro(TO DO/DOING/DONE) via drag and drop.

Ah, só tem um probleminha, você tem que utilizar a base de dados deles, pois não é possível fazer um download e instalar no ambiente da sua empresa/projeto. Então se houver alguma questão de confidencialidade no seu projeto, não é muito legal armazenar todas as atividades do projeto numa base on-line.

É isso, vou continuar minha pesquisa e ver se encontro outras ferramentas legais para scrum boards.

PS. Vale lembrar que tirar os post-its da parede e colocar numa ferramenta dessas é uma atitude também Verde (ecologica).

Menos post-its = menos papel = menos árvores derrubadas.