Metodologias Ageis

163
Revista de Cincias
Exatas e Tecnologia
Vol. IV, N. 4, Ano 2009
Kenji Taniguchi
Faculdade Anhanguera de Taubat
kenji@kenji.com.br
Fernando Eugenio Correa
Faculdade Anhanguera de Taubat
eugenio.fec@gmail.com

METODOLOGIAS GEIS E A MOTIVAO DE
PESSOAS EMPROJETOS DE DESENVOLVIMENTO
DE SOFTWARE
Aplicando prticas de SCRUM e XP para promover a
motivao de equipes de projetos de desenvolvimento
de software
RESUMO
Este artigo tem o objetivo de apresentar as caractersticas existentes nas
metodologias geis que podem ser trabalhadas para aumentar a
motivao da equipe. Conhecendo as exigncias atuais do mercado, as
estruturas organizacionais e os dois tipos distintos de desenvolvimento
atuais, um totalmente anrquico e outro totalmente focado em controle
(representado pelas metodologias tradicionais), sero apresentadas as
fragilidades e problemas atualmente conhecidos. Estes fatores geram
desconforto e insatisfao nos desenvolvedores que no se sentem
comprometidos ou motivados com suas atribuies. Com estes fatores
em mente, os mtodos geis so apresentados e dois deles, SCRUM e
eXtreme Programming, tm suas prticas estudadas de forma a
apresentar como estas podem ser trabalhadas para focar ainda mais as
pessoas de forma a aumentar seu comprometimento e motivao,
fazendo que os indivduos envolvidos sintam-se parte das tomadas de
deciso do projeto.
Palavras-Chave: SCRUM; eXtreme Programming; metodologias geis.
ABSTRACT
This article aims to present the features found in agile methodo-logies
that can be applied to increase the motivation of the team. Knowing the
current requirements of the market, the organizational structures and
the two distinct types of current development, one totally anarchic and
the other totally focused on control (represented by the traditional
methods), will be presented the weaknesses and problems currently
known. These factors generate discomfort and dissatisfaction in
developers who do not feel motivated or committed to its mission. With
this factors in mind, the agile methods are presented and two of them,
SCRUM and eXtreme Programming, have their practices studied to
present how these can be applied to focus even more on people in order
to increase their commitment and motivation, making the individuals
involved feel part of decision making phase of the project.
Keywords: SCRUM; eXtreme Programming; agile methodologies.

