FACULDADES METROPOLITANAS UNIDAS - FMU

GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE

SOFTWARE PARA INTERNET COM EQUIPES REMOTAMENTE DISTRIBUDAS
UTILIZANDO METODOLOGIA SCRUM

Paulo Henrique Lomanto




















So Paulo
2013


FACULDADES METROPOLITANAS UNIDAS - FMU










GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE
SOFTWARE PARA INTERNET COM EQUIPES REMOTAMENTE DISTRIBUDAS
UTILIZANDO METODOLOGIA SCRUM


Paulo Henrique Lomanto

Trabalho de concluso de curso para curso
Master in Project Management da instituio
Faculdades Metropolitanas Unidas (FMU) sob
orientao do Professor Ms. Antonio Carlos de
Alcantara Thimteo







So Paulo
2013

RESUMO
Este artigo representa uma anlise da literatura atual sobre o tema de gerenciamento de
projetos utilizando a metodologia de desenvolvimento de software Scrum e procura a sua
aplicabilidade no gerenciamento de equipes remotamente distribudas atravs de experincias
evidenciadas por outros autores.
O desenvolvimento deste artigo envolveu a pesquisa de dois temas distintos:
Metodologia de Desenvolvimento SCRUM e Gerenciamento Remoto de Equipes de
Desenvolvimento. Ainda dentro de cada um dos temas, procurou-se saber se os temas ainda
so atuais no ponto de vista de mercado e se suas aplicabilidades so efetivas, como forma de
guiar o desenvolvimento geral do assunto.
Por se tratarem de assuntos em destaque no mercado de trabalho e que so de certa
forma recentes por se tratarem de novas formas de trabalho evidenciados pelo mundo cada
vez mais globalizado e interligado, os referenciais tericos no so fartos, porm, de certa
forma de grande qualidade e com muitos exemplos de casos, que puderam servir de base para
o desenvolvimento da ideia geral deste artigo.
Ao final da pesquisa, foi possvel ainda obter relatos de profissional da rea que
auxiliam e complementam o tema geral deste artigo.
PALAVRAS-CHAVES: SCRUM. Gerenciamento de Projetos.

ABSTRACT
This paper represents an analysis from current literature about Project Management
using the Scrum methodology for Software Development and search for his applicability on
remote distributed teams management shown by another authors.
The development of this paper was conducted by research of two distinct subjects:
SCRUM Development Methodology and Remote Development Teams Management. On each
subject we searched to know if the subjects are still actual by the industry point of view and if
his applicability are still effective as a way to guide the general idea of this paper.
Because these are subjects highlighted on industry and are relatively new ways of
labor evidenced by a more globalized and interconnected world, the available literature is not
abundant, but have a great quality and have a great quantity of examples and cases that helped
to be a guide for this paper development.
By the end of the development of this paper it was possible to get informations from a
profssional that helps with the main subject of this paper.
KEY WORDS: SCRUM. Project Management.
1. INTRODUO
O desenvolvimento de software, principalmente para projetos de internet, exige
profissionais cada vez mais qualificados para o desempenho de suas funes, alm da
necessidade de um processo que garanta um bom ritmo, controle e qualidade do que se
desenvolve. (PROJECT MANAGEMENT INSTITUTE (PMI), 2008)
Ao longo do tempo, novas formas de gerenciamento do processo de desenvolvimento
foram criadas e refinadas. Atualmente, o processo mais difundido e utilizado para o
desenvolvimento de software, principalmente os que so para internet, o Scrum.
O Scrum uma metodologia de desenvolvimento de software gil, focada na produo
de software de forma rpida, incremental, e com garantia de qualidade daquilo que se produz.
(SANTANA, 2011; MANIFESTO for Agile Software Development, on-line)
Com cada vez mais projetos de software sendo iniciados, h uma necessidade
proporcional de profissionais para a sua execuo. Encontrar estes profissionais tm sido cada
vez mais um desafio para as empresas, que esto buscando outras formas de contratao de
mo-de-obra qualificada para a execuo de seus projetos. (SUTHERLAND, 2008;
SUTHERLAND, 2009)
Outro fator que contribui para essa busca por mo-de-obra terceirizada a economia
financeira, visto que muitas empresas especializadas em terceirizao, sejam elas na mesma
localidade geogrfica ou remotamente distantes, podem proporcionar o desenvolvimento do
software a custos bem inferiores aos que as empresas teriam se adotassem o desenvolvimento
internamente. (SUTHERLAND, 2008; BERCZUK, 2007; SUTHERLAND, 2009)
O objetivo deste artigo prover material para futuros artigos e tcnicas a partir de uma
anlise de literatura existente no que se refere ao processo de gerenciamento de equipes de
desenvolvimento remotamente distribudas utilizando-se a metodologia Srum para que se
atinja o mesmo ritmo, qualidade e controle que se obtm com equipes de desenvolvimento
que adotam o Scrum em seus ambientes nativos.








2. REFERENCIAL TERICO

2.1. O SCRUM
O Scrum se enquadra na categoria de metodologia de desenvolvimento de software
gil, como o descrito no Manifesto gil. (FILHO; ALVES, 2010; SANTANA; FREITAS,
2011; SEVERINO, 2009; MANIFESTO for Agile Software Development, on-line)
O Manifesto gil apoiado em alguns valores e ideias que devem ser seguidos por
qualquer processo de desenvolvimento que se proponha a se enquadrar como gil.
(MANIFESTO for Agile Software Development, on-line)
So eles:
Indivduos e Interaes mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ainda segundo o Manifesto gil, considera-se que h valor nos itens direita das
citaes acima, mas que os itens esquerda so mais valorizados e primordiais.
(MANIFESTO for Agile Software Development, on-line)
A metodologia Scrum tem como uma das suas principais caractersticas a criao de
software de forma gil, com qualidade, de forma incremental. (FILHO; ALVES, 2010;
SANTANA; FREITAS, 2011; SEVERINO, 2009)
Ao contrrio de outras metodologias mais conservadoras, com caracterstica
waterfall, no se espera que todos os requisitos, anlise e documentos do software desejado
estejam prontos para que se inicie o processo de desenvolvimento. Tambm no se espera que
o desenvolvimento esteja completo para que o software seja entregue. (SANTANA;
FREITAS, 2011)
Nessa metodologia, o software vai sendo desenvolvido, de forma controlada e
ordenada, assim que os primeiros requisitos so levantados.
Todo o processo de desenvolvimento visa a entregas de software de forma
incremental, ou seja, assume-se que o ciclo de vida do processo de desenvolvimento no se
encerra na sua entrega, mas que a cada entrega o software ganha maturidade, de forma
interativa e incremental. (FILHO; ALVES, 2010; SANTANA; FREITAS, 2011; SEVERINO,
2009)

