A metodologia ágil de desenvolvimento (e as ferramentas para implementá-las, como o ScrumHalf) em geral são utilizadas para gerenciar o desenvolvimento de um projeto, que na maioria das vezes, é de software.
Mas essa metodologia tem aplicações que vão muito além dos projetos. Pode ser aplicada diretamente na gestão do dia-a-dia da empresa.
É assim que fazemos na ICE. Por termos uma equipe muito enxuta, estamos sempre dividindo nosso tempo entre o desenvolvimento dos projetos e a própria administração da empresa. E como as tarefas das histórias relativas ao desenvolvimento sempre concorriam com itens como: fazer uma visita técnica, ter uma reunião com um cliente, ou mesmo ir ao banco, não era possível estimar o tempo de desenvolvimento sem levar essas outras tarefas “externas” em consideração.
Então, por que não inseri-las no planejamento? Afinal, é a mesma equipe Scrum que é responsável tanto por programar quanto por tocar o resto da empresa. Dessa forma, adotamos o ScrumHalf desde o início como ferramenta não só de gestão de projetos, mas como de gestão empresarial. Até mesmo para saber como está o andamento de uma negociação com um determinado cliente, e quem é o responsável por ela, por exemplo, fica muito mais fácil.
E qual a grande vantagem nisso?
São duas, na verdade: foco e clareza de objetivos. Tentamos ao máximo terminar uma história antes de começar outra, e isso impede que concorramos com nós mesmos; e a ordem de prioridades fica bastante explícita, facilitando a alocação do tempo para realizar cada uma das coisas que devem ser feitas.
O tamanho reduzido da equipe nos obriga a ser multi-tarefa: cada tipo de história exige uma competência maior em uma área de conhecimento, sendo que o mais experiente nessa área absorve o papel de PO; o papel de Scrum Master sempre cabe a outro membro da equipe, para não haver sobrecarga de funções; e todos trabalham em conjunto como Equipe Scrum.
Inicialmente, tivemos bastante dificuldade em ajustar o trabalho à metodologia Scrum. Começamos por fazer Sprints muito grandes, de um a dois meses, e não conseguíamos acompanhar o andamento das tarefas; as vezes, só entendíamos que a tarefa não foi útil após a Sprint ser finalizada, dois meses depois. O caminho natural foi fazer Sprints cada vez menores; dessa forma, acabamos nos adaptando a planejar o macro e executar pequenas tarefas – sempre as mais importantes – o que nos trouxe muito conhecimento sobre a direção que os projetos estavam em tempo real, tornando qualquer mudança muito menos dolorosa.
O tempo de Sprint ideal, que concluímos, é de uma semana. É feita uma reunião semanal para decidir tudo o que deve ser feito na empresa, nas diversas esferas – financeiro, administrativo, produção, P&D, mercado – escolhendo apenas aquelas que são totalmente necessárias. Um benefício imediato é a integração total de todos na empresa, eliminado a necessidade de fazer relatórios específicos de cada área para atualizar desde a equipe até os diretores.
Hoje isso já faz parte da rotina da empresa. Sempre que surge alguma coisa nova para ser feita, a primeira coisa é criar a história e colocá-la (ou não, dependendo do andamento das demais) na Sprint. Podemos dizer que estamos caminhando para nos tornar uma “empresa ágil”.
Essa é a experiência que temos para compartilhar no uso da metodologia ágil. Espero que outras empresas possam se sentir estimuladas a tentar o mesmo.
Rafael Amaro é Engenheiro Eletrônico e de Computação, sócio-diretor da ICE Interactive
Rafael, essa troca de experiência sobre Scrum é muito importante.
Cada empresa tem suas particularidades e o Scrum pode ser adaptado para cada uma, e escrever sobre como utilizamos o Scrum ajuda outras pessoas que trabalham em empresas com as mesmas características.
Eu já utilizei Scrum de diversas formas, tanto na empresa como também para projetos pessoais e até mesmo para orientar um trabalho de conclusão de curso, no qual eu fiquei de PO e atuei um pouco como equipe Scrum também para ajudar.
Nesse último caso, o Scrum seria utilizado apenas para o software que os 2 alunos iriam desenvolver. Porém, durante o projeto, vimos que tarefas de pesquisa e também de escrita (no caso, da monografia) faziam com que a quantidade de coisas desenvolvidas alterassem muito de uma Sprint para outra. Resolvemos então ampliar o projeto Scrum para todo o trabalho e não apenas o software, incluindo histórias específicas para leitura e também para capítulos da monografia. Dessa forma a velocidade da equipe foi ajustada e conseguimos produzir mais.
Estimar histórias de estudo não é fácil, porque geralmente eram textos sobre coisas novas e não tínhamos noção da dificuldade. Mesmo assim, colocar essas histórias no Product Backlog e na Sprint ajudou a equipe a ver de forma mais clara o quanto faltava para terminar o trabalho.
Agradeço por compartilhar sua experiência nesse post e desejo boa sorte para a ICE. O caminho ágil para a empresa de vocês só vai ajudar!