Anhanguera Educacional
Correspondncia/Contato
Alameda Maria Tereza, 2000
Valinhos, So Paulo
CEP 13.278-181
rc.ipade@unianhanguera.edu.br
Coordenao
Instituto de Pesquisas Aplicadas e
Desenvolvimento Educacional - IPADE
Informe Tcnico
Recebido em: 20/04/2010
Avaliado em: 15/07/2010
Publicao: 21 de dezembro de 2010
164 Metodologias geis e a motivao de pessoas em projetos de desenvolvimento de software
Revista de Cincias Exatas e Tecnologia Vol. IV, N. 4, Ano 2009 p. 163-179
1. INTRODUO
Vive-se um novo paradigma econmico que estabelece a necessidade de atualizao
contnua, da preocupao com a satisfao do cliente e da gerao de produtos e servios
de maior valor agregado (BECKER, HUSELID, ULRICH, 2001).
Hoje, mais do que as tecnologias que uma empresa possui, o conhecimento a
chave para agregar valor aos seus produtos e servios. Neste cenrio, as empresas
necessitam cada vez mais do conhecimento, comprometimento e motivao de seus
funcionrios (SPNOLA, 2008).
No entanto, um dos grandes desafios o de manter equipes motivadas e
comprometidas, baseando-se nas metodologias tradicionais de gerenciamento de projetos
de desenvolvimento de software. A aplicao das metodologias tradicionais tm resultado
em no cumprimento de prazo de entrega, escopo no atendido, grande quantidade de
erros, funcionalidades desnecessrias, descontentamento por parte do cliente entre outros
problemas (CAMPOS, FONSECA, 2008).
Com a proposta de desenvolver projetos de uma maneira capaz de responder
rpido s mudanas, com foco nas pessoas e na colaborao com o cliente, surgiram as
metodologias geis que, devido s suas caractersticas, possibilitam gerar produto com
maior valor agregado e ao mesmo tempo manter pessoas motivadas dentro das
corporaes (AKITA, 2009).
Para entender como a aplicao de metodologias geis pode aperfeioar a
qualidade do produto e tambm promover a motivao das equipes, necessrio efetuar,
ao menos, uma rpida avaliao das estruturas organizacionais e como estas afetam direta
ou indiretamente a gesto dos projetos e os indivduos envolvidos, alm disso, deve-se
efetuar a anlise baseada na viso que se tem atualmente de projeto e das metodologias
utilizadas (tradicionais e geis) e como proceder com o uso conjunto de algumas prticas
geis, visando a meta do projeto e a motivao dos indivduos.
2. CENRIO ATUAL DAS EMPRESAS DE DESENVOLVIMENTO DE SOFTWARE
No ambiente atual, intensamente competitivo, a busca por melhorar a qualidade do
produto entregue, respondendo a mudanas e satisfazendo o cliente, tem se tornado uma
meta e uma necessidade para as organizaes.
Para alcanar esse objetivo, necessrio um conjunto de atividades e tarefas que
aps sua aplicao sistemtica, resultem em software funcional. A esse conjunto de tarefas,
Kenji Taniguchi, Fernando Eugenio Correa 165
atividades e processos d-se o nome de metodologia de desenvolvimento de software (BASSI,
2009).
A gesto de um projeto de desenvolvimento de software cabe, muitas vezes, a
um gerente de projetos ou a uma equipe de gerenciamento de projetos. Esta pessoa ou
equipe tem a responsabilidade de determinar qual o melhor conjunto de boas prticas
para um projeto especfico (HELDMAN, 2006).
3. ESTRUTURAS ORGANIZACIONAIS
Cada organizao nica, possuindo cultura e peculiaridades prprias, porm, elas
podem ser estruturadas segundo trs modalidades: funcional, por projetos ou matricial.
O modelo de estrutura acaba interferindo no nvel de autoridade que um gerente
de projeto ter dentro da organizao e no comprometimento que os indivduos
envolvidos nos projetos tero com as metas e objetivos do mesmo (HELDMAN, 2006).
3.1. Organizaes Funcionais
Esta a estrutura organizacional mais comum e antiga dos trs modelos, tambm sendo
conhecida como estrutura tradicional (HELDMAN, 2006). Neste modelo organizacional,
as equipes so formadas em torno de suas especialidades e funes, sendo administradas
pelos respectivos gerentes de cara rea, estes chamados de gerentes funcionais.
Considerando o escopo de projetos, este tipo de organizao apresenta algumas
desvantagens muito claras gerncia. Pode-se destacar a clara falta ou ausncia de
autoridade do gerente de projeto, assim como o fator de que em projetos de
desenvolvimento de software tem-se a necessidade de formar equipes multidisciplinares,
o que no algo muito fcil de administrar dentro de uma estrutura funcional, pois os
indivduos tendem a manter comprometimento com sua rea e no propriamente com o
projeto (MARTINS, 2002).
3.2. Organizaes por Projetos
Nesta estrutura, o foco da empresa o projeto e suas metas. As diversas reas da empresa
tendem a se comprometer com o projeto.
Para definir projeto deve-se primeiro atentar a duas caractersticas bsicas
(MARTINS, 2002):
Um projeto uma iniciativa nica de alguma forma. Diferenciando assim,
projetos de operaes. O desenvolvimento de um novo jogo para
computador pode ser considerado um projeto, enquanto a gravao deste
em mdias para a venda consiste numa operao.
Projetos possuem um fim definido, ou seja, um objetivo que ao ser
atingido define o final do projeto.
As contrataes e a prpria atividade da rea de recursos humanos vinculada
s necessidades dos projetos, fazendo com que as caractersticas dos profissionais
contratados e mantidos sejam totalmente vinculadas ao que necessrio ao projeto. O
maior problema encontra-se no fato de haver pouco comprometimento com a empresa e
sim com o projeto, no qual os indivduos so, normalmente, contratados para desenvolver
o projeto ou mesmo uma determinada fase do mesmo.
Este ambiente focado no projeto tende a ser desestimulante para as pessoas que
visam crescimento profissional dentro da organizao (HELDMAN, 2006).
Como as equipes so formadas em torno de um projeto, a relao entre elas
de curta durao, podendo ainda haver realocao devido necessidade das
caractersticas de determinado perfil em outro projeto mais importante para a empresa
(MARTINS, 2002).
3.3. Organizaes Matriciais
Este tipo de organizao baseia-se na fuso de caractersticas da estrutura funcional com a
estrutura por projetos. As organizaes matriciais surgiram como meio de minimizar os
pontos negativos das organizaes por projetos e das funcionais e trabalhar os seus
pontos positivos. Os objetivos do projeto so atendidos e focados, mas mantendo-se a
estrutura hierrquica da empresa (HELDMAN, 2006).
Essa estrutura possibilita ainda o balanceamento de suas caractersticas conforme
a escolha da empresa, tendo-se assim, uma organizao matricial funcional, por projetos
ou balanceada (MARTINS, 2002).
4. EVOLUO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
O software era escrito sem um plano especfico e possua diversas decises de curto prazo.
Este estilo, conhecido tambm como codificao cowboy, no seguia metodologias e era
executado a partir da prpria experincia dos programadores (FOWLER, 2005).
Os ajustes necessrios devidos a novos requisitos ou defeitos encontrados (que
so cada vez mais constantes e de difcil soluo) surgiam com prioridade urgente,
gerando presso e stress, implicando em horas extras, desgaste fsico e mental. Este
desgaste acaba colaborando para a baixa qualidade e confiabilidade do software
desenvolvido e gerando, principalmente, a desmotivao da equipe.
Como alternativas para essa ausncia de prticas, surgiram as metodologias
tradicionais, que primam pelo controle e tm como objetivo transformar o
desenvolvimento de software em algo previsvel e mais eficiente. Utilizando processos
detalhados e que enfatizam o planejamento e documentaes.
Apesar de ter como objetivo a eficincia, estas metodologias no tm alcanado
suas metas ao longo dos anos de sua aplicao. A maior crtica s metodologias
tradicionais o fato de serem extremamente burocrticas e com elevado nmero de etapas
que no agregam valor ao produto (FOWLER, 2005).
Apesar da previsibilidade ao longo de um projeto ser um fator muitssimo
desejado, em desenvolvimento de software isso no , normalmente, uma realidade.
Segundo Fowler (2005), todo desenvolvedor tem o cliente como seu grande inimigo, pois
este nunca sabe o que realmente quer. Devido a este pensamento as metodologias
tradicionais buscam descrever da forma mais completa possvel os requisitos do software
e documentar todas as funcionalidades solicitadas antes do incio do desenvolvimento
para que, a partir disto, tenha-se uma ferramenta de proteo para as futuras mudanas
que (certamente) ocorrero (FOWLER, 2005).
Tratando o desenvolvimento de software como um trabalho emprico, dificilmente
seria possvel planejar desde o incio todos os requisitos e todas as funcionalidades que
realmente sero necessrias e teis.
O processo Waterfall (ou Cascata) simboliza muito bem o padro das
metodologias tradicionais. Este modelo caracterizado por fases muito bem definidas e
que a sada da fase anterior gera o produto de entrada da fase posterior. Ao trmino de
cada etapa associada uma documentao que deve ser aprovada para que tenha incio a
prxima fase (ROYCE, 1970). As etapas que compem o processo podem diferir um
pouco, porm o padro documentado em 1970 por Royce cita os seguintes passos:
Requisitos do Sistema, Requisitos de Software, Anlise, Design, Codificao, Testes e
Implantao, conforme apresentado na Figura 1.