A figura 1 exemplifica a forma como ocorrem as interaes do Scrum.

Figura 1 Processo de desenvolvimento do Scrum

Fonte: SCRUM (development) Wikipedia, the free encyclopedia

Outra caracterstica importante sobre o Scrum a sua facilidade de resposta a
mudanas de escopo do projeto em desenvolvimento. Como o processo interativo, cada
nova interao (denominada Sprint) pode ter um foco de desenvolvimento totalmente
diferente. Isso garante agilidade e flexibilidade no processo de desenvolvimento do software.
(SANTANA; FREITAS, 2011; SEVERINO, 2009)
Um dos preceitos da metodologia determina que uma equipe de Scrum seja auto-
gerenciada no escopo de processos internos de controle. Com isso, cada membro de uma
equipe deve zelar pelo bom andamento do time como um todo, seja em forma de propostas de
melhorias nos processos, seja em cobranas por resultados dos outros membros, ou qualquer
outra forma que seja benfica ao time.

2.1.1. PAPIS NO SCRUM

No Scrum temos alguns papis que so desempenhados por diferentes pessoas dentro e
fora do time. Essa diviso procura determinar as responsabilidades de cada parte interessada
do projeto, do time de desenvolvimento e das relaes entre elas. So os papis do Scrum:

ScrumMaster: membro do time de desenvolvimento responsvel pelo bom andamento
do time de desenvolvimento e por garantir que nenhuma interferncia externa do dia-a-dia dos
integrantes do time afete o seu processo interno.
O ScrumMaster tambm considerado como sendo a pessoa chave para que todos os
integrantes do time de desenvolvimento adotem e usem as prticas do Scrum.
Alm disso, o ScrumMaster a pessoa que interage diretamente com o ProducOwner
(PO) para auxiliar no processo de criao e manuteno do Backlog do produto (lista de
recursos a serem desenvolvidos), bem como manter a informao fluindo entre o PO e o time
de desenvolvimento. (FILHO; ALVES, 2010; SANTANA; FREITAS, 2011; SEVERINO,
2009)
Product Owner: o Product Owner (PO) o papel responsvel pela centralizao das
demandas de reas externas do projeto e pela manuteno do Backlog do produto. O PO pode
ser tanto o gerente do projeto, como um patrocinador, membro de alguma outra equipe da
empresa ou algum outro cliente interno. (FILHO; ALVES, 2010; SANTANA; FREITAS,
2011; SEVERINO, 2009)

2.1.2. PRODUCT BACKLOG

O Product Backlog, ou simplesmente Backlog, contm uma relao de todos os itens
do software desejados at o momento e prioritariamente mantido pelo Product Owner.
Cada um dos itens relacionados no Backlog uma histria, que ser em algum
momento, desenvolvido pela equipe de desenvolvimento.
Toda histria possui uma complexidade diferente, e para a determinao da sua
complexidade, a equipe de desenvolvimento se rene em um ciclo determinado de acordo
com o aumento do nmero de histrias no pontuadas para discutir os detalhes da execuo
dessas histrias e atribuir uma pontuao de complexidade. A reunio na qual os membros se
encontram para essa discusso chamada de Estimation Meeting, ou Reunio de Estimativa.
(FILHO; ALVES, 2010; SANTANA; FREITAS, 2011; SEVERINO, 2009)

2.1.3. SPRI NT

Cada nova interao no SCRUM denominada Sprint, que por sua vez deve ser um
perodo de tempo pr-determinado e acertado pelo time de desenvolvimento, e que possui
como usual um perodo de duas a quatro semanas. (FILHO; ALVES, 2010)
Em cada Sprint, o time de desenvolvimento assume um conjunto de tarefas a serem
desenvolvidas a partir de uma lista de requisitos formada previamente pelos stakeholders do
projeto (Product Backlog).
Cada Sprint se inicia a partir de uma reunio entre a equipe de desenvolvimento e o
PO, denominada Sprint Planning, para que o mesmo possa apresentar uma lista de histrias j
estimadas e pontuadas nas reunies de estimativa, em ordem de desejo de execuo e para que
o time de desenvolvimento possa decidir as histrias que sero executadas no decorrer do
Sprint. (COHN, 2006)
A reunio de Sprint Planning dividida em duas fases: na primeira, o time decide em
conjunto com o ScrumMaster e o PO as histrias que sero desenvolvidas no decorrer do
Sprint, enquanto que na segunda, o time de desenvolvimento detalha cada uma das histrias
que sero executadas. (FILHO; ALVES, 2010; COHN, 2006)
A partir do detalhamento das histrias, so definidas as Tasks, ou tarefas de cada
histria. Uma task nada mais do que uma pequena diviso de uma histria, algo que algum
membro do time possa executar.
Ao final do processo de Sprint Planning, o Sprint iniciado e todas as histrias com
suas respectivas tasks so inseridas em um quadro, como o demonstrado na figura 2, de
preferncia visvel a todos os membros do time, para acompanhamento e controle do que deve
ser feito, o que est sendo atualmente desenvolvido, testado e pronto. (FILHO; ALVES, 2010;
COHN, 2006)














Figura 2 Exemplo de quadro de Scrum

Fonte: SCRUM (development) Wikipedia, the free encyclopedia

