Acompanhamento de projetos distribuídos com Scrum - Engenharia de Software 30

O desenvolvimento ágil de projetos distribuídos é uma tendência para médias e grandes empresas que querem competir no mercado global, acelerar a produtividade e reduzir os custos. Nesse artigo, o Scrum foi a metodologia ágil escolhida para ajudar no acompanhamento ágil das equipes remotas por ter um foco maior em gerenciamento de projetos. Entretanto, o Scrum não foca suas práticas em ambientes distribuídos, e por isso diversos trabalhos [11] [17] relataram suas experiências, adaptações e os resultados obtidos com as mudanças feitas nas práticas Scrum.

Nesse contexto, este artigo apresenta uma abordagem para auxiliar o acompanhamento de projetos com equipes remotas. Para isso, foram definidas as adaptações das práticas do Scrum baseado na análise dos trabalhos relacionados [11] [12] [16] [17].

Embora o foco da abordagem seja o acompanhamento do projeto, é importante definirmos o contexto no qual ela será aplicada, que será apresentado nessa primeira etapa. Desse modo, é necessário definir os papéis importantes para o projeto, algumas formas de organizar as equipes, e também os recursos tecnológicos que ajudariam as equipes a amenizar os problemas enfrentados pelos membros remotos. Essas sugestões não são exaustivas, apenas exemplificativas, e visam também auxiliar àquelas empresas que pretendem mudar o projeto para o contexto distribuído e buscam informações de como realizar essa mudança.

O artigo está organizado da seguinte maneira: inicialmente serão apresentados os papéis, a organização das equipes e os recursos tecnológicos necessários. Em seguida discutiremos algumas práticas de Desenvolvimento Distribuído de Software (DDS) que dão apoio ao acompanhamento de projetos distribuídos. Na seção posterior, a abordagem é descrita, e por fim apresentamos as conclusões.

Papéis

No Scrum tradicional temos alguns papéis definidos, tais como o PO, o Scrum Master e o Time, que devem interagir frequentemente em prol do projeto. Entretanto, em um contexto distribuído esses papéis precisam se comportar um pouco diferente, além de ser necessária a criação de novos papéis tais como Representantes do Cliente e do Time. Vejamos a descrição dos papéis e suas atribuições:

· Product Owner (PO): É a pessoa responsável pelo sucesso do produto. Ele está empenhado em representar os interesses de todos os envolvidos no projeto, como os patrocinadores (stakeholders). O Product Owner é responsável por gerir o orçamento do projeto, os planos do projeto e a lista de requisitos (funcionalidades), bem como proporcionar à equipe todas as informações necessárias relacionadas com as suas expectativas sobre o software. Em um projeto distribuído pode existir mais de um PO, um para a equipe local e um por equipe remota, por exemplo;

· Representante (Proxy) do cliente: Pode ser difícil para uma equipe remota ter o cliente trabalhando fisicamente no seu local de desenvolvimento. Isso por que muitas vezes os POs estão tão envolvidos com os clientes que não conseguem estar sempre disponível para tirar as dúvidas das equipes. Por essa razão o papel de Representante do Cliente foi sugerido. Ele é responsável por tomar decisões sobre as funcionalidades e escopo do projeto. Além disso, é necessário que ele seja facilmente acessível, e tenha um grande interesse no projeto. Esse papel ajuda a transferir conhecimento do domínio do negócio do cliente para os desenvolvedores, e assim melhorar a comunicação. Deste modo, esse papel é útil quando o cliente real não está disponível para responder perguntas, podendo tomar as decisões em nome deste, servindo assim como interface. Quando surgirem questões que ele não saiba responder, ele é responsável por buscar a informação com o PO prontamente, de modo a não atrapalhar a produtividade da equipe [7] [11] [20];

· Scrum Master: O Scrum Master é responsável pelo processo Scrum, garantindo sua aplicação no projeto e que todos os envolvidos sigam e respeitem o conjunto de práticas e regras. Esse papel é muito importante no contexto distribuído, pois como os membros estão dispersos, a tendência de eles deixarem de lado algumas práticas importantes do Scrum é grande, cabendo, portanto ao Scrum Master acompanhar para que isso não ocorra;