Figura 1 Modelo Waterfall adaptada de Royce (1970).
Ao documentar o processo, mesmo confiando na ideia do mesmo, j foram
verificadas suas deficincias Eu acredito neste conceito, mas a aplicao descrita
arriscada e um convite a falhas (ROYCE, 1970, p. 2).
Conhecidas inicialmente como metodologias leves, as metodologias geis
surgiram como uma resposta necessidade de mudanas na forma de gerir projetos de
desenvolvimento de software e os processos envolvidos nestes projetos.
A principal diferena a citar entre os mtodos geis e os mtodos tradicionais o
conceito de simplicidade ou do mnimo necessrio, ou seja, ao invs de usar um enorme
conjunto de processos, busca-se iniciar um projeto com o uso do menor volume de
processos possvel e, conforme a necessidade, novos procedimentos devem ser includos
(TELES, 2005, p. 53).
Em 2001 reuniram-se 17 metodologistas para analisar o que eles estavam fazendo
de diferente em seus projetos para atingir os resultados que estavam obtendo. Desta
reunio, que tinha como meta a definio de uma metodologia que unificasse as prticas
que estavam sendo discutidas, resultou num conjunto de valores e princpios, sendo
conhecido como Manifesto gil (BECK, et al., 2001).
So quatro os valores dos mtodos geis:
Indivduos e interaes entre eles mais que processos e ferramentas.
Software funcionando mais do que documentao abrangente.
Colaborao com o cliente mais do que negociao de contratos.
Responder a mudanas mais que seguir um plano.
Isto no quer dizer que os itens direita no possuem valor, e sim que os da
esquerda possuem mais valor.
A partir do conhecimento dos valores, podem-se citar os doze princpios das
metodologias geis (BECK et al., 2001):
A maior prioridade satisfazer o cliente, por meio da entrega adiantada e
contnua de software de valor.
Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento.
Processos geis se adquam a mudanas, para que o cliente possa tirar
vantagens competitivas.
Entregar software funcionando com freqncia, na escala de semanas at
meses, com preferncia aos perodos mais curtos.
Pessoas relacionadas ao negcio e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivduos motivados, dando a eles o
ambiente e suporte necessrio, e confiar que faro seu trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para - e por
dentro de um time de desenvolvimento - atravs de uma conversa cara a
cara.
Software funcional a medida primria de progresso.
Processos geis promovem um ambiente sustentvel: os patrocinadores,
desenvolvedores e usurios, devem ser capazes de manter,
indefinidamente, passos constantes.
Contnua ateno a excelncia tcnica e bom design aumentam a
agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que no
precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto-
organizveis.
Em intervalos regulares, o time reflete sobre como ficar mais efetivo,
ento, ajustam-se e aperfeioam seu comportamento.
Apesar de todos os princpios acima citados e dos quatro valores, o maior
destaque para a real agilidade consiste em dois pontos principais: metodologias geis
so adaptativas e orientadas s pessoas (FOWLER, 2005).
A partir destes dois pontos principais enaltecidos por Fowler, tm-se duas das
mais conhecidas metodologias geis, SCRUM e eXtreme Programming (tambm
conhecida como XP).
O maior destaque dado atualmente para estas duas metodologias devido ao
fato de que elas podem ser consideradas totalmente compatveis e complementares, pois
SCRUM possui caractersticas voltadas gesto de projetos e das pessoas que esto
includas no mesmo, enquanto XP est mais direcionada gesto dos processos
(KNIBERG, 2007).
4.1. eXtreme Programming (XP)
EXtreme Programming, XP ou programao extrema so as formas que se encontra mais
comumente na literatura uma das metodologias geis mais famosas.
A metodologia gil XP foi criada para equipes pequenas ou mdias de
desenvolvimento de software que tenham que tratar constantemente com requisitos vagos
e em constante mudana (BECK, 1999).
A base da metodologia XP formada por quatro valores: comunicao, feedback,
simplicidade e coragem. Estes valores so completados por 12 prticas (FOWLER, 2005).
Algumas destas prticas, se aplicadas juntamente com outras metodologias,
permitem melhoria de processos e motivao. Alm de citar as referidas prticas, sero
explicados os motivos de sua seleo a seguir (KNIBERG, 2007):
a) Programao em pares: permite cdigo de melhor qualidade, pois recebe
refatorao quase que em tempo de execuo e tambm dissemina parte
do conhecimento entre os membros da equipe, gerando ainda aumento de
produtividade.
b) Desenvolvimento orientado a testes (ou TDD): serve de mecanismo de
proteo, pois atravs do desenvolvimento de testes que podero ser
executados automaticamente, assegura-se que ao desenvolver novas
funcionalidades que sero adicionadas ao sistema, qualquer inconsistncia
seja mais facilmente reconhecida. Esta facilidade na deteco de possveis
inconsistncias d maior segurana aos desenvolvedores.
c) Integrao contnua: poupa tempo e resolve possveis problemas futuros.
Caso algum problema de integrao ocorra este ser facilmente detectado,
pois se trata de um pequeno lote de integrao.
d) Design simples (ou incremental): partindo de um design simples
inicialmente, pode-se efetuar a melhoria contnua do mesmo, permitindo
ainda uma manuteno mais rpida e fcil.
e) Propriedade coletiva do cdigo: facilita manuteno, disseminao de
conhecimento e gera qualidade e simplicidade. Aumenta o
comprometimento da equipe com o projeto e no apenas com um
determinado conjunto de cdigos de sua responsabilidade.
f) Padro de codificao: uma premissa bsica para a propriedade coletiva
do cdigo e para que haja qualidade e facilidade de manuteno. Caso no
haja um padro definido, cada desenvolvedor sempre ter o seu prprio
padro para utilizar.
g) Ritmo sustentvel: trabalhar mais horas gera desgaste fsico e psicolgico,
baixa qualidade no servio efetuado e sintomas destrutveis como
descontentamento e desmotivao na equipe, muitas vezes sem prover
real aumento de produo.
4.2. SCRUM
SCRUM uma metodologia gil que visa fornecer software aos clientes de forma rpida e
com maior qualidade. fundamentada na teoria de controle de processos empricos e
empregando abordagem iterativa e incremental. SCRUM descrito, pelos seus criadores,
como um framework de inspeo e adaptao, dentro do qual possvel aplicar vrios
processos e tcnicas visando o desenvolvimento de produtos complexos, de forma a
aumentar a qualidade e previsibilidade dentro dos projetos (SCHWABER;
SUTHERLAND, 2009).
As metodologias geis foram criadas baseando-se, em boa parte, nas prticas que
davam certo nas empresas japonesas. Influenciadas principalmente pelo conceito de
desenvolvimento enxuto (lean development) de indstrias como Toyota e Honda
(SUTHERLAND, 2007).
Alm dos pais do processo SCRUM, Ken Schwaber e Jeff Sutherland, muitos so
os responsveis pelo conjunto de prticas que existem e so atualmente aplicadas, porm
os padrinhos do SCRUM so Takeuchi e Nonaka, os primeiros a utilizar o termo
(SUTHERLAND, 2007).
Hirotaka Takeuchi e Ikujiro Nonaka explicam em seu artigo (apud
SUTHERLAND, 2007) The New New Product Development Game o conceito de auto-
organizao e de pequenas equipes multidisciplinares e suas vantagens, alm de utilizar
pela primeira vez a referncia de SCRUM do Rugby. Neste mesmo artigo, ainda explicam,
por meio de cases, como configurar uma equipe auto-organizada e o papel da gerncia no
processo.
Com isso pode ser dito que SCRUM nasceu a partir de timas influncias para
atingir com xito a motivao de pessoas, j que tambm tem em suas razes muito das
influncias de gesto do conhecimento, foco de estudo de Takeuchi e Nonaka.
Os trs pilares de SCRUM so:
a) Transparncia: caso algo esteja errado no processo, todos devem ter
conhecimento, nada deve ser escondido ou evitado. E se algum acredita
que algo est pronto, isso deve ser equivalente ao que conta na definio
de pronto.
b) Inspeo: a inspeo deve ser feita de maneira que fatores inaceitveis
qualidade sejam encontrados, porm dentro do limite de que a prpria
inspeo no gere necessidade de nova inspeo.
c) Adaptao: aps inspeo, se necessrio efetuar alterao, esta dever ser
feita e, preferencialmente, o mais rpido possvel para que no gere
desvios futuros.
Como o foco deste artigo est na aplicao de SCRUM com a adio de algumas
prticas de XP para alcanar a qualidade do produto desenvolvido e principalmente a
motivao dos envolvidos, o SCRUM ser explicado com mais detalhes abaixo.
SCRUM formado basicamente por papis, cerimnias e artefatos, tudo isso
mantendo um conceito importante que o de time boxes (SCHWABER; SUTHERLAND,
2009).
Os papis so:
a) Product Owner (PO): o responsvel pelos requisitos e quem tem o
conhecimento do negcio e das reais necessidades do cliente. Tem a
responsabilidade de priorizar e validar os requisitos (SCHWABER;
SUTHERLAND, 2009;
b) SCRUM Master (SM): responsvel por manter o processo SCRUM
funcionando, que todos apliquem as prticas e trabalha como um
facilitador para o time (removendo impedimentos e protegendo-o de
interferncias externas), alm de auxiliar e guiar o Product Owner em suas
tarefas, se isto for necessrio (SUTHERLAND, 2007);
c) Time SCRUM (ou simplesmente Time): formado por pessoas com as
competncias necessrias para transformar os requisitos levantados pelo
PO em um pedao de software potencialmente concludo
(SUTHERLAND, 2007).
A partir destes papis, uma viso prtica que se pode ter em relao ao micro
gerenciamento e macro gerenciamento, se apresentam da seguinte forma:
a) O PO responsvel pelo macro gerenciamento, devido ao conhecimento
do negcio e mantendo a meta a ser atingida que a viso do projeto;
b) o Time responsvel pelo micro gerenciamento, isso devido as suas
caractersticas de auto organizao e multidisciplinaridade, mantendo o
foco na meta estipulada para cada iterao;
c) o SM tem a funo de remover impedimentos que o Time possa ter
durante o projeto e cuidar para que as prticas da metodologia sejam bem
aplicadas.
SCRUM possui trs artefatos principais que permitem o planejamento (Product
Backlog e Sprint Backlog) e gerenciamento (Grfico Burndown) do projeto pelo prprio Time
conforme o mesmo desenvolvido. Estes artefatos so apresentados abaixo:
a) Product Backlog: lista montada e mantida pelo PO e priorizada pelo ROI
(return over investment) sobre tudo que se acredita ser necessrio no
produto.
b) Sprint Backlog: conjunto de tarefas selecionadas pelo Time a partir do
Product Backlog para gerar um subconjunto funcional do software.
c) Grfico Burndown: grfico que demonstra o quanto resta do Backlog em
relao ao tempo disponvel.
As cerimnias em SCRUM servem como base para a inspeo e adaptao
constante pregada pela metodologia, pois atravs destas o Time capaz de
constantemente avaliar o andamento do projeto e das iteraes. As cerimnias citadas a
seguir:
a) Reunio de planejamento do release.
b) Reunio de planejamento da sprint.
c) Sprint.
d) Reunio diria.
e) Reviso da Sprint.
f) Retrospectiva da Sprint.
A Sprint uma iterao e respeita o conceito de time boxes (eventos com durao
fixa) do SCRUM. A durao das Sprints deve estar entre uma e quatro semanas, tendo-se
como prtica recomendada, que a durao seja de duas semanas, para equipes iniciantes
na prtica de SCRUM. Das cerimnias acima citadas, a Sprint pode ser destacada como a
alma geradora de valor a ser entregue ao cliente (SCHWABER; SUTHERLAND, 2009).
5. SCRUME XP COMFOCO NAS PESSOAS
Mtodos geis so adaptativos, portanto, se inteno da organizao implantar este tipo
de processos, ela deve ter em mente o conceito de que dever confiar nos indivduos que
faro parte dos projetos, envolvendo-os nas decises. (FOWLER, 2005). Um dos pontos
mais importantes em processos adaptativos que necessrio que os envolvidos sejam
competentes e motivados, e os mtodos geis disponibilizam isso atravs da participao
nas decises e na gesto das tarefas pelos envolvidos, gerando motivao e competncia.
A importncia dada pelas metodologias geis s pessoas envolvidas nos projetos
j est clara nos valores constantes no manifesto gil, no qual se destaca o primeiro destes
que cita que metodologias geis valorizam indivduos e iteraes entre eles mais que
processos e ferramentas (BECK et al., 2001).
Com este valor como principal guia, a metodologia SCRUM se destaca pelas
caractersticas de procurar manter a viso na gesto do projeto e no em processos e
controles. Em outras palavras, aplicando-se SCRUM, ser possvel descobrir o que h de
errado nos processos e o que pode ser feito para corrigir estes problemas (SCHWABER;
SUTHERLAND, 2009). Algumas prticas de XP permitem melhoria de processos
mantendo o foco no cliente e nos funcionrios.
Para esclarecer a viso de que o uso de SCRUM juntamente com algumas prticas
complementares de XP, possibilita a motivao dos indivduos envolvidos em um dado
projeto, ser apresentada uma seqncia resumida das atividades bsicas de um projeto
no qual so aplicadas as tcnicas acima citadas.
Um projeto nasce a partir de uma viso, uma necessidade ou uma idia. Mas
pode ser dito que o objetivo do projeto simbolizado pela viso. A partir desta viso o
Product Owner fica responsvel por alimentar e priorizar o Product Backlog, que
basicamente formado por um conjunto de estrias (conceito de XP para uma forma de
representar os requisitos ou casos de uso em um projeto).
muito importante tambm que seja definido o conceito de pronto para o
projeto, ou seja, se uma estria for considerada terminada, ela deve obrigatoriamente
encaixar-se no conceito de pronto que foi estipulado. Garantindo assim, que todos os
envolvidos no projeto (PO, SM e Time) tenham o mesmo significado de pronto.
A partir das estrias contidas no Product Backlog, fica a cargo do Time,
juntamente com o PO, estimar e selecionar as estrias que estejam bem descritas que
faro parte da Sprint. Isto ocorre durante a reunio de planejamento de Sprint. As
principais informaes que se deve ter para esta reunio so o prprio Product Backlog, a
capacidade (ou velocidade) do Time, o ltimo incremento gerado e o histrico de
desempenho do Time (SCHWABER; SUTHERLAND, 2009). Recomenda-se o uso de
Planning Poker (variao do mtodo de estimativa Wideband Delphi) para que o time possa
efetuar a tarefa de estimativa das estrias.
A partir de um conjunto de cartas com uma srie de valores (baseados na srie de
Fibonacci) e a partir de informaes obtidas atravs do PO, cada integrante do Time
seleciona o valor que acredita ser a estimativa que mais se aplica. Quando todos j tiverem
selecionado sua estimativa, as cartas devem ser apresentadas e caso haja uma diferena
muito grande entre os valores selecionados, os que apresentarem o maior e o menor valor
devem explicar seus motivos e aps recolherem as cartas uma nova rodada efetuada
tendo em mente as explicaes ouvidas (BASSI, 2008). A grande vantagem no uso de
Planning Poker o fato de que se evita muito a possibilidade de que haja influncias
durante a tarefa de estimativas (KNIBERG, 2007).
Com o Sprint Backlog montado e a meta da Sprint clara, as estrias selecionadas
devero ser quebradas em tarefas e o Time procede com o desenvolvimento. Como
anteriormente citado, as estrias s podero ser consideradas prontas se cumprirem o que
consta como pronto.
Uma ferramenta muito utilizada em projetos SCRUM o SCRUM Board (Figura
2). Ferramenta de micro gerenciamento de extrema valia ao Time para que possa se
gerenciar e organizar de maneira transparente a todos, pois, como um quadro de Kanban,
fica visvel a todos, e permite que a todo e qualquer instante um dos membros do Time o
atualize, selecionando uma tarefa para execuo ou mesmo atualizando as informaes do
andamento de determinada tarefa, podendo inclusive mud-la para a coluna de pronto
(KNIBERG, 2007).
Durante o perodo de durao da iterao, deve ocorrer a reunio diria (ou Daily
Meeting). Esta reunio de curta durao (normalmente 15 minutos) e serve para o Time
manter-se informado, coeso e integrado sobre o andamento das tarefas, permitindo
identificar rapidamente dentro da Sprint a necessidade de melhorias ou mudanas, um
ponto de inspeo e adaptao que incrementa a organizao e comprometimento da
equipe. (SCHWABER; SUTHERLAND, 2009). Nesta reunio os membros do Time devem
responder a trs perguntas:
a) O que fiz ontem;
b) o que planejo fazer hoje;
c) quais os impedimentos (se existirem).
Caso haja algum impedimento, o mesmo dever ser passado ao SM para que este
trate de resolv-lo para o Time (SCHWABER; SUTHERLAND, 2009).