Diariamente ocorre uma reunio com durao de 15 minutos, chamada de Daily
Meeting, em que todos os membros do time se renem em frente ao quadro do Scrum para
que todos possam informar aos outros o que esto fazendo, o que planejam fazer no prximo
dia, e o que ficou pronto. nessa reunio que os membros movem as suas tarefas (tasks) entre
as fases do quadro. Esse ciclo de reunies dirias se repete diariamente durante a realizao
do Sprint. Um fator importante dessa reunio diria a interao entre os membros do time, j
que estimula a comunicao entre todos e exposio de ideias entre os membros. (FILHO;
ALVES, 2010; COHN, 2006)
tambm no Daily Meeting que um artefato importante do Scrum, o Burndown Chart,
atualizado. Esse artefato um grfico que mostra a quantidade de tasks que so finalizadas
todos os dias e deve estar preferencialmente no quadro, para que se tenha uma noo da
velocidade do desenvolvimento do time. Esse quadro apresenta basicamente duas linhas: uma
uma linha reta contendo a evoluo ideal de tasks que deveriam estar finalizadas todos os
dias, enquanto que a segunda a realidade de tasks realizadas pelo time. A figura 3
exemplifica um Burndown Chart. (FILHO; ALVES, 2010; COHN, 2006)



Figura 3 exemplo de Burndown Chart

Fonte: Scrum(development) Wikipedia, the free encyclopedia

Ao final do Sprint, o time de desenvolvimento apresenta ao PO em uma reunio
denominada Sprint Review tudo o que foi desenvolvido durante o Sprint atual para a sua
validao.
Aps a apresentao do Review, uma reunio de retrospectiva feita entre os membros
do time de desenvolvimento e o PO para que todos possam relacionar fatos e situaes que
foram bem proveitosos no Sprint e tambm o que no aconteceu como planejado ou
atrapalhou o processo de desenvolvimento. Essa considerada uma das reunies mais
importantes do Scrum, pois a partir dela que surgem ajustes a serem feitos ao processo a
partir dos itens relacionados como problemticos e os pontos fortes so realados para futuros
sucessos. (FILHO; ALVES, 2010; COHN, 2006)
Todos os processos anteriores so repetidos a partir deste ponto, indefinidamente,
enquanto o projeto permanecer ativo.

2.2. EQUIPES DE DESENVOLVIMENTO REMOTAMENTE DISTRIBUDAS

Segundo Pearlman (2006), um time distribudo consiste em um conjunto ou grupo de
pessoas que fazem uso de tecnologia para trabalharem em um mesmo objetivo a partir de
diferentes localizaes.
Podemos, ento, entender por Equipes de desenvolvimento remotamente
distribudas toda forma de trabalho de desenvolvimento de software adotada que acontea
fora do ambiente de trabalho originalmente designado, por um ou mais indivduos.
Essas equipes de desenvolvimento podem estar distribudas em localidades diferentes,
tanto em um territrio prximo (em uma mesma cidade, por exemplo), como tambm podem
estar a milhares de quilmetros de distncia, em outro pas ou at mesmo em outro continente.
(SUTHERLAND et al, 2007).

2.2.1. MOTIVAES

Quanto a motivao, diversos so os fatores que influenciam as empresas nos dias
atuais a buscarem a distribuio de suas equipes de desenvolvimento de software em locais
remotamente distribudos.
Podemos levar em considerao dois fatores principais que levam as empresas a
buscarem esse tipo de atividade: econmico e falta de mo-de-obra local especializada.
(SUTHERLAND et al, 2007; SUTHERLAND et al, 2009)
Em relao ao fator econmico, podemos destacar os custos salariais de profissionais
que esto localizados nos grandes centros, locais esses onde esto concentradas as maiores
empresas do setor de tecnologia em geral. Uma vez que se adota a contratao de pessoal
localizado em centros de menor notoriedade, o custo profissional tende a baixar
significativamente. Indo alm, h tambm a questo de custos de mo-de-obra baixos em
centros tecnolgicos localizados em pases como ndia e China, que so muito inferiores aos
da grande maioria dos mercados internacionais. (SUTHERLAND et al, 2007;
SUTHERLAND et al, 2009)

2.2.2. FATORES DE DIFICULDADES

Quando falamos em distribuio de equipes de desenvolvimento em locais diferentes
aos da sede, temos que levar em considerao diversos fatores que precisam ser vistos e
revisados. Segundo Pearlman (2006) e Sutherland et al (2007), podemos enumerar os
seguintes fatores como sendo elementos de dificuldade na implementao de uma equipe de
desenvolvimento remotamente distribuda: cultura, fuso-horrio, comunicao, controle,
confiana, liderana, tcnica e segurana da informao.
Os fatores a serem levados em considerao variam de acordo com a forma de
distribuio que est sendo adotada. As preocupaes so diferentes se uma equipe est
localizada na mesma sede que a empresa, ou se est em outro pas ou continente.
Tambm so diferentes as preocupaes que devem existir se h o desenvolvimento
distribudo em mais de duas localidades diferentes.

2.2.2.1. Cultura

Ao implementar uma equipe de desenvolvimento remotamente distribuda, h um fator
cultural a ser levado em considerao.
Nos casos de equipes que trabalham em uma mesma localizao geogrfica (cidade), a
influncia cultural no tende a ser muito grande, pois todos os profissionais, tanto da equipe
remota, quanto da sede, tendem a compartilhar os mesmos aspectos culturais, que so
predominantemente regionais.
Quando a equipe remota comea a se afastar das proximidades da sede, pode haver
discrepncias de cultura entre os profissionais da sede e da equipe remota. Essas diferenas
podem ser em relao ao ritmo de trabalho, forma de expresso de ideias, diferentes
comprometimentos com os projetos, entre outros. (PEARLMAN, 2006)
J quando h diferenas de pases ou continentes, as diferencias culturais ficam muito
mais evidentes, j que alm dos itens citados anteriormente, aparecem questes como lngua,
conhecimentos e hbitos coletivos de pases diferentes, entre outros. (SUTHERLAND et al,
2007)

2.2.2.2. Fuso-horrio