· Time: É responsável pelo desenvolvimento do projeto. Os times têm de trabalhar coletivamente, e se auto gerenciar e organizar as tarefas necessárias para alcançar o objetivo da Sprint. Como as equipes são distribuídas, é necessário um esforço maior de seus membros para interagirem e se comunicar usando os recursos tecnológicos possíveis em prol do sucesso do projeto [9];

· Representante (Líder) do Time: Devido à dificuldade de gerenciar os empecilhos dos membros remotos, é importante a criação de um novo papel para representar a equipe. Esse papel deve ser ocupado pelo membro mais experiente (sênior) da equipe. Ele deve ser responsável por interagir com os outros líderes e com o Representante do cliente diariamente, de modo a resolver os impedimentos prontamente e as dependências entre as equipes [15].

Esses papéis foram definidos com base nos trabalhos pesquisados [7][9][10][20][15], para melhorar a interação, colaboração e comunicação entre as equipes remotas para um melhor acompanhamento do projeto.

Organização das equipes

De modo a estruturar um projeto distribuído, descreveremos algumas sugestões de organização das equipes distribuídas. Empresas que normalmente trabalham com equipes no mesmo espaço físico encontram dificuldades quando passam a trabalhar de forma distribuída. Organizar as equipes de forma errada pode acarretar em inúmeros problemas de interação e colaboração entre os membros, mudanças constantes dos requisitos devido a distorções durante a comunicação, e também a falta de motivação das equipes remotas por não se sentirem parte do projeto. Tais dificuldades na formação das equipes são alguns dos principais problemas que levam ao fracasso do projeto.

O primeiro passo para estruturar o projeto é a alocação dos membros em cada equipe. Um erro comum é criar equipes por especialidade numa mesma localidade, ou seja, equipe A formada só por arquitetos na localidade X, a equipe B só com desenvolvedores na localidade Y e a equipe C apenas de testadores na localidade Z [15]. Criar equipes por especialidade apresenta problemas ao utilizarmos metodologias ágeis, pois acaba gerando um ciclo em cascata, em que os arquitetos preparam as especificações e enviam para os desenvolvedores, que após finalizar o trabalho repassam para os testadores. As diferentes especialidades precisam interagir focando uma funcionalidade por vez. Com isso, é mais interessante montarmos equipes que possuam todas as especialidades e fazer com que eles interajam bastante.

Após definirmos como alocar os membros, iremos apresentar duas possíveis formas de organização das equipes. Na primeira formação, cada localidade possui todos os perfis necessários, e nesse caso cada localidade forma uma equipe. Já na segunda, uma equipe é formada por membros de diversas localidades, o que é comum devido à dificuldade de encontrar certas especialidades em alguns locais. Nessas duas formações mencionamos a localidade central que é aquela que possui mais contato com o PO e o cliente, e temos também as localidades remotas que são as diversas regiões espalhadas pelo mundo.

A Figura 1 apresenta a primeira formação. Nessa formação cada equipe trabalha no mesmo espaço físico, usufruindo de uma melhor comunicação entre os seus membros e maior interação entre eles para concluir as tarefas. Na Figura 1 temos a Equipe 1 na localidade central e a Equipe 2 na localidade remota. Com essa organização podemos observar a importância do papel do Proxy nas localidades remotas, uma vez que o time necessita tirar dúvidas constantemente sobre o projeto e a demora dessa resposta pode impactar na produtividade, acarretando até não alcançar o objetivo da Sprint. Desse modo, o Proxy deve sempre estar disponível e poder responder pelo Cliente. Quando ele não sabe responder algum questionamento, ele entra em contato imediatamente com o PO e fica responsável por cobrar dele uma resposta rápida. Na Equipe 1 também precisamos de um Proxy, pois ele deve responder prontamente as dúvidas dos outros Proxies das outras equipes remotas. Na Figura 1 também podemos observar uma linha entre cada papel, indicando que a comunicação dos papeis equivalentes entre as equipes devem ocorrer com mais frequência, ou seja, os Proxies devem se comunicar diariamente, assim como deve haver um contato entre os Scrum Masters.