TTULO:GERENCIAMENTODEPROJETOSNAADMINISTRAOPBLICA

RESUMO:

No desenvolvimento de software h uma forte tendncia para o

desenvolvimentogildeaplicaesdevidoaumritmoaceleradodemudanas.
Este contexto tem causado crescentes frustraes nas organizaes devido
aosplanos,especificaesedocumentaespesados,muitasvezesimpostos
por critrios de conformidade dos modelos de maturidade. Organizaes que
vinham adotando mtodos clssicos, como o modelo em cascata (waterfall)
esto cada vez mais interessadas na possibilidade de adoo de mtodos
geis. Este trabalho apresenta uma abordagem gil para o Ministrio Pblico
de Minas Gerais baseada nos mtodos de Programao Extrema, Scrum e
Kanban.

Palavraschave:GernciadeProjetos,ProgramaoExtrema,ScrumeKanban

INTRODUO:

A tecnologia da informao evidenciase pela contnua expanso e por

umaforteconcorrnciaentreempresasligadasaessesetor.Emvirtudedisso,
para que essas entidades possam permanecer nesse meio, elas precisam
desenvolver produtos e servios que, de algum modo, se destaquem e
conquistem a credibilidade de seus clientes [1]. Um item fundamental para
atingir esse objetivo, independentemente do tipo do produto a ser produzido,
denominase qualidade. A qualidade de um software est diretamente
relacionada com os nveis de qualidade dos processos envolvidos no
desenvolvimento[2].

A engenharia de software uma rea da tecnologia da informao

responsvel por esses processos de construo de software, abrangendo as
tcnicas empregadas na especificao, projeto, desenvolvimento e testes,
tendo como objetivo um produto de qualidade, ou seja, que atenda as
expectativas para as quais est sendo desenvolvido de forma organizada,
produtiva e mais econmica possvel [3]. Desta forma, para que esses
processospossamatingiraqualidadedesejada,tornaseimprescindvelouso
de tcnicas e metodologias de gerncia de projetos para o planejamento e
posteriorcontroledessesprocessos.

De acordo com Martins, em [4], na engenharia de software existe dois

tiposdeprocessosoumtodosparacontrolarodesenvolvimentodeumprojeto
de software: os mtodos clssicos (ou definidos) e os mtodos geis (ou
empricos).

Osmtodosclssicosdeterminamoquedeveserfeito,quandoecomo.
O contexto do projeto, as atividades necessrias para execuo deste e o
prazodeentregasodefinidosnoinciodoprojeto.Comoexemplodemtodo
clssico, temse o modelo em cascata (waterfall) com fases distintas de
especificao de requisitos, projeto e desenvolvimento, todas agrupadas em
nveis.Amaiordificuldadedessemodeloacomodarmudanascomoprojeto
jemandamento,poisumnveldependedooutro,sendoassim,casoumnvel
qualquerpreciseseralterado,onvelanteriordeverserrefeito.Josmtodos
geis tm representado alternativas s modalidades tradicionais de
desenvolvimento e gesto de projetos de softwares [5], suportando projetos
comrequisitosinstveis,esefundamentamem4supervalores:

IndivduoseInteraesmaisimportantesqueprocessoseferramentas.

SoftwareFuncionalmaisimportantequedocumentaoelucidativa.

Presenadoclientemaisimportantequenegociaodecontrato.

Respostassmudanasmaisimportantesqueseguimentodeplano.

O presente artigo realiza um estudo da viabilidade de utilizar a

combinao de alguns mtodos geis Programao Extrema, Scrum e
Kanban , no gerenciamento de projetos de software do Ministrio Pblico de
Minas Gerais. O Ministrio Pblico uma instituio permanente, essencial
funo jurisdicional do estado, incumbindolhe a defesa da ordem jurdica, do
regimedemocrticoedosinteressessociaiseindividuaisindisponveis.

MTODOSGEISPARAGERENCIAMENTODEPROJETOS:

Um dos aspectos mais interessantes dos mtodos geis sua

estruturaoconceitual.Oficialmentesoquatrodeclaraesdevalorquenos
inspiram um pequeno conjunto de princpios que nos guiam e uma grande
quantidadedemtodosquenosajudamaestabelecercomoascoisasdevem
ser feitas. Cada mtodo estabelece seu prprio conjunto de pressupostos e
prticas. E so comuns equipes de projeto adotarem prticas de diferentes
mtodosenquantoosadaptamssuasrealidades.