As equipes remotamente distribudas precisam o tempo todo se comunicar com
membros de outras equipes e com a sede da empresa. Essa comunicao deve ocorrer sempre
que possvel dentro de horrios nos quais os profissionais estejam em seus horrios de
trabalho regulares, para no afetar regras de legislaes locais de trabalho ou afetar a vida
pessoal dos profissionais. (SUTHERLAND et al, 2007; SUTHERLAND et al, 2009;
BERCZUK, 2007; PEARLMAN, 2006)
A diferena de fusos horrios em equipes em um mesmo pas geralmente no tende a
ser um fator de dificuldade, a no ser em pases que tenham dimenses continentais.
Se levarmos em considerao pases como Estados Unidos da Amrica (E.U.A.), que
possui quatro horas de diferena entre a sua costa leste e oeste, podem ser necessrios ajustes
na forma e rotinas das equipes de modo que os horrios de comunicao coincidam com suas
jornadas de trabalho locais. (The official US time (NIST & USNO), on-line)
No Brasil, essa diferena de fuso-horrio no tende a ser um fator de dificuldade, se
levarmos em considerao que h apenas trs fusos-horrios diferentes. (Observatrio
Nacional, on-line)
J quando falamos sobre equipes distribudas em pases diferentes, com grandes
diferenas de horrio, h necessidade de que as rotinas de trabalho sejam pensadas de forma a
compensar essa diferena. Pode haver ainda casos em que as equipes, que sigam jornadas de 9
a 10 horas de trabalho dirias, no tenham horrio comum de trabalho, caso o fuso horrio
esteja em uma faixa de diferena acima de 9 horas e menor que 15 horas. (SUTHERLAND et
al, 2007)

2.2.2.3. Comunicao

As equipes remotamente distribudas necessitam de comunicao constante com
outras equipes e com a sede da empresa, de forma a trocar informaes o tempo todo sobre
questes tcnicas, organizacionais e de controle do projeto.

De acordo com levantamentos, a comunicao em projetos remotamente distribudas
o principal fator de dificuldades que as equipes e empresas tm enfrentado. (SUTHERLAND
et al, 2007; BERCZUK, 2007; SUTHERLAND et al, 2009; SUTHERLAND et al, 2008;
HUNDERMARK, on-line)
Segundo Sutherland (2007), um dos principais mecanismos de comunicao entre as
equipes o uso de mensagens eletrnicas (e-mails), mas segundo a anlise de Pearlman
(2006), o uso constante de mensagens eletrnicas deve ser o ltimo recurso a ser utilizado por
no ser transparente e pessoal.
Apesar do uso constante de mensagens eletrnicas, outras formas que ganham
destaque na comunicao entre equipes esto: mensagens instantneas, voz sobre IP, telefonia
convencional e videoconferncia. (PEARLMAN, 2006)
Com a evoluo constante de meios de comunicao e com o surgimento de cada vez
mais tecnologias de transmisso de informaes, podemos assumir que o fator comunicao
tem deixado de ser uma dificuldade quando o assunto uma equipe de desenvolvimento
remotamente distribuda.

2.2.2.4. Controle

No desenvolvimento de software, uma das principais dificuldades enfrentadas por
qualquer equipe de desenvolvimento e seus respectivos gerentes de projeto o controle do
andamento dos trabalhos.
Diversas formas, mtodos e refinamentos aparecem todos os anos com o intuito de
auxiliar no processo de controle do que est sendo desenvolvido, das atividades das equipes e
de mostrar aos clientes e demais reas das empresas a situao atual de seus projetos.
Essa dificuldade existe em equipes que trabalham na mesma sede, mas so
potencialmente mais visveis quando as equipes esto distribudas, visto que cada vez mais os
processos e mtodos de controle existentes levam em considerao a presena e a
proximidade dos profissionais para que os relatrios de andamento sejam repassados e ajustes
feitos nos processos visando ao aumento constante da produtividade. (PEARLMAN, 2006;
SUTHERLAND et al, 2007)

2.2.2.5. Liderana

Toda equipe de desenvolvimento de software possui lderes de projetos responsveis
pelo direcionamento dos projetos, rotinas e mtodos das equipes que esto envolvidas no
desenvolvimento. (PROJECT MANAGEMENT INSTITUTE, 2008)
Segundo Sutherland et al (2007) e Berczuk (2007), a liderana em equipes
remotamente distribudas possui uma caracterstica de diluio, muitas vezes tendo a falsa
impresso de sua inexistncia ou de que ela existe mas no est inteiramente envolvida com o
projeto em si.
Em toda relao entre pessoas envolvidas em um projeto, o lder aquela pessoa que
guia o restante do time para o objetivo comum a ser alcanado, potencialmente um dos
membros dotados de grande carisma, caracterstica essencial para se conquistar seguidores.
(PEARLMAN, 2006; SUTHERLAND et al, 2009)
A liderana em equipes distribudas deve tambm ser distribuda, de forma que cada
centro de desenvolvimento (localidade remota) tenha o seu prprio lder local, que deve estar
em constante ateno ao seu time de desenvolvimento e tambm diretamente relacionado com
as atividades da sede da empresa, a fim de que a liderana exercida na sede seja replicada
atravs de todas as localidades de desenvolvimento distribudas. (SUTHERLAND et al, 2007;
PEARLMAN, 2006)

2.2.2.6. Confiana

De acordo com Sutherland et al (2008) e Pearlman (2006), a confiana entre os
profissionais de uma equipe de desenvolvimento primordial para que se atinja os objetivos
do projeto que est sendo desenvolvido.
Por confiana, segundo os autores, podemos entender como sendo a clareza dos
objetivos a serem alcanados, o nvel de conforto dos membros dos times, o grau de
envolvimento com os resultados, entre outros motivos.
Ainda segundo os autores, a principal dificuldade em se atingir estes nveis desejados
est relacionada com a comunicao, item primordial para a execuo de qualquer projeto de
desenvolvimento de software, citado anteriormente. Quando o nvel de comunicao no
satisfatrio, ou quando ela simplesmente no ocorre, os profissionais envolvidos nas equipes
principalmente remotas tendem a perder a sua confiana no projeto e no seu papel dentro do
mesmo.

