De acordo com o Professor James D. Herbsleb, no seu livro Global Software Development, lançado em 2001, “A tendência do mercado é de muitos dos times de desenvolvimento estarem dispersos geograficamente, essa configuração de desenvolvimento traz algumas vantagens competitivas, buscando soluções globais, como a redução do tempo de entrega do projeto, através de times paralelos trabalhando além das limitações de fuso-horário.” Por isso, o Desenvolvimento Distribuído de Software tornou-se uma grande realidade para as empresas, mas gerenciar times nesse estilo não é tão simples quanto parece. Assim surgiu o Projeto FireScrum, uma maneira de usar a Metodologia Ágil Scrum no gerenciamento de projetos que são feitos de forma distribuída.

O Desenvolvimento Distribuído de Software (DDS) surgiu como solução para o problema da falta de mão-de-obra das empresas, uma vez que a demanda por aplicações cresce exponencialmente e não há oferta de tantos profissionais para suprir essa necessidade do mercado, ele busca acelerar o desenvolvimento e reduzir o tempo das entregas, por meio de equipes trabalhando paralelamente e extrapolando o fuso-horário. A ideia de gerir um projeto de DDS utilizando o Scrum faz muito sentido, porque para o ambiente ser produtivo, com várias equipes distanciadas, precisa-se de uma gestão muito esforçada e aplicada, com uma grande ajuda do uso da tecnologia. Para entendermos a funcionalidade do Projeto FireScrum, vamos ver melhor como a Metodologia Ágil funciona.

O Scrum se baseia muito na interatividade dos membros e da alta mutabilidade do produto e dos seus processos. Para definir essas características do produto, ocorre a comunicação de uma necessidade do cliente, usando essas informações, define-se o Product Backlog, o qual será dividido em várias releases (que são pequenas entregas), cujo conjunto delas é denominado Sprint Backlog, mas o que é Sprint? Sprint é o tempo determinado para o desenvolvimento dessas atividades, o projeto é dividido em várias delas, que durante execução de cada uma, ocorre as Daily’s, que são pequenas reuniões diárias para discutir o andamento do projeto, que abordam o que já foi feito, o que será feito no próximo momento e as dificuldades encontradas no processo. No final de cada Sprint, acontece a Review meeting, na qual a equipe apresenta o resultado alcançado ao cliente, e logo após, é feita a Retrospective meeting, onde o Scrum Master conduz o time através dos problemas enfrentados, para a proposição de melhorias do processo/produto. Como o Scrum se fundamenta na interação constante e eficiente dos membros do time, mas por um outro lado, com o crescimento contínuo do desenvolvimento de software por equipes remotas, torna-se essencial o uso de ferramentas de apoio que minimizem os impedimentos gerados na aplicação do Scrum como metodologia de desenvolvimento em equipes distribuídas.

O Projeto FireScrum surgiu para solucionar alguns desses problemas, ele é uma ferramenta open source que foi desenvolvida para dar suporte ao gerenciamento de times distribuídos. Suas funcionalidades foram implementadas por 60 pós-graduandos, que cursaram a disciplina de Engenharia de Software da Universidade Federal de Pernambuco (UFPE), os 60 integrantes da disciplina foram distribuídos em seis times responsáveis, cada um, por um módulo do sistema FireScrum:

• Core
• Poker Planning
• TaskBoard
• Bug Tracking
• Desktop Agent
• Test Module
  
  

Cada time funcionava como um fábrica de desenvolvimento independente com um Scrum Master cada. A proposta da disciplina foi simular um ambiente próximo da realidade da indústria de software, proporcionando aos alunos o exercício da mesma, usando seus conceitos, métodos, práticas e ferramentas e permitindo aos estudantes adquirirem uma experiência prática de vivência de problemas e imprevistos que acontecem, e que precisam ser resolvidos.

Acompanharam mais de perto o desenvolvimento do módulo Planning Poker, cujo processo foi orientado pela Metodologia Scrum. Este módulo tinha o objetivo de simular sessões de estimativa nas quais os participantes pudessem discutir sobre suas opiniões como se estivessem numa sala presencialmente, visto que os participantes deste time moravam em 4 cidades distintas. Para a realização desse projeto, foram realizadas 5 Sprints. Visto que, no início do projeto os membros não eram tão proficientes com a metodologia, e o comprometimento e a comunicação entre os integrantes do time de desenvolvimento não era eficiente, criou-se uma dificuldade inicial. Notou-se que ao longo das Sprints, a proficiência dos membros melhorou muito, tanto nos aspectos técnicos quanto no autogerenciamento. No final do projeto, foram encontrados 5 problemas principais enfrentados pelo time de desenvolvimento, e como isso foi solucionado:

1. Equipe Geograficamente Distribuída, como comentado várias vezes, é necessário que o time de desenvolvimento seja visto como uma unidade, para contornar a barreira da distância, os membros utilizaram várias ferramentas de comunicação via web.
2. Daily’s, visto que é uma parte importante para a resolução de problemas e atualização, foi utilizada mais uma ferramenta de comunicação online para o seu controle.
3. Visibilidade, é muito importante que as atividades necessárias sejam visíveis, portanto, os membros fizeram uma planilha de delegação e controle dessas atividades.
4. Atribuições do Scrum Master, o Scrum Master tem a função de auxiliar na solução de problemas do time de desenvolvimento, no modo remoto, os membros optaram por adicionar a atividade de gerir eficientemente os membros, verificar sua comunicação, entre outros.
5. Acoplamento de Atividades, muitas das atividades escolhidas eram dependentes entre si, então, ao longo das Sprints, elas eram analisadas e feitas de forma que fossem completamente independentes.

A necessidade do mercado por sistemas mais complexos num curto espaço de tempo e requisitos altamente mutáveis levaram as empresas a adotarem o desenvolvimento ágil para reduzir o tempo das entregas, mas isso traz uma série de problemas. O objetivo deste texto foi destacar os problemas que surgem durante um projeto e quais são as suas possíveis soluções. Dentro do PET, nos deparamos com muitos problemas parecidos e, ao longo do tempo, nos acostumamos a resolvê-los!