A Programao Extrema[6], ou simplesmente XP, uma metodologia

leve, eficiente, de baixo risco, flexvel, preditiva, cientfica e divertida de se
desenvolver software. XP adequada para ser utilizada por equipes de
desenvolvimento pequenas ou mdias em projetos com requisitos mal
definidosouquesofremmudanascontinuamente.

As equipes que utilizam XP devem ter entre 2 e 10 desenvolvedores e

seusmembrosdevemsercapazesdeexecutartestesnosistemadiariamente.
UmdoscriadoresdomtodoXP,KentBeck,argumentaqueoXPextremo
(extreme) dando grande nfase a atividades reconhecidamente boas pela
comunidade.DentreasprincipaisatividadesdoXPpodesedestacar:
 Revisodecdigo:Cdigorevisadoatodomomento,aindaenquanto
estsendoescrito.

Testes de unidade e aceitao: todos os envolvidos no produto

devero testar o produto o tempo todo. Desenvolvedores (testes de unidade),
Clientes(testesfuncionais)

Simplicidade no projeto: o projeto do software o mais simples

possvel para suportar as funcionalidades do software em um determinado
momento.

Testesdeintegrao:Sofeitasvriasintegraesduranteummesmo
dia. Para cada pequena parte de componente que desenvolvida, h uma
integraodessecomponenteaoproduto.

Iteraes curtas: Ciclos de desenvolvimento curtos so bons por que

permitemdescobrircomantecednciaproblemasnoprojetoeagregarvalorao
negcio do cliente com maior rapidez. No XP, as iteraes so muito curtas,
podendoserdeapenasalgunsdias.

OScrumumarcabouoparadesenvolvimentodeprodutoscomplexos
fundamentado na teoria emprica de controle de processos, que suportada
pelo trip formado por transparncia, inspeo e adaptao. A transparncia
garante que todos os elementos do processo devem ser visveis e
compreendidos pelos envolvidos no processo. J a inspeo defende que os
elementosdoprocessodevemsermonitoradoscomfrequnciasuficientepara
quevariaesinesperadassejamdetectadaseasintervenesdevidassejam
realizadas. Por fim, a adaptao consiste em ajustar o processo sempre que
ocorram variaes indevidas. A adaptao deve ser rpida para diminuir o
impacto negativo das variaes na qualidade e tambm para que novos
desviossejamevitados.

Scrum um mtodo gil similar ao XP, porm com foco maior em

gerncia. XP tem foco em engenharia, embora possua algumas prticas
relacionadas gerncia [7]. O processo de gesto descrito pelo Scrum
bastantesimples,bemcomosuasprticas,artefatoseregras.OScrumno
prescritivo e, portanto no descreve o que deve ser feito em todas as
circunstncias. Mesmo assim, aplicvel em projetos complexos e o seu
conjuntosimplesdeprticasajudammantertodooprojetobastantevisvel,o
que permite que os praticantes saibam exatamente o que est ocorrendo e
faamajustespontuaisparaqueoprojetocontinuecaminhandoemdireoao
alcancedosobjetivostraados.

Por fim, o Kanban [8] uma expresso japonesa com origem nos
cartesutilizadosnasempresasjaponesasparasolicitarcomponentesaoutras
equipes da mesma linha de produo. Kanban designa um mtodo de
fabricao em srie, desenvolvido pela Toyota Motor Company, aplicado aos
processos de aprovisionamentos, produo e distribuio, seguindo os
princpiosdojustintime(JIT).
 A traduo literal da palavra kanban anotao visvel ou sinal. De
modogeral,vemseempregandonaliteraturaestapalavracomosignificadode
carto, pois o Sistema Kanban conhecido por empregar determinados
cartes para informar a necessidade de entregar e/ou produzir certa
quantidade de peas ou matriasprimas. Em muitos trabalhos, notase a
utilizaoindiscriminadadapalavrakanbansignificandotantocarto,como
se referindo ao sistema propriamente dito. Nesta seo, e no decorrer do
presente trabalho, utilizase a seguinte distino de termos: os cartes ou
sinais empregados so tratados por sinalizadores, reservandose,
consequentemente,apalavrakanbanaosistemacomoumtodo.