2.2.2.7. Tcnica

Todo projeto de desenvolvimento de software envolve diferentes pessoas, cada uma
com a sua prpria tcnica de desenvolvimento de software, e com seus determinados nveis de
domnio e conhecimentos sobre as mesmas. O processo de criao de software puramente
intelectual e inerente a cada individuo. (PATTERNS and Practices for Distributed Teams, on-
line)
Da mesma forma que cada indivduo possui a sua tcnica, o projeto tambm apresenta
sua caracterstica principal que moldada conforme as tcnicas dos indivduos envolvidos no
processo de desenvolvimento.
De acordo com Pearlman(2006), a tcnica dos membros das equipes de
desenvolvimento remoto importante, mas no to importantes quanto a personalidade dos
indivduos, que precisam ser flexveis quanto ao seu mtodo de codificao ou realizao das
suas atividades.
Ao se imaginar um projeto que consiste na gerao de muitas linhas de cdigo, um
padro deve ser estabelecido (caracterstica principal do cdigo) e todos os membros devem
ter a possibilidade de adaptabilidade de acordo com a maioria dos outros membros ou de
acordo com padres impostos sobre o cdigo principal do projeto que est sendo codificado.
(SUTHERLAND et al, 2007; SUTHERLAND et al, 2009)

2.2.2.8. Segurana da informao

Em muitos casos de desenvolvimento de software, o contedo ou codificao que est
sendo gerada pode conter informaes crticas das empresas patrocinadoras do projeto, ou
pode ainda conter segredos de mercado ou tcnicas que podem evidenciar dados ou
informaes sigilosas.
Quando falamos em equipes de desenvolvimento remotamente distribudas, fica
implcita a necessidade de transmisso constante de informaes entre as equipes de
desenvolvimento e a sede da empresa, que podem conter dados sigilosos conforme os
descritos anteriormente.
Para Pearlman (2006), uma das principais caractersticas no processo de
desenvolvimento com equipes remotamente distribudas a facilidade de uso de novas
tecnologias que permitem a constante troca de informaes entre os diferentes membros das
equipes, possibilitando assim um aumento cada vez maior de proximidade entre os membros
independente da distncia fsica entre estes mesmos indivduos.
J segundo Sutherland et al (2007), uma das maiores preocupaes envolvidas com as
equipes remotas est relacionada com a forma e segurana como as informaes e cdigos so
transmitidas e trocadas entre os diferentes membros das equipes. Inclusive, so citadas formas
de controles bem rgidos como sendo pr-requisitos na implantao de equipes remotas como
meio de garantir o sigilo e integridade das informaes trocadas.
Com base em diferentes opinies e critrios, podemos afirmar que a segurana da
informao um fator relacionado primariamente cultura da empresa que est adotando o
desenvolvimento remotamente distribudo e tambm com a cultura e responsabilidade dos
membros envolvidos com o projeto como um todo.




2.3. USO DE SCRUM

Todo processo de desenvolvimento de software exige uma forma de controle, mtodos
e processos para que se atinjam os devidos resultados dentro do oramento e prazo
planejados. (PROJECT MANAGEMENT INSTITUTE, 2008)
Independente dos fatores que fazem com que empresas busquem economia ou mo-
de-obra em localidades diferentes de suas sedes para a execuo de seus projetos de
desenvolvimento de software, todo projeto necessita das mesmas formas de controles,
mtodos e processos citados acima.
O Scrum tem sido cada vez mais adotado por equipes de desenvolvimento com muito
sucesso, aumentando a produtividade e qualidade dos projetos envolvidos. (SEVERINO,
2009; LOYOLA; PINHEIRO, 2010)
Segundo Filho e Alves (2010) o uso do Scrum visa principalmente a interao e
proximidade entre os profissionais dos times para que o sucesso possa ser atingido.
Analisando um cenrio onde os membros dos times de desenvolvimento esto remotamente
distribudos, tais caractersticas podem no estar presentes, o que pode causar rupturas nos
mtodos e processos que so as bases da metodologia Scrum.
Para que os pilares da metodologia e todo o ritual que o Scrum necessita sejam
mantidos, faz-se necessria uma anlise mais aprofundada da forma como o Scrum pode ser
aplicado em projetos contendo pessoas separadas fisicamente umas das outras.
De acordo com Sutherland et al (2007, 2009) podemos dividir equipes de
desenvolvimento remotos que utilizam Scrum em trs modelos de Scrum principais: Scrum
isolado, Scrum distribudo e Scrum integrado.
No modelo de Scrum isolado, considera-se que as equipes remotamente distribudas
utilizam o Scrum com seus mtodos e processos de forma autnoma, sem que uma interaja
com a outra. Seguindo esse princpio, cada equipe possui sua prpria forma de trabalho, ritmo
de Sprints, fluxos de reunies e Backlogs separados, sem relao direta com outros times de
desenvolvimento. Analisando esse modelo, podemos concluir que se trata praticamente de
subprojetos de um projeto maior, em que cada equipe, com seu prprio backlog, trabalha de
forma completamente isolada e sem nenhuma interdependncia.
J no modelo de Scrum distribudo, ainda segundo Sutherland et al (2007, 2009), h
uma diviso de trabalho (histrias) distribudo entre diferentes equipes de desenvolvimento
separadas umas das outras, mas interligadas atravs da figura do ScrumMaster de cada uma
das equipes, que so responsveis pela integrao entre os membros dos diferentes times de
desenvolvimento. Nesse modelo, h uma maior integrao entre os membros das diferentes
equipes, devido ao fato de que h a necessidade de comunicao constante em funo da
dependncias entre histrias que so assumidas por diferentes equipes. Do ponto de vista de
organizao do Scrum, temos nesse modelo um nico backlog, que compartilhado entre
todas as equipes, mas cada equipe pode ou no ter o seu prprio ritmo de desenvolvimento
sem relao direta com outras equipes.
Finalmente, no modelo de Scrum integrado, ainda segundo Sutherland et al (2007,
2009), podemos observar que diferentes membros de uma mesma equipe esto distribudos,
assim como as equipes. Existe a possibilidade de que membros de diferentes equipes possam
estar trabalhando numa mesma localidade, ou at mesmo que duas ou mais equipes possam
estar trabalhando de forma particionada e divididas em diferentes regies. No h uma regra
especfica para esse modelo. A sua principal caracterstica que as diferentes equipes acabam
sendo especializadas em determinadas funes dentro da cadeia de desenvolvimento, e assim,
cada equipe passa a ser responsvel por uma parte de uma histria comum a todas as equipes.
Analisando esse ponto de vista, podemos subentender que nesse modelo temos uma grande
quantidade de profissionais, divididos em diversas equipes de desenvolvimento, trabalhando
em um mesmo conjunto de histrias e fazendo parte de um ecossistema de desenvolvimento
maior (o projeto em si). A sua diviso passa, ento, a ser por tipos e nveis de proficincia de
cada equipe, cada uma responsvel pela concretizao de uma pequena parte do todo.
Seja qual for o modelo de Scrum distribudo, h de se analisar as caractersticas
especficas do Scrum e como essas caractersticas necessitam ou no de ajustes para
funcionarem de forma plena tendo profissionais distribudos juntos ou no com suas
respectivas equipes. Segundo uma anlise de Berczuk (2007), uma distribuio de equipes
utilizando Scrum amplifica todo e qualquer pequeno problema ou dificuldade que o processo
do Scrum em si pode ter em relao aos membros das equipes e com o projeto em questo,
sendo ento necessrios ajustes constantes no trabalho e na forma como os profissionais
atuam sub tais circunstncias.
Fatores culturais tambm devem ser levados em considerao, principalmente quando
as equipes esto distribudas em localidades muito distintas. H de se considerar,
principalmente, a lngua nativa de cada localidade, quando falamos em equipes em pases
distintos, sendo que essa deve ser uniforme e de comum entendimento entre todos os
membros. Sutherland et al (2009) aponta como a lngua sendo um dos maiores obstculos
para uma plena comunicao entre os diversos profissionais envolvidos nos projetos.
Ainda sobre o fator cultural, podemos destacar a afirmao de Sutherland et al (2009)
de que indivduos de pases diferentes podem ter hbitos e formas de pensamento diferentes
sobre o projeto e sobre as atitudes profissionais. Em seu estudo, recomenda-se que haja uma
integrao gradual entre os diferentes profissionais, seja atravs de aproximao local via
transferncia temporria de membros entre as equipes, seja atravs de constantes incentivos
de participao em reunies remotas, de forma que haja uma maior troca cultural para que no
existam diferenas entre os membros.