Figura 2 Desenho representativo de um SCRUM Board.
Fonte: Adaptado de Kniberg (2007).
Ao trmino da Sprint, executada a reviso da Sprint, momento este no qual o
resultado alcanado apresentado ao PO para sua anlise e aprovao. Esta reunio
fornece dados importantes para anlise no prximo planejamento de Sprint (SCHWABER;
SUTHERLAND, 2009).
Aps a reviso ocorre a reunio de retrospectiva da Sprint. Essa reunio mais
uma pea fundamental no processo de inspeo e adaptao em projetos SCRUM. Nela, o
Time ir levantar o que funcionou e o que ocorreu de errado na ltima Sprint, analisando
o que e como pode ser melhorado. A participao do SM nessa reunio possibilita que
este incentive o uso da metodologia e encontre caminhos para tentar resolver ou
minimizar os problemas e impedimentos encontrados. O ciclo SCRUM facilmente
visualizado Figura 3.
Incluindo ainda a prtica da programao em pares (XP) em alguns momentos,
pode-se aumentar o nivelamento do conhecimento dentro da equipe, alm de possibilitar
reviso de cdigo durante a construo do mesmo (KNIBERG, 2007).
Durante o desenvolvimento do projeto, novas estrias (ou requisitos) podero ser
includas no Product Backlog sem que isso gere impactos no trabalho do Time, pois o PO
dever incluir estas estrias e prioriz-las para que na prxima reunio de planejamento
de Sprint, essas novas estrias sejam consideradas (dependendo ainda de sua prioridade).

