Durante o terceiro encontro do user group Scrum Amazonia, foram discutidas a técnica de gerenciamento de tempo Pomodoro e o uso de ferramentas para suporte ao gerenciamento de projetos Scrum.

Então…

Essa pergunta é frequentemente feita por entusiastas assim como organizações que utilizam Scrum para o gerenciamento de seus projetos, independente de seus níveis de experiência. Vamos falar um pouco sobre as ferramentas, seus objetivos e as que estão em uso no mercado (as principais) e então vamos discorrer um sobre o cerne da questão.

Entre as ferramentas em uso atualmente temos aquelas utilizadas online, hosteadas em algum web server que disponibilizam suas funcionalidades online, sem necessidade de instalação ou deployment por parte do usuário. Algumas são 100% gratuitas enquanto que outras possuem versões mais completas e pagas. Entre estas ferramentas podemos citar:

* Scrumpad
* Scrumy
* SkinnyBoard
* Banana Scrum

Em se tratando de ferramentas que não são web-based (com instalação e/ou deploy), podemos citar as mais utilizadas Redmine, ScrumWorks e ScrumWorks Pro, Mingle, VersionOne, Scrum for Team System, RallyDev, TargetProcess, entre outras. As tecnologias utilizadas pelas ferramentas variam desde simples php até Widgets GWT e Ruby on Rails. O blog Scrum Breakfest apresentou uma pesquisa de 2008 que no momento mostrava como se encontrava o uso das ferramentas de deploy no mercado. A figura abaixo mostra esse uso.

Com relação puramente a Scrum, algumas têm suas funcionalidades bem focadas na arquitetura do Scrum enquanto que outras (Skinny Board, Scrum Pad) já adicionam por exemplo funcionalidades a mais, como o Kanban. Lembrando que Kanban não é Scrum, mas uma ferramenta Lean.

Na verdade, a questão principal das ferramentas é o valor que ela adiciona na administração do projeto ou ao projeto em si. Temos que diferenciar o valor gerado ao gerenciamento e o valor gerado ao projeto. O valor gerado ao gerenciamento, ou ao sistema de gerenciamento de projetos (vide PMBOK) utilizado é definido pela organização. Isso será válido enquanto o Scrum estiver rodando apenas em alguns times esparsos na organização e enquanto a cultura organizacional ditar necessidades alheias ao Scrum. O valor gerado ao projeto é definido pelo time e pelo Product Owner. O TIME define quais tecnologias podem vir a melhorar o processo de trabalho, enquanto que o PO lida com valores de negócio.

Por exemplo, a geração de estatísticas, gráficos como o burndown, etc. É fato que Scrum não trabalha com horas trabalhadas e sim com o número de horas que ainda restam para uma tarefa ou estória ser considerada realizada. Porém, quando uma organização está iniciando em Agile e Scrum, ela muito provavelmente vem aplicando metodologias baseadas nas práticas do PMBOK ou outro processo pré-definido qualquer que facilitam a extração de horas trabalhadas. E isso as organizações o fazem porque faz parte de suas culturas calcular (baseando-se em estimativas) o custo de um projeto, ou quanto tempo resta para terminar o projeto, ou quanto custa cada developer, ou qualquer outra medida que sob o ponto de vista de organização facilita o gerenciamento da tríade CUSTO, TEMPO, ESCOPO.

Temos então dois pontos de vista: o da organização e o do time. Em um mundo ideal, esse ponto de vista seria o mesmo, mas isso é uma outra estória. Sob o ponto de vista da ORGANIZAÇÃO, sendo ela iniciante em Scrum, a mesma deve inciar com práticas mais lúdicas como o Scrum Board, post-its, etc. Por quê? Porque se tal organizacão buscar ferramentas “puras” em Scrum como o ScrumWorks, ela vai sentir falta de estatísticas passíveis de serem geradas no decorrer do Sprint como as famigeradas horas trabalhadas. Sob o ponto de vista do TIME, ele pode definir que o uso de uma ferramenta pode melhorar seu trabalho, porém se isso impactar de alguma forma a organização (geralmente isso é definido pela figura de um gerente de projeto), seja infraestruturalmente ou seja pela quebra de alguma cerimônia, fica para o ScrumMaster a tarefa de proteger o time de quaisquer impactos. Ou seja, mesmo que o time defina utilizar uma ferramenta pode ser que isso não seja facilitado pela organização. Ou pode ser que ele utilize a ferramenta sem problemas.

O que pode motivar um time a adotar uma ferramenta? Isso realmente varia de time pra time, mas podemos citar alguns pontos que podem ser indicadores:

* Facilidade de acesso a critérios de aceitação de user-stories;
* Acompanhamento das releases planejadas;
* Maior visibilidade da situação dos projetos de escopo fixo e os riscos atuais;
* Acesso a ações planejadas para lições aprendidas; e
* Acompanhamento remoto.

Para a organização já vimos o que pode motivar: necessidade cálculos e estatísticas para gerenciamento do projeto. Um bom exemplo prático é que determinadas instituições demandam acompanhamento bem próximo do seu portfólio de projetos (podendo levar ao command and control…) e processos como ISO e CMMI demandam registros.

Sendo assim, partindo desses dois pontos de vista, pode-se utilizar ferramentas, desde que:

* Isso não impacte o trabalho do time;
* Seja de consenso entre time e organização (se estiverem “separados”);
* Agregue valor ao time e/ou à organização.

E sob o ponto de vista puramente do Scrum? Não precisamos de ferramenta alguma!