2.3.2. Reunies

Assim como descrito anteriormente, cada nova iterao do Scrum (Sprint) possui uma
srie de reunies, que vo desde o planejamento (Estimation e Planning), at a sua concluso
(Review e Retrospective), passando pela fase principal de execuo, em que so feitas as
reunies dirias (Daily Meeting).
Como um dos pilares do Scrum est constitudo na comunicao e interao entre os
profissionais de uma mesma equipe, podemos assumir que as reunies so um dos principais
pontos de ateno, j que so nelas que ocorrem as principais interaes entre os membros.
Ao analisar um cenrio no qual os profissionais das equipes esto remotamente
distribudos, ou at mesmo em diferentes equipes de desenvolvimento, deve sempre haver
uma forma clara e ampla de comunicao entre os seus integrantes, principalmente nas
reunies que fazem parte dos rituais do Scrum.
Pearlman (2006) prope que diversos mecanismos de comunicao podem e devem
ser utilizados em ambientes com profissionais trabalhando remotamente, principalmente
tendo em vista a evoluo tecnolgica e a diminuio constante de custos para que tal
comunicao ocorra.
Segundo anlise de Sutherland et al (2007, 2009) todos os rituais do Scrum podem ter
o mesmo efeito de uma equipe reunida numa mesma localidade contanto que haja o
comprometimento de todos os membros envolvidos, e desde que todo o suporte tecnolgico
esteja presente, seja ele na forma de videoconferncias, comunicao telefnica, ou qualquer
outro meio que seja em tempo real. Percebe-se tambm que, quando os membros das equipes
tm a possibilidade de verem uns aos outros, o fluxo e resultado de todos os rituais tendem a
ser praticamente os mesmos que os de uma equipe localmente reunida.
Assim como descrito anteriormente, o fator cultural pode ser um fator de dificuldade
entre os membros de equipes muito distantes. Na anlise de Sutherland et al (2009), por
exemplo, indivduos de trs diferentes pases (Alemanha, ndia e Holanda) possuem formas
de tratamento profissionais e pessoais bem distintas. Enquanto na Alemanha os profissionais
tendem a serem diretos e falarem alto, na ndia os profissionais tendem a um comportamento
mais cauteloso. J na Holanda, h mais o conceito de hierarquia tradicional de trabalho do que
nos outros pases que adotam o Scrum e seu conceito de auto gerenciamento. Podemos ento
assumir que os ScrumMasters, no seu papel de facilitador, tenha que intervir de forma
constante na comunicao, principalmente mas reunies do Scrum, de forma a minimizar as
diferenas culturais de suas equipes.

2.3.3. Controle de informaes

Por se tratar de projetos de desenvolvimento de software, onde a tecnologia em si est
em constante uso, o controle e compartilhamento de informaes entre os diversos membros
das equipes remotamente distribudas tende a no ser um fator de dificuldade. H de se
observar, no entanto, que a infraestrutura necessria para que se obtenha o mximo de
produtividade na transmisso e recepo de informaes seja bem planejada e esteja
disponvel sem interrupes a todas as equipes envolvidas no projeto.
No processo de desenvolvimento de software, comum a prtica de uso de sistemas
para controle de verses de cdigo e repositrios centrais de informaes para documentos.
Berczuk (2007) e Sutherland et al (2007, 2009) citam em suas experincias que uma base
tecnolgica para compartilhamento e controle de informaes deve existir e ser slida para
que no cause impactos no processo de comunicao.
Podemos assumir, portanto, a necessidade de termos um ambiente estvel, de alta
performance, e principalmente uniforme entre todas as equipes de desenvolvimento que
estejam envolvidas no projeto, sejam essas equipes locais e prximas, sejam elas distantes e
remotamente distribudas.