Figura 3 Fluxo de um projeto SCRUM.
Fonte: Adaptado de Haddad (2009).
Conforme apresentado, atravs da aplicao de SCRUM, se obtm vrios
momentos em que a equipe de desenvolvimento pode escolher, adaptar, inspecionar,
auto-organizar e mensurar seu prprio trabalho.
6. CONSIDERAES FINAIS
As metodologias geis surgiram como uma alternativa no ambiente atual das
organizaes. Neste cenrio, tm-se as grandes, as pequenas e as mdias organizaes.
Economicamente, para as grandes organizaes possvel implantar processos
tradicionais, porm estes so pesados e burocrticos, gerando desperdcio e desmotivando
seus funcionrios devido ao nmero elevado de procedimentos que devem ser seguidos
para efetuar uma dada tarefa. Nestes casos, os membros das equipes so normalmente
tratados como meros recursos, um nmero, um elemento que permitir que empresa
alcance seu objetivo que o desenvolvimento de um determinado produto ou servio com
os requisitos descritos no incio do projeto e que provavelmente no reflitam mais as reais
necessidades do cliente ao trmino do trabalho.
Na grande maioria das empresas (compostas por mdias, pequenas e micro
empresas) muito comum no fazer uso de nenhuma metodologia ou processo. Por falta
de recursos financeiros ou pelo motivo que estes processos possam atrasar e encarecer os
projetos. Nestes casos, tem-se a tpica ocorrncia do processo de codificao e correo em
ciclos que parecem infindveis e, devido falta de planejamento, tem-se prazos no
cumpridos, excesso de erros durante todo o perodo e sobrecarga entre os membros da
equipe.
A opo de uma empresa pelo uso de metodologias geis j fornece aos
desenvolvedores a sensao de que a organizao confia em suas competncias, somando-
se a isso prticas SCRUM, que focam totalmente nas iteraes entre os indivduos da
equipe e como estes interagem, tem-se um ambiente totalmente favorvel ao crescimento
profissional com grande troca de conhecimentos devido formao de equipes
multidisciplinares. Estas equipes se auto-gerenciam (selecionando numa iterao o que
ser feito, como ser e, at mesmo, por quem ser feito), mantendo o conhecimento dirio
do andamento das tarefas e permitindo constantes mudanas caso haja necessidade.
Todos esses fatores promovem na equipe o sentimento de que todos esto no
controle do projeto, o qual no pertence empresa, ao cliente ou a um gerente de projeto,
e sim a todos os envolvidos, e que desta forma sentem-se mais valorizados e
comprometidos com o objetivo que, ao ser alcanado, motivar ainda mais estes
indivduos em busca de conhecimento e crescimento profissional por meio da adaptao
constante empregada no processo.
AGRADECIMENTOS
Alguns fatos fazem-nos quase desistir de algumas coisas, felizmente temos pessoas para
nos apoiar e estimular. Agradeo minha esposa, Priscila, por sempre ficar ao meu lado e
instigar-me a desenvolver este artigo, aos meus pais, Avandir e Zilda, que juntos
formaram tudo que sou hoje e que ainda hei de me tornar, aos professores, Kenji e
Robson, pela orientao e pelo lado humano apresentado, e ao meu irmo e mestre,
Avandir (ndio), por tudo que passamos e por tudo que ele me mostrou e ensinou durante
sua passagem. Obrigado.
REFERNCIAS
AKITA, F. Voc no entende nada de SCRUM. Disponvel em:
<http://akitaonrails.com/2009/12/10/off-topic-voce-nao-entende-nada-de-scrum>. Acesso em:
21 fev. 2010.
BASSI, D. Planejamento gil de projetos. Engenharia de Software Magazine, Rio de Janeiro,
Devmedia Group, 8. ed., jan. 2009. Disponvel em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=11306>.
______. Estimativas geis com planning poker. Engenharia de Software Magazine, Rio de Janeiro,
Devmedia Group, 9. ed., fev 2009. Disponvel em:
BECK, K. Extreme programming explained: embrace change. 1. ed. Reading: Addison Wesley,
1999. 224 p.
BECK, K. et al. Manifesto for agile software development. Disponvel em:
<http://www.agilemanifesto.org >. Acesso em: 17 jul. 2009.
BECKER, B.E.; HUSELID, M.A. The HR scorecard: linking people, strategy and performance.
Boston: Harvard Business School Press, 2001. 235 p.
CAMPOS, A.; FONSECA, I. Por que SCRUM?. Engenharia de Software Magazine, Rio de Janeiro,
Devmedia Group, 4. ed., set. 2008. Disponvel em:
FOWLER, M. The new methodoly. Disponvel em:
<http://martinfowler.com/articles/newMethodology.html>. Acesso em: 10 fev. 2010.
HADDAD, M. Estrutura do SCRUM. Disponvel em:
<http://connections.fiap.com.br/blogs/scrum/entry/estrutura_do_scrum?lang=pt_br>. Acesso
em: 25 fev. 2010.
HELDMAN, K. Gerncia de projetos (PMP Project Management Professional): guia para o
exame oficial do PMI. 3. ed. Traduo de Luciana do Amaral Teixeira. Rio de Janeiro: Elsevier,
2006. 529 p.
KNIBERG, H. SCRUM e XP direto das trincheiras: como fazemos SCRUM. Infoqueue, 2007. 145 p.
Disponvel em: < http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches>. Acesso
em: 9 jan. 2010.
MARTINS, J.C.C. Gesto de projetos de desenvolvimento de software (PMI - UML). 1. ed. Rio de
Janeiro: Brasport, 2002. 189 p.
NONAKA, I.; TAKEUCHI, H. The new new product development game. Harvard Business
Review, Boston, 1986. Disponvel em: <http://hbr.org/product/new-new-product-development-
game/an/86116-PDF-ENG>. Acesso em: 13 jul. 2009.
ROYCE, W.W. Managing the development of large software systems. Wescon, Los Angeles, 1970.
Disponvel em: <http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf>.
Acesso em: 13 fev. 2010.
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM. Disponvel em:
<http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf#view=fit>.
Acesso em: 10 fev. 2010.
SUTHERLAND, J. The SCRUM papers: nuts, bolts and origins of an agile process. Disponvel em:
<http://scrumtraininginstitute.com/home/stream_download/scrumpapers>. Acesso em: 25 jan.
2010.
SPNOLA, R.O. Introduo gesto de conhecimento. Engenharia de Software Magazine, Rio de
Janeiro, Devmedia Group, 6. ed., nov. 2008. Disponvel em:
TELES, V.M. Um estudo de caso da adoo das prticas e valores do extreme programming. 2005.
181 f. Dissertao (Mestrado em Informtica). UFRJ, IM/DCC, Rio de Janeiro, 2005. Disponvel em:
<http://www.improveit.com.br/xp/dissertacaoXP.pdf>. Acesso em: 18 fev. 2010.

Metodologias Ageis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologias Ageis

Uploaded by

Copyright:

Available Formats

163

You might also like