Na utilizao do Kanban pressupese que exista determinada

quantidadedepeasnosarmazns(estoques)entreasestaesdetrabalho.
Emoutraspalavras,asseguradaadisponibilidadedepeassuficientesparaa
formao dos produtos num dado perodo de trabalho. O processo
subsequente, visto como um cliente deve ir ao processo precedente, o
fornecedor, para adquirir as peas necessrias j prontas. O processo
precedente,porsuavez,produzaexataquantidaderetirada,reabastecendoo
armazm, entendido como um supermercado. Segundo [9], existe um
considervel nmero de possibilidades no uso deste esquema, visto que se
podem combinar diferentes tipos e quantidades de sinalizadores, formas de
retirada,pontosdeprogramao,tiposdearmaznsouestoques,etc.

GERENCIAMENTO DE PROJETOSNO MINISTRIO PBLICO DE MINAS

GERAIS

Antigamente, cada servidor era responsvel, praticamente, por um

sistema. Este desenvolvedor (servidor), junto ao cliente, realizava o
levantamento de requisitos, fazia as anotaes que achava necessria e
programava todo o sistema. Isso trazia diversos problemas para o MPMG. O
conhecimento do sistema fica restrito apenas a uma pessoa, e caso esse
sassedefrias,porexemplo,noexistianingumcapazdemanterosistema.

Atualmente, o desenvolvimento de software no MPMG vem sofrendo

grandesmodificaes.Foramcriadasequipesporprojetos,sendocadaequipe
composta por certa de cinco desenvolvedores. Logo, resolveuse o problema
de disseminao de conhecimento dos sistemas desenvolvidos. No entanto,
como existem mais pessoas envolvidas, contribuindo no desenvolvimento do
mesmo sistema, tornouse necessrio gerenciar e organizar as tarefas
realizadas,objetivandoumamaiorprodutividade.

Com o objetivo de melhorar o gerenciamento de projetos do MPMG,

realizouse um levantamento de alguns mtodos geis, a saber Programao
Extrema,ScrumeKanban.ComonoMPMGtmsesoftwarescomplexosonde
nem todos os requisitos esto claros a partir do seu incio e no se tem um
plano bem definido do que ser implementado, optouse pela utilizao dos
mtodosgeis.
 Paratestarasmelhoriasdaaplicaodeummtodogil,escolheuseo
Sistema de Registro nico, conhecido entre os servidores e membros pela
sigla SRU. Este sistema encontrase em desenvolvimento aproximadamente
quatroanos.Destaforma,jexistemdiversasfuncionalidadesimplementadas.

Mas como este sistema encontrase em constantes evolues, espera

se que, com a aplicao desses mtodos geis, terse uma melhora do
projetocomoumtodo,podendoseestimarmelhorosprazosparaliberaode
novasfuncionalidadesparaousurio,dentreoutrosbenefcios.

Inicialmente este sistema foi concebido por apenas uma pessoa, mas,
nos dias atuais, a equipe consta de seis desenvolvedores, sendo quatro
servidores e dois estagirios. Alm dos desenvolvedores existe uma pessoa
responsvelpelolevantamentodosrequisitoseiteraescomousurio.Desta
forma,aequipedesteprojetocontmsetepessoas.Assim,aprimeiropassoj
havia sido tomado, o sistema possui uma equipe pequena, multifuncional e
autoorganizada.

Osegundopassofoidividirtodososrequisitosaseremimplementados
em uma lista de pequenas funcionalidades entregveis e classificlas por
prioridade. Alm disto, foi atribudo um grau de complexidade e esforo para
cada tarefa. Cada tarefa, com suas respectivas informaes de custo, foram,
ento, escritas em cartes e coladas na parede. Utilizaramse colunas
nomeadasparailustrarondecadaitemestnofluxodetrabalho.

Aps a lista de funcionalidades, dividiuse o tempo em curtas iteraes

de durao fixa (sprint de trs semanas). O objetivo ter entregas de
funcionais do sistema de trs em trs semanas, para que o usurio possa
visualizar o que est sendo feito. Alm disto, definiuse um limite do trabalho
emandamento.Otrabalhofoilimitadoaquatrofuncionalidades.Assim,sempre
existir uma programao em par na equipe, com o objetivo de ajudar
disseminaroconhecimentodosintegrantesmaisexperientes.