2.3.4. Ferramentas de auxlio

Num processo de desenvolvimento de software utilizando Scrum, o enfoque principal
est relacionado com a interao entre os membros das equipes de desenvolvimento, sendo
esse um dos pilares das metodologias geis. O mesmo enfoque deve ser dado para as equipes
que esto remotamente distribudas, pois trata-se da mesma metodologia. Por outro lado, h
de se considerar que a distncia pode causar algumas rupturas na metodologia se todos os
membros no estiverem com o mesmo objetivo em mente. Apesar de ser funo do
ScrumMaster zelar pela adoo e manuteno da metodologia, pode-se tornar necessria a
adoo de ferramentas e sistemas que facilitem o cotidiano de uma equipe que trabalha com
Scrum remoto.
Como sugerido por Pearlman (2006), o atual cenrio de desenvolvimento de software
possui diversas facilidades ao alcance das equipes de desenvolvimento. Quando necessrio,
ou at mesmo til, pode-se utilizar essas ferramentas como forma de facilitao nas relaes
cotidianas. Deve-se, no entanto, atentar para que a sua adoo no infrinja os preceitos e
rituais da metodologia.
Observa-se atravs do estudo de Sutherland et al (2009) que um processo de
implantao de uma equipe de desenvolvimento remoto tende a necessitar de ajustes nos
primeiros dois Sprints de trabalho remoto, onde se observa como acontecem as relaes entre
os membros e principalmente quais as deficincias e como estas deficincias podem ser
solucionadas atravs da adoo de sistemas e formas de controle extras ao Scrum.
Uma prtica comum a Sutherland et al (2009) e Berczuk (2007) se refere adoo de
uma ferramenta especfica denominada ScrumWorks para a gerao e compartilhamento
eletrnico do SprintBacklog, que consiste basicamente no quadro de tarefas do Sprint
corrente. Tambm adota-se o conceito de compartilhamento do Burndown Chart entre as
equipes, porm de formas distintas, mas igualmente satisfatrias: enquanto Sutherland et al
(2009) cita que as equipes fazem uma impresso diria do seu Burndown Chart, gerado
atravs da ferramenta ScrumWorks, Berczuk (2007) cita que a adoo escolhida em seu
estudo foi a de reconstruo diria do Burndown Chart em quadros das equipes de forma
simultnea, de forma a incentivar a comunicao e compartilhamento de informaes entre os
diferentes escritrios.
Apesar da forma de evidenciao escolhida, tanto do SprintBacklog quanto do
Burndown Chart, podemos observar nos dois casos acima que a maior preocupao a de
sempre manter os rituais e mtodos de controles que so premissas da metodologia Scrum.
Para as reunies de Daily Meeting, Sprint Review, Retrospective, Sprint Planning e
Estimative, Pearlman (2006) cita como sendo o cenrio ideal um apanhado de tecnologias que
permitem a comunicao e interao entre os membros, porm no cita nenhuma em
especfico, pois as equipes devem ser auto suficientes para as escolhas que fazem com que se
sintam mais confortveis e produtivos, cabendo ao ScrumMaster apenas assegurar que as
escolhas no infrinjam a metodologia. J segundo Sutherland et al (2009) e Berczuk (2007), a
forma de comunicao atravs de ferramentas deve ser uma deciso em um nvel mais do
ScrumMaster, podendo ou no consultar os membros das equipes, mas que a sua deciso a
mais importante.
Assim como no item anterior, podemos tambm observar a importncia em sempre
procurar manter os rituais e mtodos do Scrum, independente da forma e tecnologia que
venha a ser utilizada para a comunicao entre os diversos membros das equipes de
desenvolvimento remotas.
O uso de tecnologias pode ser observado, atravs da anlise da literatura, de forma
ampla e benfica, contanto que no se interfira de forma a alterar a metodologia Scrum, j que
a metodologia em si possui rituais, mtodos e processos muito bem definidos e qualquer
alterao na forma de trabalho poderia acarretar em dificuldades maiores. Repara-se tambm
que em nenhum momento, a literatura cita a alterao da metodologia, mas apenas que
ferramentas de auxlio e suporte existem e suas adoes tendem a ser sempre benficas.


4. METODOLOGIA

Este artigo composto de uma pesquisa bibliogrfica, cujo tema inicial foi definido
em funo de experincia profissional do seu autor, que procurou atravs de referencias na
rea demonstrar as capacidades de utilizao de uma metodologia amplamente utilizada em
seu ambiente profissional (SCRUM) em outros ambientes de trabalho que no o seu habitual.
Conforme Lakatos e Marconi (2003), uma pesquisa bibliogrfica compreende em um
processo de investigao cientfica focada na anlise e interpretao de literatura prvia de
outros autores sub uma nova interpretao.
Ainda sob a anlise de Lakatos e Marconi (2003), a fonte para a escolha do assunto
de livre escolha do autor, tendo geralmente grandes influncias em experincia profissional
ou pessoal, leituras prvias, observaes, entre outros. O tema principal deste artigo foi
determinado em funo da experincia profissional do autor em conjunto com observaes
sobre padres de projetos de desenvolvimento de software.
Procurou-se durante o seu desenvolvimento, a criao de um levantamento
bibliogrfico atravs da identificao aprofundada dos temas envolvidos, a localizao dos
materiais e a sua compilao.
Aps todo o processo de levantamento feito, foi necessrio um cruzamento das
informaes, que por ora possuam divergncias de pontos de vista entre os autores.
Pde-se ento, aps toda a anlise inicial dos assuntos, desenvolver em detalhes a
explanao das ideias e cruzamento de informaes, efetuando-se sempre uma anlise crtica
aos contedos apresentados pelos diferentes autores.


5. APRESENTAO E ANLISE DOS DADOS

Durante o processo de desenvolvimento deste artigo, houve a oportunidade de
obteno de relatos de experincias de um profissional ligado rea de desenvolvimento de
software que utiliza Scrum como metodologia principal e que est implementando um
processo de gesto de equipes remotas de Scrum. A identidade, empresa que trabalha e
detalhes da forma de implementao no foram autorizadas para divulgao neste trabalho.
Em seu relato sobre a implementao deste modelo de gesto de equipes remotas com
Scrum, foram confirmadas diversas das dificuldades apresentadas por outros autores
pesquisados neste artigo, com a exaltao do fator comunicao como sendo o ponto mais
crtico de ateno e ajustes.
Conforme explicado pelo profissional, a distncia entre os membros das equipes gera
muitos rudos de comunicao, mas que esse fator est diretamente relacionado ao perfil
profissional de cada membro das equipes que compem o time de desenvolvimento. Foi
relatado, a ttulo de exemplo, que um determinado profissional possui muito mais propenso
ao entendimento incorreto em uma comunicao distncia do que os demais profissionais,
enquanto que h casos de entendimento sem rudos em relao a outros profissionais.


6. CONSIDERAES FINAIS

Atravs desta anlise de literatura, em conjunto com os relatos oferecidos por
profissional qualificado na rea de projetos de software que utiliza Scrum, podemos afirmar
que a metodologia gil Scrum uma metodologia amplamente adotada em diferentes escalas
de desenvolvimento de software, alm de ser muito bem empregado e com alto nvel de
maturidade quando as equipes de desenvolvimento so voltadas para a produo de software
para internet.
Pode-se tambm concluir que a sua adoo e seu sucesso deve-se principalmente ao
fator humano dos projetos, pois parte dos membros de suas equipes a motivao necessria
para que a adoo de forma plena e produtiva ocorra. Assim como diversas outras
metodologias de desenvolvimento de software, h no Scrum pontos de ateno que devem ter
os devidos cuidados, mas que em funo do seu dinamismo e alta capacidade de resposta a
mudanas, podem ser facilmente corrigidos e contornados.
Conclui-se que a adoo do Scrum em equipes de desenvolvimento de software para
internet pode ser amplamente adotado, tendo os mesmos benefcios e caractersticas de uma
equipe alocada, contanto que se observem alguns detalhes e tenha-se a preocupao de
garantir que a metodologia est sendo amplamente adotada, que as barreiras culturais sejam
vencidas e que, acima de tudo, garanta-se que a comunicao e interao, que so premissas
do Scrum, ocorram de forma transparente e sem empecilhos, garantindo assim o sentimento
de que os membros integrantes das equipes de desenvolvimento fazem parte de um nico
projeto de desenvolvimento de software.
6. REFERENCIAS BIBLIOGRFICAS

BERCZUK, S. Back to Basics: The Role of agile Principles in Success with a Distributed
Scrum Team. In: Proceedings of the Conference on Agile 2007. Washington D.C.: IEEE
Computer Society; 2007.

COHN, M. Agile Estimating and Planning. 1
a
ed. Upper Saddle River, New Jersey: Prentice
Hall; 2006.

FILHO, A. C. O.; ALVES A. L.
oinia
Pontifcia niversidade atlica de ois 200

HUNDERMARK, P. Do Better Scrum. Disponvel em: <http://www.scrumsense.com/wp-
content/uploads/2009/12/DoBetterScrum-v2.pdf>. Acesso em: 23 de agosto de 2013.

LAKATOS, E. M.; MARCONI, M. A. Fundamentos da Metodologia Cientfica. 5
a
ed. So
Paulo: Atlas; 2003

LOYOLA, K. D.; PINHEIRO, N. D.

Otoni [trabalho de concluso de curso]. Tefilo Otoni: Faculdades Unificadas DOCTUM;
2010.

MANIFESTO for Agile Software Development nternet isponvel em
<http://www.agilemanifesto.org/>. Acessado em: 23 de agosto de 2013.

OBSERVATRIO Nacional [Internet]. Disponvel em: < http://pcdsh01.on.br >. Acessado
em: 04 de setembro de 2013.

PATTERNS and Practices for Distributed Teams [Internet]. Disponvel em:
<http://blogs.msdn.com/b/jmeier/archive/2009/11/23/patterns-and-practices-for-distributed-
teams.aspx>. Acessado em: 23 de agosto de 2013.

PEARLMAN, S. Leading Without Seeing: managing distributed teams [Internet].
Disponvel em: <http://www.slideshare.net/shanepearlman/leading-without-seeing-managing-
distributed-teams>. Acessado em: 23 de agosto de 2013.

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of
Knowledge. 4
a
ed. Pennsylvania: Project Management Institute. 2008.

SANTANA, K. F. G.; FREITAS, R. A. Desenvolvimento gil: Uma Abordagem Sobre o
Scrum. [local desconhecido]: [editor desconhecido]; 2011.

SCRUM (development) Wikipedia, the free encyclopedia [Internet]. Disponvel em:
<http://en.wikipedia.org/wiki/Scrum_(development)>. Acessado em: 04 de setembro de 2013.

SEVERINO, L. J. O Poder do PMBOK no Gerenciamento de um Projeto Scrum [trabalho
de concluso de curso]. Londrina: Universidade Estadual de Londrina, Departamento de
Computao; 2009.

SUTHERLAND, J. et al. Distributed Scrum: Agile Project Management with Outsourced
Development Teams. In: HICSS'40: Proceedings of Hawaii International Conference on
Software Systems. Big Island, Hawaii: IEEE Computer Society; 2007.

SUTHERLAND, J. et al. Distributed Scrum: The Secret Sauce for Hyperproductive
Offshored Development Teams. In: Proceedings of Agile 2008 Conference. Toronto: IEEE
Computer Society; 2008.

SUTHERLAND, J. et al. Fully Distributed Scrum: Replicating Local Productivity and
Quality with Offshore Teams. In: HICSS'42: Proceedings of Hawaii International
Conference on Software Systems. Big Island, Hawaii: IEEE Computer Society; 2009.

THE Official US time (NIST & USNO) [Internet]. Disponvel em: <http://www.time.gov>.
Acessado em: 04 de setembro de 2013.