CONCLUSO:

A Programao Extrema bastante prescritiva comparada ao Scrum.

ElaincluiquasetudodoScrummaisalgumasboasprticasdeengenhariade
software bem especficas como desenvolvimento orientado a testes e
programaoempar.ScrummenosprescritivoqueXP,umavezqueeleno
prev nenhuma prtica especfica de engenharia. Porm, Scrum mais
prescritivo que Kanban, uma vez que prescreve coisas como iteraes e
equipesmultifuncionais.

Uma das principais diferenas entre Scrum e RUP (Rational Unified

ProcessMtodoClssico)quenoRUPvocrecebecoisasdemais,evoc
supostamenteremoveomaterialquenoprecisa.NoScrumvocrecebemuito
pouco,esupostamenteadicionaomaterialquelhefalta.
 J Kanban deixa quase tudo em aberto. As nicas restries so:
Visualizeseufluxodetrabalhoelimitesuasatividadesemandamento.Apenas
a alguns centmetros de faa qualquer coisa, mas ainda assim
surpreendentementepoderoso.

Aindamuitocedoparaavaliarosresultadosalcanadospelaaplicao
dosconceitosdosmtodosgeisnoMPMG.Noentanto,nosprimeirosmeses
daimplantao,percebeuseaimportnciadoacompanhamentodotempode
execuo das tarefas (tempo mdio para completar uma funcionalidade,
algumas vezes denominado lean time). Aperfeioar o processo para tornar o
tempo de execuo o menor e mais previsvel possvel ainda um desafio.
Prever o tempo gasto em todo o fluxo nos permite uma maior fidelidade aos
ANS Acordos de Nvel de Servio (ou do ingls SLAs ServiceLevel
Agreements)efazerplanosdeentregamaisrealistas.

TantoXPquantoScrumeKanbansoempricosnosentidoqueseesperaque
seexperimenteoprocessoepersonalizeaoseuambiente.Naverdade,temse
que experimentar. Nenhum mtodo gil fornece todas as respostas eles
apenasfornecemumconjuntobsicoderestriesparaconduziroseuprprio
processodemelhoria.

Assim, a aplicao das prticas geis no MPMG est em uma fase

embrionria, mas os primeiros resultados foram muito positivos. Como
trabalhos futuros, pretendemse organizar melhor as equipes, verificar se o
perododetrssemanassatisfatrioparaotamanhodoSprintetestaroutros
limitesparaaquantidadedetrabalhoemandamento.

REFERNCIAS:

[1] Torreo, P. G. B. C. Ambiente de Aprendizado para Educao em

Gerenciamento de Projetos. Dissertao (Mestrado) Universidade Federal
dePernambuco,2005.

[2] Cavalcanti, A. P. C. Bandeira, L. R. P. Donegan, P. M. Um modelo de

gerncia de projetos baseado no rup com aplicaes de pmbok. Simpsio
InternacionaldeMelhoriadeProcessosdeSoftware,2004.

[3] Pressman, R. S. Software Engineering: A Practitioners Approach. 6. Ed.

McGrawHill,2005.

[4] Martins, J. C. C. Tcnicas para Gerenciamento de Projetos de Software.

Brasport,2007.

[5][CorameBohner2005]Coram,M.Bohner,S.Theimpactofagilemethods
onsoftwareprojectmanagement.In:Proceedingsofthe12thIEEEInternational
Conference and Workshops on Engineering of ComputerBased Systems.
Washington, DC, USA: IEEE Computer Society, 2005. p. 363370. ISBN 0
769523080.

[6] Beck, K. Extreme programming explained: embrace change. [S.l.]:

AddisonWesley,2000.(TheXPseries).ISBN9780201616415.

[7] SCHWABER, K. Agile Project Management with Scrum. [S.l.]: Microsoft

Press,2004.

[8] Anderson, D. J. Kanban: Successful Evolutionary Change for Your

TechnologyBusiness.1nd.ed.[S.l.]:BlueHolePress,2010.

[9] JUNIOR, M. G. F. M. L. Adaptaes ao sistema kanban: reviso,

classificao,anliseeavaliao.RevistaGestoeProduoUNIPAC,v.15,
p.173188,2008.