Gesto de Projetos em Software Livre

(Ttulo Provisrio)
Cesar Brod
com a colaborao de Joice Kfer

Pgina 1 de 117
Agradecimentos
Obrigado minha mulher Meire e minhas filhas Natlia, Aline e Ana Luiza por estarem sempre ao
lado deste nerd.
Obrigado a meus pais por me apontarem o caminho que levou-me a fazer sempre o que amo.
Obrigado ao Rubens Queiroz de Almeida, por ter plantado a semente deste livro.
Obrigado ao meu editor Rubens Prates, por sua pacincia de J em esperar por este livro.
Obrigado a inmeras pessoas da Solis, da Univates, da UFRGS e da Unicamp que fazem parte de
muitos captulos deste livro.
Obrigado especial minha mais do que melhor amiga, scia e crtica, Joice Kfer, pelo incentivo,
apoio, mimos e broncas na dosagem sempre certa.

Pgina 2 de 117
Apresentao

Pgina 3 de 117
ndice
Agradecimentos....................................................................................................................................2
Apresentao........................................................................................................................................3
Prefcio.................................................................................................................................................6
Como ler esse livro...............................................................................................................................8
Vendendo a idia...................................................................................................................................9
O que software livre?.......................................................................................................................13
Eu e o software livre...........................................................................................................................17
O software livre na Univates..............................................................................................................19
O Grupo de Usurios Gnurias........................................................................................................20
Sagu Workshop e SDSL.................................................................................................................21
A Univates como referncia, no como proprietria.....................................................................22
O desenvolvimento do Sagu...............................................................................................................24
A arquitetura inicial do Sagu.........................................................................................................25
Arquitetura Miolo..........................................................................................................................26
Gnuteca um teste de conceito para o Miolo....................................................................................28
Utilizando a UML...............................................................................................................................30
Mas o que a UML afinal?............................................................................................................30
Extreme Programming........................................................................................................................35
Planejamento..................................................................................................................................36
Projeto............................................................................................................................................37
Codificao....................................................................................................................................38
Testes.............................................................................................................................................39
Miolo..................................................................................................................................................40
Plano Diretor de TI Um modelo......................................................................................................43
O ndice..........................................................................................................................................43
Resumo..........................................................................................................................................44
Ecologia do Conhecimento............................................................................................................45
A Informtica na Univates, a evoluo para um Ecossistema.......................................................45
Acompanhamento de chamados tcnicos..................................................................................48
Software livre na Academia......................................................................................................49
Software Livre na bagagem......................................................................................................51
Ambiente de rede......................................................................................................................52
A Solis.......................................................................................................................................53
A Tecnologia do Ecossistema....................................................................................................53
Economia.......................................................................................................................................54
Sumrio da Economia em Licenas..........................................................................................54
Aproveitamento de cdigo e colaboraes...............................................................................55
Desenvolvimento pago por outras instituies.........................................................................61
Plano Diretor de Tecnologia da Informao PDTI.....................................................................61
Tomada de Deciso...................................................................................................................62
Comit de Tecnologia da Informao.......................................................................................62
Comit Interinstitucional de Tecnologia da Informao...........................................................63
Planejamento de Capacidade.........................................................................................................65
Equipamentos............................................................................................................................65
Rede..........................................................................................................................................66
Software....................................................................................................................................66
Suporte......................................................................................................................................67
Concluso.......................................................................................................................................67

Pgina 4 de 117
O Mtico Homem-Ms.......................................................................................................................68
O portal Cdigo Livre........................................................................................................................70
Cooperativismo e Software Livre Um modelo de negcios............................................................71
Trs anos de Microsoft.......................................................................................................................73
Engenharia de Software para Software Livre.....................................................................................75
Introduo......................................................................................................................................75
Software aberto e software livre....................................................................................................75
Modelos de desenvolvimento de software: a Catedral e o Bazar..................................................76
Processo de desenvolvimento de software livre............................................................................77
Prticas das comunidades de desenvolvimento de SL..............................................................78
Linux....................................................................................................................................78
Apache..................................................................................................................................80
Python...................................................................................................................................80
PostgreSQL..........................................................................................................................81
Ruby on Rails.......................................................................................................................82
Drupal...................................................................................................................................83
OpenOffice.Org....................................................................................................................84
A Engenharia de Software e o Software Livre..............................................................................84
Especificao de Requisitos......................................................................................................85
Gerncia de Configurao.........................................................................................................85
Coordenao..............................................................................................................................86
Gerncia de Evoluo e Manuteno........................................................................................87
Reuso e Componentizao........................................................................................................87
Teste e Garantia da Qualidade...................................................................................................88
Refatorao...............................................................................................................................88
Prticas de desenvolvimento gil..............................................................................................88
Padres de Projeto (Design Patterns)........................................................................................89
Concluso.......................................................................................................................................89
O Grande Contrato.............................................................................................................................90
Scrum..................................................................................................................................................92
A ordem nascida do Caos...............................................................................................................92
Previously on Lost.........................................................................................................................93
O que voc fez ontem?...................................................................................................................95
Product Backlog.............................................................................................................................96
Sprint Backlog.............................................................................................................................100
Burndown Chart...........................................................................................................................100
ScrumMaster................................................................................................................................101
User Stories..................................................................................................................................101
O jogo da estimativa....................................................................................................................105
Bibliografia.......................................................................................................................................109

Pgina 5 de 117
Prefcio
Os e-mails trocados acerca deste livro, com meus amigos e meu editor, datam de meados de 2003.
Na poca, atravs de minha empresa, a BrodTec, eu atuava como gestor de TI no Centro
Universitrio Univates, em Lajeado, onde desde 1999 desenvolvamos e integrvamos solues
utilizando tecnologias livres. Em 2000 criamos o primeiro repositrio de software livre brasileiro, o
CodigoLivre.Org.Br e nele colocvamos a nossa prpria produo: softwares para a gesto
acadmica, para bibliotecas, para a gesto de contedo web e tambm um framework de
desenvolvimento que incorporava muito do que havamos amadurecido na direo de uma
metodologia orgnica de desenvolvimento.
Mas aliada evoluo de uma metodologia de desenvolvimento que honrava a colaborao e o
compartilhamento de informaes atravs do uso de softwares livres, em conjunto com a reitoria da
Univates, em especial com o Professor Eloni Jos Salvi, concebi um modelo de negcios que deu
origem primeira cooperativa de desenvolvimento e integrao de solues em software livre de
que se tem notcia: a Solis, fundada em janeiro de 2003. Foi por a que o Rubens Queiroz de
Almeida, mantenedor do portal Dicas-L (www.dicas-l.com.br) comeou a dizer que eu devia contar
toda esta histria em um livro e o outro Rubens, o Prates, editor da Novatec, comprou a ideia.
Meu senso crtico, porm, nunca permitiu que eu passasse da pgina 30 e do esboo inicial de 10
captulos. Eu viajo bastante, especialmente palestrando em vrios lugares do Brasil e do mundo
sobre o trabalho que venho desenvolvendo com softwares livres. A cada nova palestra, a cada
conversa com gestores, professores, alunos, equipes de desenvolvimento eu sentia que o livro que
eu escrevia ainda carecia de uma fundamentao maior. Ao mesmo tempo, eu queria que, antes de
mais nada, ele mantivesse o formato de um relato de experincias, um conjunto de pequenas
histrias que, colocadas na devida sequncia, auxiliassem o leitor em sua aprendizagem nas prticas
e mtodos para a gesto de projetos que me foram teis.
Sem conseguir finalizar o livro, fui colocando em minhas palestras e nos artigos que eu produzo
para o Dicas-L muito daquilo que fazia parte das eternas 30 pginas. Elas foram revistas, ampliadas,
novos assuntos foram abordados de tal forma que, em determinado ponto, eu achei que o livro era
desnecessrio, j que todo o contedo estava na web e eu podia seguir acrescentando novos artigos
a meu bel prazer. Alguns fatores fizeram-me mudar de ideia.
O primeiro que acabei escrevendo uma parte do livro Free as in Education1, publicado pela
OneWorld.Net em 2004 com o patrocnio do Ministrio de Apoio ao Desenvolvimento da Finlndia.
Este livro aborda a importncia de softwares de cdigo livre e aberto na gerao de emprego e
renda, no desenvolvimento de pases emergentes e na potencial soluo de conflitos. Coube a mim a
anlise da utilizao de softwares livres e de cdigo aberto na Amrica Latina. Nico Coetzee fez o
estudo relativo frica e Frederick Noronha sia no industrializada. Niranjan Rajani foi o
coordenador do trabalho.
No final de 2007 eu e minha scia, Joice Kfer, trabalhamos na traduo para o portugus do livro
Redes sem Fio no Mundo em Desenvolvimento2, publicado no incio de 2008 e que teve mais de
dois milhes de downloads entre 2008 e 2009. Entre 2009 e 2010 traduzi, com a reviso tcnica da
Joice, dois livros de Fred Brooks Jr.: O Mtico Homem-Ms e O Projeto do Projeto do modelo
implementao, ambos publicados no Brasil pela editora Campus Elsevier. A leitura que fizemos
durante a traduo reforou nossa percepo bvia de que mais agradvel, ainda hoje, ter um livro
nas mos, na bagagem, na cabeceira da cama, do que ficar com o computador ligado o tempo todo,

1 O livro completo pode ser obtido em http://miud.in/cRs. A parte relativa Amrica Latina, escrita por Cesar Brod,
pode ser obtida em http://brodtec.com/helsinki.pdf
2 Disponvel em http://wndw.net/

Pgina 6 de 117
lendo informaes na tela isto talvez mude em um futuro prximo, quando os tablets realmente
tornem-se populares. Alm disto, estas trs tradues, em conjunto, representam mais de mil
pginas digitadas e revisadas, um esforo que poderia ser tambm dedicado para a elaborao de
meu livro.
O ltimo fator que meus artigos relativos gesto e metodologia de desenvolvimento so bastante
lidos e referenciados na web, o que parece indicar que h um pblico para este assunto.
De 2006 a 2009 tambm trabalhamos com a gesto de projetos de desenvolvimento em cdigo
aberto e interoperabilidade junto Universidade Federal do Rio Grande do Sul (UFRGS) e
Universidade Estadual de Campinas (Unicamp), atravs de um contrato com a Microsoft, o que
ampliou ainda mais a nossa experincia com a gesto de equipes e nos deu a oportunidade de
exercitar, ainda mais, metodologias geis de desenvolvimento, em especial o Scrum.
A participao da BrodTec na coordenao do temrio nas edies de 2009 e 2010 da Latinoware,
implicando em mais conversas com mais pessoas, e a consolidao de parte do conhecimento que
eu havia adquirido de forma prtica e emprica na disciplina de mestrado em Engenharia de
Software, ministrada pelo Professor Marcelo Pimenta na UFRGS, para a qual fui convencido pela
Joice a assistir como aluno ouvinte (ela assistiu como aluna especial) foram fundamentais para que
eu me convencesse que, finalmente, eu poderia produzir um material digno de meus potenciais
leitores.

Pgina 7 de 117
Como ler esse livro
Tentei colocar os captulos deste livro em uma ordem mais ou menos cronolgica, buscando seguir
o roteiro de minha prpria aprendizagem e enfatizando o aprimoramento orgnico de uma
metodologia de gesto e desenvolvimento que usa uma srie de elementos dos quais me apropriei
pelo caminho. Ao longo do livro, procurei introduzir uma srie de mtodos, prticas e conceitos
sem, de forma alguma, competir com o vasto material j existente sobre muitos assuntos sobre os
quais eu trato aqui. Por outro lado, busquei no obrigar o leitor a correr atrs de referncias externas
a todo o momento. Quando necessrio, uso notas de rodap com links que permitem um
aprofundamento maior em um ou outro tema. A Bibliografia, ao final do livro, constitui o meu
prprio conjunto bsico de referncia e aprendizagem.
Mesmo optando pela ordem cronolgica, o leitor deve sentir-se vontade para usar captulos
especficos como material de pesquisa ou referncia, especialmente aqueles mais conceituais (os
que introduzem, por exemplo, UML, Extreme Programming e Scrum, por exemplo). Aqueles mais
interessados em modelos de negcios podem focar sua leitura na parte mais histrica da evoluo
de formas de criao de produtos, gerao de emprego e renda com software livre, ideias sobre
contratos com clientes e outros assuntos relacionados, deixando completamente de lado os aspectos
mais tcnicos.

Pgina 8 de 117
Vendendo a idia

Luciano, Carlos e Maurcio,

Pensei bastante sobre a metodologia de implementao do novo

Sistema Administrativo. Sei que nesta fase de estudo de uma
nova ferramenta ainda podem surgir polmicas sobre o mtodo de
migrao e a prpria ferramenta empregada, o que totalmente
natural. Por isto mesmo, peo a vocs um voto de confiana na
adoo das regras de desenvolvimento deste novo sistema e na
linha mestra que adotaremos na implementao do mesmo.

Aqui segue um primeiro "draft" para o desenvolvimento do novo

Sistema Administrativo, que vocs devem transformar em um
documento final. Sou flexvel em vrios aspectos, exceo
das datas chaves do cronograma que devem ser mantidas a todo o
custo.

Projeto Interno

Novo Sistema Administrativo

Nome-cdigo: UniverSis

Coordenador: Prof. Luciano Brando

Objetivo: Migrao do Sistema Administrativo existente na

Univates para uma estrutura baseada em Intranet, com bases de
dados padro SQL e acesso dos clientes atravs de browsers
padro de mercado. O novo UniverSis utilizar ferramentas de
sistemas abertos e ser publicado para a comunidade acadmica
que poder participar do projeto.

Pr-requisitos:

<NOTA>
Sei que isto uma imposio, certamente passvel de
questionamento. Aqui onde peo, justamente, o maior voto de
confiana.
</NOTA>

Pgina 9 de 117
1. A interface do usurio ser exclusivamente atravs de
browser padro (Netscape, Internet Explorer ou outro)
2. A base de dados para o desenvolvimento inicial ser o MySQL

<NOTA>
A migrao para o Oracle ou outra base SQL deve ser tranquila,
mas devemos comear com uma base na qual consigamos suporte da
comunidade "OpenSource" com facilidade.
</NOTA>

3. A base de dados de testes deve refletir a modelagem da

atual, mas deve ser INDEPENDENTE da existente.

<NOTA>
Luciano, sei que tens crticas quanto a isto. Podemos discutir
os malefcios e benefcios dos mtodos infinitamente. Quero
evitar neste momento qualquer entrave no desenvolvimento que
possa ter como raiz a migrao dos dados e os testes de
volume. Confio que no meio do processo teremos um bom plano de
migrao de bases de dados.
</NOTA>

4. Todas as ferramentas utilizadas sero OpenSource, ou em

ltimo caso OpenSource para o ambiente acadmico.

Ferramentas adotadas

SO Servidor: Linux
SO Cliente: No importa, desde que use browsers padro
Base de dados: MySQL - inicialmente, com possibilidade de
porte para qualquer outra base padro SQL
Linguagens: PHP (preferencialmente) e qualquer acessrio
OpenSource necessrio.

Cronograma:

20.11.99 - Documentao do projeto completa

01.12.99 - Publicao do projeto na Internet e contato com as
principais Universidades do pas
01.12.99 - 01.03.00 - Definio de atribuies de
colaboradores externos

Pgina 10 de 117
 - a cada ms, teste de mdulos principais -

01.05.00- Laboratrio de funcionalidades e incio da migrao

das bases de dados
01.07.00 30.07.00 - Migrao total das bases e testes de
stress com situaes reais em paralelo com o sistema original
01.07.00 30.07.00 - Ajustes e correes
01.08.00 - UniverSis em produo, com backups dirios e
possibilidade de retorno ao sistema tradicional

O texto acima a transcrio de uma mensagem de correio eletrnico enviada Maurcio de Castro
(hoje scio-proprietrio da empresa Sol7) e outros membros da equipe de desenvolvimento em 20
de outubro de 1999. Este o primeiro registro do Sagu, na poca chamado de UniverSis.
O Sagu (Sistema Aberto de Gesto Unificada) foi o primeiro projeto em software livre desenvolvido
na Univates. O cronograma acima foi cumprido risca, com um grupo que se manteve em trs
desenvolvedores at a entrada do sistema em produo, em agosto de 2000. Esta equipe foi
crescendo at que em 2003, com 20 pessoas, formou, com o incentivo da Univates, a Solis,
Cooperativa de Solues Livres. A Solis hoje conta com mais de 50 associados que vivem
exclusivamente de servios em software livre e presta servios para clientes espalhados por todo o
Brasil.
fundamental para que qualquer projeto seja bem sucedido que:
1. a equipe esteja engajada, comprometida com ele;
2. a equipe tenha f e respeito em seu lder;
3. que toda a estrutura organizacional superior o apoie.
Isto verdade para qualquer projeto, mas quando falamos de software livre, o desafio ainda maior
e mais interessante. Em 1999 o conceito de software livre ainda no era to difundido como hoje
(mesmo na mensagem acima, eu usava o termo OpenSource ao invs de Free Software ou Software
Livre). Quando desenvolvemos um projeto em software livre, ele ser bem sucedido se:
1. a equipe est engajada, comprometida com ele, entende a filosofia do software livre e com
isto est disposta a trabalhar de forma colaborativa, mesmo com pessoas externas equipe;
2. a equipe tenha f e respeito em seu lder, que deve entender que est coordenando um
projeto que pode ter colaborao que est alm de sua gesto;
3. que toda a estrutura organizacional superior o apoie e saiba que no dona do que est
sendo desenvolvido.
Na Univates no foi muito difcil de se conseguir isto, especialmente porque em uma instituio de
ensino privada o negcio j a produo e a venda do conhecimento, sem que ela seja dona do
mesmo. Alm disto, o pr-Reitor Administrativo/Financeiro da instituio na poca, o Professor e
Mestre em Economia Eloni Jos Salvi, j tinha uma boa experincia na lida tecnolgica e a mente
bastante aberta novas propostas e tecnologias. Ele mesmo encarregou-se de conseguir o apoio de
seus colegas na reitoria. Mais adiante, tivemos algumas vezes que provar que a nossa escolha
pelo software livre foi a correta no s filosoficamente, mas tambm tcnica e economicamente. No
captulo [incluir aqui] retornaremos a este aspecto. Ainda assim, repetidamente tnhamos que

Pgina 11 de 117
esclarecer s pessoas com as quais trabalhvamos ou a quem nos reportvamos o que , afinal,
software livre, especialmente evitando confuses sobre livre e grtis, confuso que,
infelizmente, importamos graas ao dbio sentido da palavra free em ingls. A confuso que
persiste, ainda hoje, parcialmente devida ao forte lobby daqueles a quem interessa perpetuar ad
infinitum o moribundo modelo do software proprietrio e em parcela ainda maior por culpa nossa,
os que trabalham com software livre, j que no fomos ainda capazes de esclarec-la
suficientemente.

Pgina 12 de 117
O que software livre?
Software livre no um conceito novo. Na verdade, ele mais antigo que o conceito de software
proprietrio, este definido como um programa ou conjunto de programas de computadores que so
de propriedade de uma pessoa ou empresa, protegidos por mecanismos conhecidos como
"patentes", "direitos autorais", "marcas registradas" ou outros.
Para poder utilizar um software proprietrio voc deve aceitar a "licena de uso" que o acompanha.
Esta licena normalmente limita a responsabilidade da empresa que fornece o software e estabelece
seus deveres como usurio do produto. Tipicamente, estas licenas garantem o direito de uso, mas
no de posse do programa de computador (num arranjo similar ao aluguel de um bem material
qualquer) e probem a cpia do programa e sua modificao. A Microsoft3, uma grande empresa que
desenvolve e comercializa softwares proprietrios orientava seus distribuidores a comparar um
programa de computador com um apartamento:
"Quando voc adquire um software de sistema operacional Windows, obtm na verdade
uma licena para utilizar esse software e no direitos totais de posse sobre ele. Existem
limites sobre o que voc pode fazer com o software de sistema operacional e esses limites
so explicados detalhadamente na licena. Na verdade, esse tipo de acordo j algo bem
comum nos dias de hoje: voc precisa de diversos acordos para utilizar coisas o tempo
todo, mesmo que no tenha direitos plenos para fazer o que quiser com elas. Por exemplo:
Voc aluga um apartamento, mas no pode realizar alteraes estruturais, ou at mesmo
estticas, sem o consentimento do proprietrio."4
Programas de computadores, porm, no so "entidades fsicas" como um apartamento e no
deveriam ser tratados como tal. Um programa de computador um conjunto de instrues de base
lgica e matemtica que explica a uma mquina o que ela deve fazer. O programa abaixo, por
exemplo, escrito na linguagem de programao Python, ilustra como um computador pode conjugar
verbos regulares em portugus:

# Programando em Python
# Exemplo 3 - Cesar Brod
#
# modulo_conjuga.py
#
# Mdulo que conjuga verbos regulares em Portugus
# verso 0.0 07/07/2001 20h17
#
def conjuga(verbo):
"Conjuga o tempo presente de verbos regulares"
conjugado=[]
conjuga_ar = ['o','as','a','amos','ais','am']
conjuga_er = ['o','es','e','emos','eis','em']
conjuga_ir = ['o','es','e','imos','is','em']
termina_em = verbo[-2:]
if termina_em == 'ar':
for terminacao in conjuga_ar:
conjugado.append(verbo[:-2]+terminacao)
elif termina_em == 'er':
for terminacao in conjuga_er:
conjugado.append(verbo[:-2]+terminacao)

3 http://www.microsoft.com
4 http://windowslicensing.msoem.com/portuguese/3mod_operating.asp#use (este link no est mais ativo, mas seu
contedo est armazenado em
http://web.archive.org/web/20020906180605/http://windowslicensing.msoem.com/portuguese/3mod_operating.asp)

Pgina 13 de 117
 elif termina_em == 'ir':
for terminacao in conjuga_ir:
conjugado.append(verbo[:-2]+terminacao)
else:
print 'Tem certeza que '+verbo+' um verbo regular?'
return conjugado

As linhas precedidas de "#" so comentrios, servem para documentar o programa - o computador

no faz nada com elas. As linhas seguintes "ensinam" ao computador que ele deve verificar a
terminao do verbo em "ar", "er" ou "ir" e substituir esta terminao pela da respectiva
conjugao. Assim, o verbo "amar" conjugado da seguinte forma:

Verbo "amar"

Na linha:

if termina_em == 'ar':

O programa passa a saber que as terminaes para o verbo "amar" so:

conjuga_ar = ['o','as','a','amos','ais','am']

Em:

for terminacao in conjuga_ar:

conjugado.append(verbo[:-2]+terminacao)

O que o programa faz pegar o verbo "amar" sem as duas ltimas

letras - verbo[:-2] - e acrescentar a terminao que ele obtm da lista
conjuga_ar.

O resultado :

amo, amas, ama, amamos, amais, amam

O conhecimento que utilizei para criar este programa encontrado em muitos livros de gramtica e
ensinado por nossos professores nos primeiros anos de escola. De forma similar, mesmo os
programas mais complexos so construdos a partir de uma base que o conjunto do conhecimento
humano. A partir de qual momento, ento, torna-se justo tornar proprietrio um programa que usa
em sua construo conhecimento que de domnio pblico? Eu poderia "patentear" o meu simples
"conjugador de verbos", vend-lo a alguma escola e impedir que o mesmo seja modificado e
copiado? Certamente que sim! Muitas empresas fazem isto. Mas isto moralmente aceitvel?
Entre meados dos anos 50 - quando computadores comearam a ser usados comercialmente - at o
final dos anos 60, programas eram livremente trocados entre empresas e programadores com o
incentivo dos fabricantes de computadores. As mquinas eram carssimas e quanto mais programas
estivessem livremente disponveis, mais "valor agregado" percebiam as empresas que eram capazes
de comprar os computadores5. Com a popularizao dos computadores nas empresas e a queda de
seu preo, o software passou a se tornar tambm um negcio e programas que eram livres passaram
a ser comercializados. No meio acadmico, programas ainda eram livremente desenvolvidos e
compartilhados at o final dos anos 70, quando novas mquinas (mini e microcomputadores) com

5 An early history of software engineering by Robert L. Glass -

http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/srinivasan/01-29-1999.html

Pgina 14 de 117
sistemas operacionais proprietrios passaram a se tornar populares. Os sistemas operacionais
proprietrios acabavam por prender seus usurios a um conjunto de ferramentas de produtividade e
desenvolvimento que tinham que ser obtidas dos prprios fabricantes dos computadores ou de
"software-houses" independentes. Em resumo, o software passou a ser vendido quando a margem
de lucro no "hardware" (os computadores) diminuiu. A partir do incio dos anos 80, tornou-se
comum a venda de computadores com software, cujo preo estava embutido no valor do
equipamento. Um usurio leigo, mesmo nos dias de hoje, compra um computador sem saber que
uma grande parcela do que paga no relativa ao equipamento, mas sim aos programas que o
acompanham. Como o mercado de informtica muito novo, especialmente para o usurio
domstico e pequenas empresas que apenas passaram a ter acesso aos computadores na ltima
dcada, a lgica de mercado que se imps predominantemente a de que natural "alugar" um
software como se aluga um apartamento.
No incio dos anos 80, um programador do laboratrio de inteligncia artificial do MIT
(Massachussets Institute of Technology), Richard Stallman, iniciou um movimento que busca
conscientizar as pessoas de que programas de computadores so uma manifestao do
conhecimento humano e, como tal, no podem ser propriedade de ningum. Em 1984 Richard criou
a Free Software Foundation e a licena de uso de programas de computador GPL - General Public
License. Um programa distribudo sob esta licena pode ser copiado, modificado e redistribudo.
Muitos programadores concordaram com as ideias formatadas originalmente por Stallman e hoje
existem programas e sistemas bastante complexos desenvolvidos totalmente em software livre.
Dentre os mais populares esto o sistema operacional Gnu/Linux e o conjunto de aplicativos para
escritrio OpenOffice.Org.
Para que um programa possa ser copiado, basta que isto seja legalmente permitido, uma vez que
qualquer pessoa que possui um computador dona dos meios de produo6 que permitem que a
cpia seja efetuada. O que d o direito legal, ou no, de que o programa seja reproduzido sua
licena de uso. As licenas de software proprietrio limitam, ou efetivamente impedem, que o
mesmo seja copiado. A cpia de um software proprietrio constitui-se em uma ao ilegal chamada
comumente de pirataria, cuja pena inclui multas altssimas e mesmo a priso do infrator7. A licena
de um software livre8 garante a seu usurio o direito de copi-lo, assim, no existe pirataria em
software livre.
Para que um programa possa ser modificado, alm de que isto seja legalmente permitido por sua
licena, necessrio que se tenha acesso a seu cdigo-fonte, sua receita. possvel, por exemplo,
que meu programa "conjugador de verbos" seja estendido para outros tempos verbais, uma vez que
temos acesso "receita" do programa original. Todo o software livre garante acesso a seu cdigo-
fonte e sua licena permite que o mesmo seja, legalmente, modificado, desde que a verso
modificada tambm seja um software livre - isto o que garante que o conhecimento que levou
produo deste software continue de propriedade coletiva e no de algumas poucas pessoas ou
empresas.
Mesmo que voc no entenda nada de programao, o acesso ao cdigo-fonte permite que voc
contrate os servios de quem entende disto para que modifique um programa em software livre,
adequando-o sua necessidade. O modelo de negcios que sustenta empresas e pessoas que vivem
de software livre tem por base a venda de servios. Claro que este modelo no interessa a empresas
que, mesmo com poucos anos de existncia, tornaram-se milionrias (e fizeram milionrios) com a
venda de conhecimento fechado em caixas de contedo idntico que so vendidas milhares de
vezes, e, como so estas as empresas que hoje dominam o mercado de informtica, perfeitamente
6 Liberdade em Software: Direitos, Deveres, Metfora e Ganhando a Vida, Robert J. Chassell -
http://www.brod.com.br/handler.php?module=sites&action=view&news=35
7 Lei de Software - http://www.mct.gov.br/legis/leis/9609_98.htm
8 Licena Creative Commons GPL - http://creativecommons.org/licenses/GPL/2.0/

Pgina 15 de 117
natural uma enorme resistncia e investimentos em propaganda contra o software livre.

Pgina 16 de 117
Eu e o software livre
Pensei em vrios ttulos para este captulo, especialmente um que no parecesse pretensioso ou
egosta. Todos soaram como algum pretensioso ou egosta procurando um ttulo que no fosse
pretensioso ou egosta. Assim, ficou o ttulo acima, que secundrio perante a histria que se inicia
a partir do prximo pargrafo, esta sim, uma verdadeira egotrip.
Em 1988 eu estudava Fsica na UFRGS em Porto Alegre, o primeiro curso superior que no conclui
(na segunda Universidade, comecei este mesmo curso na USP, em So Paulo) e por diletantismo lia
sobre inteligncia artificial e sistemas especialistas. Eu possua um computador MSX, que tinha
entre suas vrias peculiaridades a capacidade de enderear 64 Kbytes de memria, 32 Kbytes por
vez. Um dos programas-exemplo em um dos livros que eu estava lendo simulava um "psiclogo"
conversando com o usurio e tentando, atravs do reconhecimento de uma lista de palavras-chave,
mudar de assunto e fazer perguntas "surpreendentes". O livro era em espanhol e o programa estava
escrito em Basic. Decidi tornar o programa mais interessante transformando o "psiclogo" no
"Analista de Bag", simulando uma conexo com o consultrio do mesmo e trabalhando a lista de
palavras-chave de forma a que, quando usadas, trocavam o "cenrio" da consulta, invariavelmente
levando o consulente a falar da relao que tinha com sua me. O diagnstico da "loucura" ou
"faceirice" do "bagual" era sempre "um causo de dipo". Na poca, eu prestava servios para o
Banco do Brasil, em Porto Alegre, que havia recentemente adquirido microcomputadores cujo
formato de gravao em disquete era o mesmo que o meu MSX. Assim, reescrevi o programa para
que o mesmo cdigo pudesse ser executado em MSX-Basic (minha mquina) e Mbasic (as
mquinas do Banco do Brasil). Isto garantiu-me uma quantidade de usurios que, nas horas vagas
(ao menos acho que eram horas vagas), podiam brincar com o meu programa e contribuir com
sugestes. O programa passou a armazenar a conversa dos usurios e apontar palavras mais usadas,
que passaram a ser usadas como palavras-chave em novas verses. Nas ltimas verses, era capaz
de armazenar declaraes do consulente que continham algumas palavras-chave, lembrar delas e
fazer perguntas com base nas mesmas. Por exemplo: se o consulente digitasse "No convivo bem
com minha famlia", a palavra "famlia" era uma das palavras-chave e o verbo "conviver" estava na
lista de conjugaes. Assim, mais adiante o "analista" poderia perguntar algo do tipo "Antes disseste
que no convives bem com tua famlia, explica melhor...". Esta utilizao de elementos que eram
inseridos pelo prprio consulente, junto a cenrios que poderiam vir tona aleatoriamente ou
atravs do reconhecimento de palavras-chave tornou o sistema bastante interessante, um brinquedo
agradvel. Como me apropriei indevidamente do "Analista de Bag", eu distribua o programa em
disquete, com instrues, cdigo-fonte e recomendaes para que o usurio comprasse a obra do
escritot Lus Fernando Verssimo, na esperana de nunca ser processado pelo mesmo.
O tempo passou, perdi contato com as pessoas que trabalhavam comigo na poca, e, infelizmente, a
ltima cpia que eu tinha do programa foi doada por descuido junto com o meu MSX em um
disquete que foi formatado e aproveitado para alguma outra coisa. H algum tempo, tentei fazer
uma "busca do software livre perdido". Fiquei sabendo que algum colocou o meu programa para
rodar em uma implementao de BASIC para o ambiente /370 da IBM, por volta de 1992 e que o
mesmo podia ser acessado atravs de terminais 3270, mas nunca mais tive acesso ao programa, que
um dia espero reescrever, talvez em Python.
Desde que conclu o curso tcnico em eletrnica, em 1982, passei a trabalhar na rea de suporte
tcnico, onde era bastante comum entre os colegas a troca de informaes e pequenos programas
que nos ajudavam na soluo de problemas, ainda que alguns poucos colegas preferissem "esconder
o ouro". Quando escrevi o "Analista de Bag - o programa" jamais cheguei a pensar em ganhar
dinheiro com ele, uma vez que, a rigor, nenhuma das ideias que usei nele eram novas, mesmo que
eu as houvesse combinado de maneira criativa. O fato de eu ter distribudo o "Analista" como um

Pgina 17 de 117
software livre foi mais uma questo circunstancial, ainda que reflexo da forma como eu j pensava,
do que algum compromisso filosfico que acabei por abraar mais tarde.
Meu primeiro contato com o software livre, conforme definido e protegido pela Free Software
Foundation, tambm foi casual (no que eu acredite em casualidade ou destino, mas isto tambm j
outra histria): no incio de 1993 eu estava trabalhando na Tandem Computers (hoje a diviso de
produtos NonStop da HP), que havia vendido um sistema Unix Telemig, em Minas Gerais. Eu
havia pedido a meu chefe que adquirisse uma licena do SCO-Unix para que eu rodasse em meu
laptop (precursor do notebook) e assim pudesse simular situaes e problemas que tnhamos na
instalao em Minas. O custo do SCO-Unix, porm, fez com que meu chefe negasse o pedido e que
eu fosse atrs de outras alternativas. Havamos, recentemente, instalado um link de 64 Kbps com
nossa matriz, na Califrnia e eu j havia aprendido com a equipe tcnica da empresa como usar este
link para ter acesso Internet (ainda uma pequena parcela do que hoje) e aos grupos de notcias
(USENET). Usando ferramentas como o Gopher e o Archie (precursores dos mecanismos de busca
atuais) acabei descobrindo informaes sobre o Minix e posteriormente sobre o Linux, sistemas
Unix que eu poderia instalar em meu laptop sem nenhum custo. Fiz o download do Linux com um
conjunto de GNU tools de uma Universidade da Califrnia e, seguindo algumas instrues,
consegui fazer com que o GNU/Linux rodasse em meu laptop sem maiores traumas, para meu
deleite e a total incompreenso da grande maioria dos meus colegas de trabalho, que no entendiam
o porque da minha felicidade com aquilo que "mais parecia o DOS". Mas eu sabia! Eu tinha um
Unix!
Com o aumento da equipe tcnica da Tandem, chegamos a ter um pequeno "grupo de usurios" que
em 1995 j rodava o Linux com o Xfree86 (modo grfico) e fazia uma srie de experincias
interessantes, especialmente com as mquinas em rede.

Pgina 18 de 117
O software livre na Univates
Em 1996, com verbas da Rede Tch (RNP), a Univates9 conectou-se Internet e implementou seu
provedor de acesso. Fbio Wiebbelling (hoje empresrio, proprietrio da ITS) foi Porto Alegre
fazer um curso de Linux na UFRGS com a Professora Liane Tarouco10, depois de j ter tido alguma
experincia com o Solaris em uma mquina da Sun Microsystems.
Tambm em 1997 eu comeava a planejar meu retorno para o sul, especialmente para o Vale do
Taquari, investindo junto com outros scios, na criao de um provedor de acesso Internet11, que
acabou unindo foras com o provedor da Univates. Durante o final de 1997 e o incio de 1998, eu e
o Fbio, interagamos bastante na manuteno do provedor e trocvamos muitas idias sobre a
possibilidade de adoo do GNU/Linux em maior escala pela Univates. Entre 1997 e 1999, sob a
coordenao do Fbio, todos os servidores que usavam sistemas operacionais proprietrios na
Univates foram substitudos por servidores GNU/Linux. Na mesma poca eu deixava a sociedade
no provedor de acesso para fundar a Brod Tecnologia12 e dedicar-me consultoria e
desenvolvimento de solues em software livre. Em agosto de 1999, eu e o Fbio, viajamos para a
Califrnia para participar da LinuxWorld Conference and Expo onde, dentre outras coisas,
participamos de tutoriais sobre PHP e MySQL. Em outubro de 1999, a Brod Tecnologia foi
contratada para assumir a gesto dos recursos de informtica da Univates, intermediando tambm a
relao da instituio com a Solis, Cooperativa de Solues Livres13, sobre a qual escrevo no
captulo [completar aqui], quando propusemos a migrao do sistema acadmico/administrativo
existente e desenvolvido em software proprietrio para um novo sistema, a ser desenvolvido
internamente, totalmente em software livre. Como o sistema existente j estava dando sinais de que
no aguentaria o crescimento em sua base de dados que seria causado por novas matrculas de
alunos e uma alternativa comercial proprietria implicaria em investimentos da ordem de R$
100.000,00, no mnimo, obtivemos a autorizao da reitoria para tocar o projeto que mais tarde foi
batizado de Sagu.
Ainda no final de 1999, a Univates havia feito um investimento na ampliao de sua estrutura de
informtica, com a instalao de mais de 100 novas mquinas desktop. Decidimos que no
adquiriramos licenas de softwares de produtividade e escolhemos o StarOffice como padro. A
razo, pela qual justificamos esta escolha foi o custo do pacote equivalente, enquanto o StarOffice
era distribudo gratuitamente pela Sun Microsystems. A principal vantagem tcnica do StarOffice,
porm, a de que o mesmo possua uma interface consistente independente do sistema operacional
adotado, o que veio a permitir a migrao do sistema operacional das mquinas dos usurios para o
GNU/Linux.
Mesmo considerando as dificuldades iniciais em qualquer migrao de ambiente, o sucesso na
adoo do software livre na Univates motivou o desenvolvimento de novos sistemas como o
Gnudata14,o Gnuteca15 e especialmente o framework Miolo16 entre tantos outros, assim como a
utilizao de outros softwares livres desenvolvidos externamente, especialmente os sistemas
Teleduc17 e Rau-Tu18, originados na UNICAMP.
9 http://www.univates.br
10 http://penta.ufrgs.br/liane.html
11 http://www.bewnet.com.br/
12 http://www.brod.com.br
13 http://www.solis.coop.br
14 Infra-estrutura para a implementao de bases de dados analtico-estatsticas usada no Banco de Dados Regional da
Univates - http://www.bdr.univates.br
15 Sistema de gesto de acervo, emprstimos e colaborao para bibliotecas - http://gnuteca.codigolivre.org.br
16 http://www.miolo.org.br
17 Sistema para a educao distncia - http://teleduc.nied.unicamp.br/teleduc/
18 Sistema para a criao de bases de conhecimento - http://www.rau-tu.unicamp.br

Pgina 19 de 117
Os reflexos da adoo do software livre na Univates so visveis at hoje. Vrias empresas
incubadas na Inovates, a incubadora empresarial da instituio, so usurias ou desenvolvedoras de
softwares livres. Marcelo Malheiros, que desenvolveu os projetos Rau-Tu e Nou-Rau, idealizados
por Rubens Queiroz de Almeida, da UNICAMP, hoje coordenador dos cursos de informtica da
Univates. O Ncleo de Tecnologia da Informao da instituio, o antigo CPD, desenvolve a quase
totalidade dos sistemas internos com softwares livres como a linguagem PHP e a base de dados
PostgreSQL. A prpria Solis ainda uma das grandes fornecedoras de servios de suporte em
infraestrutura para a Univates.
muito difcil imaginar, hoje, o que poderia ter acontecido caso uma fortuita srie de fatores no
houvessem se combinado no final dos anos 1990 e princpio dos anos 2000, justamente tendo a
Univates como cenrio. verdade que constru um projeto pessoal e profissional onde imaginava
desenvolver solues a partir de tecnologias livres e eu precisava de um ambiente, como a Univates,
que servisse de terreno intelectualmente frtil onde estas ideias pudessem ser semeadas. H alguns
anos antes, em 1995, ainda na Tandem, eu havia participado de um treinamento chamado Solution
Selling19, onde aprendamos tcnicas para uma venda honorvel, na qual cliente e fornecedor
sairiam sempre ganhando. Ao rever o material para este livro noto o quanto este treinamento ficou
carimbado na minha mente e o quanto ele influenciou minha tcnica de venda e at de gesto de
desenvolvimento. As tcnicas ensinadas no Solution Selling visam habilitar o vendedor a
entender a dor de seu cliente e, a partir da, buscar a melhor cura para esta dor, sempre
reconhecendo que quem conhece efetivamente a dor que sente o prprio cliente.
Mas analisando mais profundamente o que coloco no captulo Vendendo a ideia, vamos rever a
construo do ambiente favorvel na Univates para que a ideia da adoo de solues em software
livre fosse comprada pela instituio.
Quando desenvolvemos um projeto em software livre, ele ser bem sucedido se:

1. a equipe est engajada, comprometida com ele, entende a filosofia do software livre e com
isto est disposta a trabalhar de forma colaborativa, mesmo com pessoas externas equipe;
2. a equipe tenha f e respeito em seu lder, que deve entender que est coordenando um
projeto que pode ter colaborao que est alm de sua gesto;
3. que toda a estrutura organizacional superior o apoie e saiba que no dona do que est
sendo desenvolvido.

O Grupo de Usurios Gnurias

Ningum sabia muito bem o que era software livre no incio dos anos 2000. O projeto que
comevamos a desenvolver na Univates, implicando no desenvolvimento e na adoo de softwares
livres exigia que, rapidamente, consegussemos aliados nossa causa. A quase totalidade das
pessoas que trabalhavam conosco no CPD era formada por alunos da instituio. Em especial,
nossos monitores de laboratrios tinham que, ao mesmo tempo que aprendiam a usar o Linux e o
StarOffice (que depois tornou-se o OpenOffice.Org), lidar com a resistncia dos seus colegas
usurios dos laboratrios, acostumados a usar os softwares da Microsoft em suas casas e exigiam
que a instituio lhes oferecesse o mesmo tipo de ferramentas.
Tomamos uma srie de aes para minar esta resistncia, garantir o engajamento no s da equipe
mas tambm da maior parte possvel dos usurios e evangelizar as pessoas na filosofia do software
livre. Ministramos cursos internos sobre o uso das ferramentas, promovemos seminrios e
buscamos que nossa equipe participasse dos eventos sobre software livre que comeavam a surgir

19 http://en.wikipedia.org/wiki/Solution_selling

Pgina 20 de 117
no Brasil. Eu sempre buscava que, cada coisa que aprendssemos, descobrssemos ou
desenvolvssemos ganhasse o formato de um artigo ou palestra que pudesse ser apresentado em
algum evento. Como tudo era muito novo, nossa produo era intensa e muitos da nossa equipe
palestraram e participaram de eventos em vrios lugares do Brasil e do mundo. S estas histrias
dariam um livro parte, mas vou concentrar-me na histria do grupo de usurios Gnurias.
Desde a primeira edio do Frum Internacional de Software Livre a nossa equipe do CPD da
Univates participou ativamente do evento, desde a apresentao de palestras at o suporte
estrutura de acesso Internet. Durante a segunda edio, em 2001, eu e a Ana Paula Arajo, a Preta,
assistamos a uma palestra do grupo LinuxChix20 e ela teve a ideia de criarmos um grupo com uma
ao mais local, com foco menos tcnico e mais inclusivo, com aes de popularizao do uso de
tecnologias livres. Na mesma hora sugeri o nome Gnurias e a coisa pegou. Em um primeiro
momento a Preta, a Joice Kfer, a Ana Paula Fiegenbaum, a Viviane Berner e a Marceli Arnhold
formaram o grupo do qual fui nomeado, orgulhosamente, padrinho.
Dentre as aes do grupo estavam a Semana do Pinguim, que entre 2002 e 2004 acontecia todos
os semestres na Univates, em 2005 passou a ser anual e em 2006 teve a sua ltima edio. Durante
a Semana do Pinguim vinham para a Univates palestrantes de vrios lugares do Brasil falar sobre
suas experincias com o uso de software livre, o que servia como um grande incentivo aos alunos
da Univates. Na edio de 2006 fomos alm do software livre, com oficinas sobre pandorgas e
rdios de galena.
Em parceria com uma escola municipal de nossa regio, o grupo ministrou oficinas de informtica
para crianas, sempre com a ideia da tecnologia tornar-se um elemento de apoio na aprendizagem
das matrias que j eram ministradas na escola. Alm disto, em outras escolas foram ministradas
oficinas de criao de pginas web, de uso do OpenOffice.Org, de ferramentas educacionais como o
gCompris e muitas outras. Em parceria com a Univates as meninas do grupo ainda deram aulas de
informtica para as pessoas da melhor idade, ensinando os vovs e vovs a trocarem e-mails com
seus filhos e netos, muitas vezes distantes e com os quais h muito no se comunicavam.
Acredito que a ltima ao do grupo foi um curso que ministramos para jovens desempregados, em
2007, em uma parceria com o SINE da cidade de Arroio do Meio, onde em uma semana dvamos
aos jovens elementos para que eles pudessem enriquecer seus currculos com o conhecimento
bsico de ferramentas de informtica para o uso em escritrios. A produo do currculo era, em si,
um dos elementos do curso.
Infelizmente o grupo Gnurias foi minguando na medida em que suas componentes se formaram,
saram de Lajeado ou comearam outros empreendimentos. Por alguma razo para a qual ainda
buscamos explicao, no conseguimos manter aceso o entusiasmo do grupo e fazer com que o
mesmo sobrevivesse com novos membros. Ainda assim, de uma forma ou outra, as aes
voluntrias continuaram acontecendo de uma forma ou outra com a participao de uma ou outra
componente do grupo.
O Gnurias foi, entretanto, fundamental quanto disseminao e o engajamento com a cultura do
software livre enquanto desenvolvamos nossos projetos na Univates.

Sagu Workshop e SDSL

Na gesto de qualquer projeto inovador necessria uma grande capacidade de liderana. No caso
de um projeto com software livre eu ouso dizer que o gestor deve ser quase um lder espiritual, um
grande motivador da equipe. Alm disto, a equipe deve estar sempre aberta colaboraes externas,
vindas de descobertas de cdigos melhores j produzidos por outros ou mesmo pela colaborao

20 http://www.linuxchix.org/

Pgina 21 de 117
espontnea na forma de cdigo ou crticas. Busco exercer a liderana de forma a permitir que todos
na equipe tenham voz e sejam valorizados pelo seu talento. Sempre que possvel, exponho este
talento ao reconhecimento externo, de desconhecidos. O que pode parecer a um novo colaborador, a
princpio, assustador, acaba por ser muito gratificante quando outros, alm da equipe, passam a
valorizar o seu talento.
Quando estvamos ainda no incio do desenvolvimento do Sagu, nosso sistema de gesto acadmica
sobre o qual falaremos mais adiante, decidi que, antes de colocar o sistema em produo,
ofereceramos comunidade o Sagu Workshop, onde contaramos a todos o que estvamos fazendo,
incluindo nossas motivaes e expondo o nosso cdigo. Em maro de 2000 ministramos o primeiro
Sagu Workshop na Univates, com 20 participantes vindos de todos os lugares do Brasil uma
tremenda surpresa para ns! Durante uma semana ministramos oficinas de PHP, PostgreSQL e
mostramos como o Sagu, que ainda entraria em produo em julho do mesmo ano, funcionaria. O
sucesso foi tanto que ainda tivemos mais duas edies do Sagu Workshop, at ele tornar-se o SDSL
Seminrio de Desenvolvimento em Software Livre, evento que era organizado em parceria com a
Univates, Unisinos e Unicamp e mais adiante, teve a parceria tambm da UnB.
Ainda que a contribuio direta ao cdigo do Sagu (e de outros sistemas que desenvolvemos
depois) no tenha sido muito grande, a contribuio indireta na forma de troca de ideias sobre o
melhor uso do PHP, do PostgreSQL e outros componentes do sistema sempre foi de valor
inestimvel. A exposio dos desenvolvedores s ideias e cdigos alheios faz com que o apego ao
prprio cdigo diminua em funo do amor maior a um conhecimento que pode ser construdo
coletivamente.

A Univates como referncia, no como proprietria

Quando assumi a gesto de TI da Univates a dor relativa ao sistema acadmico existente era
muito presente e forte. Ele j mostrava sinais de desgaste e simplesmente no suportaria o volume
de dados que seria gerado a partir do vestibular de inverno de 2000. Eu e o Fbio Wiebbelling
embasamos muito bem nossa proposta de construo de um novo sistema acadmico utilizando
softwares livres e o modelo do sistema anterior, bem conhecido pela equipe de desenvolvimento
que estava na instituio. Como a Univates estava em um momento de crescimento, com
necessidade de investimento financeiro nas mais variadas reas (em especial, na construo de
novos espaos para acomodar os novos alunos), nossa proposta, ainda que temerria, veio a calhar.
Hoje, revendo tudo o que passou, vejo que qualquer outra proposta seria to temerria quanto a
nossa, mas a nossa foi a mais transparente e sincera, oferecendo uma nova tecnologia para a
construo de uma soluo que aproveitaria o conhecimento adquirido na soluo existente.
Obviamente, era tambm a mais barata.
O apoio da organizao existiu desde o princpio, o que no impediu repetidas perguntas sobre a
propriedade do que estava sendo desenvolvido, um assunto eternamente retomado por muitos anos.
No sei se at hoje.
Nossa equipe que j desenvolvia o Sagu e outros sistemas tinha a plena conscincia de que havia se
apropriado de uma srie de coisas para poder escrever o Sagu, a comear pela prpria linguagem de
programao, o PHP, e a base de dados, o PostgreSQL, sem contar com a infinidade de bibliotecas
para a gerao de documentos, autenticao de usurios, e a lista segue interminvel. Este era um
dos argumentos que usvamos para dizer que o Sagu (e outros sistemas produzidos por ns)
deveriam ser entregues comunidade como software livre, da mesma forma que nos apropriamos
de seus componentes. Mas o argumento mais forte sempre foi comparar nosso modelo de
desenvolvimento ao prprio modelo de negcio da instituio, que era o de formatar o
conhecimento para fornecer a seus alunos, sem ser necessariamente a dona do mesmo. Esta
argumentao ficou mais fcil quando passamos a usar sistemas desenvolvidos por outras

Pgina 22 de 117
instituies, como o Teleduc e o Rau-Tu.

Pgina 23 de 117
O desenvolvimento do Sagu
Ainda antes da efetiva contratao da BrodTec pela Univates, o trabalho junto ao CPD da
instituio acabou fazendo com que eu fizesse uma srie de pequenos trabalhos pontuais de
consultoria e efetivas intervenes no ambiente de informtica da instituio em conjunto com o
Fbio Wiebbelling, chefe do CPD e uma das pessoas que mais conhece o ambiente GNU/Linux em
todo o mundo mesmo nos dias de hoje. Quando fomos juntos LinuxWorld Expo na Califrnia, em
1999, j tnhamos como misso levantar alternativas para o desenvolvimento de um novo sistema
administrativo, uma vez que o que estava sendo usado, baseado em softwares proprietrios,
comeava a dar sinais de que sua vida estava chegando ao final. Contnuos problemas de
instabilidade do sistema indicavam que conseguiramos mant-lo com alguma confiabilidade apenas
at meados de 2000. O incremento da base de dados com as matrculas que seriam efetuadas no
vestibular de inverno daquele ano levariam o sistema ao colapso. Mesmo antes disto, enquanto o
Sagu j estava sendo desenvolvido, sofremos problemas de corrupo da base de dados que nos
obrigaram algumas vezes a restaurar backups de dois ou trs dias anteriores aos problemas, limpar a
base (muitas vezes limitando o acesso de usurios informaes histricas) e voltar o sistema
ativa com riscos cada vez maiores. Por outro lado, o modelo ER (Entidade Relacionamento, sobre o
qual estarei falando no captulo [aqui]) usado para a construo do sistema havia sido muito bem
projetado pelo Professor Luciano Brando (hoje scio da OM Informtica), auxiliado pelo Maurcio
de Castro (hoje scio da Sol7) e pelo Carlos Bush (hoje gerente de solues e inovaes da
Processor) e foi essencial para o rpido desenvolvimento do Sagu, uma vez que o adotamos quase
integralmente.
Na LinuxWorld, enquanto o Fbio concentrava-se na aquisio de experincias e troca de idias em
implementao de ambientes seguros de redes e desempenho, eu pesquisava linguagens e bases de
dados em software livre que fossem boas alternativas para o nosso desenvolvimento. Foi quando
tomei maior contato com o PHP e pude ver a facilidade e velocidade que a linguagem permitia na
criao de aplicaes voltadas para a web, que j era o nosso desejo. Passamos noites muito
divertidas no Motel 6, debruados em cima do nico livro sobre PHP que havia disponvel [citar o
livro] e testando uma srie de conceitos necessrios ao desenvolvimento do nosso novo sistema.
Quando retornamos ao Brasil, apresentamos nossas ideias ao CPD e montamos um projeto de
migrao que levamos reitoria. O projeto consistia em desenvolver um novo sistema que
replicasse toda a funcionalidade do existente e desse espao para novas implementaes de forma
segura e com boa escalabilidade. Isto deveria ser feito em menos de seis meses. Assim, a
consultoria da BrodTec foi contratada em regime integral e o projeto comeou. Lembro que o
Professor Eloni Salvi, nosso pr-Reitor administrativo e financeiro, que efetivamente convenceu
seus colegas na reitoria disse a mim e ao Fbio na aprovao do projeto: Senhores, vossa cabea
acaba de ser colocada prmio e, junto delas, a minha.... Como vocs esto lendo este texto,
podem concluir que nossas cabeas esto salvo, ainda que envolvidas em novos projetos.
O Sagu comeou a ser desenvolvido com as seguintes premissas:
Independncia de base de dados: Como os problemas que enfrentvamos no sistema
antigo eram em grande parte devidos amarrao que tnhamos com uma base de dados
proprietria, o novo sistema nos deveria permitir a fcil migrao para qualquer outra base
caso isto se mostrasse necessrio.
Interface Web: Os usurios deveriam poder acessar o sistema independente do sistema
operacional que rodassem em seus computadores e o novo sistema tambm deveria permitir
que no futuro migrssemos as estaes dos clientes tambm para software livre (o que
comeou a ser feito em janeiro de 2000). A melhor maneira de se conseguir isto era

Pgina 24 de 117
 utilizando um browser padro (na poca o Netscape ou o Internet Explorer) como cliente.
Modularidade: O sistema seria dividido em mdulos especficos e bem definidos, de forma
que o processo de desenvolvimento pudesse ser melhor dividido entre os membros da equipe
e facilitasse a colaborao de outras pessoas.
Em janeiro de 2000 o novo sistema processou em paralelo o vestibular de vero da Univates, com
sucesso e velocidade superiores ao esperado. Processamentos de classificao que levavam mais de
trs horas no sistema anterior, em um servidor Pentium II 400 com 512 Mbytes de memria,
demoravam apenas alguns minutos em uma mquina Pentium 200 com 64 Mbytes de memria
usada nos testes (o valoroso desktop do Maurcio!).
O sistema foi batizado de Sagu (inicialmente um acrnimo para Sistema Aberto de Gesto
Universitria e hoje Sistema Aberto de Gesto Unificada) pelo Professor Eloni Salvi quando
precisamos de um nome para apresentar o projeto21 no Workshop de Software Livre, que ocorreu
em paralelo ao 1.o Frum Internacional de Software Livre, nos dias 4 e 5 de maio de 2000.
O Sagu entrou em produo em julho de 2000 e at a sua substituio pelo projeto Alpha,
desenvolvido internamente pela Univates, foi o responsvel pela automao do relacionamento
acadmico/administrativo e financeiro de mais de 10.000 alunos com a Instituio de Ensino. Ainda
hoje, o Sagu um dos carros-chefe do faturamento da Solis.

A arquitetura inicial do Sagu

O desenvolvimento do Sagu deu-se em tempo recorde, aproveitando a modelagem da base de dados
do sistema anterior. Se por um lado, isto nos permitiu colocar o Sagu em produo na Univates em
menos de seis meses, por outro herdamos uma estrutura de dados que no era a mais adequada ao
crescimento e ao desenvolvimento cooperativo do sistema. Para a equipe do Sagu era relativamente
simples olhar o modelo ER (Entidade-Relacionamento) da base de dados e entender as necessidades
de negcio atendidas por este modelo. Para quem estava de fora, porm, um conjunto de tabelas e
seus relacionamentos no ilustram de maneira fcil a finalidade do Sagu.
O Sagu possua um mdulo de abstrao da base de dados (DBAL - Database Abstraction Layer),
que consistia no programa common.php3 e permitia que o sistema utilizasse outras bases de dados
que no o PostgreSQL (ainda que, na prtica, isto no tenha sido feito). Cada um dos mdulos do
Sagu, porm, era responsvel pelo acesso base de dados e interface com o usurio.

21 http://www.inf.unisinos.br/~marinho/Teaching/local/WSL2000/Definitivo/016-brod.ps

Pgina 25 de 117
Arquitetura Miolo
Com o Sagu j em produo, na segunda metade do ano 2000 iniciamos a produo de um sistema
para o Banco de Dados Regional do Vale do Taquari22, hospedado na Univates. Durante o
desenvolvimento deste sistema acabamos aproveitando muito do cdigo desenvolvido para o Sagu e
comeamos a sistematizar melhor o nosso desenvolvimento. Em 2001 convidamos algumas pessoas
externas instituio, como o desenvolvedor Alessandro Binhara, o Prof. Leandro Pompermayer e
o consultor Thomas Sprietersbach (que nos ajudou tambm em inmeras outras ocasies) para que
tomassem conhecimento do que estvamos desenvolvendo e pudessem contribuir com suas
sugestes. O resultado concreto deste workshop interno de transferncia de tecnologia foi o
framework de desenvolvimento Miolo, base da nova verso do Sagu e de praticamente todas as
solues desenvolvidas pela Univates e posteriormente pela Solis. Durante o desenvolvimento do
Miolo tivemos tambm a honra de ter contribuies diretas de Rasmus Lerdorf, criador da
linguagem PHP, que trabalhou com nossa equipe, em Lajeado, por cerca de dez dias.
As seguintes premissas foram a base para o desenvolvimento do Miolo:
a documentao do sistema deveria ser clara e criada de maneira dinmica, ao mesmo
tempo em que o sistema desenvolvido;
o framework deveria tratar todas as questes de segurana e perfis de usurios,
isolamento e comunicao entre os mdulos desenvolvidos com ele;
os mdulos funcionais que compem os sistemas a serem desenvolvidos deveriam refletir
a necessidade de negcio que atendem, de tal maneira que, quem os programe, no
precise necessariamente conhecer a base de dados;
a construo da interface de usurio deveria poder ser feita por um webdesigner, que no
necessitasse conhecer a fundo as caractersticas internas do sistema.
Desta forma, conseguiramos dividir melhor as tarefas de desenvolvimento do Sagu e de outros
sistemas. Um designer, por exemplo, poderia concentrar-se em criar uma interface agradvel para o
usurio, sem ter que conhecer a base de dados. Um administrador de base de dados poderia
concentrar-se em aspectos de performance da base, no necessitando conhecer profundamente os
programas que a acessam.
Assim, a nova arquitetura proposta para o Sagu, com o framework Miolo, passou a ser a seguinte:

Note que agora, seguimos com o modelo de abstrao de base de dados, mas no mais na forma de
22 http://www.bdr.univates.br/

Pgina 26 de 117
um programa como na verso anterior do Sagu, mas sim atravs de uma srie de objetos fornecidos
pelo framework Miolo que fazem a conexo e demais funes de armazenamento e busca de
informaes na base. Outros objetos do Miolo permitem a construo da lgica de negcio, sempre
usando o paradigma de orientao objetos. A forma como a comunicao com o usurio ser feita
pelo programador da lgica de negcio, mas a interface pode ser feita por um webdesigner, atravs
do uso de temas e folhas de estilo, que podem ser coerentes para todos os mdulos do sistema, ou
diferenciados, de acordo com as necessidades e caractersticas dos usurios.

Pgina 27 de 117
Gnuteca um teste de conceito para o Miolo
Neste captulo comeo a tratar mais explicitamente questes de gesto e metodologia de
desenvolvimento, falando tambm sobre as opes que sempre se apresentam e as decises que
temos que tomar, mesmo sem termos todos os elementos para tal.
Quando desenvolvemos o Sagu na Univates, tnhamos uma presso tremenda de tempo em funo
da necessidade do esgotamento do sistema administrativo usado anteriormente. Aproveitamos o
modelo ER deste sistema anterior, buscamos mapear o mximo possvel s telas da interface web
para que tivessem alguma similaridade aplicao com a qual os usurios j estavam acostumados
e entre janeiro e julho de 2000 o sistema foi desenvolvido e entrou em produo. Durante este
perodo, nossa equipe ainda estava aprendendo a usar a linguagem PHP. No houve um rigor maior
na documentao do sistema ou mesmo uma preocupao com sua possibilidade de seu
crescimento. Ainda assim, o Sagu provou-se vivel e fomos agregando a ele uma srie de
funcionalidades e adicionando usurios ao sistema. Sabamos que teramos que reescrev-lo desde o
princpio e esta foi uma das principais razes de termos criado o framework Miolo. Mas o Sagu
tinha uma complexidade tal que preferimos optar por amadurecer o Miolo com o desenvolvimento
de uma aplicao nova, o Gnuteca.
O Gnuteca23 um sistema em software livre composto de mdulos para gerir acervos bibliogrficos,
controlar emprstimos, pesquisar em bases bibliogrficas e administrar o sistema de forma local e
remota, promovendo maior agilidade e qualidade aos servios prestados por bibliotecas, assim
como prover o fcil intercmbio de informaes com outros sistemas de Bibliotecas, mantendo-se
dentro de normas internacionais ISO e do padro internacional de catalogao MARC 21. um
sistema abrangente e genrico que pode moldar-se a diferentes realidades de diferentes usurios,
permitindo tambm a criao de uma infraestrutura de colaborao entre bibliotecrios e demais
funcionrios das bibliotecas, evitando a repetio desnecessria de trabalho: uma vez feita a
catalogao de um ttulo em uma biblioteca, estes dados catalogrficos podem ser "importados"
para o sistema de outra biblioteca que adquira o mesmo ttulo.
Com a integrao de novas pessoas ao nosso CPD e j com alguma perspectiva de agregar
desenvolvedores externos a nossos projetos, decidimos adotar alguma metodologia consagrada que
nos permitisse documentar nossos sistemas, facilitando a interao com os usurios (clientes) e a
comunicao de necessidades e resultados ao pblico externo. Optamos por utilizar a UML (Unified
Modeling Language) como padro de desenvolvimento e algumas caractersticas de Extreme
Programming (XP)24 como padro de atitude.
Antes de iniciar o projeto, realizamos uma oficina prtica de UML e orientao objetos para trazer
nossa equipe a experincia de profissionais da rea de anlise e projeto de sistemas. Esta oficina
acabou por definir muitos dos conceitos que seriam aplicados ao Gnuteca.
Quem deve definir o que o sistema far quem ir utiliz-lo. Assim, o Gnuteca iniciou-se com o
levantamento de todos os processos utilizados em uma biblioteca, desde a forma de catalogao de
acervo e seus padres at a interao com o usurio no balco de atendimento, passando por
consultas ao acervo, relatrios e o relacionamento com outros sistemas. Tudo isto foi documentado
em "casos de uso", "diagramas de sequncia", "diagramas de classe" e "diagramas de atividade".
Alm de envolvermos o cliente interno (nossas bibliotecrias e funcionrios) no processo, contamos
com a consultoria da Control25 e com a participao de vrios bibliotecrios que comearam a
contribuir com sugestes a partir da apresentao do projeto conceitual em 13 de junho de 2001 na

23 http://www.gnuteca.org.br
24 http://www.extremeprogramming.org/
25 http://www.control.com.br/

Pgina 28 de 117
sede da Control em Porto Alegre. O cdigo-fonte em produo foi sempre disponibilizado
prematuramente no site do projeto, a fim de que a comunidade pudesse acompanhar sua evoluo,
ainda que em estgios no funcionais.
O Miolo foi utilizado para o desenvolvimento do mdulo Web de interao com o aluno (pesquisas,
renovaes, reservas), assim como para os mdulos de administrao e catalogao, acessados
pelos bibliotecrios atravs da Intranet. Para os mdulos usados no balco de atendimento
escolhemos o PHP-GTK26.
Nota: Pablo Dall'Oglio, da equipe de desenvolvimento do Gnuteca, hoje proprietrio da
empresa Adianti e o principal autor brasileiro sobre PHP-GTK e orientao a objetos com
a linguagem PHP.
O Gnuteca, entrou em fase de testes no campus da Univates da cidade de Encantado em outubro de
2001. Nessa fase foram realizados diversos ajustes ergonmicos e operacionais do sistema de
acordo com solicitaes dos nossos usurios. Em 25 de fevereiro de 2002 o sistema entrou em
produo no campus central da Univates atendendo a mais de 5 mil usurios com um acervo de
mais de 50 mil exemplares.
Ainda que eu retome mais adiante este assunto, j adianto que o custo de desenvolvimento do
Gnuteca at a sua primeira verso no chegou a R$ 50.000,00 (dados de meados de 2002) e que o
mesmo no possui nenhum pr-requisito que exija o pagamento de licenas, independente do
nmero de usurios ou o acesso base de dados.

26 http://gtk.php.net At onde tenho conhecimento, o sistema de atendimento em balco do Gnuteca o maior projeto
j escrito em PHP-GTK

Pgina 29 de 117
Utilizando a UML
Antes de comear este captulo j vou dizendo que no est no escopo deste livro ensinar a utilizar a
UML. Para isto h uma vasta documentao na web27 e tambm impressa qual eu no teria muito
o que acrescentar. A UML tambm no a nica forma de se modelar o desenvolvimento de um
sistema, mas , com certeza, uma das mais utilizadas. Uma das principais vantagens da UML a de
que, atravs de seus diagramas, podemos evoluir desde uma documentao grfica que os usurios
do sistema entendem at um diagrama de sequncia que se aproxima bastante da forma como o
programa ser escrito com o paradigma de orientao a objetos. Outra questo, por vezes difcil de
admitir, a de que programadores dificilmente gostam de documentar os sistemas que
desenvolvem. Na verdade, quanto mais especializados se tornam os programadores, menos ainda
eles gostam de documentar os sistemas. Por isto importante que se incentive, cobre e motive uma
boa documentao inicial dos sistemas a serem desenvolvidos, antes que os programadores
comecem a codificar. Posteriormente, busca-se incluir processos de documentao automtica e o
envolvimento de uma pessoa que se encarregue de manter a documentao atualizada, mesmo que
os programadores no o faam. Esta uma tarefa bastante rdua.
Um outro benefcio da UML o fato de existirem alguns programas em software livre que
permitem a modelagem de uma maneira bastante prtica e at agradvel. No desenvolvimento do
Gnuteca optamos por utilizar o Dia28. No site oficial do Gnuteca (www.gnuteca.org.br) esto
disponveis alguns dos diagramas UML utilizados no desenvolvimento do sistema.

Mas o que a UML afinal?

A UML, Unified Modeling Language (Linguagem Unificada de Modelagem) uma proposta do
OMG29, Object Management Group (Grupo de Gesto de Objetos) visando criar um padro de
documentao para o desenvolvimento de sistemas, facilitando sua compreenso entre grupos de
desenvolvedores e a interoperabilidade entre os sistemas desenvolvidos. As especificaes do OMG
acabaram por se tornar padres de fato mesmo no desenvolvimento de sistemas em software livre,
uma vez que as mesmas esto livremente disponveis para download no portal da organizao.
Na prtica, a UML permite ao desenvolvedor uma linguagem com a qual ele pode ao mesmo tempo
ir fazendo uma montagem mental do sistema a ser desenvolvido enquanto o prprio usurio pode
entender o que est sendo desenvolvido e assim interagir com o desenvolvimento.
Normalmente, o primeiro diagrama com o qual trabalhamos na UML justamente o de Use Cases
(Casos de Uso), usado para a obteno de requerimentos para o sistema a ser desenvolvido.

27 Comece por este link: http://www.uml.org e siga para Getting Started With UML
28 http://www.gnome.org/projects/dia/
29 http://www.omg.org

Pgina 30 de 117
O diagrama acima ilustra um ator, no caso um usurio da biblioteca conectado ao sistema atravs
da Internet. Dentro de cada elipse esto as operaes possveis que um usurio pode realizar e, junto
a cada seta, os dados necessrios para a realizao de cada operao. Note que para a montagem
deste diagrama basta uma conversa com o bibliotecrio, perguntando o que ser disponibilizado de
servios para os usurios da biblioteca atravs da Internet. Para cada tipo de ator nas mais variadas
situaes elaborado um diagrama deste tipo. O diagrama de caso de uso est includo nos
diagramas de comportamento da UML, justamente por definir mais aspectos comportamentais
mesmo do que aspectos tcnicos.
O prximo diagrama que utilizamos o de atividades, outro diagrama de comportamento. Ele
define a forma e o fluxo de como uma operao ocorre. Nele j devemos buscar evidenciar
condies e tratamentos de excees ou erros.
No exemplo abaixo temos uma operao de devoluo. uma operao realizada no prprio balco
de atendimento da biblioteca. O que acontece neste diagrama que cada uma das operaes
possveis, descobertas durante a elaborao dos casos de uso, so levantadas e analisadas fundo.
Tipicamente, nesta fase, o programador j comea a enxergar o programa, enquanto o usurio
ainda capaz de entender, questionar e colaborar com os diagramas.

Pgina 31 de 117
O prximo diagrama o de classes, um diagrama de estrutura da UML. Nele procuramos
entender quais so os objetos todos que fazem parte do sistema e sua relao uns com os outros.
Abaixo temos o exemplo de um diagrama simplificado de classes do Gnuteca.
Ainda que este diagrama no seja to fcil de entender por quem no esteja envolvido com um
sistema de bibliotecas, observe que Materiais est associado Famlias, o que leva concluso de
que os Materiais disponibilizados na Biblioteca podem estar agrupados em Famlias (Livros,
Vdeos, Peridicos). Materiais esto associados tambm Exemplares, pois pode haver a
disponibilidade de mltiplos exemplares de um determinado material. Exemplares esto associados
a um determinado Estado: o material pode estar disponvel, emprestado, reservado ou ainda em
recuperao. Note que o Usurio est ligado ao Material no diretamente, mas atravs de um
Emprstimo. O Usurio ainda pertence a um Grupo ao qual esto associadas Polticas, assim como

Pgina 32 de 117
as Polticas tambm esto associadas Famlias. Isto acontece porque cada grupo de materiais,
associado a um determinado grupo de usurios, pode ter uma poltica diferenciada de emprstimo.
Um usurio que pertena ao grupo Professores pode tomar emprestado um livro da Biblioteca por
um perodo de duas semanas, enquanto um usurio do grupo Alunos poder ficar apenas uma
semana com o mesmo livro. A Univates disponibiliza calculadoras cientficas na biblioteca, que s
podem ser emprestadas a um grupo especfico de usurios. importante visualizar as classes (ou
objetos) que compem um sistema at para que algumas decises de implementao sejam tomadas.
Neste caso, uma das coisas que se evidenciaram foi a definio de que todas as polticas de
emprstimo deveriam ser parametrizveis diretamente pelo administrador da biblioteca.

O prximo diagrama que utilizamos foi o de sequncia, um diagrama de interao da UML. Este j
um diagrama mais complexo e mais prximo da programao. Ele especialmente til quando
novos programadores so integrados ao desenvolvimento do sistema, uma vez que representa
visualmente a interao entre os atores atravs da interface de usurio, lgica de negcio e conexo
com bases de dados.

Pgina 33 de 117
Ainda assim, um diagrama de sequncia permite ao analista de sistemas ou ao programador explicar
para o usurio o que acontece dentro do sistema, sem a necessidade de assust-lo com a linguagem
de programao. Note que no diagrama acima, o operador, no caso um atendente da biblioteca,
recolhe o material que lhe foi entregue e verifica seus dados. No Gnuteca isto feito atravs da
leitura do cdigo-de-barras impresso no material, com auxlio da interface de usurio, que foi
escrita na linguagem PHP-GTK. A seguir, o sistema verifica se h algum atraso na devoluo e,
havendo, calcula a multa (que pode ser paga na hora ou acrescida no sistema financeiro que a
incorporar a outras dvidas do aluno, se for o caso). O passo seguinte verificar se aquele material
devolvido possui alguma reserva, o que feito diretamente pelo sistema (o Gnuteca permite que os
usurios da biblioteca reservem materiais pela Internet e as polticas de uso definem quanto tempo
esta reserva poder ser mantida). Havendo reserva, o material encaminhado ao setor de reservas,
caso contrrio, recolocado no acervo.
Durante o desenvolvimento do Gnuteca, buscamos tornar o sistema o mais genrico e abrangente
possvel, o que fez com que o mesmo acabasse por ser adotado por bibliotecas universitrias,
bibliotecas independentes e mesmo para colees pessoais.

Pgina 34 de 117
Extreme Programming
Quando comecei a assistir uma palestra do pessoal da Hiperlgica sobre Extreme Programming na
LinuxExpo em So Paulo, em maio de 2001, cheguei a pensar: "Justo agora que adotamos a UML
me aparecem com mais uma metodologia...". Logo notei, porm, que a metodologia Extreme
Programming, ou XP, no chega a se opor UML e , em praticamente todos os casos, um bom
complemento ela. Mais do que isto, descobri que j utilizvamos no desenvolvimento de nossos
projetos em software livre, mesmo que intuitivamente, muitos dos conceitos de XP.
Antes de comearmos a entender o que XP, vamos analisar um pouco da evoluo do
desenvolvimento de software ao longo do tempo:
Por volta de 1960 os computadores comearam a ser utilizados cada vez com mais intensidade nas
empresas, uma vez que, at ento, estavam quase que exclusivamente limitados ao uso militar. As
mquinas eram carssimas, e por isso, seus recursos deveriam ser explorados ao mximo. Os
programas eram otimizados ao extremo para a arquitetura do computador em que iriam rodar, e os
poucos programadores que existiam no estavam muito preocupados com a legibilidade do que
escreviam, at porque no tinham mesmo muita opo. Existem muitas histrias sobre programas
de computadores que simplesmente tinham que ser descartados quando uma arquitetura de
hardware era substituda por outra.30
Em 1968 Edsger Dijkstra31 escreveu um artigo onde chamava a ateno para o perigo da utilizao
da declarao GOTO em um programa. Este artigo continha as idias centrais do que hoje
chamado Engenharia de Software. Da para a frente foram surgindo mais e mais regras para a
escrita de programas de computadores, como que buscando colocar ordem em uma terra sem lei. No
incio dos anos 80 a "ordem na casa" acabou permitindo que se produzisse software de muito
melhor qualidade, legibilidade e portabilidade do que o que era produzido alguns anos antes, s que
a cada novo problema que surgia, novas regras eram criadas para que tal problema fosse evitado, a
ponto que a partir dos anos 90 comearam a surgir questes sobre a distncia colocada entre as
metodologias existentes e a prtica de programao.
Em 1997 Eric S. Raymond escreveu a primeira verso de seu artigo The Cathedral and the
Bazaar32, no qual analisava o desenvolvimento do kernel Linux de forma ao mesmo tempo
cooperativa e anrquica. A mxima do artigo de Raymond : Given enough eyes, all bugs are
shallow, ou seja, com muita gente trabalhando no mesmo cdigo, os problemas se evidenciam, e
podem, portanto, ser consertados. Dentro da anarquia do desenvolvimento do Linux, surgiu uma
metodologia com razes quase que exclusivamente prticas, a qual chamada por Raymond de
Bazaar, em oposio ao mtodo Cathedral que pressupe um conjunto de regras acadmicas
para a produo de software.
O mtodo Bazaar parece funcionar muito bem para projetos que so de interesse de um grande
nmero de pessoas, como o kernel Linux e vrios outros projetos em software livre. Mas quando
estamos desenvolvendo um projeto que atenda um determinado nicho, cujas necessidades so de
uma populao restrita e o grupo de desenvolvedores pequeno, torna-se necessrio o acordo sobre
a utilizao de alguma metodologia, ainda mais quando se quer que outros desenvolvedores
agreguem-se de forma fcil ao projeto.
O Sagu um bom exemplo. O projeto foi desenvolvido com grande velocidade, entrando em
30 Uma histria interessante a do ITS - Incompatible Time Sharing, um sistema operacional desenvolvido no MIT
pela equipe de Richard Stallman que teve que ser totalmente descartado em funo da Digital ter abandonado a
arquitetura PDP-10. Uma boa traduo deste relato pode ser encontrada em http://www.cipsga.org.br/sections.php?
op=viewarticle&artid=61
31 A ntegra do texto de Dijkstra pode ser encontrada em http://www.acm.org/classics/oct95/
32 Leia o artigo na ntegra em http://www.cipsga.org.br/sections.php?op=viewarticle&artid=50

Pgina 35 de 117
produo na Univates menos de seis meses aps sua escrita ter se iniciado. Teve por base o modelo
ER do sistema anterior, uma vez que o mesmo precisava ser substitudo rapidamente dada sua
crescente instabilidade e incapacidade da arquitetura utilizada em acompanhar o crescimento da
Univates. Quando o Sagu foi entregue comunidade como um software livre e quando comeamos
a agregar mais pessoas ao nosso desenvolvimento passamos a sentir cada vez mais a necessidade de
trabalhar com alguma metodologia que propiciasse o fcil entendimento do que escrevamos e
colocasse alguma ordem em nossa prpria anarquia - uma simples passada de olhos no cdigo do
Sagu permite acompanhar a evoluo de seu estilo e padres de codificao. Como descrito
anteriormente, no incio de 2001 j havamos decidido que usaramos a UML como padro de
desenvolvimento do Sagu2 (o Sagu orientado a objetos). Como o Sagu j estava muito grande,
comeamos a exercitar a UML no desenvolvimento do Gnuteca (Sistema de Gesto de Acervo,
Emprstimo e Colaborao entre Bibliotecas) e do Miolo, o ambiente que atende o desenvolvimento
de aplicaes de bases de dados voltadas para a Web, consistindo em mtodos de apresentao,
conexo base de dados entre outros.
Tudo bem at aqui, mas este captulo no deveria ser sobre Extreme Programming? Ouso dizer que
XP mais um conjunto de regras de conduta e comportamento para desenvolvedores do que uma
metodologia de desenvolvimento. Por isto minha recomendao que se conhea primeiro a UML
para depois temper-la com XP.
Em 1990 Kent Beck33 comeou a estudar em bases prticas o que facilitava e o que dificultava a
produo de software, mas sem olhar os programas que eram escritos, e sim focando-se na
satisfao do cliente e na forma como as equipes de desenvolvedores trabalhavam. Kent pde
observar que o custo de desenvolvimento de um sistema estava muito mais ligado ao custo das
pessoas do que ao hardware ou licenas de software empregados, e que para a boa continuidade e
crescimento de um projeto era necessrio envolver o usurio (cliente) no processo de produo e
tornar cada programa to claro quanto possvel para a leitura por humanos. Assim, Kent
desenvolveu a metodologia XP com base em quatro princpios bsicos: comunicao, simplicidade,
realimentao (feedback) e coragem. A partir de 1996, Kent Beck passou a aplicar seus conceitos
na prtica na Daimler-Chrysler.
O desenvolvimento de um projeto com XP passa por quatro fases: Planejamento, Projeto,
Codificao e Testes, cada fase contemplando um conjunto de regras.

Planejamento
O planejamento comea com a escrita de User Stories, uma espcie de Use Cases (UML) diet. O
usurio ou cliente escreve histrias que representam o que o sistema deve fazer por eles, evitando
usar qualquer terminologia tcnica. Em conjunto com os programadores, o tempo de
desenvolvimento de cada mdulo do sistema que contemple cada uma das User Stories estimado.
Caso o tempo estimado para o desenvolvimento seja maior do que trs semanas a Use Story deve
ser subdividida em outras.
A fase seguinte a Release Planning, onde a equipe de negcios e a de desenvolvimento
concordam com a ordem na qual os mdulos do sistema sero desenvolvidos e entregues para a
produo. importante que a equipe de negcios esteja envolvida, pois nem sempre possvel para
os programadores avaliarem a importncia da disponibilizao de um determinado mdulo do
sistema, ao mesmo tempo que pode ser difcil para a equipe de negcios entender a dependncia
entre os mdulos do sistema e a complexidade de seu desenvolvimento. Para um executivo pode ser
crucial que um relatrio financeiro possa estar disponvel rapidamente, mas ele depende de mdulos
contbeis que devem ser escritos antes. Ao final do Release Planning deve estar claro para todos a

33 Kent Beck escreveu sua prpria biografia em http://c2.com/ppr/about/author/kent.html

Pgina 36 de 117
ordem na qual os mdulos do sistema sero disponibilizados e todos devem se comprometer com
isto. Para facilitar este planejamento, a equipe deve procurar levar em conta apenas quatro
variveis: escopo, recursos, tempo e qualidade. s vezes pode ser possvel adiantar o
desenvolvimento de um mdulo, por exemplo, se diminuirmos seu escopo, ou seja, a quantidade de
coisas pela qual tal mdulo responsvel. Sempre possvel tambm diminuir o tempo de
realizao de um projeto aumentando os recursos disponveis para ele, mas cuidado: 100 horas de
programao de um desenvolvedor no so iguais a uma hora de programao para um grupo de
100 desenvolvedores. Quanto mais desenvolvedores em um projeto mais variveis relativas
comunicao entre eles entram em jogo34. No recomendvel, porm, acelerar um projeto
diminuindo os testes do sistema, comprometendo assim sua qualidade. Concentrando-se apenas
nestas quatro variveis possvel acelerar as decises sobre a sequncia de desenvolvimento.
Outra regra Move People Around. O conhecimento no deve ser concentrado nas mos de poucas
pessoas. Envolva pessoas em diferentes projetos e troque-as de tempos em tempos.
A comunicao entre as pessoas e o envolvimento dos usurios (clientes) no desenvolvimento
extremamente importante. No se deve, porm, perder mais tempo na comunicao dos resultados e
na tomada de decises do que no desenvolvimento em si. Por isto a XP prope Stand-up Meetings,
reunies que devem acontecer todos os dias pela manh, preferencialmente no ambiente de
desenvolvimento. Estas reunies informais devem tender a substituir integralmente todas as demais
reunies.
Uma das regras mais importantes do Planejamento em XP Fix XP when it breaks, ou seja, se a
metodologia no est funcionando, conserte a metodologia! Nem sempre pode ser possvel seguir
tudo o que uma determinada metodologia prope e faz mais sentido mudar a metodologia do que
querer acomodar, em todos os casos, o desenvolvimento de um sistema a regras imutveis.

Projeto
Simplicidade a palavra de ordem. Muitos de ns que j coordenamos ou desenvolvemos projetos
conhecemos o mtodo KISS - Keep It Simple, Stupid (literalmente: Mantenha a simplicidade,
estpido!). XP coloca a simplicidade como regra. Nada deve ser desenvolvido sem que seja
necessrio - evite prever necessidades futuras! Quando deparar-se no sistema com alguma estrutura
complexa, substitua-a o mais rpido possvel por outra mais simples. Estruturas complexas tendem
a se tornar cada vez mais caras e difceis de manter.
Escreva uma System Metaphor, ou metfora do sistema, dando nomes simples e significativos aos
objetos que o compem. Estes nomes devem ser facilmente identificados pela sua funo ou
importncia do sistema no negcio da empresa ou instituio qual atendem. Na Daimler-Chrysler
todos os objetos do sistema esto associados a nomes utilizados na linha de montagem dos
automveis. Faa isto de forma ingnua, mas clara. Veja no captulo sobre UML os nomes que
adotamos, por exemplo, para as classes que compem o sistema.
As User Stories escritas na fase de planejamento devem agora ser transformadas em CRC Cards
(CRC significa Classe, Responsabilidade e Colaborao). Cada CRC Card funciona como um
script que representa as funes que cada mdulo do sistema ir desempenhar e como ele ir se
relacionar com outros mdulos. Os usurios devem ser envolvidos nesta fase, e idealmente, lendo o
CRC Card deve ser possvel que uma pessoa consiga simular o papel do mdulo que ele representa.
Quando surge uma dvida sobre a forma como um determinado mdulo ou funo devem ser
desenvolvidos, apela-se para Spike Solutions (Solues Relmpago). Antes de conhecermos o XP
chamvamos as Spike Solutions de Testes de Conceito ou Prottipos Prematuros. Spike
34 Um livro que aborda muito bem esta e outras questes O Mtico Homem-Ms, de Frederick P. Brooks, com
traduo de Cesar Brod para a editora Campus Elsevier

Pgina 37 de 117
Solutions so usadas para testar uma ideia que pode ser utilizada pelo sistema, mas da qual no se
tem a certeza exata de seu comportamento. Neste caso, desconsideramos o sistema como um todo e
testamos a ideia isoladamente, com conscincia de que ela pode no servir para nada depois e que
todo o cdigo desenvolvido para test-la tambm pode no ser aproveitado para nada.
A ltima regra da fase de projeto Refactor Mercilessly, que livremente traduzo por No se
apaixone pelo seu cdigo. Claro que o cdigo pode ser reaproveitado, mas novas tecnologias e
ideias surgem a toda hora e alguma coisa que fizemos no passado e que achamos sensacional pode
deixar de s-lo de uma hora para a outra. Esta regra no deve se contrapor, porm, a da
simplicidade. No fique querendo modificar tudo o que j funciona apenas porque algum surgiu
com uma nova ideia, por melhor que seja. Sempre que tiver dvida, discuta com a equipe. Caso a
nova idia venha a simplificar algo complexo, reescreva seu cdigo sem d nem piedade.

Codificao
Como o usurio participou de todo o planejamento, especialmente como co-autor das User
Stories, ele deve estar sempre disponvel (Customer Always Available) durante o processo de
codificao para sanar eventuais dvidas que possam surgir e colaborar com sugestes. No caso do
Sagu tnhamos na Univates, especialmente no desenvolvimento do sistema financeiro/contbil, a
presena de uma pessoa de nossa contabilidade, que participa inclusive de treinamentos tcnicos.
No Gnuteca, as bibliotecrias da Univates estavam envolvidas no projeto desde a sua concepo e a
primeira apresentao pblica do projeto deu-se no para uma equipe tcnica, mas para um grupo
de bibliotecrios.
A equipe de desenvolvimento deve concordar com os Coding Standards que sero utilizados,
preferencialmente baseando-se em experincias de comprovado sucesso anterior. Nossa equipe
tomou por base o PHP Coding Standards e os adaptou nossa realidade e estilo de codificao.
Uma regra que sempre gera alguma surpresa (e at polmica) a Unit Test, que define que os testes
devem ser definidos e codificados antes mesmo que o mdulo que ir ser testado esteja escrito.
Pensando-se nos testes que sero feitos j refina a codificao e elimina-se de incio possveis erros.
Os desenvolvedores devem trabalhar em pares (Pair Programming). O resultado prtico uma
programao mais criativa, clara e menos sujeita a erros. Por incrvel que possa parecer, a
produtividade tambm maior quando se tem dois programadores trabalhando ao mesmo tempo no
mesmo cdigo, alm de ser mais fcil disseminar o conhecimento entre os projetos trocando-se os
pares de tempos em tempos. Usamos esta tcnica desde o incio do desenvolvimento do Gnudata
(infraestrutura em software livre para bases de dados estatstico/comparativas) e do Gnuteca.
Em XP, a propriedade do cdigo coletiva (Collective Code Ownership), assim todos compartilham
do mesmo orgulho, e das mesmas crticas. A propriedade coletiva do cdigo est totalmente
alinhada com o desenvolvimento de software livre.
A otimizao do cdigo deve ser feita por ltimo (Optimize Last) e apenas quando necessria. No
tente resolver gargalos antes que os mesmos apaream. Lembre-se que o preo do hardware j est
muito menor do que h dez anos, ao passo que as horas de bons desenvolvedores esto mais caras.
Pense se no mais barato aumentar o espao em disco ou comprar processadores mais rpidos do
que pagar um ms de um DBA para otimizar a base de dados.
A ltima regra da Codificao No Overtime, sem horas-extra. Em XP o dia de oito horas e a
semana de quarenta horas. Desta forma que os projetos devem ser dimensionados. Por mais que s
vezes seja difcil afastar um programador de uma tarefa que ele faz com prazer, isto deve ser feito.
A prtica mostra que a produtividade diminui e a quantidade de erros aumenta quando se trabalha
demais: existem limites que, antes de mais nada, so limites fsicos. Mesmo que o programador

Pgina 38 de 117
sinta-se compelido a continuar trabalhando ele deve abandonar a codificao e concentrar-se na
documentao e no planejamento. Apresente para a equipe jogos como o Quake ou outros que
possam ser jogados coletivamente.

Testes
Muitas das regras desta fase j foram definidas nas fases anteriores. Crie os testes mesmo antes de
criar os mdulos do sistema (Unit Tests) e efetivamente execute-os mesmo que eles no tenham
condies de serem testados. Existem vrios ambientes de testes que dependem da linguagem
utilizada e uma srie de mtodos e recomendaes. Adote uma delas ou crie uma metodologia que
possa ser aplicada a seu sistema.
Quando aparecer um problema (When a Bug is Found) antes de resolv-lo crie um teste que possa
detect-lo efetivamente, evitando assim que o mesmo tipo de problema aparea repetidas vezes. A
importncia disto se torna mais evidente a partir do momento que somos obrigados a resolver
mltiplas vezes o mesmo tipo de problema.
Por fim, devem ser definidos junto com os usurios/clientes os Acceptance Tests, um conjunto de
regras que iro dizer que um mdulo est pronto para entrar em produo. O Acceptance Test uma
volta s Use Stories, quando o usurio poder comprovar que o mdulo que foi desenvolvido
corresponde sua necessidade.

Pgina 39 de 117
Miolo
Nos captulos anteriores contei um pouco da histria de alguns sistemas que foram desenvolvidos
sob a minha coordenao na Univates e sobre alguma metodologia que acabamos adotando. A razo
de eu ter usado esta sequncia foi para poder dizer, agora, que toda a evoluo de nossa
metodologia de desenvolvimento se deu de forma bastante natural, orgnica. O aprendizado no
desenvolvimento relmpago do Sagu, o reaproveitamento de cdigo no Gnudata e a concluso de
que deveramos afinar a nossa metodologia de desenvolvimento foi algo com o que a equipe foi
amadurecendo e concordando no decorrer do tempo. Sempre procuro em meus projetos cercar-me
de pessoas que tenham uma grande independncia, sejam autodidatas e, como costumamos falar em
nossa equipe, tenham sevirol - que saibam mesmo buscar solues criativas para os problemas
que vo aparecendo e para as demandas vindas dos usurios. Como gestor de uma equipe de
desenvolvimento procuro, antes de mais nada, atuar como um facilitador para que o ambiente seja
harmnico e busco trazer para mim as decises quando no h convergncia em algum conflito, o
que no algo to incomum. Por outro lado, trabalho muito usando um elemento da filosofia do
Unix: No news is good news! - ou seja, se ningum vem me falar nada, sinal de que as coisas
esto andando bem. Assim, procuro dar a maior independncia possvel aos desenvolvedores ao
mesmo tempo em que eles tm a confiana de que podem buscar em mim o apoio em questes para
as quais necessitam de novos elementos para uma determinada deciso ou futuro desenvolvimento.
O Miolo35 foi um resultado bem claro desta evoluo orgnica de nossa metodologia de
desenvolvimento. A equipe j estava familiarizada com a linguagem PHP (mais adiante, no captulo
[XXX] volto a discutir sobre a deciso de ferramentas para o desenvolvimento) e havia concordado
que o desenvolvimento utilizaria o paradigma da orientao a objetos usando a UML para a
documentao. Vrios elementos do Extreme Programming j estavam sendo utilizados por ns,
mesmo antes de conhecermos formalmente esta metodologia. A ideia de que deveramos ter um
ambiente de desenvolvimento que contemplasse todas as coisas comuns a todos os programas,
possibilitando o desenvolvimento mais rpido de solues, era consenso. Logo aps nosso primeiro
workshop interno de transferncia de tecnologia, que aconteceu em 2001 e que mencionei em O
Desenvolvimento do Sagu, Vilson Grtner e Thomas Sprietersbach comearam a desenvolver o
Miolo. Mais adiante, Ely Edison Matos da Universidade Federal de Juiz de Fora tornou-se um
importante colaborador, o que ilustra bem a questo anteriormente colocada que, no
desenvolvimento de um software livre, pode-se contar com ajuda importante que no est
diretamente abaixo de nossa prpria gesto de desenvolvimento.
O nome Miolo uma histria parte e, antes que ela perca-se no tempo, vou cont-la aqui. O Sagu
tambm o nome de uma popular sobremesa gacha, feita com vinho. Uma das brincadeiras da
nossa equipe era a de que para se fazer um sagu melhor, tnhamos que usar um vinho melhor. A
vincola gacha Miolo bastante famosa pela excelente qualidade de seus vinhos e, por isso,
comeamos a usar o nome-cdigo de Miolo para o framework que desenvolvamos. Com o tempo,
criamos outras desculpas para o nome. Miolo tambm aquilo que est por dentro, no meio,
como o miolo de um po. Ao menos aqui no sul chamamos tambm de miolos o que est dentro
do nosso crebro. Assim, o Miolo d tambm a ideia de um kernel, algo central s aplicaes, de
certa forma invisvel ao aspecto externo mas fundamentalmente responsvel por toda a sua
funcionalidade.
Com a sua evoluo, o Miolo foi responsabilizando-se por vrias funes comuns a boa parte das
aplicaes, dentre elas:
Controles de interface com o usurio, escritos em PHP e renderizados em HTML

35 www.miolo.org.br

Pgina 40 de 117
 Autenticao de usurios
Controle de permisso de acesso
Camada de abstrao para acesso a bancos de dados
Camada de persistncia transparente de objetos
Gerenciamento de sesses e estado
Manuteno de logs
Mecanismos de trace e debug
Tratamento da pgina como um webform, no modelo event-driven
Validao de entrada em formulrios
Customizao de layout e temas, usando CSS
Gerao de arquivos PDF
Voc no precisa entender o que cada uma destas funes significam, mas caso queira aprofundar-se
no framework Miolo, a pgina do projeto oferece um bom tutorial sobre sua utilizao. O fato
que, com o uso do Miolo, estimamos uma economia de mais de dois teros no tempo de
desenvolvimento e um notvel aumento de qualidade na escrita de cdigo, vinda naturalmente da
necessidade de um padro de escrita exigido pelo framework.
As figuras abaixo exemplificam o cdigo html necessrio para a exibio de uma tabela e, a seguir,
o cdigo para a mesma finalidade utilizando o Miolo:
[Joice, j vou te dar um trabalhinho aqui... ao invs de usar as figuras, reescrever este cdigo, pode
ser?]

Pgina 41 de 117
 importante salientar que a origem do Miolo est no pensamento de nossa equipe desde o princpio
do desenvolvimento do Sagu, l em 1999, ainda que ele no tivesse ainda evoludo nem para o seu
formato atual e sequer tivesse recebido seu nome. Ns sabamos que o Sagu tinha um prazo muito
estreito para a sua entrada em produo e, por isso, muitas ideias sobre a elegncia e portabilidade
do cdigo foram deixadas para a verso 2, mas o germe do Miolo j estava l. Tivesse o projeto
Sagu, ou qualquer outro de nossos projetos na Univates e na Solis, sido iniciado entre cinco e dez
anos depois, talvez o Miolo sequer existisse, j que outros frameworks36 para o desenvolvimento em
PHP ainda mais genricos surgiram e passaram a contar com uma comunidade maior de
desenvolvedores. Talvez por estar muito atrelado no em sua capacidade, mas por sua histria
ao desenvolvimento de aplicaes de porte relativamente grande para instituies de ensino, o
Miolo no teve a disseminao que poderia ter tido. Ainda assim, hoje, ele a base de todo o
desenvolvimento da Solis e teve um valor inestimvel na aprendizagem de uma grande equipe,
tanto em tcnicas de orientao objetos como metodologia de desenvolvimento e padronizao de
cdigo.

36 Recomendo bastante aos que esto comeando a explorar frameworks em PHP uma visita ao portal do CakePHP:
http://cakephp.org

Pgina 42 de 117
Plano Diretor de TI Um modelo
Dentre as muitas coisas que aprendi com o professor Eloni Salvi est a mxima de que o trabalho de
informtica equivale a um trabalho de manuteno de esgoto. Enquanto tudo funciona bem,
ningum percebe o esforo que necessrio para a sua manuteno. Basta um cano estourar, porm,
que todos comeam a sentir o cheiro caracterstico e a procurar pelos culpados. Por isso
importante, sempre, documentar de forma clara, inteligvel por aqueles a quem nos reportamos,
tudo o que fazemos em termos de gesto, desenvolvimento e manuteno daquilo que compe os
elementos de tecnologia da informao em uma empresa ou instituio. Mais do que isto, os
tomadores de deciso devem saber, claramente, da importncia da tecnologia da informao no
crescimento e diferencial estratgico da empresa. Isto mais fcil ou mais difcil dependendo da
natureza da empresa. Durante todo o tempo em que a BrodTec prestou servios para a Univates
produzi um documento anual, depois transformado no Plano Diretor de Tecnologia da Informao
(PDTI), que ilustrava os benefcios adquiridos com o uso e desenvolvimento de software livre,
estado atual da rea de TI, necessidades atuais e futuras relativas a usurios e infraestrutura. Este
plano tambm servia como base para uma apresentao reitoria e como um dos elementos para o
planejamento estratgico da instituio.
Em outros trabalhos desenvolvidos pela BrodTec vrios outros documentos foram desenvolvidos e
fico feliz em observar que, em muitos casos, eles continuaram a ser usados como base evolutiva ou
referncia para outros documentos e, especialmente, aes posteriores.
Agora que o leitor est a par do que foi desenvolvido e aprendido durante a fase em que a BrodTec
prestou servios para a Univates, encerro este captulo com algumas informaes e recomendaes
sobre a elaborao de um PDTI, tomando como base o que foi desenvolvido para a Univates e j
agradecendo a instituio, na figura de seu reitor, Professor Msc Ney Jos Lazzari, pela autorizao
de mais esta pea de conhecimento livre.

O ndice
O ndice j diz bastante coisa sobre o documento. Comento aqui, brevemente, cada um de seus
componentes.
0. Histrico de Revises Este item deve ser obrigatrio em todos os documentos que
recebem contribuies de vrias pessoas e passam por um
processo de reviso e aprovao. Ele conta a histria sucinta
da evoluo do documento e deve ser bem simples. Basta
uma tabela que conste a alterao do documento, sua
pgina, a razo da alterao (incluso, deleo) e o autor
desta alterao.

1. Resumo Similar ao Resumo (ou Abstract) de um trabalho acadmico,

ele deve descrever em um pargrafo a finalidade do
documento.

2. Introduo No PDTI Univates este item composto pelo captulo

Ecologia do Conhecimento, que funciona como um
prembulo para o resgate histrico que vem no captulo
seguinte.

3. Histrico necessrio posicionar o leitor da evoluo at o momento,

Pgina 43 de 117
 antes de partir para propostas para o futuro e pedidos de
novos investimentos. No PDTI Univates ele o captulo A
Informtica na Univates, a evoluo para um Ecossistema,
composto de vrias sees.

4. Economia Qual foi a economia obtida com os investimentos em TI?

Esta parte especialmente importante para os responsveis
pelos investimentos e constitui-se em forte argumento
quando da solicitao de novos recursos.

5. Plano Diretor de Tecnologia da
Informao PDTI
Aqui a proposta para o futuro, sempre embasada naquilo
que foi desenvolvido at o momento. Quanto mais
fundamentados e documentados estiverem os itens
anteriores, melhor a possibilidade de aprovao no que
proposto neste captulo.

6. Concluso Mais um resumo, agora levando em considerao que o

leitor (ou o pblico que assistiu a apresentao do
documento) esto cientes de toda a informao at aqui
exposta.

Todo List Um documento como este um ser vivo, sempre

alimentado por ideias daqueles a quem apresentado. Por
isso ele deve, at seu derradeiro momento, contar com a
lista de coisas que ainda devem fazer parte dele. Este item
pode ser excludo das verses de apresentao e
distribuio, mas deve ser mantido parte como guia para
futuras verses.

Repare que os itens 1 a 5 servem para nivelar e ganhar os leitores ou a audincia da apresentao.
Eles constituem-se na defesa da ideia, no currculo da capacidade da equipe, nos sucessos
alcanados. Eles devem ser escritos de forma factual e eventuais problemas e suas solues e
tambm problemas sem solues devem ser expostos. Uma postura de transparncia radical deve
ser adotada e eles devem construir toda a base de justificativa para o que ser proposto no item 5.
Os textos a seguir foram extrados diretamente da proposta de PDTI para a Univates no ano de
2004. Algumas informaes foram editadas ou omitidas para preservar dados estratgicos ou
confidenciais da instituio.

Resumo

Com o crescimento da Univates e a utilizao cada vez maior da tecnologia da informao,

evidente a necessidade de que o uso desta tecnologia seja pensado de forma estratgica,
alinhado ao planejamento estratgico da prpria instituio. Este documento busca reunir a
experincia adquirida na evoluo dos sistemas de informtica da Univates, no contato com
outras instituies de ensino e empresas, na evoluo da comunidade e das solues em
software livre e dos conceitos de Contedo Aberto (Open Content), e, especialmente, no
contato com os usurios de nosso ambiente de TI e gestores com atribuies similares s
minhas em outras instituies, formando a base de uma proposta para um Plano Diretor de
Tecnologia da Informao (PDTI) para a Univates, alinhado ao seu Plano Estratgico.

Pgina 44 de 117
Ecologia do Conhecimento

Os sistemas computacionais foram ao longo do tempo evoluindo de auxiliares operacionais

para um complemento evoluo de formas do tratamento do conhecimento. No a toa
que uma grande obsesso da Cincia da Computao replicar o comportamento do nosso
crebro e nossos sutis mtodos de deciso quando lidando com uma ampla gama de
informaes. Ainda assim, fora do alcance do que pode ser totalmente informatizado esto
outros aspectos do conhecimento, como conversas e ideias. Esta proposta de PDTI busca
tratar o conhecimento na forma de um ecossistema que integre dados, informaes,
documentos, conversas e ideias que compreendem e circulam por toda a Univates.
A ideia de uma Ecologia do Conhecimento foi proposta por Derek Keats e Madiny Darries,
no documento Towards a Knowledge Ecology Strategy for the University of the Western
Cape, onde os autores produziram um Estudo de Caso da Univates que serviu como base
para a adoo de software livre pela UWC. Outros documentos foram usados como
referncia para esta proposta, como o PDI da Unesp e a Pesquisa Nacional Sobre Gesto dos
Sistemas de Informao e suas Tecnologias para Aprimoramento das IES (Lobo &
Associados Consultoria). Dentre as conversas importantes, das quais surgiram boas idias
que no s foram aplicadas neste documento, mas na prpria evoluo da estrutura de
informtica da Univates, esto as que tive com o Prof. Dr. Imre Simon (projeto Tidia,
FAPESP), Prof. Dr. Carlos Vogt (Presidente da FAPESP, Diretor do Laboratrio de
Jornalismo da Unicamp), Prof. Dr. Carlos Masiero (CIO, USP), Rubens Queiroz (Centro de
Computao, Unicamp) e o Prof. Dr. Derek Keats (CIO, UWC).

O conhecimento a capacidade de pessoas e das comunidades de continuamente gerar e renovar, de

modo a responder a novos desafios e oportunidades. As pessoas que desenvolvem conhecimentos podem
ser inspiradas e apoiadas, mas dificilmente podero ser "gerenciadas" como meras extenses de
mquinas, como na Era Industrial.

A ecologia do conhecimento um campo interdisciplinar da prtica gerencial que surgiu da confluncia

de estratgias de gesto, comunidades de prtica, sistemas adaptativos complexos e gesto do
conhecimento. um corpo cada vez maior de conhecimento e prticas que focam na contnua melhoria
das relaes, ferramentas e mtodos para criar, integrar, compartilhar, usar e alavancar conhecimento.

Maria Alice Capocchi Ribeiro, Msc37

A Informtica na Univates, a evoluo para um Ecossistema

No muito diferente de outras instituies, at 1999 a informtica na Univates era usada de

forma no integrada, com poucas estaes de trabalho em rede utilizando aplicativos de
escritrio e um sistema administrativo que evoluiu de uma aplicao em Cobol para um
ambiente baseado na plataforma MS-Access. Este ambiente, em 1999, serviu de base para a
migrao para o SAGU (Sistema Aberto de Gesto Unificada), que usado at hoje na
instituio.

37 http://www.rh.com.br/ler.php?cod=3762&org=2

Pgina 45 de 117
Entre 1999 e 2004, o sucesso com o SAGU e com a adoo de ferramentas de produtividade
livres como o Star/OpenOffice fez com que a Univates evolusse para uma poltica de
adoo preferencial e desenvolvimento integral de aplicaes em software livre para a rea
administrativa e a ampliao gradual (ainda que bastante lenta) do uso de software livre
tambm na rea acadmica.

A comparao com ferramentas e aplicativos em software proprietrio que ainda mantemos

na instituio nos fez comprovar ao longo do tempo que a economia (assunto sobre o qual
falaremos mais no item Economia) um efeito colateral importante de uma srie de outros
benefcios que temos com o uso do software livre, especialmente a flexibilidade, imunidade
a vrus (e a indisponibilidade causada por eles) e a independncia tecnolgica.
A disponibilizao de sistemas para os usurios da Univates atravs da rede, com a
concentrao de servios na Intranet, alm de criar um ambiente central-virtual
compartilhado por todos, potencializou a cumplicidade dos usurios com o desenvolvimento
de novos sistemas e servios, ao mesmo tempo em que os tornou mais exigentes e
dependentes da nossa estrutura de informtica, que deve se tornar cada vez mais disponvel,
tolerante a falhas e eficiente para suprir as demandas que impactam a produtividade dos
usurios e a eficincia da instituio.
Ainda em 2001 optamos por criar um ambiente de software onde pudssemos concentrar os
requisitos bsicos de qualquer sistema que vissemos a desenvolver em uma camada que
pudesse servir e ser reaproveitada, gerando no s economia na escrita de cdigo, mas
permitindo que aspectos relativos distribuio de dados, controle de acessos, segurana e
outros no precisassem mais ser programados nas aplicaes, mas fossem inerentes ao
prprio ambiente. A este ambiente demos o nome de Miolo, e a primeira aplicao
desenvolvida com ele foi o Gnuteca, que responsvel pela gesto de acervo, emprstimos e
outros aspectos relacionados aos servios de nossa biblioteca. O Gnuteca entrou em
atividade em fevereiro de 2002.
A partir da, todo o novo desenvolvimento de aplicaes passou a ter o Miolo como base, a
ponto de, em um determinado momento, os usurios passarem a confundir as aplicaes
disponibilizadas na Intranet com o prprio Miolo. Hoje, nossos usurios tm sua
disposio na Intranet servios como o registro de ponto, solicitaes de servios de apoio,
compras e chamados tcnicos, controle de documentao na norma ISO 9002, reservas de
salas e veculos, entre muitos outros. Isto tambm faz com que, com o uso intensivo da
Intranet para o acesso aos servios, a mesma sirva como um meio ideal de divulgao de
informaes aos funcionrios da Univates, evoluindo para um ponto de encontro virtual.

Pgina 46 de 117
 Figura 1 Evoluo do acesso Intranet

Os servios aos alunos atravs da Internet tambm foram se intensificando, especialmente

atravs da integrao a sistemas como o Sagu e o Gnuteca. Hoje os alunos da Univates
podem usar a Internet ao se inscreverem para o vestibular, administrarem sua matrcula e
alteraes nos perodos determinados, localizar sua sala de aula, verificar sua situao
financeira, imprimir boletos para pagamentos bancrios, fazer a inscrio em eventos,
reservar e renovar material emprestado da biblioteca, verificar suas notas, entre outros. Os
portais Inter e Intranet foram ambos desenvolvidos com o Fred, um sistema para a gesto de
contedos que tambm tem o Miolo como base, o que facilita a integrao de solues e a
oferta de servios atravs dos portais. Apenas como exemplo, o sistema de nossa estao
meteorolgica, tambm em software livre, disponibiliza dados histricos e em tempo real
sobre o clima de Lajeado atravs de nosso portal Internet.

Figura 2 Evoluo do acesso Internet

Pgina 47 de 117
 Alunos, funcionrios e outros colaboradores da instituio ainda tm acesso a servios
tradicionais de e-Mail, listas de discusso (quase cinquenta, reunindo turmas, grupos de
interesse de alunos e funcionrios, entre outras), ambientes de criao coletiva de
documentos e de formao dinmica de bases de conhecimento (Rau-Tu). Alguns
professores j esto utilizando o WebDirio para o registro de freqncia e notas dos alunos.
Todos estes servios esto convergindo para um ambiente nico, e so acessados de forma
segura por usurios atravs de uma arquitetura de senhas fortes38. Em fase de testes e
implantao ainda esto um sistema de agenda compartilhada, um sistema de
armazenamento eletrnico de artigos, teses e dissertaes e outros.

Acompanhamento de chamados tcnicos

Figura 3 Evoluo dos chamados tcnicos, entre agosto de 2002 e julho de 2003

Em final de julho de 2002, disponibilizamos na Intranet o sistema Scotty, atravs do qual so

feitos os registros de chamados tcnicos e seu acompanhamento. Atravs da anlise destes
chamados e sua recorrncia aprimoramos nossos processos de manuteno corretiva,
preventiva e preditiva, especialmente com a criao de uma imagem de instalao para as
mquinas usadas pelos funcionrios e por um mecanismo de atualizao e instalao
automtica de softwares: uma vez detectada uma falha em um programa, a correo ou a
atualizao testada e instalada automaticamente em todas as mquinas. Desta forma, cada
vez que um problema detectado, ele afeta um nmero menor de pessoas, j que a correo
feita logo a partir da primeira ocorrncia. Sistemas de suporte remoto tambm foram
implantados, minimizando a necessidade de deslocamento da equipe. A evoluo dos
chamados nos permite ainda detectar aonde h falhas de treinamento de pessoal (tanto de
usurios quanto da equipe de suporte) e definir treinamentos. No segundo semestre de 2004
estaremos ministrando cursos internos em Gnu/Linux Bsico, OpenOffice, Sagu e Agata
Report, alm de vrios cursos voltados ao suporte interno, nos quais, alm da equipe do
CPD, esto sendo envolvidos os monitores dos laboratrios acadmicos. Outras vezes, a
recorrncia de um certo tipo de chamado tcnico tambm aponta para a falta de
38 Processo de unificao de logins e senhas com o OpenLdap iniciado em meados de 2004

Pgina 48 de 117
 documentao de algum de nossos sistemas ou procedimentos. Isto nos levou a, alm de
aprimorar bastante os manuais do Sagu e do Gnuteca, disponveis na Intranet, criar pequenas
cartilhas de cada um dos sistemas disponveis, apresentando-os aos usurios. A este tipo de
aes que visam a diminuir o nmero de chamados tcnicos a partir da anlise do
comportamento dos usurios, damos o nome de manuteno proativa.
Alm da simples evoluo do nmero de chamados, o Scotty ainda nos permite verificar a
qualidade dos servios de suporte, atravs da comparao do nmero dos chamados com o
seu efetivo atendimento dentro dos prazos estabelecidos pelos prprios usurios, e a partir
de maio de 2004 tambm com o registro da opinio do usurio sobre o atendimento (que
manifestada de forma voluntria).

Figura 4 Evoluo do atendimento dos chamados tcnicos

Ainda que tenhamos conseguido manter um nmero de usurios crescente em relao ao

nmero de analistas, o grfico acima mostra que, mesmo com aes de manuteno
preditiva, h uma tendncia ao crescimento dos chamados no atendidos ao final de cada
ms (a partir de maro de 2004), o que mostra que o nmero de analistas est
subdimensionado.

Nota: Repare que os dados factuais, comprovados, j servem de argumento para a solicitao de
um aumento da equipe.

Software livre na Academia

Na rea acadmica tivemos um aumento da simpatia dos docentes pelo software livre
especialmente aps a contratao do Prof. Marcelo Malheiros em agosto de 2002, oriundo
da Unicamp, um entusiasta e desenvolvedor de sistemas em software livre que so utilizados
na Unicamp, Univates e vrias outras instituies de ensino. Com o Prof. Malheiros
intensificamos o uso do ambiente Teleduc na nossa experincia em educao distncia, e
mesmo em cursos presenciais. Mais recentemente, com a contratao da Prof.a Maria
Abadia, em novembro de 2003, passamos a oferecer aos docentes um apoio mais efetivo na

Pgina 49 de 117
busca de alternativas de ferramentas livres para a substituio de softwares proprietrios.
Segundo o Prof. Malheiros: Ainda h muita coisa que pode ser feita em todos os cursos
oferecidos pela instituio, como a adoo de ferramentas de matemtica e estatstica
livres, programas educativos, etc. S que o trabalho bem maior, pois estas solues
precisam estar muito bem estruturadas, documentadas e apoiadas internamente na
instituio para serem aceitas em substituio aos programas no livres que costumam ser
utilizados.
Outros aspectos bastante importantes na adoo de software livre na Univates so o
incentivo aos grupos de usurios Gnurias e Taquarix e a disponibilizao de um ambiente
onde a comunidade pode hospedar projetos em software livre, o portal Cdigo Livre.
Os grupos de usurios se beneficiam da estrutura da instituio para organizar encontros e
eventos envolvendo nossos alunos e buscando coloc-los em contato com vrios expoentes
da comunidade de software livre. Um destes eventos a Semana do Pingim, que
acontece uma vez a cada semestre e busca trazer novidades e mostrar a nossos alunos as
oportunidades que existem com o software livre. O grupo Gnurias ainda trabalha com
escolas pblicas, buscando despertar em alunos do ensino mdio e fundamental uma
curiosidade tecnolgica, que os provoca no s a buscar o acesso tecnologia, atuando
como agentes de mudana em suas comunidades, mas tambm permitir que eles
desenvolvam capacidades que possam servir de apoio ao seu aprendizado e diferencial
quando tiverem de enfrentar o mercado de trabalho. Parte deste trabalho das Gnurias inclui
expor os alunos ao ambiente da Univates, em oficinas que so realizadas nos finais de
semana nos laboratrios da instituio, despertando neles a vontade e ambio pelo ensino
superior, pela aprendizagem contnua.

Escola Aberta e o grupo Gnurias

Graas ao grupo Gnurias vrias crianas que ficavam em casa sem ter o que fazer, agora esto tendo a
oportunidade de aprender a lidar com o COMPUTADOR, ter uma noo do que um COMPUTADOR,
porque hoje em dia a TECNOLOGIA est muito avanada, cada dia esto sendo criadas coisas novas,
como por exemplo: computadores cada vez mais potentes com a capacidade de criar, fazer, inventar e
descobrir coisas novas, coisas que os nossos antepassados nunca imaginacem (sic) que poderiam ser
inventadas!

Para algumas crianas,apenas tocar em um computador j maravilhoso. Neste projeto ESCOLA

ABERTA, ns crianas estamos tendo a oportunidade, de mostrar o talento que temos em todas oficinas.
Estamos aprendendo muito. Eu, j sabia lidar com um computador, mas resolvi me aprofundar mais,
aprender mais!

Eu no poderia deixar de agradecer ao GRUPO GNURIAS tudo o que estou aprendendo a mais, mas no
agradecer s por mim, mas por todos que esto tendo esta oportunidade!

A vocs o MEU MUITO OBRIGADO!

Vanessa Helena Barbon Corbelini

12 anos, 6 srie
(texto copiado e colado do original digitado pela Vanessa em uma oficina na Univates)

O portal Cdigo Livre surgiu da necessidade de termos maior controle sobre os programas
que j eram desenvolvidos na Univates, com a adoo de ferramentas para o controle de
verses, controle de tarefas e stio web com informaes especficas sobre cada um dos
projetos. Para isto, implantamos no final do ano 2000 o ambiente SourceForge, um

Pgina 50 de 117
 conjunto de ferramentas que se destinam especificamente gesto do desenvolvimento
cooperativo de software. Nesta poca, passamos a receber a primeira contribuio externa,
voluntria, aos softwares que desenvolvamos na Univates, de Ericson Smith (Estados
Unidos) e Uwe Steinmann (Alemanha) para a psLib, uma biblioteca para a gerao de
relatrios impressos usada at hoje em nossos sistemas. Logo, a visibilidade de nosso
sistema de gesto de projetos comeou a crescer em funo do acesso da comunidade ao
cdigo dos sistemas que desenvolvamos, e logo recebemos pedidos de hospedagem de
outros projetos em software livre em nosso ambiente. No incio de 2001 criamos o portal
Cdigo Aberto, destinado a hospedar projetos em software livre da comunidade brasileira, e
que passou a servir como uma ampla fonte de referncia e aprendizagem em cima do
trabalho de outros desenvolvedores. Em 2002, a pedido de Richard Stalmann, presidente da
Free Software Foundation, mudamos o nome do portal para Cdigo Livre. Em meados de
2003, com o Cdigo Livre consumindo boa parte de nossos recursos de rede com mais de
200 projetos hospedados e mais de 2.000 desenvolvedores ativos, firmamos um acordo com
a Unicamp, que passou a hospedar o portal, que hoje mantido conjuntamente pela Univates
e Unicamp. Hoje so mais de 840 projetos hospedados, com mais de 6.500 desenvolvedores
cadastrados.
O Cdigo Livre acabou servindo como um centro de exposio de nossos projetos e outros
da comunidade, sendo onde as contribuies de cdigo entre um projeto e outro acontecem.
Mais adiante, em Aproveitamento de Cdigo e Colaboraes, relatamos tais contribuies,
estimando o total de horas que economizamos no desenvolvimento de nossos prprios
sistemas graas ao trabalho de outros, que tambm puderam se beneficiar de nosso trabalho.
Outra iniciativa importante e hoje nacionalmente reconhecida so os SDSL (Seminrios de
Desenvolvimento de Software Livre), cuja origem est na primeira edio do Sagu
Workshop em julho de 2000, onde buscvamos novas idias para os nossos sistemas ao
mesmo tempo em que transferamos aquilo que desenvolvemos para os participantes do
evento. Como acabamos desenvolvendo novos produtos alm do Sagu, o III Sagu Workshop,
em julho de 2002, aconteceu em paralelo ao I Seminrio Univates de Desenvolvimento de
Software Livre. O evento motivou o interesse da Unisinos e Unicamp (j nossa parceira no
portal Cdigo Livre), e o IV Sagu Workshop aconteceu em julho de 2003, junto ao I SDSL,
na Unisinos, em So Leopoldo (a partir da, o SAGU Workshop deixou de existir de forma
isolada e estamos incentivando um encontro de usurios do Sagu e do Gnuteca a partir dos
prximos SDSL). O II SDSL, que aconteceu na Unicamp, Campinas, em dezembro de 2003,
j contou tambm com a organizao do ISTEC (Ibero-American Science and Technology
Education Consortium). O III SDSL marcou a volta do evento Univates, com um pblico
pagante de 37 pessoas de 10 Estados brasileiros, um portal prprio na Internet
(www.sdsl.org.br) e a participao da UnB na organizao e que sediar tambm o IV SDSL
em dezembro deste ano, em Braslia.

Software Livre na bagagem

O trabalho pioneiro com software livre na Univates acabou proporcionando muitas

oportunidades de exposio deste trabalho em vrios lugares do Brasil e do mundo, atravs
de intercmbios formais (trs alunos que trabalhavam no CPD, e hoje na Solis, estiveram em
Gelsenkirchen: Vilson Grtner, Marcone Luis Theisen e Daniel Afonso Heisler) e da
participao em eventos no Peru, Chile, Uruguai, Austrlia, Estados Unidos, Costa Rica,
frica do Sul e outros.
Josi Petter, acadmica do curso de Histria, teve a oportunidade de conhecer Machu Pichu

Pgina 51 de 117
 no Peru em novembro de 2003 graas a um convite da Unesco para apresentar seu trabalho
com o grupo Gnurias na I Conferencia Latinoamericana y del Caribe sobre desarrollo y uso
del Software Libre em Cuzco. A Univates contribuiu com a ajuda de custo para a estadia,
enquanto a Unesco arcou com as demais despesas.
Joice Kfer, acadmica do curso de Engenharia da Computao esteve na Austrlia em
janeiro de 2004, patrocinada pela Solis, Univates, e em grande parte pela Linux International
Austrlia, como keynote speaker da Miniconferncia Educacional, durante a
Linux.Conf.Au, onde, alm de fazer uma palestra sobre o uso do software livre no apoio ao
ensino de crianas, com base na experincia do grupo Gnurias, ainda pde estabelecer
contato com muitos desenvolvedores e trazer novas idias, especialmente para a estrutura do
portal Univates.

Na Austrlia pude aprimorar meus conhecimentos em outra lngua (ingls). Em todas as viagens conheci
diversas pessoas importantes, com as quais troquei idias e, nesta troca, sempre se aprende algo.
Certamente me tornei mais independente: na Austrlia tive que me virar sozinha... e foi bastante difcil
esta sensao.

Ainda na viagem de ida para a Austrlia, eu chorava de saudade, medo e preocupao. Afinal, era a minha
primeira viagem internacional. Uma mulher sentada ao meu lado, colocou a mo no meu ombro e no
falou nada, s sorriu como quem diz: "Vai passar" e ficou encantada que na minha idade eu j estava indo
sozinha para um lugar to distante e para falar sobre um trabalho to legal. Eu ia apresentar os projetos
das Gnurias com o uso do Software Livre no ensino fundamental e mdio. A mulher era parapelgica e
estava indo para o Uruguai, fazer um tratamento para tentar voltar a caminhar. Na hora, dei-me conta que
eu estava chorando por problemas to pequenos perto do dela, que estava muito confiante. Na juventude,
ela tinha lutado pela causa feminista e se identificou com o nosso trabalho. Ela me disse que, uma viagem
destas, na minha idade, equivalia a uma Universidade inteira. Concordo com ela.

As viagens e a participao em eventos me ajudaram principalmente na questo de falar em pblico.

Cada vez mais os medos vo sumindo...

Joice Kfer

Joo Alex Fritsch, formado em Administrao pela Univates, ps-graduando em

Cooperativismo e presidente da Solis, esteve, sob patrocnio da Unesco, no Uruguai e no
Chile participando de seminrios de transferncia de tecnologia sobre o Gnuteca, o que
acabou, alm de trazer mais idias para o sistema, fomentando um grupo que hoje mantm a
sua verso em espanhol.

Ambiente de rede

Hoje, todos os usurios de nosso ambiente de informtica tm seus computadores integrados

nossa estrutura de rede, que conecta praticamente todos os prdios da Univates atravs de
uma estrutura de fibra tica. A administrao da rede centralizada no prdio 1, onde se
concentram os servidores e sistemas de gesto, todos baseados em software livre. Os
investimentos em nossa rede e infra-estrutura acompanharam com atraso a expanso de
nossos sistemas, de nosso parque instalado e da necessidade de nossos usurios.
Historicamente, desde a disponibilizao do acesso Internet, em 1996, temos
constantemente utilizado mecanismos de limitao de trfego, armazenagem de arquivos e
outros. Os usurios possuem cotas mximas de armazenamento de informaes em nossos

Pgina 52 de 117
 servidores, e o acesso internet monitorado e bloqueado de acordo com o stio acessado e
tipo de contedo. Hoje estamos revendo esta questo, e questionando se o excesso de
controle no est sendo mais caro do que um aumento de recursos para os usurios e uma
menor rigidez no controle de acesso ainda que em recente pesquisa da Lobo & Associados
pudemos comprovar que a grande maioria das instituies de ensino implementa controles
de acesso rede pelos mais diversos motivos.
Temos uma separao de nossos ambientes administrativo, acadmico e contedo web
pblico, com replicao de dados para a maior garantia de segurana em caso de um
eventual ataque. Ainda so necessrios muitos investimentos na replicao da estrutura onde
temos pontos individuais que, em caso de falhas, indisponibilizam o acesso aos sistemas
isto ocorre tanto em servidores, como ativos de rede e interconexo entre prdios.

A Solis

J em meados de 2000, logo aps a implantao do SAGU, a equipe do CPD Univates

passou a ser requisitada para prestar servios de consultoria, desenvolvimento, implantao
e integrao de sistemas em software livre. Estes servios, ainda que trouxessem recursos
para a instituio, estavam fora do foco da mesma, que nunca imaginou se tornar uma
software-house. Ainda assim, estava evidente uma oportunidade de negcios que podia ser
potencializada para os alunos da instituio, aliada ao seu inerente compromisso e misso
com o desenvolvimento regional. Aps algumas discusses sobre a melhor forma de se
aproveitar esta oportunidade, a Univates incentivou a equipe do CPD, formada quase
totalmente por alunos da instituio, a formar uma cooperativa que, alm de assumir os
servios de desenvolvimento e suporte da Univates, pudesse buscar novas oportunidades no
mercado. A Solis, cooperativa de desenvolvimento e integrao de solues livres, foi
formada em janeiro de 2003, e em setembro de 2003 a grande parte dos servios realizados
pelo CPD da Univates foi terceirizada para a cooperativa, que comeou com 20 cooperados
e hoje conta com mais de 30.
Nota: Mais recentemente, mesmo continuando a usar os servios da Solis, a Univates optou por
reaparelhar seu desenvolvimento interno e desenvolveu um novo sistema acadmico e
administrativo, ainda baseado em softwares livres, chamado Alfa. A Solis conta hoje com mais de
50 colaboradores.

A Tecnologia do Ecossistema

O prprio histrico da evoluo da informtica na Univates, descrito acima, mostra que ela
no pode ser pensada de forma destacada de uma srie de outros elementos. Ela deve ser
vista como a estrutura tecnolgica de um ambiente de troca permanente de informaes e
decises, e involucrar em uma proposta de soluo e evoluo tudo aquilo que parte de um
ambiente que pode ser tecnologicamente definido, e tudo aquilo que faz uso deste ambiente,
mas que no pode ser tecnologicamente definido e que muitas vezes tm aes que fogem
ao controle de qualquer previso ou mesmo descrio.

O que Ecossistema?

Pgina 53 de 117
 Ecossistema (de ecologycal system, sistema ecolgico) designa o conjunto formado por todos os
organismos vivos que habitam numa determinada rea, pelas condies ambientais dessa rea, e pelas
relaes entre as diversas populaes e entre estas e o meio.
http://pt.wikipedia.org/wiki/Ecossistema

A evoluo da informtica na Univates, especialmente com o uso do software livre, causou

impactos que estavam fora do escopo de um planejamento inicial, mas que retornam
beneficamente tanto na forma de reconhecimento e destaque ao nosso trabalho, como na
forma mais efetiva e mensurvel de contribuies de cdigo para nossos sistemas, passando
pela possibilidade de exposio de nossos tcnicos (hoje da Solis) a um universo de outros
desenvolvimentos e pessoas, com viagens apoiadas e patrocinadas no s pela Univates, mas
pela Unesco, Linux International, HP, etc...
J em sua misso, a Univates define o ecossistema em que se encontra: Gerar, mediar e
difundir o conhecimento tcnico-cientfico e humanstico, considerando as especificidades e
as necessidades da realidade regional, inseridas no contexto universal, com vistas
expanso contnua e equilibrada da qualidade de vida.
Assim, alinhado ao Plano Estratgico, o Plano de Desenvolvimento de Informtica, pensado
na forma de base a uma ecologia do conhecimento, deve involucrar em sua proposta todos
os elementos da misso da Univates: o conhecimento em si, a regio no contexto universal, e
os atores em seus vrios papis (alunos, professores, funcionrios, membros da
comunidade). E os atores, vistos como usurios dos sistemas de informtica e geradores das
demandas para a evoluo destes sistemas, tambm so parte deles, e centro de um
ecossistema onde no sero centro em todos os momentos.

Economia

Ainda que no seja o aspecto mais importante para a adoo de uma ou outra tecnologia, h
que se convir que recursos limitados para investimentos exigem a constante necessidade de
se trabalhar com solues criativas e com o menor custo possvel. A adoo do software
livre, especialmente na administrao da Univates, permitiu que adaptssemos e
desenvolvssemos solues com domnio da tecnologia, alm da imediata economia em
funo de no haver a necessidade de se pagar por licenas de uso.

A seguir, o documento elaborado para a Univates apresenta o levantamento de todo o parque

instalado e a economia feita ao no se utilizar softwares proprietrios. A tabela abaixo apresenta
um exemplo do que pode ser feito, com os nmeros omitidos, j que os mesmo podem variar
bastante. Para a economia vinda do uso do Sagu, Gnuteca, Teleduc, Agata Report e outros foram
consideradas, na poca, as opes equivalentes mais baratas, mesmo que no atendessem a
totalidade das necessidades da Univates.

Sumrio da Economia em Licenas

Pgina 54 de 117
 Descrio Total Economizado

n desktops rodando exclusivamente softwares livres

m desktops com Sistema Operacional proprietrio e

OpenOffice

Sobrevida de x computadores que seriam obsoletos com

software proprietrio

Uso de software livre nos servidores

Uso de bases de dados livres

No necessidade de licenas de acesso s bases de dados

Uso do Sagu

Uso do Gnuteca

Uso do Teleduc

Uso do Agata Report

Uso de estrutura em software livre para correio eletrnico

Total R$ 0,00

No est considerada aqui a economia feita com a utilizao de softwares livres para o
ensino, que cresce consideravelmente e ainda necessita ser devidamente avaliada.
Ainda que cada tipo de software proprietrio tenha sua poltica de atualizao a prtica tem
mostrado que a cada dois anos os investimentos em software se repetem.

Aproveitamento de cdigo e colaboraes

Mais difcil de mensurar a economia indireta obtida a partir da prpria cultura de

aproveitamento de cdigo e colaborao que existe na comunidade de software livre. Com
softwares proprietrios, como ns mesmos temos o exemplo a partir de nosso ERP, ficamos
na maior parte do tempo merc de implementaes ou solues vindas de um fornecedor
nico (ainda que, at neste caso, tenhamos buscado alternativas). No quadro abaixo,
ilustramos os principais cdigos alheios que utilizamos na construo dos nossos sistemas,
assim como colaboraes que recebemos.

Cdigo da O que faz Onde foi utilizado Estimativa de

Comunidade economia de tempo
(um desenvolvedor)

PEAR Camada de abstrao Agata Report39 2 meses

Pgina 55 de 117
 Cdigo da O que faz Onde foi utilizado Estimativa de
Comunidade economia de tempo
(um desenvolvedor)

de base de dados,
permitindo a conexo
com diferentes sistemas
de bases de dados

JPGraph Biblioteca e aplicativos Agata Report, Scotty40, 6 meses

para a criao dinmica GnuData41, Fred42
de Grficos

PHPDocWriter Gera documentos no Agata Report 12 meses

formato OpenOffice
(XML) dinamicamente

FPDF Gera documentos no Agata Report 6 meses

formato PDF
dinamicamente

Yala Autenticao Internet, solicitao de ms

OpenLdap diretamente conta de e-Mail
atravs do PHP

HTMLArea Editor grfico em Fred 2 meses

JavaScript para a
autoria web

phpNuke Gesto de contedo Os temas (visual) do 1 ms

web PhpNuke foram
utilizados ou usados
como base em vrios
ambientes web

Phpopenchat Salas de bate-papo para Fred 1 ms

a web (no liberado
para uso geral por
limitao de recursos)

WebMiau Aproveitado o cdigo Fred 3 meses

para nosso WebMail

Gettext Estrutura que permite Todos -

39 O Agata Report (www.agata.org.br) um sistema para a extrao de informaes e gerao de relatrios a partir da
conexo direta com bases de dados. Na Univates ele utilizado para a gerao de diversos relatrios a partir dos
sistemas Sagu, Gnuteca e Microsiga
40 O Scotty (http://scotty.codigolivre.org.br) o sistema de gesto de chamados tcnicos e ordens de servios utilizado
atravs da Intranet da Univates
41 O Gnudata (http://www.bdr.Univates.br) a base para a implementao de nosso Banco de Dados Regional na
internet
42 O Fred (http://fred.codigolivre.org.br) o gestor de contedo Web utilizado para os portais Internet e Intranet da
Univates

Pgina 56 de 117
 Cdigo da O que faz Onde foi utilizado Estimativa de
Comunidade economia de tempo
(um desenvolvedor)

que nossos sistemas

sejam traduzidos em
outras lnguas

ImageMagik Redimensionamento Fred 3 meses

dinmico de imagens
para a exibio nos
portais web

Twiki Algoritmos, formatao MioloWiki43 1 ms

e exemplo de cdigo

DocBook Ferramenta para a MioloWiki 6 meses

gerao de textos em
mltiplos formatos

Diff Classe para exibir MioloWiki 1 ms

diferenas entre
verses de um mesmo
texto

Total aproximado 44 meses

Colaboraes da O que faz Onde foi utilizado Estimativa de

Comunidade(diretame economia de tempo
nte em nossos (um desenvolvedor,
produtos) considerado apenas o
tempo que serviu
diretamente
Univates)44

Bruno Depero (Itlia) Testes e melhorias na Agata Report 1 ms

conexo com bases de
dados distintas,
traduo para o italiano

Jeffrey Buchbinder Uso de mltiplas Agata Report ms

(Frana) buscas secundrias
(subqueries) e
melhorias no cdigo

43 O MioloWiki (http://wiki.solis.coop.br) utilizado na criao cooperativa de documentos, e na Intranet Univates a

base para os manuais de usurio do Sagu, Gnuteca e outros
44 Note-se que, mesmo que uma colaborao na forma de uma traduo para uma outra lngua (ou conexo com bases
de dados diversas) possa no ter influenciado diretamente o uso de um programa pela Univates, isto acaba
auxiliando no aumento da visibilidade de tal programa e permitindo o seu uso por mais pessoas, que posteriormente
podem colaborar em funcionalidades que utilizamos aqui.

Pgina 57 de 117
 Colaboraes da O que faz Onde foi utilizado Estimativa de
Comunidade(diretame economia de tempo
nte em nossos (um desenvolvedor,
produtos) considerado apenas o
tempo que serviu
diretamente
Univates)

fonte usado na
mesclagem de
documentos (merge)

Thomas Sprietersbach Melhoras no sistema de Agata Report ms

(Alemanha, Brasil) traduo e traduo
para o alemo

Luciano Stein (Brasil) Implementaes de Agata Report 1 ms

funcionalidades para a
conexo com bases
SQL Server e Oracle e
testes com o Windows

Johannes Schill Traduo para o Sueco Agata Report -

(Frana)

Brad McCrorey Melhorias na gerao Agata Report ms

de documentos
PostScript

Christian Etuy (Frana) Traduo para o Agata Report -

Francs

Tarique Nagpur e Verso para o MySQL Agata Report ms

Girish Nair (ndia) e testes

Steph Fox (Estados Auxlio com o PhpGtk Agata Report 1 ms

Unidos) e com a traduo para o
ingls

Frank Krommann Ajuda na conexo com Agata Report -

(Estados Unidos) a base de dados
FrontBase

Andrew M. Yochum Ajuda na conexo com Agata Report -

a base de dados Sybase

Flavio Jose Fonseca de Ajuda na conexo com Agata Report -

Souza (Brasil) a base de dados mssql

Brice Vissiere (Brasil) Soluo de problema Agata Report ms

na quebra de coluna

Pgina 58 de 117
 Colaboraes da O que faz Onde foi utilizado Estimativa de
Comunidade(diretame economia de tempo
nte em nossos (um desenvolvedor,
produtos) considerado apenas o
tempo que serviu
diretamente
Univates)

Eduardo Fernandes Ajuda na conexo com Agata Report -

(Brasil) a base de dados SQL
Server

Tomas Cox (Brasil) Auxlio com o uso do Agata Report ms

PEAR DB

Lucas Di Pentima Traduo para o Agata Report -

(Espanha) Espanhol

Yannick Warnier Documentao e Tulip45 ms

correo de erros

Unicamp (vrios) Modelagem da base de Fred 1 ms

dados do sistema de
ramais telefnicos e
inscries em eventos
via web

Uwe Vrias contribuies na PsLib46 1 ms

Steinman(Alemanha) criao da PsLib

Ericson C. Smith Converso de nossa PsLib ms

(Estados Unidos) biblioteca psLib para
classes em PHP, o que
permitiu seu uso em
mais programas

Jay Haugen Alinhamento de texto e PsLib ms

(Alemanha) suporte a documentos
colorido

Joel Leon (Estados Adio de novas PsLib 2 meses

Unidos) funcionalidades,
Jos Paulo B. da Silva soluo de problemas
e outros diversos, verso na
linguagem C e criao
de extenses para
outras linguagens

45 O Tulip (http://tulip.solis.coop.br) um editor de cdigo em PHP, criado para economizar tempo na escrita de
programas nesta que a linguagem de programao mais utilizada na Univates.
46 A psLib (http://pslib.codigolivre.org.br) uma biblioteca que permite a gerao dinmica de documentos, utilizada
em praticamente todos os programas desenvolvidos pela Univates/Solis

Pgina 59 de 117
 Colaboraes da O que faz Onde foi utilizado Estimativa de
Comunidade(diretame economia de tempo
nte em nossos (um desenvolvedor,
produtos) considerado apenas o
tempo que serviu
diretamente
Univates)

(Python, TCL e Perl)

Rudinei Pereira Dias, Gerao de cdigo de Miolo47 ms

Unilassale barras

Ely Matos48, UFJF Mltiplas contribuies Miolo 6 meses

na rea de segurana,
orientao a objetos e
melhorias diversas

Total aproximado 16 meses

47 O Miolo (www.miolo.org.br) o ambiente de desenvolvimento de praticamente todos os programas desenvolvidos

pela Univates/Solis
48 O Ely Matos o desenvolvedor externo mais ativo para o framework Miolo.

Pgina 60 de 117
Desenvolvimento pago por outras instituies

H alguns casos onde melhorias que implementamos em nossos sistemas, ou mesmo

sistemas completamente novos que posteriormente adotamos, foram pagos por outras
instituies. No caso do Sagu249, ainda em desenvolvimento, toda a modelagem e escrita de
cdigo inicial (cerca de dois meses de trabalho) foram pagas pela Universidade Federal de
Roraima, onde os mdulos acadmicos j esto sendo utilizados.
Enquanto trabalhava como Student Assistant na Alemanha, o Marcone Luis Theisen
desenvolveu o LdapSearch, um sistema de busca em bases de dados de autenticao de
usurios no padro Ldap que hoje utilizado integralmente na Univates, em nosso processo
de unificao de acesso aos nossos sistemas.
Muitas melhorias feitas no Gnuteca, Sagu e Agata Report surgiram a partir de servios
prestados para outras instituies de ensino, ainda que, enquanto isto ocorria, no nos
preocupamos com este registro. Na quase totalidade das vezes em que algum de nossos
sistemas foi implantado em outra instituio de ensino, novas necessidades acabaram
tambm trazendo idias que foram incorporadas ao nosso desenvolvimento.

Plano Diretor de Tecnologia da Informao PDTI

Tudo o que j est escrito acima neste documento mostra que, ainda que a TI na Univates
tenha evoludo de forma gerenciada, com resultados que, alm de informatizar a maioria dos
processos administrativos internos e acadmicos da instituio, ainda foram capazes de
atrair a ateno de outras instituies no pas e no exterior. Esta evoluo, porm, deu-se at
pouco tempo de forma reativa: as necessidades surgiam, o CPD atendia a esta necessidade,
mas no existia uma busca de antecipar novas necessidades que podiam surgir a partir do
prprio cumprimento do plano estratgico da Univates.
Ainda assim, com o volume crescente de necessidades e a constante mudana em requisitos
naquilo que j estava desenvolvido nos levou a um planejamento no de antecipao destas
necessidades, mas de construo de um ambiente e processos que nos permitissem a
adaptabilidade de nossos sistemas a necessidades cambiantes da instituio e de seus
usurios. Deste planejamento surgiram processos como o de manuteno proativa
anteriormente descrito; o ambiente de desenvolvimento Miolo, hoje base de todo o nosso
desenvolvimento; a prtica de construo de prottipos prematuros, auxiliando os usurios
na definio de suas necessidades, e outros. A maioria destes processos esto distantes da
compreenso dos usurios, a no ser que eles tenham que ser explicitamente envolvidos em
algum deles. Isto natural, pois ao usurio interessa o resultado final, e no o que leva a este
resultado.
Esta proposta visa a aliar o PDTI ao Plano Estratgico da Univates, buscando no um
exerccio de futurologia, mas construir um guia de melhores prticas que alie de forma
proativa a Tecnologia da Informao s necessidades j previstas, e para as quais solues
podem ser antecipadas de forma planejada. Alm disto, esta proposta busca a manuteno do
pioneirismo e destaque da Univates no desenvolvimento, integrao de solues e uso de
Software Livre, e o exerccio de sua latente liderana em um acordo interinstitucional e
alianas estratgicas na rea de TI que beneficiem a regio e ampliem o mercado de atuao

49 O Sagu2 (http://sagu2.solis.coop.br) a reescrita do Sagu utilizando o ambiente Miolo (www.miolo.org.br), o que

permite uma melhor diviso de seus mdulos, facilidade de manuteno e adio de novas funcionalidades.

Pgina 61 de 117
 para os alunos e egressos dos cursos afins TI. Enfim, esperamos aqui exercer a idia da
Ecologia do Conhecimento, para a qual naturalmente evolumos, com a ampliao de nosso
Ecossistema.

Tomada de Deciso
At hoje, a tomada de deciso sobre as aes do CPD partem da requisio por parte dos
usurios (atravs de um projeto ou chamado tcnico), sua priorizao e atendimento pela
equipe do CPD e terceirizados dentro da melhor percepo do que pode ser feito com os
recursos existentes, da renegociao com o solicitante e do aval do pr-Reitor
Administrativo/Financeiro. Isto gera alguma frustrao dos usurios, especialmente quando
um projeto por ele solicitado preterido em funo de outro que se tornou urgente, uma vez
que, obviamente, com novas necessidades da instituio, as prioridades mudam, e os
recursos para atend-las so limitados. H exemplos clssicos de projetos da prpria Proad,
como o GnuBuy (sistema de leilo reverso) que, mesmo entrando constantemente no
planejamento, tem sido preterido em funo de outros. Outros exemplos existem.
O avano de nossos cursos na rea de TI, e mesmo o aumento natural do uso da informtica
por todos os alunos da instituio, tem gerado demandas tanto de servios quanto de
estrutura, alm de uma interao maior na definio de necessidades com a rea acadmica,
especialmente no contato com o Prof. Marcelo Malheiros. H um bom potencial de
aproveitamento de alunos em vrios projetos de TI, mas precisamos definir como isto ser
feito. A Solis, em sua ltima contratao, pontuou melhor os candidatos que j tivessem
integrados em projetos da comunidade de Software Livre, e dois alunos da Univates com
projetos no portal Cdigo Livre foram admitidos como cooperados.

Comit de Tecnologia da Informao

Com a idia de melhorar o processo de tomada de deciso na disponibilizao e
planejamento futuro de recursos e sistemas de informtica, sugerimos a criao de um
Comit de TI, presidido pelo Consultor de Tecnologia e formado por representantes de
usurios de nosso ambiente de rede e sistemas, de tomadores de deciso (reitoria), dos
principais fornecedores de servios, dos corpos docente e discente. Inicialmente este comit
ter reunies mensais onde sero apresentados os projetos em andamento, necessidades,
limites de recursos, prioridades, e discutidas formas de atender a todos atravs de melhores
prticas e acordos. O formato destas reunies e o encaminhamento dos assuntos nelas
tratados deve ser feito no mesmo formato j utilizado nas reunies de gesto da qualidade.

Quem Resumo das Atribuies

Consultor de Tecnologia Preside o Comit e com base em suas deliberaes administra o

oramento destinado TI. Administra conflitos e tem o voto de
Minerva nos casos de impasse.

Coordenador do CPD Atua como secretrio do Comit, redigindo a ata das reunies e
Univates cobrando junto aos envolvidos o encaminhamento das aes, quer
envolvam compromissos da equipe interna do CPD ou terceirizados,
assim como aes de usurios e demais pessoas apontadas pelos
demais membros do Comit da definio de necessidades ou

Pgina 62 de 117
 Quem Resumo das Atribuies

modelagem de sistemas.

Representante da Reitoria Faz com que as discusses e deliberaes do Comit estejam

alinhadas ao Plano Estratgico da Univates, e leva reitoria questes
do comit e a realimentao para o Plano Estratgico.

Representantes dos grupos Traz ao grupo necessidades especficas relativas aos vrios sistemas
de usurios de sistemas disponibilizados na Univates (Sagu, Gnuteca, gata, Portais, e
internos outros) e auxilia na priorizao de novos desenvolvimentos.
Recomenda-se aqui que os grupos de usurios busquem ter suas
reunies em separado, com os tcnicos responsveis pelos sistemas,
para que a discusso no Comit seja sempre mais estratgica do que
operacional.

Representante do corpo Aponta necessidades de uso e desenvolvimento de TI necessrios

docente rea acadmica, e busca aliar oportunidades de desenvolvimento
busca de conhecimentos que podem ser aproveitados na experincia
educacional, em projetos de pesquisa (especialmente as que podem
obter financiamento externo) e no envolvimento de alunos atravs de
estgios e bolsas.

Representante do corpo Traz ao grupo os interesses dos alunos, tanto como usurios dos
discente servios oferecidos como na busca de oportunidades de envolvimento
atravs de estgios e bolsas. (DCE)

Representante do setor de Acompanha a evoluo de necessidades de investimentos e servios

apoio em infra-estrutura e traz informaes sobre novas construes e
instalaes que podem influenciar a estrutura de TI, ou depender dela.

Representante da rea de
infraestrutura de
telecomunicaes

Convidados especiais Convidados pelo Comit sempre que um determinado assunto ou

conhecimento pode se beneficiar de ajuda externa.

Representante de Convidados pelo Comit a participar de reunies ou parte delas,

fornecedores respondendo e orientando em questes especficas aos produtos e
servios fornecidos.

Comit Interinstitucional de Tecnologia da Informao

A Univates reconhecida como referncia na adoo e desenvolvimento de software livre na

comunidade acadmica, tanto nacional como internacionalmente. Uma prova disto a
expanso de nossos workshops de desenvolvimento para o SDSL, Seminrio de
Desenvolvimento de Software Livre, hoje organizado em parceria com a Unicamp,
Unisinos, UnB e Istec, mas alm disto a prpria adoo de softwares por ns desenvolvidos

Pgina 63 de 117
 por instituies como a Unicruz, UFJF, UFRR e o apoio de organizaes como a Unesco na
disseminao do Gnuteca. Praticamente em todos os eventos dos quais participamos temos
sido contatados em funo da curiosidade por nosso uso de software livre. A Univates pode
aproveitar este reconhecimento transformando-o em uma efetiva liderana em um Comit
Inter-institucional de Tecnologia da Informao, cujo objetivo a adoo e disseminao de
tecnologias livres e contedos abertos, com a adoo e definio de padres e viabilizando
com economia a informatizao de processos administrativos e acadmicos.

Figura 5 Cadeia de valor do processo educacional (Keats & Darries)

Segundo uma pesquisa feita por Derek Keats e Madini Darries50 junto a estudantes de
universidades sul-africanas, o valor percebido em uma instituio de ensino est no
conhecimento que adquirem em sua passagem pela instituio, no processo de aprendizagem
que leva a tal conhecimento (capacidade dos docentes em transmitir o conhecimento,
metodologia de ensino) e no reconhecimento da prpria instituio em seu meio (pesquisa,
insero comunitria, colocao de egressos no mercado de trabalho). Vrios outros fatores
como o prprio contedo usado nos cursos, dados e informaes utilizados na gesto
administrativa ou acadmica e os sistemas administrativos so comuns para qualquer
instituio de ensino e, por isso, tidos como uma base necessria, mas que no
necessariamente agrega valor ao processo educacional. Assim, faz sentido que as instituies
50 Towards a Knowledge Ecology Strategy for the University of Western Cape

Pgina 64 de 117
 trabalhem em conjunto no desenvolvimento e integrao de sistemas que atendam a esta
base e diferenciem-se onde os alunos e a comunidade, na qual est inserida, realmente
percebam valor.
O Comit Interinstitucional de Tecnologia de Informao pode ser proposto a alguma das
entidades das quais a Univates j faz parte, ao grupo de instituies que j utilizam os
sistemas por ns desenvolvidos, ou ainda pode ter um carter internacional j na sua
formao, com a busca do apoio da Unesco e a integrao atividades como o Avoir
(African Virtual Open Initiatives &Resources) e o Istec (Ibero-American Science and
Technology Education Consortium). A atividade inicial deste comit seria a definio da
base tecnolgica comum da qual todas as instituies de ensino poderiam se beneficiar para,
a seguir, buscar, entre as instituies, desenvolvimentos e sistemas que pudessem ser
padronizados, generalizados e usados por todas as demais, definindo grupos de trabalhos,
investimentos, prazos e compromissos para atender aos interesses de todas as instituies
participantes (ainda que os contedos desenvolvidos estejam disponveis de forma livre a
qualquer interessado).
Este comit pode servir ainda para a identificao de problemas e solues adotadas na
insero de cada instituio em sua comunidade regional, identificando quais destas
solues e modelos podem ser transplantados para outras regies e realidades, especialmente
ampliando a gerao de emprego e renda e buscando ampliar oportunidades de intercmbio
para os estudantes.
Uma primeira proposta de trabalho para este Comit Interinstitucional de TI a definio de
aes que levem ao desenvolvimento de um ERP Acadmico.
Nota: Esta proposta de um Comit Interinstitucional de TI ainda um sonho que acredito ser
realizado.

Planejamento de Capacidade

Equipamentos

Como j exposto anteriormente, a expanso de nossa base de TI deu-se de forma reativa s

necessidades da Univates. Mesmo os servios hoje disponibilizados padecem de uma
estrutura adequada para a sua oferta, e nossos usurios experimentam paradas que, se por
um lado so inevitveis em funo da prpria falibilidade dos equipamentos, por outro
poderiam ser evitadas com o investimento em uma estrutura mais robusta e com maior
capacidade de tolerncia a falhas. Outros servios ainda deixam de ser oferecidos (ou sofrem
atraso em sua oferta), ainda que tecnicamente viveis, seja por falta de equipamentos ou
recursos humanos (salas de bate-papo especializadas por curso, sistema de agenda
compartilhada, como exemplo). A adequao da capacidade atual de TI, com alguma folga,
nos permitir avaliar melhor as necessidades de expanso (hoje a expanso ocorre quando
alguma necessidade fica na iminncia do no atendimento) com medidas efetivas de sua
utilizao. Tais medidas hoje so usadas praticamente na identificao de gargalos que j
impactam algum sistema.
Algumas aes de adequao ao consumo atual de TI pela Univates j esto sendo tomadas,
especialmente com investimentos em ativos de rede. Outras merecem uma anlise imediata
(talvez com a rpida criao do Comit de TI), como a aquisio de novos equipamentos
para servios eventuais, mas que j causam impacto na rede e sistemas (como relatrios,

Pgina 65 de 117
 autenticao, Teleduc) e a criao de uma estrutura de replicao mnima de ambiente para a
rpida retomada de servios em caso de pane generalizada e o aumento da autonomia no uso
de energia eltrica com a aquisio de um grupo gerador (especialmente levando em conta
que j sofremos por causa disto em momentos como matrcula de calouros).
Nota: A seguir, o documento oficial apresenta uma srie de dados sobre o crescimento estimado da
instituio nos prximos anos e, com base na capacidade atual, prope a aquisio ordenada de
equipamentos para os prximos trs anos. Estes dados foram omitidos aqui por questes de
confidencialidade.
H que se levar em conta ainda, especialmente com constante diminuio do custo dos
computadores e do acesso Internet, com sua crescente popularizao, que observaremos
nos prximos anos uma utilizao maior dos servios que oferecemos de forma remota. de
se esperar tambm que mais alunos venham instituio com equipamentos que tenham
capacidade de conexo rede sem fio (pdas e notebooks wireless), e isto deve at ser
incentivado. O prprio contedo multimdia oferecido nos cursos distncia, e que passa a
ser gerado por nossos cursos na rea de comunicao ir trazer impactos para a nossa
estrutura de rede e servidores. Ainda neste ano estaremos testando vdeo-conferncias
atravs da web, e isto deve gerar um trfego adicional que necessita ser medido e avaliado.
Novos servios desejados podem entrar em calendrio de testes e implementao, com seu
consumo de capacidade agora devidamente medido, e novos investimentos avaliados e
planejados de acordo pelo Comit de TI. Dentre os novos servios desejados esto (sem se
limitar a eles):
Servidor de DataWarehousing para a extrao de relatrios a partir de espelhos
das bases de sistemas de produo, minimizando o impacto a eles;
Sistema de autenticao e acesso para PDAs para a disponibilizao de servios
web como o controle de presenas e notas tambm para PDAs sem fio (e posterior
expanso para um controle automtico de ponto e freqncia com smartcards ou
identificao rdio-identificada;
Expanso da oferta de contedo multimdia via web em todas as salas
(especialmente vdeo-conferncia);
Sala dedicada vdeo-conferncia
Sistema de digitalizao, arquivo e busca de documentos (facsmile digital)

Rede
Nota: As estimativas de valores relativas expanso da rede foram omitidas aqui.

Software
A quase totalidade do desenvolvimento de software para a Univates, assim como o suporte
aos vrios sistemas que utilizamos est terceirizada para a Solis, para a qual a folha de
pagamento do CPD foi transferida em setembro de 2003. O acompanhamento dos
projetos desenvolvidos pela Solis feito atravs de documento prprio, e novas requisies
de desenvolvimentos passam hoje pela aprovao da reitoria, mas podem passar pelo Comit
de TI aqui proposto. Durante o ano de 2004 a prpria adequao na forma de relacionamento
com a Solis e especialmente novas necessidades que surgiram na oferta de servios via
Inter/Intranet e a manuteno do desenvolvimento do Sagu em sua verso 1 fez com que
realocssemos muitas horas prestadas pela cooperativa Univates. A partir da renegociao

Pgina 66 de 117
 do contrato com a Solis em setembro de 2004 temos que rever as prioridades, especialmente
no que diz respeito a destinao de horas ao desenvolvimento do Sagu2 para que no
venhamos a ter problemas de desempenho com o aumento de sua base de dados e acesso a
ela. Alm disto, h projetos solicitados por usurios da instituio que ainda precisam ter
suas horas aprovadas (sistema de avaliao 360 para o RH; um sistema para a gesto de
contatos com alunos, egressos e comunidade; sistema para a criao de Cursos e Eventos
com controle de fluxo; sistema para chamados de apoio das bibliotecrias para a consulta ao
COMUT e consultoria bibliogrfica; sistema para a rotulagem de amostras de resduos
atravs da web; BDI; Currculos com integrao ao Lattes; portal dos professores) e novas
horas a serem dedicadas a projetos como a implantao do sistema Nou-Rau (Biblioteca
Digital), sua integrao ao Gnuteca e ao Clara-OCR (sistema da USP para a digitalizao de
documentos) e a possibilidade de integrao dos mesmos bases da iniciativa Open
Archives.

Suporte
O suporte ao ambiente de informtica da Univates tambm est terceirizado em sua grande
parte para a Solis, sob gesto do CPD. Ainda que muitas aes de manuteno proativa
tenham sido tomadas e constantemente aprimoradas, o prprio aumento constante no
nmero de equipamentos, servios e usurios tem gerado uma demanda que as estatsticas
de nosso sistema de chamados tcnicos j mostra que est reprimida. A prpria Solis deve
propor um aumento no nmero de horas destinadas ao suporte de rede, software bsico e
aplicaes.

Concluso
A ideia bsica desta proposta de PDTI torn-lo um documento vivo, com aes de
melhoria contnua que o realimentem e o transformem em um guia de aes e investimentos
na expanso do uso da tecnologia na Univates, exercitando o conceito de ecologia do
conhecimento em uma gesto que envolva e leve em conta na tomada de decises todos os
que, de alguma forma, usam a tecnologia em seu dia-a-dia. O Comit de Tecnologia de
Informao aqui proposto involucra usurios, fornecedores e tomadores de deciso e,
idealmente, deve ter autonomia na negociao de um oramento para a rea de TI e sua
administrao. Com uma proximidade maior da rea acadmica, que possui representao
no comit, espera-se fomentar aes integradas, especialmente de desenvolvimento de
software, que envolvam o corpo docente e discente. O Comit Interinstitucional amplia a
viso e ao das iniciativas de TI de vrias instituies, buscando sempre a economia e a
gerao de oportunidades.
A proposta de continuidade dos servios da Brod Tecnologia passar da gesto do CPD, que
auxiliou a evoluo do uso de TI na Univates e seu destaque com o pioneirismo no uso e
desenvolvimento de software livre, para uma gesto estratgica que evolui e integra o PDTI
ao Plano Estratgico da Instituio, com a presidncia do Comit de Tecnologia de
Informao e a busca de relaes interinstitucionais que permitam a evoluo do Comit
Interinstitucional de Tecnologia da Informao.
No ano seguinte apresentao deste documento atuei, atravs da BrodTec, como consultor do
Comit de TI da Univates. A transio de minhas funes gerencias para o comit deu-se de forma
tranquila e, em 2005, deixei de atuar diretamente na instituio, mantendo-me ainda como
cooperado e consultor estratgico da Solis at fevereiro de 2006, quando comea mais uma fase de
aprendizagem na gesto de projetos.

Pgina 67 de 117
O Mtico Homem-Ms
Fred Brooks Jr. confessa em seu mais recente livro, The Design of Design, que tomou emprestado
o ttulo de uma obra anterior de Gordon Glegg. Como tive a honra de ser o tradutor de duas obras
de Brooks para o portugus, O Mtico Homem-Ms e o prprio O Projeto do Projeto da
modelagem implementao, ambos publicados pela Campus Elsevier, sinto-me a vontade de, para
este captulo, tomar emprestado o nome de um dos livros e de um ensaio seminal de Brooks sobre
Engenharia de Software.
Conheci a primeira edio, em ingls, de O Mtico Homem-Ms (The Mythical Man-Month) em
1988, quando fui pela primeira vez para os Estados Unidos ser treinado na manuteno dos
processadores de comunicaes NCR-Comten. Um dos instrutores, Jim Wild, percebeu em nossas
conversas o meu interesse crescente por desenvolvimento de software e pela forma correta de
fazer as coisas. De fato, desde que eu estudava eletrnica no Colgio Tcnico Lavoisier, no Tatuap,
em So Paulo, eu j me interessava por software. Aprendi Basic com um curso publicado na revista
Nova Eletrnica e exercitava meus programas no papel e, quando conseguia, nos poucos Sinclairs
ZX-80 que o colgio havia comprado. Profissionalmente, a primeira linguagem de programao que
aprendi foi o Assembler IBM/370, mas a verdade que durante um bom tempo meu principal
trabalho era com a manuteno de hardware. Verdade seja dita, porm, que ali no final dos anos
1980 havia muito software envolvido na manuteno de hardware, desde a execuo e
parametrizao de rotinas de testes at a necessidade de, ao menos basicamente, entender o software
executado pelos clientes para ter uma melhor ideia de como diagnosticar o problema.
Foi Jim Wild quem presentou-me com uma edio de O Mtico Homem-Ms, que at hoje um de
meus livros de cabeceira. Nele, Fred trata de algumas questes bem bsicas, por vezes bvias e por
isso mesmo extremamente importantes. Dentre outras coisas, com Fred aprendi que o bvio deve
ser constantemente lembrado, exercitado, pois aquilo que est sempre vista corre o risco de, com o
costume, passar despercebido em algum momento. No artigo que d ttulo ao livro, Fred diz que
adicionar mo de obra a um projeto que j est atrasado tem o grande potencial de atras-lo ainda
mais, por vrios fatores. O principal deles o acrscimo da necessidade de comunicao entre os
membros da equipe aumentada que, por si, j uma sobrecarga de trabalho. Em No existe bala de
prata Fred fala da natureza dos problemas de software e sua individualidade, dizendo que no h
uma soluo mgica, como uma bala de prata para matar lobisomens, que funcione para todos os
casos, mas em uma reviso de seu prprio artigo publicada na edio de 20 anos de O Mtico
Homem-Ms (a que foi traduzida para o portugus), ele aponta algumas esperanas na busca desta
soluo.
O livro de Fred, publicado originalmente em 1975, mas contendo ensaios escritos ainda no final dos
anos 1950, surpreendentemente atual. Tive a oportunidade de perguntar a Fred a razo desta
longevidade quando do lanamento da edio em portugus. Ele respondeu-me:
O livro primariamente sobre os aspectos pessoais da engenharia de software, no sobre os
aspectos tcnicos. As pessoas no mudaram tanto assim desde 1975.
Algumas das prticas que aprendi sobre Extreme Programming (e mais adiante sobre Scrum)
solidificaram o que eu j havia aprendido e aplicado a partir da leitura dos ensaios de Fred. Posso
dizer, com tranquilidade, que o livro que mais influenciou minha forma de gesto de projetos (e at
de pessoas) foi O Mtico Homem-Ms. Com o tempo e a experincia, outras leituras, conversas e
vivncias prticas foram temperando esta influncia. E no posso deixar de acrescentar aqui que sou
extremamente grato ao Andr Wolff, editor da Campus Elsevier, por ter proporcionado a
oportunidade que levou-me traduo dos livros do Professor Brooks e a conhec-lo pessoalmente,
quando convidei-o a palestrar na edio de 2009 da Latinoware.

Pgina 68 de 117
Na Bibliografia esto outros livros que ajudaram a formar minha base de pensamento para o
exerccio de minha profisso (e tambm para muitas atitudes de minha vida pessoal). Aqui cito
apenas outros dois:
The Cathedral and the Bazaar, de Erick S. Raymond. Neste livro Eric analisa a maneira atravs da
qual o sistema operacional Linux foi desenvolvido, sempre colocado para o escrutnio de um
imenso nmero de usurios e desenvolvedores com seu cdigo totalmente exposto. Segundo
Raymond, dado um grande nmero de olhos, todos os problemas vm tona e, assim, podem ser
mais facilmente resolvidos.
Just for Fun, de Linus Torvalds. Nele Linus d a recomendao sobre a forma como um software
deve ser liberado: logo cedo e sempre!

Pgina 69 de 117
O portal Cdigo Livre
Na edio de 2000 da Linux World Conference and Expo conheci mais de perto o projeto
SourceForge.Net, um grande repositrio de programas em cdigo aberto disponibilizado para a
comunidade de desenvolvedores. Todos podem usar o portal para distribuir seus programas,
hospedar a pgina de seu projeto, ter o controle de verses na evoluo de sua produo, discutir
novas funcionalidades e prestar suporte aos usurios atravs de listas de discusses e utilizar uma
srie de outros servios. Na noite do mesmo dia em que contatei o pessoal do SourceForge liguei
para o Vilson Gartner, um dos principais desenvolvedores do Sagu e posteriormente principal autor
e mantenedor do framework Miolo para que tomasse conhecimento do projeto e instalasse uma
verso local, na Univates, para avaliarmos a possibilidade de us-lo para disponibilizar os nossos
projetos.
Na poca j havamos contado aos quatro cantos do mundo sobre o desenvolvimento do Sagu em
software livre e j havamos distribudo o cdigo para algumas pessoas e instituies. Mas no
tnhamos ainda um controle formal de verses e nem uma pgina web especfica para o projeto. O
SourceForge, por outro lado, no tinha uma verso em portugus e ns gostaramos de oferecer
nosso portal na nossa lngua. O resultado disso foi a criao do portal CodigoLivre.Org.Br, que no
momento da escrita deste livro hospedava mais de 2.000 projetos com mais de 15.000 usurios
registrados. Hoje o portal est hospedado na Unicamp.
Quando o portal foi disponibilizado para a comunidade, em janeiro de 2001, seu nome era Cdigo
Aberto. Em novembro do mesmo ano, uma srie de discusses com Richard Stallman, presidente da
Free Software Foundation nos levaram a adotar o nome Cdigo Livre para o portal.
Sinceramente confesso que, mesmo hoje, ainda acho que a discusso em cima da semntica e da
importao desnecessria da duplicidade de significados da palavra "free" est aqum do real
esprito de compartilhamento e liberdade de acesso ao conhecimento. Alis, para brasileiros de uma
certa idade, como eu, a "Abertura" virou quase sinnimo de "Liberdade" a partir das manifestaes
por uma "Abertura ampla, total e irrestrita", em voz alta, pelas ruas de nosso pas, chamando por
uma democracia que j tardava no final dos anos 1960 e incio dos anos 1970. Hoje, ainda temos
que aprender a valorizar melhor esta abertura e liberdade, no s com nosso voto, mas com a efetiva
cobrana e fiscalizao de nossos eleitos. Mas isto j est fora do escopo deste livro.
O Cdigo Livre atendia a duas de minhas crenas, desenvolvidas a partir do aprendizado das
leituras que citei anteriormente:
O cdigo que produzamos era liberado logo de incio e sempre. De fato, o controle de
verses ficava aberto viso de todos.
Com isto, nosso desenvolvimento estava sempre aberto crticas e sugestes, que vinham
das mais variadas formas. Olhos suficientes e problemas tona. Um verdadeiro incentivo a
uma limpeza constante do cdigo.
Uma coisa interessante que passou a acontecer foi que, cada vez mais, nossa equipe recebia
solicitaes de servios e suporte daqueles que comeavam a experimentar nossos sistemas, em
especial o Sagu e o Gnuteca. Isto nos obrigou a pensar em uma forma melhor de estruturar estes
servios e esta foi, em grande parte, a origem da Solis.

Pgina 70 de 117
Cooperativismo e Software Livre Um modelo de negcios
Se uma estrutura de negcios cooperativa funciona para a Sunkist e para a Land O'Lakes,
ela pode funcionar tambm para a produo de software. Depois de uma srie de projetos
de desenvolvimento de software em uma universidade, desenvolvedores no Brasil esto
usando um plano de negcios antigo em uma forma inovadora.
Assim foi apresentado o artigo51 que escrevi para a revista Linux Journal de abril de 2004.
J a partir de 2001 ns comevamos a viver uma situao, de certa forma, incmoda dentro da
Univates. A divulgao do Sagu, do Gnuteca, e mesmo de nossa adoo do StarOffice mostravam
claramente nosso pioneirismo na adoo de softwares livres. Especialmente os cursos que
desenvolvemos para a equipe interna de funcionrios sobre o uso do StarOffice acabaram sendo
contratados por uma srie de clientes no Rio Grande do Sul. Cursos sobre o desenvolvimento na
linguagem PHP eram ministrados por nossa equipe em todo o Brasil e as implantaes do Sagu e do
Gnuteca comearam a acontecer e a exigir uma boa quantidade de suporte.
O incmodo vinha do fato que a Univates no era, e nunca quis ser, uma fbrica de software. Por
outro lado, era inegvel que havamos desenvolvido uma fonte de receitas que deveria ser
aproveitada. Na poca, a Univates j comeava a discutir a criao de uma incubadora (que depois
concretizou-se na Inovates) e o pr-reitor administrativo, Professor Eloni Salvi, mestre em
economia a quem eu me reportava diretamente, um grande mentor em empreendedorismo. A
equipe do CPD era formada, em sua quase totalidade, por alunos da instituio. Avaliando o que era
gasto com o CPD em termos de salrios, encargos, espao fsico e equipamentos, parecia bastante
vivel, economicamente, tornar toda esta equipe uma entidade terceirizada. Mas que tipo de
entidade?
O Vale do Taquari tem uma tradio agrcola bastante forte, especialmente atravs de cooperativas
de produo rural. Os alunos da Univates e, por consequncia, os funcionrios do CPD, eram em
boa parte oriundos de famlias vindas do meio rural. Assim, o cooperativismo j estava na veia de
todos. Analisando uma breve descrio sobre o cooperativismo, da International Co-operative
Association (www.ica.coop), vemos que ele tem muito a ver com a forma de produo de software
livre:
Cooperativas tem por base a ajuda mtua e o cuidado com o prximo. Uma cooperativa
um tipo de negcio ou organizao. um grupo de pessoas que trabalha em conjunto para
resolver seus prprios problemas e atender a suas necessidades. As cooperativas diferem de
outros tipos de organizao por observar trs regras principais: 1) cooperativas tratam as
pessoas com justia e respeito; 2) cooperativas encorajam as pessoas a trabalharem na
soluo de seus problemas mtuos; e 3) cooperativas fornecem produtos e servios que vo
de encontro s necessidades das pessoas, ao invs de apenas fazer dinheiro.
Estava claro que as 20 pessoas que deixavam seu emprego como funcionrios do CPD da Univates
tinham que ter o seu sustento, mas tambm era claro que a forma pela qual viria este sustento era
diferente da forma pela qual funcionavam outras empresas de software. A Solis, Cooperativa de
Solues Livres, no teria patentes ou propriedade intelectual alguma sobre a sua produo, j que
lidava, da mesma forma que uma instituio de ensino, com o conhecimento livre que sempre
estaria ao alcance de todos. Sua capacidade de criao, de soluo de problemas seria a base da
oferta de seus servios. Mas a Solis nascia com o apadrinhamento da Univates, que j seria seu
grande cliente desde o princpio.
O que era o valor equivalente folha de pagamento dos funcionrios do CPD tornou-se o valor do

51 http://www.linuxjournal.com/article/7081?page=0,0

Pgina 71 de 117
contrato entre a Univates e a Solis. Como o custo trabalhista da Solis era bem menor, a diferena
permitiu o aluguel de uma sede e o financiamento de equipamentos para os cooperados, coisas com
as quais a Univates no precisaria mais arcar, o que foi extremamente importante para demonstrar
esta economia aos tomadores de deciso da instituio.
Com o tempo, outros clientes garantiram que a Solis ficasse mais independente da Univates. A
Univates, por sua vez, acabou por reaparelhar seu CPD, hoje o NTI (Ncleo de Tecnologia da
Informao) para o seu suporte e desenvolvimento interno, mas mantendo-se tambm como cliente
da Solis.
A Solis um dos projetos da BrodTec dos quais tenho muito orgulho, mas ele jamais teria sido
possvel sem a viso empreendedora da Univates, em especial de seu reitor, Ney Jos Lazzari e do
pr-reitor administrativo na poca, Eloni Jos Salvi que, junto comigo e com a bem-vinda
colaborao do Prof. Derli Schmidt definiu o projeto que deu origem ao modelo de negcio da
Solis, um exemplo de compromisso de uma universidade com o desenvolvimento de sua regio.
Fundada em janeiro de 2003, a Solis a primeira cooperativa de desenvolvimento e integrao de
solues em software livre. Seu exemplo foi seguido por uma srie de outras cooperativas em todo
o Brasil e na Amrica Latina e, graas a este projeto, tive a oportunidade de ministrar palestras e
minicursos em vrios lugares do Brasil e do mundo sobre este modelo de negcios. Hoje a Solis
emprega, entre cooperados, estagirios e funcionrios, mais de 60 pessoas, uma das empresas que
mais arrecada impostos no Vale do Taquari e ficou em terceiro lugar no ano de 2010 como a melhor
empresa para se trabalhar, segundo o Instituto Great Place to Work (GPTW), entidade com
atuao em 40 pases, em parceria com a revista Computerworld, que divulgou o ranking Great
Place to Work TI & Telecom.

Pgina 72 de 117
Trs anos de Microsoft
Em novembro de 2005 fui convidado a palestrar sobre modelos de negcios para software livre em
um local um pouco diferente daqueles aos quais eu estava acostumado: a sede da Microsoft em So
Paulo. Roberto Prado, gerente de estratgias da Microsoft, havia preparado um evento para os
executivos de vendas e parceiros da empresa, acreditando que eles deveriam entender melhor o
avano do software livre e de que maneira poderiam competir ou colaborar com o modelo, usando-o
a favor dos negcios da empresa.
Este no foi o meu primeiro contato, obviamente, com a Microsoft. Alm de ter trabalhado em
empresas que eram clientes da Microsoft eu mesmo fui um usurio do MS-DOS e Windows at
1993, quando comecei a usar de maneira cada vez mais crescente o Linux, at passar a us-lo, para
meu uso pessoal e na minha empresa, exclusivamente, a partir de 1998. No contato com os clientes
de minha empresa, porm, sempre convivi com a plataforma Microsoft (alm dos ambientes
operacionais da Apple, da IBM e outros).
Na Linux World de 2002 a Microsoft j estava presente com um estande e com sua equipe vestindo
uma camiseta com os dizeres: We want to talk! Como eles queriam conversar, fui falar com eles.
O que o funcionrio da Microsoft disse-me foi basicamente o que a empresa seguiu dizendo nos
anos que se seguiram: No entendemos ainda o modelo do software livre e para ns no faz
sentido abrirmos mo de nossa propriedade intelectual. J cometemos um erro no passado ao no
prestar muita ateno Internet comercial achando que teramos ns mesmos a nossa rede. No
queremos cometer o mesmo tipo de erro, por isso estamos aqui para conversar e entender melhor o
que o cdigo aberto e como isto pode fazer sentido para nossos negcios. As palavras podem no
ter sido exatamente estas, mas o sentido do que ouvi est preservado.
Em 2003, quando eu organizava o primeiro Congresso Internacional Software Livre Brasil, que
aconteceu em Curitiba, a Microsoft quis participar como patrocinadora e fornecer palestrantes para
o evento. Concordei com isso porque sempre achei e sigo achando que faz parte da liberdade
ouvir o que todos tm a dizer para a boa formao de nossa opinio. Isto causou uma certa comoo
e muitos protestos, inclusive do presidente da Free Software Foundation, Richard Stallman, que fez
questo de enviar sua palestra em vdeo para o evento, j que havia quebrado o brao e estava
hospitalizado.
Depois da palestra que ministrei na Microsoft em So Paulo, ainda fui convidado a participar de um
evento para parceiros da empresa, em Boston, 2006, desta vez como ouvinte e com direito a um
almoo com o Steve Ballmer, CEO da empresa, para o qual poderamos fazer perguntas. Na poca,
a Microsoft j havia lanado seu portal Port2552 para comunicar comunidade suas aes
relacionadas a cdigo aberto, em especial a criao de seu Open Source Software Lab e o incio de
iniciativas de interoperabilidade. Perguntei ao Steve Ballmer: Est claro para mim que a Microsoft
quer seguir crescendo e ganhando dinheiro, e agora sente a necessidade de trabalhar mais prxima a
projetos de cdigo aberto. Mas qual a real possibilidade de vermos a Microsoft abrir o cdigo de
seus produtos em prol de uma maior interoperabilidade?. A resposta do CEO da Microsoft foi
ainda mais direta que a que eu havia recebido em 2002: A Microsoft uma grande empresa de
tecnologia com compromisso de aumentar o capital investido por seus acionistas. Nossa proximidde
com projetos de cdigo aberto , em primeiro lugar, para entendermos como o modelo funciona. J
liberamos alguns de nossos cdigos e estamos avaliando o resultado disto. Aonde fizer sentido para
o nosso negcio, colaboraremos com a comunidade, abriremos nosso cdigo. Aonde no julgarmos
que isto faa sentido, manteremos nosso mecanismo de licenas e competiremos fortemente sempre
que necessrio. E como em tudo o que fazemos, onde entrarmos para competir ser para ganhar.

52 http://port25.technet.com/

Pgina 73 de 117
No Frum Internacional de Software Livre de 2006, a Infomedia TV decidiu sediar um debate entre
a Microsoft e a comunidade de software livre. A Fabiana Iglesias, diretora da empresa, convidou-me
a organizar os temas com os desenvolvedores de projetos em software livre e pediu ao Roberto
Prado que fizesse a mesma coisa do lado da Microsoft. Foi um debate muito interessante sobre
mtodos e ferramentas de desenvolvimento, segurana e interoperabilidade. Coube a mim e ao
Prado debatermos sobre licenas. O Prado defendeu a propriedade intelectual e eu defendi que
licenas restritivas e propriedade intelectual no faziam sentido algum, dizendo inclusive que, se a
Microsoft abrisse todos os seus cdigos, isso no causaria nenhum impacto negativo aos negcios
da empresa. Durante este debate, mais uma vez o presidente da Free Software Foundation, Richard
Stallman, fez-se presente gritando, frente das cmeras, Libertas quae sera tamen - Liberdade
ainda que tardia.
Passados alguns meses, o Prado ligou-me e contou-me que estavam iniciando no Brasil uma srie
de parcerias com universidades pblicas, incentivando a criao de laboratrios para tratar de
questes de interoperabilidade e cdigo aberto. Ele convidou-me a participar do projeto dizendo
mais ou menos assim: Voc est a defendendo o software livre, criticando o modelo da Microsoft,
mas que tal vir trabalhar conosco na produo de software de cdigo aberto, interopervel com
Linux e Windows, trazendo tudo o que voc tem dito diretamente aqui para dentro? Pareceu-me
hipocrisia no aceitar esta proposta e entre 2006 e 2009 a BrodTec coordenou o desenvolvimento de
software nos laboratrios de interoperabilidade da Universidade Federal do Rio Grande do Sul
(UFRGS) e da Universidade Estadual de Campinas (Unicamp), com algumas atuaes tambm
junto UNESP e PUC-RS.
A nica condio colocada pela BrodTec para assumir este trabalho que tudo o que fosse
desenvolvido fosse, de fato, publicado na forma de cdigo aberto, com o que a Microsoft estava
plenamente de acordo, mas as publicaes deveriam ser feitas no Codeplex, o portal de
desenvolvimento colaborativo mantido, na poca, pela empresa e hoje por uma fundao da qual ela
faz parte. Partindo do mesmo princpio de publicao logo de incio e de manter o cdigo sempre
visvel, criamos no Codeplex o portal ndos.codeplex.com, um apontador para todos os projetos que
desenvolvamos junto s universidades.
Este contato muito prximo com a academia durante quase trs anos, trabalhando com tecnologias
inovadoras e em contato com professores pelos quais eu nutro grande admirao, como Philippe
Navaux, Nicolas Maillard, Luciana Nedel, Manuel Menezes (da UFRGS), Sandro Rigo (Unicamp)
e tantos outros foi muito especial para a minha aprendizagem e tambm da minha scia, a Joice
Kfer, que teve a oportunidade de conhecer muitas pessoas brilhantes enquanto conclua seu curso
de Engenharia da Computao. Os bolsistas de nosso projeto foram muitos durante este perodo e o
nome de todos eles est nos projetos listados em ndos.codeplex.com. Todos tm a gratido
profunda, minha e da Joice, pelo tempo que passamos juntos e pudemos, dentre outras coisas,
exercitar a metodologia Scrum, em especial no desenvolvimento do Interop Router na Unicamp.
Enquanto na Unicamp desenvolvamos um nico projeto, com uma equipe que variava entre quatro
e cinco bolsistas e o Professor Sandro Rigo como orientador, na UFRGS tnhamos vrios projetos,
cada um tocado tipicamente por um aluno e seu orientador. Estes projetos iam desde a criao de
seres humanos virtuais com articulaes anatomicamente corretas at sistemas de visualizao de
realidade aumentada e de processamento paralelo massivo. Todos eles desenvolvidos em cdigo
aberto e acessveis pelo portal ndos.codeplex.com. A organizao diferente nos laboratrios de cada
instituio nos permitiu exercitar formas diversas de gesto de equipe. Se o laboratrio de
interoperabilidade na Unicamp permitiu-nos trabalhar mais diretamente com o Scrum, o da UFRGS
acabou por nos levar ao contato com pessoas, a leituras e estudos (de fato!) que nos fizeram
explorar outros aspectos de engenharia de software.

Pgina 74 de 117
Engenharia de Software para Software Livre
Quando a Joice graduou-se, no final de 2008, os bolsistas com os quais desenvolvamos projetos de
interoperabilidade, na UFRGS, incentivaram-na para que logo iniciasse seu mestrado, comeando
como aluna especial de algumas disciplinas de mestrado da prpria UFRGS. Na poca eu fazia a
traduo de O Mtico Homem-Ms e a Joice a sua reviso tcnica. Ela gostou da disciplina de
Engenharia de Software, ministrada pelo Professor Marcelo Pimenta, e convidou-me a participar
como aluno ouvinte.
As aulas aconteciam todas as sextas-feiras pela manh, durante todo o primeiro semestre de 2009.
Elas tiveram grande influncia na minha deciso de levar adiante a escrita deste livro. De certa
forma, eu achava que faltava-me uma certa base acadmica para tratar de temas relativos gesto e
mtodos de desenvolvimento, criao de modelos de negcios, trabalho em equipe e tudo o mais
sobre o que agora escrevi. A troca de experincias durante as aulas e a presena constante e
positivamente crtica, ainda que dura e justa, do Professor Pimenta serviu para que, tambm com a
ajuda da Engenheira Joice, muito de meu conhecimento prtico ganhasse uma solidez que no
deixou de me surpreender. A prpria traduo de O Mtico Homem-Ms foi beneficiada por esta
experincia.
Como trabalho de final de disciplina, eu e a Joice desenvolvemos o trabalho Engenharia de
Software para Software Livre, cujo contedo est, em grande, parte reproduzido abaixo.

Introduo
Para aqueles que no esto envolvidos diretamente com o desenvolvimento de software livre e
aberto pode existir a impresso de que o mesmo se d de forma anrquica e desorganizada, com
uma grande disperso geogrfica de desenvolvedores e a falta de um processo formal de
desenvolvimento e documentao. Tal disperso, porm, um dos fatores que leva necessidade da
utilizao de ferramentas e repositrios que permitam a interatividade entre os desenvolvedores e a
organizao do cdigo por eles desenvolvido. Os repositrios de cdigo livre no restringem o
acesso apenas aos desenvolvedores de cada projeto, expondo o cdigo ao escrutnio de uma
comunidade extremamente ampla, evidenciando rapidamente possveis erros. A correo destes
erros pode ser feita tanto pelos desenvolvedores do projeto quanto por colaboradores eventuais.
Um dos exemplos mais expressivos o sistema operacional GNU/Linux que, atravs da Internet, foi
criado de forma coletiva. CASTELLS (2003) comenta sobre este fato:
S uma rede de centenas, milhares de crebros trabalhando cooperativamente, com diviso de trabalho
espontnea e coordenao malevel mas eficiente, poderia levar a cabo a tarefa extraordinria de criar um
sistema operacional capaz de lidar com a complexidade de computadores cada vez mais interagindo por meio
da Internet.

O envolvimento de empresas de tecnologia renomadas como a Sun e a IBM, respectivamente nos

projetos OpenOffice.Org e Apache, que esto entre os discutidos neste artigo, tambm aproximou
tcnicas e processos tradicionais de Engenharia de Software a projetos de software livre e aberto.

Software aberto e software livre

No incio dos anos 80, Richard Stallmann, do Laboratrio de Inteligncia Artificial do MIT,
decepcionado com a forma pela qual as empresas de software passaram a proteger cada vez mais
seus cdigos atravs de patentes e mecanismos de direitos autorais, iniciou um movimento que
desencadeou, em 1985, a criao da Free Software Foundation. Stallmann, props uma lgica
diferente da imposta pela indstria quanto produo e distribuio de programas de computador. A

Pgina 75 de 117
Fundao considera os softwares como um produto cientfico e cultural que deve estar disponvel
para todos. Com esta filosofia, a FSF propiciou um entorno de desenvolvimento comunitrio,
incentivando a produo de programas alternativos aos comerciais que estavam disponveis e
protegendo-os legalmente atravs de licenas como a GPL (General Public License), que, segundo
WILLIAMS (2002), garante aos usurios destes programas quatro liberdades:
A liberdade de executar o programa para qualquer propsito;
A liberdade de estudar como o programa funciona e adapt-lo s suas necessidades. Acesso
ao cdigo-fonte um pr-requisito para esta liberdade;
A liberdade de redistribuir cpias, permitindo a ajuda ao prximo;
A liberdade de aperfeioar o programa e liberar estes aperfeioamentos, de modo que toda a
comunidade se beneficie. Acesso ao cdigo-fonte um pr-requisito para esta liberdade.
No final dos anos 90, empresas de tecnologia de ponta, especialmente do Vale do Silcio na
Califrnia, comearam a utilizar de uma forma mais ampla softwares livres na criao de seus
produtos. Esta foi a poca do estouro comercial das distribuies Linux (pacotes que incluam o
ncleo do sistema operacional e uma srie de aplicativos que podiam substituir sistemas comerciais
existentes), quando vrias empresas abriram seu capital e passaram a atuar de forma mais agressiva
no mercado.
Software livre a traduo do termo, em ingls, free software. A palavra free, entretanto, na lngua
inglesa tem dois significados. Richard Stallmann (WILLIAMS op. cit.) distingue-os com os
exemplos free as in free beer (free como em cerveja de graa) e free as in freedom (free como em
liberdade). Assim software livre diz respeito liberdade e no gratuidade.
Em funo da dualidade da palavra free, Eric Raymond passou a liderar a defesa do uso do termo
open source software (software de cdigo aberto). Este termo tambm era benfico s empresas que
comeavam a utilizar software livre mas tinham receio de seu cunho ideolgico. At hoje o debate
entre o uso dos termos open source software ou free software continua. Para o escopo deste trabalho
considera-se indistintamente os termos software livre e aberto, levando-se em conta que os projetos
aqui considerados tm seu cdigo fonte aberto e o mesmo disponibilizado de forma livre.

Modelos de desenvolvimento de software: a Catedral e o Bazar

BROOKS (1995) afirma que a adio de desenvolvedores a um projeto atrasado apenas ir atras-lo
ainda mais, em funo do aumento exponencial da complexidade e da comunicao, enquanto a
quantidade de trabalho aumenta linearmente. RAYMOND (1999) observa que, se a afirmao de
Brooks fosse integralmente real, o Linux seria invivel. Adiante, em sua argumentao, Raymond
cita o trabalho de Gerald Weinberg, especialmente sua discusso sobre programao sem ego,
observando que quando os desenvolvedores no so possessivos com relao ao seu cdigo e
encorajam outras pessoas a procurarem por problemas e melhorias em potencial, o avano do
software se d dramaticamente mais rpido do que de qualquer outra forma.
A partir disto, da anlise do desenvolvimento do Linux e de sua prpria experincia como hacker,
Raymond descreve dois estilos de desenvolvimento: a Catedral e o Bazar.
Nesta metfora a Catedral corresponde a um processo de desenvolvimento unilateral comparado a
de um pastor que entrega sua mensagem aos fiis sem que esta seja contestada. O Bazar, por outro
lado, corresponde a um ambiente amplo de negociao e troca de idias, onde os comerciantes
competem entre si e ouvem seus potenciais compradores que influenciam diretamente no conjunto
de mercadorias que desejam comprar. A Figura 1 ilustra esta metfora aplicada ao desenvolvimento
de software.

Pgina 76 de 117
 Figura 1 Estilos de desenvolvimento Catedral e Bazar (FABERLUDENS)
No lado esquerdo da ilustrao est o modelo Catedral onde uma equipe de desenvolvedores
entrega um programa compilado, ou seja, sem disponibilizar o seu cdigo fonte, aos usurios. A
indisponibilidade do cdigo fonte impede a colaborao externa equipe. direita est o modelo
Bazar, no qual notam-se imediatamente duas diferenas fundamentais:
o cdigo fonte disponibilizado para que outros desenvolvedores (hackers) possam
conhec-lo e modific-lo;
h um processo de realimentao do qual tanto os desenvolvedores quanto os usurios
participam (atravs de listas ou fruns de discusso, ambientes colaborativos e outros),
contribuindo para a melhoria contnua do programa desenvolvido.
A popularizao do Linux e de outros softwares livres acabou por mostrar o poder do modelo Bazar
e muitas empresas passaram a utiliz-lo em maior ou menor grau. Alguns produtos de software
migraram do controle de empresas de tecnologia para comunidades de desenvolvimento. Dois
exemplos bastante significativos so o navegador web Firefox, originado do Netscape que pertencia
empresa AOL, e o conjunto de aplicaes para escritrio OpenOffice, que resultou da abertura do
cdigo do StarOffice pela Sun Microsystems.
O contrrio tambm acontece. Produtos originados de comunidades de desenvolvimento tm hoje
papel importante dentro de grandes empresas. O servidor web da IBM tem por base o software livre
Apache e o Google grande usurio e contribuidor de projetos livres como a linguagem Python.
A necessidade de um controle das contribuies recebidas e a utilizao de software livre de forma
crescente em um ambiente profissional e empresarial levou as comunidades de desenvolvimento
utilizao de uma srie de prticas de organizao e controle, visando garantir a qualidade dos
produtos desenvolvidos. Na prxima Seo sero abordadas algumas prticas adotadas por
comunidade de desenvolvimento elencadas neste artigo.

Processo de desenvolvimento de software livre

De acordo com MOCKUS et. al. (2002), o estilo de desenvolvimento de cdigo aberto tem a
capacidade de competir e, em muitos casos, tornar obsoletos os mtodos tradicionais de
desenvolvimento de software comercial. Os autores concluem isto ao examinar os mtodos de
desenvolvimento de dois projetos de cdigo aberto bem conhecidos e populares: o servidor web
Apache e o navegador web Mozilla. Ainda em 2002, os autores j identificaram mtodos, processos
e boas prticas aplicadas ao desenvolvimento de software aberto, que so radicalmente diferentes do

Pgina 77 de 117
estilo comercial de desenvolvimento de software:
sistemas abertos so construdos por potencialmente centenas ou milhares de voluntrios,
ainda que alguns destes "voluntrios" tenham seu trabalho patrocinado por suas empresas;
o trabalho no designado, os desenvolvedores escolhem as tarefas que querem executar;
no h um projeto detalhado do sistema;
no h um plano de projeto, cronograma ou lista de entregas.
Com o amadurecimento da utilizao e do desenvolvimento de softwares livres tambm em
ambientes comerciais, porm, possvel encontrar um melhor detalhamento de projetos, incluindo
sua especificao, documentao, cronogramas e listas de entregas.
O desenvolvimento de software livre, em sua maioria, se d em comunidades de desenvolvedores e
usurios. Alguns projetos, porm, tm empresas como suas mantenedoras, com maior ou menor
envolvimento da comunidade. O projeto MySQL53, por exemplo, tem como sua principal
mantenedora, hoje, a Sun Microsystems, com forte envolvimento da comunidade. A brasileira
Solis54, uma cooperativa de desenvolvimento e integrao de softwares livres, possui uma srie de
produtos que, por sua especificidade, mesmo distribudos sob licenas no restritivas, no agregam
uma grande comunidade de desenvolvimento em seu entorno.
Nas Sees seguintes sero abordadas as prticas e ferramentas utilizadas em algumas comunidades
de desenvolvimento de software livre.

Prticas das comunidades de desenvolvimento de SL

Com o objetivo de verificar as prticas utilizadas em projetos de naturezas diversas, mas todos
desenvolvidos em software livre, foi feita uma anlise sucinta baseada na documentao disponvel
nos prprios portais web das comunidades e, sempre que possvel, em trabalhos de outros autores.
As comunidades elencadas foram as seguintes:
kernel Linux;
servidor web Apache;
linguagem de programao Python;
sistema gerenciador de banco de dados PostgreSQL;
framework de desenvolvimento Ruby on Rails;
gestor de contedo web Drupal;
conjunto de aplicativos de produtividade para escritrio OpenOffice.Org.

Linux
Em agosto de 1991, Linus Torvalds enviou um email para o grupo comp.os.minix (que discutia e
trocava informaes sobre o sistema operacional Minix), dizendo o seguinte:
Ol a todos vocs usando o minix. Estou construindo um sistema operacional livre (apenas como um hobby, no
ser to grande ou profissional como o gnu) para o 386 (486) e seus clones. (...) Qualquer sugesto bem-
vinda, mas no prometo que as implementarei. (TORVALDS, DIAMOND, 2001).

O tempo mostrou que o desenvolvimento, estilo Bazar (RAYMOND op. cit.), do Linux foi capaz de
aglomerar um grande nmero de desenvolvedores, usurios e mesmo empresas que exploram
comercialmente o sistema.

53 http://www.mysql.com
54 http://www.solis.coop.br

Pgina 78 de 117
TUOMI (2000) lembra que, at o Linux ser possvel, entretanto, uma srie de outros atores, eventos
e metodologias j existiam, e procura resumir, graficamente (Figura 2) os principais elementos que
permitiram o surgimento do Linux.

Figura 2 - Origens do Linux (TUOMI, 2000)

De fato, a grande maioria dos projetos em software livre tem sua origem em projetos anteriores, de
maneira direta ou indireta, sendo possvel observar elementos destes ancestrais no novo projeto. O
desenvolvimento do Linux ainda fortemente baseado em listas de discusses, mantidas
inicialmente no Usenet55. Elas foram e ainda so a base do desenvolvimento do Minix, do Gnu e,
por sua vez, derivaram dos RFCs (Request for Comments Pedidos de Comentrios), documentos
que formaram a base de toda a estrutura da Internet.
O modelo de desenvolvimento do Linux foi herdado da cultura do Unix, na qual existe um conjunto
de ferramentas, que podem ser facilmente reutilizadas e combinadas como componentes de novas
ferramentas.
O anncio do Linux na lista de discusses deu incio a uma comunidade virtual que, em sua grande
parte, no tinha interaes sociais diretas e confiava totalmente na Internet como a base de suas
ferramentas de desenvolvimento. Com o nmero de contribuies e registros de problemas, vindos
de todas as partes do mundo, era claro que um controle maior sobre isto era necessrio. No incio
dos anos 90 ferramentas como JitterBug e CVS eram usadas, respectivamente, para o registro de
problemas e o controle de verses. Mais recentemente elas foram substitudas pelo BugZilla56 e o
Git57. Outra ferramenta adicional o PatchWork58, usado para o controle de contribuies oferecidas
pela comunidade de desenvolvedores e administradas por cada um dos mantenedores dos vrios
mdulos do kernel Linux que tm o direito de colocar o cdigo diretamente no sistema de controle
de verses.
A distribuio do kernel Linux inclui dois arquivos que informam sobre os mantenedores dos vrios
mdulos (MAINTAINERS) e sobre os autores das vrias contribuies recebidas (CREDITS)
(LEE, COLE, 2003). Estes arquivos mostram a hierarquia do desenvolvimento do Linux. A rigor,
qualquer pessoa pode contribuir para o cdigo do Linux, mas ele precisa passar pelo crivo e
aprovao do mantenedor do mdulo em questo e, posteriormente, ser includo no ramo estvel da
distribuio (depois de passar pelos estgios de desenvolvimento).

55 Usenet (do ingls Unix User Network) um sistema de discusses distribudo disponvel na Internet.
56 http://www.bugzilla.org/
57 http://git.kernel.org
58 http://ozlabs.org/~jk/projects/patchwork/

Pgina 79 de 117
No momento da produo deste documento, eram 546 os mantenedores dos vrios mdulos do
Linux listados no arquivo MAINTAINERS e 498 contribuidores no arquivo CREDITS. Os
comandos utilizados, em uma console Linux, para obter o nmero individual de mantenedores e
contribuidores foram, respectivamente, os seguintes:
catMAINTAINERS|grep"P:"|sort|awk'!x[$2]++'FS="P:"|wc
catCREDITS|grep"N:"|sort|awk'!x[$2]++'FS="N:"|wc

Apache
O projeto Apache59 teve incio em fevereiro de 1995 com a formao de um consrcio para a
soluo de problemas existentes no programa httpd, desenvolvido por Rob McCool no NCSA
(National Center for Supercomputing Applications)60. O nome do servidor Apache veio do fato de
que ele era o mesmo programa httpd com remendos (do ingls a patchy server). Posteriormente,
o Apache foi todo reescrito e h muito pouco ou nada do seu cdigo original (CONLON, 2007).
O projeto mantido pela Apache Software Foundation, que cuida de outros projetos alm do
servidor web, contando com mais de 800 colaboradores diretos com acesso ao cdigo fonte.
O enfoque do desenvolvimento do Apache manter o projeto pequeno. Ele liderado por um
comit gestor cuja participao est limitada queles que contribuem com o cdigo do projeto. Toda
a evoluo deve ser resultado de um consenso tcnico. Qualquer funcionalidade que ultrapasse a do
servidor web bsico tratada como um projeto auxiliar, que deve integrar-se ao principal atravs de
sua interface bem definida.
Interessados em avanar na hierarquia do projeto devem comear utilizando-o, depois contribuir
com o cdigo e eventualmente ganhar acesso base do cdigo fonte (controle de verses). A partir
da podem candidatar-se a membros do comit gestor.
A metodologia usada pela comunidade do Apache baseada em listas de discusses especficas para
usurios, desenvolvedores, testadores, anncios de novas funcionalidades, entre outras. O registro e
controle de problemas so feitos atravs do Bugzilla que tambm serve para a submisso de
pequenos consertos ao cdigo fonte (patches). Qualquer cdigo submetido deve estar de acordo
com o guia de estilo61 disponibilizado no portal do projeto.
A documentao oficial, tambm disponibilizada no mesmo portal, mantida em formatos XML
bastante estritos e os colaboradores devem segui-los. Existem, porm, vrias pginas wiki62
mantidas pela comunidade.
O controle de verses feito com o software Subversion.

Python
A linguagem de programao Python foi lanada para a comunidade em 1991, o que significa que
ela contempornea do kernel Linux. Seus desenvolvedores, porm, procuraram, desde o princpio,
documentar o estilo, a cultura e as ferramentas de desenvolvimento. A maior fonte de referncia
para este documento foi o portal oficial da linguagem63.
A cultura Python tem muito de humor e leveza. O prprio nome da linguagem deriva do grupo de
humor britnico Monty Python e o criador da linguagem, Guido van Rossum, chamado de
Benevolente Ditador Vitalcio. Em 1999, Tim Peters, junto com Guido, publicaram na lista de
discusso comp.lang.python os princpios de projeto da linguagem pedindo, na mesma publicao,
59 http://httpd.apache.org
60 http://hoohoo.ncsa.illinois.edu/
61 http://httpd.apache.org/dev/styleguide.html
62 http://wiki.apache.org/httpd/
63 http://www.python.org

Pgina 80 de 117
que os mesmos no fossem levados to a srio (os autores no recomendam que a lista de princpios
seja usada como tatuagem, por exemplo). Ainda assim, tais princpios ilustram bem a cultura e o
estilo de desenvolvimento do Python:
belo melhor que feio;
explcito melhor que implcito;
simples melhor que complexo;
complexo melhor que complicado;
plano melhor que aninhado;
esparso melhor que denso;
legibilidade conta;
casos especiais no so especiais o suficiente para violar as regras;
ainda que a praticidade vena a pureza;
erros nunca devem passar silenciosamente;
a no ser que sejam explicitamente silenciados;
em caso de ambiguidade, resista tentao de adivinhar;
deve haver uma - e apenas uma - maneira bvia de fazer algo;
mesmo que tal maneira no seja to bvia primeira vista, a no ser que voc seja holands;
agora melhor do que nunca;
embora nunca seja frequentemente melhor do que exatamente agora;
se a implementao difcil de explicar, a ideia ruim;
se a implementao fcil de explicar, talvez a ideia seja boa;
espaos de nomes (namespaces) so uma ideia fantstica - vamos fazer mais deles!
Estes princpios, associados forma de programao orientada a objetos da linguagem (que exige
uma identao formal em sua sintaxe), levam a um cdigo limpo e legvel.
As ferramentas usadas no desenvolvimento da linguagem so descritas por Brett Cannon em
Guido, Some Guys, and a Mailing List: How Python is Developed64. Para o registro e controle de
problemas usada a ferramenta RoundUp65, que tambm usada para a submisso de sugestes de
cdigo e solicitao de novas funcionalidades; para o controle de verses, o Subversion66; listas de
discusses distintas so usadas para a comunicao dos grupos de desenvolvimento, gesto de
problemas e para anncios diversos. Sugestes de melhorias para a linguagem passam por um
processo de anlise e aprovao mais formal, iniciado pela submisso de um PEP (Python
Enhancement Proposal Proposta de Melhoria do Python), que alm de passar pela equipe de
desenvolvimento, deve ter o aval do mantenedor da linguagem (o Benevolente Ditador Vitalcio).

PostgreSQL
O sistema gerenciador de banco de dados PostgreSQL67 um dos mais antigos projetos
desenvolvidos em cdigo aberto (CONLON, op. cit.). Michael Stonebreaker, que havia abandonado
o projeto Ingres na Universidade da Califrnia, em Berkeley, no final dos anos 70, retornou, em
1985, para trabalhar em sua evoluo, inicialmente batizada de Post-Ingres e depois reduzida para
Postgres. O Postgres apenas ganhou um interpretador SQL68 em 1994, graas ao trabalho de
64 http://www.python.org/dev/intro/
65 http://roundup.sourceforge.net/
66 http://subversion.tigris.org/
67 http://www.postgresql.org/
68 Structured Query Language Linguagem Estruturada de Pesquisa

Pgina 81 de 117
Andrew Yu e Jolly Chen, quando foi lanado com o nome de Postgres95 sob uma licena de cdigo
aberto.
Por ser o primeiro gerenciador de banco de dados relacional distribudo sob uma licena de cdigo
aberto, o Postgres logo foi adotado por uma crescente comunidade. Em 1996 teve seu nome trocado
para PostgreSQL e passou a ser mantido pelo PostgreSQL Global Development Group. Sua equipe
nuclear formada por sete desenvolvedores, responsveis pela direo do projeto; por 24
contribuidores principais, que se destacam por seu envolvimento com o projeto e a importncia de
suas contribuies; e por mais 36 desenvolvedores ativos69.
Para coordenar o trabalho dos desenvolvedores, o projeto mantm pginas especficas70 com o plano
para a nova verso (ainda que a data de lanamento seja mais um desejo do que um compromisso),
listas de tarefas, matriz de funcionalidades a serem disponibilizadas em cada verso, lista de
perguntas mais frequentes e instrues para novos colaboradores. As colaboraes devem sempre
ser enviadas atravs de uma lista de discusso especfica, o que garante que elas sero revistas e
consideradas por desenvolvedores experientes e, caso aprovadas, submetidas equipe nuclear. H
tambm uma lista especfica para a discusso de bugs (que devem ser submetidos atravs de um
formulrio padro) e outras para os demais componentes do projeto. Aps o aceite de um registro de
bug, o mesmo passa para uma lista de tarefas, na estrutura de um wiki pblico, para que os usurios
e desenvolvedores possam conferir se um determinado problema que encontram conhecido e j
est com a sua soluo encaminhada, ou se algo novo que deva ser relatado.
A comunidade PostgreSQL utiliza o PGFoundry71, uma implementao completa do repositrio
GForge72, para o controle de colaboraes e verses para todos os seus projetos auxiliares, mas
mantm um repositrio CVS73 parte para o prprio PostgreSQL, ainda que espelhos com o
Subversion sejam externamente disponibilizados.

Ruby on Rails
Ruby on Rails (RoR)74, um framework para o desenvolvimento na linguagem Ruby, comeou como
um projeto de David Heinemeier Hansson em 2004 e hoje envolve uma comunidade de mais de
1.400 contribuidores. De forma similar aos mantenedores do Linux, o Ruby on Rails conta com
uma equipe nuclear (core team), que tem acesso direto ao cdigo fonte do projeto, alm de atuar
em seu direcionamento futuro e filtrar sugestes de novas funcionalidades e melhorias vindas da
comunidade de usurios.
Michael Koziarski, um dos membros da equipe nuclear, mantm um portal de prticas para a
criao de aplicaes com o Ruby on Rails, o TheRailsWay.Com75, que serve para a divulgao de
mtodos de refatorao, reuso e outras tcnicas. comum observar perto de uma centena de
comentrios em cada um dos artigos publicados no TheRailsWay.Com.
David Heinemeier Hansson, em conjunto com Sam Ruby e Dave Thomas, escreveu o livro Agile
Web Development with Rails. Este livro, artigos e documentos espalhados pela comunidade de
RoR mostram um forte compromisso dos usurios e desenvolvedores do projeto com metodologias
geis.
Da mesma forma que o Linux, o RoR utiliza o Git como o repositrio de cdigo e controle de

69 Em12/05/2009, http://www.postgresql.org/community/contributors/
70 http://wiki.postgresql.org/wiki/Development_information
71 http://pgfoundry.org/
72 http://gforge.org/
73 http://www.nongnu.org/cvs/
74 http://rubyonrails.org
75 http://www.therailsway.com

Pgina 82 de 117
verses. O sistema para o registro e controle de problemas o LightHouse76. As listas de discusses,
para o pblico em geral, a equipe nuclear, os anncios de segurana e outras, so mantidas no
Google Groups. H ainda um wiki77 para a produo colaborativa de documentos por parte da
comunidade, um agregador de blogs78 e uma coletnea de publicaes pequenas79 (twits).

Drupal
Como muitos projetos de software livre, o Drupal80 surgiu para resolver um problema especfico de
um grupo pequeno de pessoas, no caso estudantes da Universidade de Anturpia, na Blgica. No
ano 2000, conexes de alta velocidade Internet ainda eram um luxo, mas Hans Snijder possua
uma conexo ADSL em seu alojamento na universidade. Ele e seu colega Dries Buytaert decidiram
ampliar este acesso para mais oito colegas, o que fizeram com facilidade. A questo que ainda
faltava uma simples ferramenta para que os estudantes compartilhassem informaes entre si. Dries
resolveu este problema criando um pequeno quadro de avisos, baseado na web, onde o grupo
poderia colocar informaes sobre materiais de aula, o estado da rede ou simplesmente onde iriam
jantar.
O software apenas recebeu um nome quando Dries concluiu sua graduao e ele e seus colegas
decidiram abrir o quadro de avisos para o mundo externo a fim de que, mesmo deixando a
Universidade, todos pudessem manter contato. Assim, nasceu o drop.org que deveria chamar-se
dorp.org, em funo do nome dado em holands nacionalidade de Dries para um pequeno
vilarejo. Um erro de digitao fez com que dorp virasse drop. Em janeiro de 2001 Dries decidiu dar
o nome de Drupal para o software que era a base do quadro de anncios e lan-lo sob uma licena
livre, de forma a que outros o conhecessem e viessem a contribuir com ele. Logo o Drupal tornou-
se um popular gestor de contedo web, com uma grande comunidade de colaboradores e uma srie
de conferncias e seminrios organizados em todo o mundo.
A forma como o Drupal foi concebido, desde o seu princpio, buscando aplicar os conceitos de
padres de projeto81 (Design Patterns), permitiu que o mesmo fosse facilmente estendido atravs de
uma infinidade de mdulos desenvolvidos e mantidos pela comunidade externa ao ncleo principal
atravs de uma API bem documentada (Drupal API). Dentre os padres explicitamente utilizados no
Drupal esto os seguintes: Singleton, Decorator, Observer, Bridge, Chain of Responsibility e
Command (GAMMA et. al. 1995). A ltima verso estvel do Drupal (6.10) conta com mais de
2.300 mdulos desenvolvidos pela comunidade, alm de mais de 260 temas. Os mdulos ampliam a
funcionalidade para a gesto de contedo web, ferramentas de comunicao e mesmo aplicaes
bastante complexas como sistemas de gesto de contatos e controle de chamados tcnicos. Os temas
permitem que um portal desenvolvido com o Drupal tenha muitas aparncias diferentes para o seu
usurio final.
A base de comunicao da comunidade do Drupal o prprio Drupal, com seus fruns de
discusses, sistema de registro de problemas e boletins de notcias. Para o controle de verses e
repositrio de cdigo fonte, o Drupal utiliza o CVS, mas um repositrio Git foi tambm
disponibilizado em janeiro de 2009. Ainda que seja difcil estimar o total de contribuidores para o
Drupal, em maio de 2009 o nmero de indivduos que escreveram alguma coisa no Drupal
Handbook, a base de documentao do projeto, era de 1258.
Qualquer nova funcionalidade ou cdigo includo no ncleo do Drupal deve passar pela aprovao

76 https://rails.lighthouseapp.com
77 http://wiki.rubyonrails.org/
78 http://planetrubyonrails.com/
79 http://search.twitter.com/search?q=rails
80 http://drupal.org
81 http://api.drupal.org/api/file/developer/topics/oop.html/6

Pgina 83 de 117
daqueles com acesso manuteno do cdigo fonte (core commiters). Hoje, uma pessoa
responsvel por isso: Dries Buytaert. Ainda assim, Dries conta com o apoio dos mantenedores dos
ramos estveis e de desenvolvimento da verso atual, duas imediatamente anteriores e a verso
futura. H ainda 23 mantenedores82 responsveis por mdulos que so considerados parte integral
do ncleo do Drupal e que esto junto ao pacote do sistema distribudo para a instalao. Todos
estes mantenedores devem ser indicados por Dries, ou aprovados por ele aps a manifestao
individual do interessado ou recomendao de outros.

OpenOffice.Org
O OpenOffice.Org surgiu a partir do StarOffice, um produto proprietrio da empresa alem Star
Division que foi comprada pela Sun Microsystems em 1999. Assim, o StarOffice passou a ser um
produto da Sun e aps ter o cdigo, pertencente a outras empresas, removido, foi lanado com o
nome de Open Office e em cdigo aberto. Mas como Open Office era a marca registrada de outra
empresa, o mesmo foi renomeado para OpenOffice.Org (CONLON, op. cit.).
O OpenOffice.Org atraiu um grande nmero de usurios por ser a primeira sute de produtividade
interopervel com arquivos escritos no Microsoft Office e de cdigo aberto.
Para contribuir com o projeto, os interessados devem concordar que seu cdigo seja de propriedade
compartilhada com a Sun, tendo que preencher um documento de aceitao (Sun's Joint Copyright
Assignment). Alm de desenvolver cdigo fonte, a comunidade incentivada a participar das listas
e fruns de discusses sobre qualidade, marketing, ajuda a usurios, interface, entre outros. As
principais fontes de documentao para os desenvolvedores esto reunidas em um wiki83 e
recomenda-se, para garantir a interoperabilidade entre linguagens de programao, modelos de
objeto e arquiteturas de hardware, a utilizao do UNO (Universal Network Objects) que o
modelo de interface baseada em componentes para o OpenOffice.Org. O wiki apresenta um captulo
sobre o uso de Design Patterns (Singleton, Factory, Listener, Element access, Properties, UCB
comments e Dispatch comments) e estilos de codificao para o projeto.
Organizado na forma de um comit, o projeto OpenOffice.Org similar ao Apache, onde existem
membros, contribuidores, desenvolvedores e lderes do projeto, tendo a Sun como mantenedora.
Alm disso, a CollabNet hospeda e colabora com a gesto do projeto.
Para o registro e controle de bugs utilizada uma verso modificada do Bugzilla, chamada
IssueTracker. O CVS utilizado para o controle de verses e repositrio de cdigo.

A Engenharia de Software e o Software Livre

De acordo com FIORINI (1998):
A Engenharia de Software visa sistematizar a produo, a manuteno, a evoluo e a recuperao de produtos
intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso controlado e
utilizando princpios, mtodos, tecnologia e processos em contnuo aprimoramento. Os produtos desenvolvidos
e mantidos, seguindo um processo efetivo e segundo preceitos da Engenharia de Software asseguram, por
construo, qualidade satisfatria, apoiando adequadamente os seus usurios na realizao de suas tarefas,
operam satisfatria e economicamente em ambientes reais e podem evoluir continuamente, adaptando-se a um
mundo em constante evoluo.

Para entender melhor quais prticas de Engenharia de Software esto evidenciadas no

desenvolvimento de SL, a Figura 3 resume a cadeia de valor formada pelas comunidades, prticas
executadas e ferramental de apoio que resultam em projetos de SL.

82 http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt em maio de 2009

83 http://wiki.services.openoffice.org

Pgina 84 de 117
De maneira geral, observa-se que as comunidades de desenvolvimento de SL, por mais que
funcionem de maneira independente umas das outras, utilizam um conjunto de ferramentas que
instrumentalizam as prticas que aplicam.
Tomando por base o documento eletrnico (ebook) Gesto de Projetos de Software Livre:
Uma Abordagem de Prticas, publicado pela organizao Via Digital, e REIS (2001), a seguir so
listadas algumas prticas de Engenharia de Software relacionando-as com as prticas utilizadas
pelas comunidades anteriormente citadas.

Especificao de Requisitos
No foram encontradas evidncias de especificaes de requisitos desenvolvidas anteriormente ao
incio de cada projeto. Acredita-se que isto deva-se ao fato de que grande parte dos projetos surge
de motivaes pessoais (os requisitos esto na cabea do desenvolvedor original), o novo software
replica funcionalidades de algum produto existente (a anlise de requisitos j existiu para este
produto existente) e a natureza do SL evolutiva (a interao e contribuies da comunidade far
com que novas necessidades possam ser atendidas na medida em que se manifestem).

Gerncia de Configurao
A gerncia de configurao permite que os desenvolvedores trabalhem de forma paralela e eficiente
em um mesmo projeto. Para isto as comunidades utilizam repositrios de software com sistemas de
controle de verso que permitem que os vrios desenvolvedores submetam seu cdigo de forma
compartilhada e controlada, permitindo retornos verses anteriores em caso de problemas. Estas
ferramentas permitem a manuteno simultnea de ramos de produo (estveis), de teste e
desenvolvimento de um mesmo software.
Observou-se que todas as comunidades possuem prticas de gerncia de configurao, ainda que
nem todas utilizem as mesmas ferramentas em seus projetos. A Tabela 1 sumariza as ferramentas
para a gesto de configurao de cada um dos projetos aqui mencionados.

Figura 3 - Corrente de valor para produo de projetos de SL (VIA DIGITAL)

Projeto Ferramenta
Kernel Linux Git
Apache Subversion
Python Subversion
PostgreSQL CVS
Ruby on Rails Git

Pgina 85 de 117
Drupal CVS e Git
OpenOffice CVS

Tabela 1 Ferramentas de Gerncia de Configurao

Coordenao
Tipicamente, no incio de projetos de SL no existem procedimentos definidos de coordenao. Eles
surgem e evoluem organicamente na medida em que mais desenvolvedores agregam-se aos
projetos. Como observado nas comunidades de desenvolvimento, um projeto pode surgir a partir da
iniciativa de um nico desenvolvedor (como ocorreu com Linux, Python, Ruby on Rails e Drupal),
a partir de um grupo tentando solucionar um problema comum (Apache) ou atravs de uma
iniciativa empresarial ou acadmica de abrir o cdigo de um determinado produto para o
desenvolvimento comunitrio (OpenOffice.Org, PostgreSQL).
Os projetos que surgem atravs da iniciativa individual possuem, normalmente, uma coordenao
centralizada, fortemente focada na figura de uma pessoa que define os rumos do projeto e o juiz
final em eventuais conflitos. Linux, Python, Ruby on Rails e Drupal apresentam este tipo de
gerncia.
Os projetos que surgem atravs de um grupo ou a partir de empresas tendem a se organizar atravs
de comits. Estes so formados por desenvolvedores eleitos internamente na comunidade ou pelos
membros fundadores do projeto. Os projetos que apresentam este tipo de coordenao so Apache,
PostgreSQL e OpenOffice.
Nota-se, porm, independentemente da forma de organizao de cada comunidade, a prevalncia
das listas ou fruns de discusses na coordenao e distribuio das tarefas de desenvolvimento.
A Tabela 2 resume as ferramentas usadas na coordenao de cada projeto.
Projeto Ferramenta
Listas de discusses
Kernel Linux CVS
Patchwork
Listas de discusses
Apache Subversion
Bugzilla
Listas de discusses
Python Subversion
RoundUp
Listas de discusses
PostgreSQL CVS
Fluxo de submisso de erros (formulrio, lista e wiki)
Listas de discusses
Ruby on Rails Git
LightHouse
Drupal Drupal (mdulos Frum e Project)
OpenOffice Listas de discusses
CVS

Pgina 86 de 117
 IssueTracker

Tabela 2 Ferramentas de Coordenao

Gerncia de Evoluo e Manuteno

Na medida que os projetos de SL evoluem, natural que sejam encontrados problemas (bugs) que
necessitam ser priorizados e resolvidos de acordo com seu grau de severidade. Todas as
comunidades observadas utilizam algum mtodo de gerncia de evoluo. Esta gerncia ocorre da
seguinte forma: qualquer usurio ou desenvolvedor, ao detectar algum problema, faz o registro do
mesmo em ambiente disponibilizado pelo projeto, j atribuindo a sua percepo de severidade do
problema (alta/mdia/baixa). Em seguida, o grupo ou desenvolvedor, responsvel pela parte do
projeto onde o problema foi detectado, captura diretamente este registro ou recebe sua notificao
atravs de algum intermedirio, prioriza e agenda sua soluo.
Algumas comunidades utilizam o prprio sistema de registro de problemas tambm para o registro
de solicitaes de novas funcionalidades e sugestes de melhorias. Observam-se, porm, estilos
diferentes na forma de tratamento destas solicitaes. No PostgreSQL, por exemplo, h uma matriz
de funcionalidades a ser implementada a cada verso e um processo de submisso de melhorias que
devem ser avaliadas por desenvolvedores mais experientes e aprovadas pela equipe nuclear. J no
Drupal as ideias para as novas funcionalidades podem surgir a partir dos fruns e solicitaes
formais (feature requests - enviadas a partir do mesmo sistema de submisso de erros), mas as
mesmas s faro parte de uma prxima verso do sistema se isto for da vontade do lder do projeto.
A Tabela 3 resume as ferramentas utilizadas pelos projetos em sua gerncia de evoluo e
manuteno.

Projeto Ferramenta
Bugzilla
Kernel Linux
Listas de discusses
Bugzilla
Apache
Listas de discusses
RoundUp
Python
Listas de discusses
Formulrio prprio
PostgreSQL Lista de discusses
Lista de tarefas (wiki)
LightHouse
Ruby on Rails
Listas de discusses
Drupal Drupal (mdulo Project)
IssueTracker (baseado no Bugzilla)
OpenOffice
Listas de discusses

Tabela 3 Ferramentas de Gerncia de Evoluo e Manuteno

Reuso e Componentizao
A filosofia do Unix que defende a criao de ferramentas pequenas e autocontidas que podem ser

Pgina 87 de 117
ligadas umas s outras para solucionar problemas mais complexos permeou integralmente o
desenvolvimento do Linux e, em um grau maior ou menor, todos os projetos aqui citados. Isto est
fortemente ligado s tcnicas de reuso e componentizao.
O reuso manifesta-se pelo hbito da comunidade em, antes de desenvolver qualquer coisa, verificar
se esta j no existe.
A componentizao est clara nas bibliotecas compartilhadas e disponibilizadas entre os vrios
projetos de SL. Apenas para ficar em um exemplo, a biblioteca Curl, utilizada para a transferncia
de arquivos via FTP, HTTP e outros protocolos, utilizada pelas linguagens PHP (com a qual o
Drupal foi desenvolvido), Python e Ruby, dentre outras. Ou seja, estas linguagens valem-se de um
componente externo para implementar uma funcionalidade que nativamente no possuem, ao invs
de desenvolv-lo.

Teste e Garantia da Qualidade

Por ser desenvolvido de forma distribuda e colaborativa, o SL utiliza mecanismos de garantia de
qualidade como: o uso de linguagens de alto nvel (que segundo Brooks um dos principais fatores
para a melhoria da qualidade e produtividade no desenvolvimento de software); o uso de controle
de verses (que permite um controle do desenvolvimento distribudo e o fcil retorno a uma verso
funcional em caso da submisso de um cdigo com erro) e a exposio do cdigo a um imenso
nmero de pessoas (de acordo com Raymond, dados olhos suficientes, os problemas so
evidentes).
Alm disto, prticas de liberao de verses de testes (alpha e beta) antes da publicao da verso
final (release) tambm so comuns todos os projetos observados.

Refatorao
Como observado anteriormente, o cdigo fonte de qualquer projeto em SL est disponvel ao olhar
de todos. A primeira forma como algo escrito certamente no ser a ltima na composio de um
projeto e existe uma boa chance que sequer seja do mesmo autor. Ou seja, o software
naturalmente refatorado pelo simples processo de interao entre os desenvolvedores e o cdigo.
Alm disto, os desenvolvedores, por saberem da exposio de seu cdigo, preocupam-se com a
elegncia do mesmo. Isto evidente nos princpios que ilustram a cultura e o estilo de
desenvolvimento do Python, nas prticas recomendadas para a criao de aplicaes com o Ruby
(que explicitamente mencionam tcnicas de reuso e refatorao) e nos fruns do Drupal onde
comum ver um desenvolvedor refatorar o cdigo de outro em uma simples troca de mensagens.

Prticas de desenvolvimento gil

Ainda que no seja possvel inferir no desenvolvimento de cada projeto qual a totalidade das
prticas utilizadas pelos desenvolvedores, observa-se um forte envolvimento dos mesmos com
prticas de desenvolvimento gil (em parte j evidenciado nas Sees sobre Refatorao e Reuso).
O criador e lder do projeto Ruby on Rails autor de um livro sobre desenvolvimento gil com o
framework e os blogs da equipe do projeto tambm mostram seu envolvimento com o uso e
disseminao com prticas geis.
O Drupal possui mdulos especficos para o desenvolvimento baseado em testes (Test Driven
Development) e automao dos mesmos.
O Python considerado por muitos uma linguagem de programao gil (YOUNKER, 2008).

Pgina 88 de 117
Alm disto, algumas fases e prticas do Extreme Programming, por exemplo, podem ser aplicadas
diretamente s comunidades de SL:
o conhecimento no deve ser concentrado nas mos de poucas pessoas, que devem ser
trocadas de tempos em tempos. A observao dos mantenedores dos vrios projetos que
existe uma rotatividade e a prpria abertura do cdigo evita a concentrao da informao;
a simplicidade uma palavra de ordem. As estruturas devem ser mantidas simples. Isto
evidencia-se na filosofia do Unix, na cultura de desenvolvimento do Python e de outros
projetos;
o cliente est sempre disponvel. Nada pode ser mais verdadeiro do que para um projeto de
SL, cujos clientes esto, na maior parte das vezes, online utilizando e testando cada nova
verso dos programas dos projetos;
a propriedade coletiva do cdigo. As licenas de SL, na prtica, tornam naturalmente o
cdigo de propriedade coletiva.

Padres de Projeto (Design Patterns)

Dos projetos observados, o Drupal e o OpenOffice.Org evidenciam a utilizao de Design Patterns
em seu desenvolvimento. Isto era esperado pois estes projetos constituem-se em aplicaes. Os
desenvolvedores podem optar por utilizar Python ou Ruby on Rails para desenvolver aplicaes
utilizando Design Patterns ou no. No foi possvel identificar se Design Patterns foram utilizados
no desenvolvimento do Linux e do Apache.

Concluso
Foi possvel notar nos vrios projetos em Software Livre aqui observados que, independentemente
da forma como se iniciaram, todos eles evoluram para a adoo de prticas de Engenharia de
Software. Estas prticas evidenciaram-se em diferentes graus para cada um dos projetos. Em alguns
casos, referncias explcitas a estas prticas esto disponveis nas reas destinadas a
desenvolvedores nos portais dos projetos, como nos casos especficos do Drupal, OpenOffice.Org,
Ruby On Rails e Python. Nos demais casos, mesmo no estando to explcitas, so possveis de
serem encontradas em fruns e listas de discusses.

Pgina 89 de 117
O Grande Contrato
Trabalho com vrias formas de integrao de sistemas e desenvolvimento de solues desde o final
dos anos 80, sempre usando novas tecnologias. Isto continua acontecendo na BrodTec. Fui
apresentado ao livro "O Mtico Homem-Ms", do Fred Brooks Jr. em 1988 e ele foi fundamental na
formao do meu pensamento sobre a forma atravs da qual projetos deviam ser desenvolvidos.
Quase dez anos depois comecei a estudar Extreme Programming, que usei junto com a UML
(Unified Modeling Language) na gesto de desenvolvimento do projeto Gnuteca a partir de 2000,
assim como em outros projetos que vieram depois. Mais adiante, o Scrum passou a fazer parte no
s da vida da nossa empresa como da minha forma de pensar.
O mais novo livro do Fred, "O Projeto do Projeto da modelagem implantao", em seu captulo
quatro, trata da questo do estabelecimento de contratos entre fornecedores e clientes. J na abertura
do captulo, Fred cita um texto de Pahl e Beitz:
Qualquer tentativa de formular todos os requisitos possveis no incio de um projeto ir falhar e causar atrasos
considerveis.

Mais adiante, o prprio Fred conclui:

A presso por um conjunto de requisitos completo e acordado provm, em ltima instncia, do desejo - com
frequncia uma demanda institucional - por um contrato de preo fixo para uma entrega especfica. Ainda
assim, esta demanda est baseada frontalmente na evidncia concreta (?) de que essencialmente impossvel
especificar um conjunto completo e preciso de requisitos para qualquer sistema complexo, a no ser atravs da
interao iterativa com o processo de modelagem.

Parece-me que todos aqueles que desenvolvem alguma experincia com gesto de projetos acabam
chegando a concluses parecidas. Jeff Sutherland, em sua apresentao As Razes do Scrum84
comenta que importante levar em conta que as metas de um projeto so alcanadas a partir de um
"espao de navegao" dinmico, onde uma srie de coisas - como mudanas de tecnologia e
requisitos - iro causar, inevitavelmente, desvios no rumo desta navegao, que devem ser
constantemente considerados.
Eu defendo sempre o desenvolvimento de prottipos prematuros, mesmo que no totalmente
funcionais, que permitam ao cliente experimentar seus prprios requisitos e seu atendimento. Desta
forma, junto com a equipe de desenvolvimento, ele capaz de avaliar, refinar o que est sendo
desenvolvido, descobrir o que realmente deseja e, em especial, quais destes desejos realmente traro
as funcionalidades e vantagens realmente importantes para o sistema, todas alinhando-se cada vez
mais a seu negcio, dentro do espao de navegao que est sendo explorado. Prottipos de papel
que simulam a interface de um sistema so muito eficazes.
Vou alm. Piamente acredito que contratos de desenvolvimento so absolutamente inteis e apenas
amarram o cliente a definies que ele fez sem o total conhecimento do que ele realmente desejava.
Infelizmente, hoje, os contratos mais penalizam o cliente do que o auxiliam. Eles do a desculpa aos
fornecedores de entregar, protegidos por um contrato, exatamente aquilo que o cliente no
conseguir utilizar na forma em que foi entregue.
Este um problema cuja soluo no fcil e, ainda que exista, ela no pode, simplesmente, ser
replicada em todas as situaes em que ocorre. Idealmente, deve existir uma relao de confiana
absoluta entre cliente e fornecedor, de forma que o cliente no tenha receios em mudar seus
requisitos ao descobrir novas necessidades na medida em que o sistema desenvolvido e que o
fornecedor no fique em desvantagem ao ter que modificar o que est desenvolvendo - muitas vezes
sendo obrigado a jogar fora parte de seu cdigo e considerar novas alternativas.
84 http://www.brod.com.br/ra-zes-do-scrum

Pgina 90 de 117
H uma cultura muito forte, baseada na compra e venda de produtos finalizados. Infelizmente, tais
produtos, especialmente tratando-se de software, existem cada vez em menor quantidade.
Ser que uma empresa que adquiriu uma soluo de gesto de relacionamento com seus clientes, h
trs anos, imaginou que estes clientes passariam a utilizar o twitter como a sua forma preferencial
de elogiar ou reclamar dos produtos da empresa? Mais do que isto, eles esperam que a empresa
manifeste-se tambm atravs do twitter. Mas possvel (ou mesmo vantajosa) a integrao do
sistema atual de relacionamento, de alguma forma automtica ou semiautomtica, com o twitter? A
h uma srie de outras questes e crticas relativas a graus de automao e integrao entre
sistemas. Eliminando humanos de certos processos, coisas importantes passaro desapercebidas.
Isto d muito pano pra manga, mas s pra citar uma coisinha, eu sou totalmente contra a gerao
automtica de boletins a partir de material que colocado em sistemas de gesto de contedo. Por
outro lado, acho legal avisar aos seguidores da empresa, no twitter, sobre a publicao de um
contedo novo em sua pgina - desde que se tenha o pleno conhecimento de que estamos tratando
de formas diversas de comunicao.
Mas divaguei. A oferta de uma soluo que atenda a um cliente deve passar por uma fase de
aquisio de conhecimento de seu negcio. No total, claro. O cliente sempre dominar seu negcio
e qualquer ferramenta tecnolgica que entregarmos a ele deve auxili-lo a dominar ainda mais. Ter
a pretenso de que entenderemos totalmente o negcio do cliente a mesma coisa que imaginar que
o cliente vir a dominar a linguagem de programao, frameworks e mtodos que usaremos para
desenvolver uma soluo. De novo, devemos navegar, em conjunto com o cliente, no espao do
projeto, da modelagem e criao de seus sistemas.
Uma forma de se comear a migrar dos grandes contratos para uma soluo de plena confiana
mtua , talvez, usar o passo intermedirio de minicontratos. Identifica-se, junto com o cliente, uma
rea especfica de seu negcio para a qual possa ser desenvolvida (ou melhorada) alguma soluo,
com segurana e compromisso de ambas as partes e um limite de tempo (e consequente limite de
funcionalidades) bastante grande. O limite mgico de tempo, a meu ver, de trs meses. Ainda h
muitas empresas que esto comeando a explorar melhor seus portais de contedo, sistemas de
relacionamento com clientes e muitos outros para os quais h uma infinidade de sistemas
plenamente customizveis, modulares, que daro o espao necessrio para uma compreenso
melhor de outras necessidades do cliente. Ao final deste perodo, sempre em conjunto com o cliente,
explora-se novas oportunidades. No decorrer do tempo, a navegao pelo espao de projetos e
solues torna-se um processo contnuo e de confiana, onde o fornecedor tem a tranquilidade de
sua remunerao e o cliente reconhece que esta remunerao justa e traz benefcios a seu negcio.
Tal confiana suplantar, ento, a necessidade de um contrato.

Pgina 91 de 117
Scrum
Caso voc no tenha pulado diretamente para este captulo, deve ter percebido a construo, a
evoluo orgnica de uma metodologia de gesto e desenvolvimento que est embutida em cada um
dos projetos aqui descritos. Minha inteno com os dois ltimos captulos, quando falei sobre
Engenharia de Software para Software Livre e sobre a evoluo de um modelo de contrato entre
fornecedor e cliente foi a de criar o ambiente para falar mais sobre o Scrum. Esta metodologia,
forma e atitude de trabalho a da qual mais tiramos elementos para o desenvolvimento de nossos
projetos, sem esquecer o aprendizado anterior com Extreme Programming, UML e todos os
ensinamentos do Fred Brooks Jr. e das vrias pessoas que fizeram parte da vida da nossa empresa (e
da nossa vida) at agora.
Os textos abaixo so adaptados e estendidos a partir de seus originais publicados para o portal
Dicas-L85.

A ordem nascida do Caos

Depois da excelente apresentao do Alexandre Marcondes no encontro do grupo SOLIVRE-PR em
Ivaipor, 2006, parei para pensar h quanto tempo eu j estava envolvido com gesto de projetos e o
quanto pude aprender com a experincia alheia. J cheguei a fazer apresentaes sobre o que
chamei de "evoluo de uma metodologia orgnica de desenvolvimento", contando especialmente a
histria que levou ao desenvolvimento de vrios dos sistemas da Solis. Posso dizer que,
especialmente a partir de 1993 (mesmo ano em que conheci o Linux) fui me envolvendo de maneira
crescente com a gesto de equipes e projetos. Como vim da rea de suporte de hardware e as
primeiras equipes que gerenciei trabalhavam com o suporte a clientes, eu estava acostumado com o
imprevisvel quando, gradualmente, fui migrando para a gesto de ambientes e desenvolvimento de
software.
Talvez por ser virginiano (at demais, como alguns dizem), sempre me interessei por metodologias
de trabalho que levassem a uma maior satisfao e produtividade, com liberdade de ao e
valorizao de talentos. Programao , antes de tudo, uma arte. Mas antes disto, todo o trabalho
bem feito uma obra de arte. Assim, devemos conciliar nosso compromisso de "entregas" para
nossos clientes com alguma forma de darmos a devida "liberdade criativa" aos que esto
produzindo.
Com uma frequncia maior do que eu gostaria, ouo pessoas dizerem que, muitas vezes, no existe
a "maturidade" suficiente para que se permita um trabalho sem um absoluto controle, que as pessoas
no podem trabalhar "soltas". Eu aprendi que, devidamente motivada, a pessoa trabalha dentro dos
horrios aos quais se impe e entrega seus projetos dentro dos prazos (mesmo que, por vezes, tenha
que renegoci-los) com a alegria de que fez algo porque quis e no porque foi obrigada a faz-lo.
Clientes, gestores e equipes envolvidos em um projeto devem concordar em uma viso, um plano
de ao e serem todos cmplices de sua execuo. A transparncia deve existir do incio ao fim do
projeto, da sua negociao comercial sua entrega e aceitao. A motivao para a realizao do
trabalho se constri atravs da viso da produo de um bem comum, que servir a todos os
envolvidos no s como um produto final, mas como uma oportunidade de aprendizagem e
interao com outras pessoas. Cada um que trabalha no projeto deve sentir-se automotivado pela
vontade de aprender, crescer, ser remunerado de acordo e fazer parte de um ambiente que valoriza
seu potencial e respeita sua liberdade.

85 http://www.dicas-l.com.br/brod

Pgina 92 de 117
Meu livro de cabeceira sobre engenharia de software ainda O Mtico Homem-Ms, escrito
originalmente em 1975 por Fred Brooks, Jr. Ele acaba passando pouco tempo na minha cabeceira
pois sempre o empresto quando h a necessidade ou quando eu sinto que o livro pode ajudar. Este
livro influenciou tanta gente que uma busca no Google sobre o tema j praticamente permita que
voc absorva as ideias do autor sem necessariamente ler o livro. Se o ingls no uma lngua
familiar para voc, tente os resultados em portugus. Mas se a falta do conhecimento da lngua
inglesa realmente o seu caso, voc deveria se preocupar. A falta de conhecimento da lngua inglesa
um dos principais pontos de bloqueio no avano em uma carreira na rea de informtica.
Mas voltando ao livro, Fred observa que, quando um projeto est atrasado, adicionar pessoas ao
projeto servir apenas para atras-lo ainda mais. Ele tambm diz que devemos considerar o tempo
que perdemos em gesto e comunicao quando temos pessoas demais trabalhando em um projeto e
que ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobr-lo, pois muito
fcil esquecermos que o programador precisa de "tempo para pensar" alm do "tempo para
programar".
A forma simples e objetiva com a qual Fred via as coisas j em 1975 caem como uma luva para as,
hoje, chamadas metodologias geis de desenvolvimento. As metodologias geis destacam-se por
reconhecer que mudanas acontecem no decorrer do desenvolvimento de um projeto e que o cliente
deve estar envolvido e presente durante sua execuo. Esta presena necessria porque a interao
entre as pessoas ser constante e o produto final deve ser amigvel a ponto de, praticamente,
prescindir de documentao.
A metodologia Scrum complementa as prticas de Extreme Programming e, a meu ver, acaba
servindo tanto como uma evoluo para aqueles que j usam Extreme Programming como um
excelente ponto de partida para a aplicao destas prticas.
No jogo de rugby, o "scrum" a forma de reiniciar o jogo aps uma falta acidental ou outro
incidente onde no possvel determinar quem cometeu a falta. No basquete acontece de forma
similar quando o juiz no consegue determinar para qual time deve ir a bola e a joga para cima
frente de um jogador de cada time. S que, no rugby, todos os jogadores se posicionam em um bolo
humano para competir pela bola no reincio de jogo. No to simples como eu descrevi, h regras
quanto forma como a bola deve ser retomada, mas j d pra ter uma ideia. O termo foi associado
ao desenvolvimento pela primeira vez no artigp The New New Product Development Game, de
Hirotaka Takeuchi e Ikujiro Nonaka. Neste artigo, os autores dizem que deve ser adotada uma
forma de desenvolvimento onde toda a equipe trabalha como uma unidade para atingir um objetivo
comum. Exatamente como feito quando se tem que recuperar a bola em um "scrum" no jogo de
rugby.

Previously on Lost
Tirando quem acaba de voltar de uma longa viagem fora do sistema solar, todos os demais j
assistiram ou ao menos ouviram falar do seriado Lost: a histria dos sobreviventes de um desastre
areo que acabam em uma ilha no exatamente deserta. Nela, sempre que parece que a ordem
estabelecida, alguma surpresa acontece. O personagem John Locke - que casualmente, ou no, tem
nome de filsofo - o ScrumMaster da ilha. Ainda na primeira temporada, com o ataque surpresa
de javalis, o homem teve a ideia de caar e carnear os bichos. No seriado isto no explcito, mas
evidente que Locke gacho!
Quem j trabalhou em qualquer projeto em que a especificao resultou em algo que era exatamente
o que o cliente queria, parabns! Na maioria dos casos isto no acontece. No por culpa do cliente,
mas porque os projetos so desenvolvidos ao longo de um tempo onde as necessidades podem
mudar e a prpria interao entre a equipe de desenvolvimento e o cliente pode mostrar que existem

Pgina 93 de 117
solues melhores do que as que foram pensadas inicialmente - e um erro ater-se a especificaes
iniciais quando uma possibilidade melhor, mais simples ou mais econmica de atender o problema
aparece. As metodologias geis levam isto em conta. Tudo muda a todo o tempo! o caos! Como
colocar ordem neste caos? No princpio era o caos, diz a bblia, mas em seis dias o criador deu um
jeito e ainda descansou no stimo. Deus tambm ScrumMaster certificado.
J falamos sobre o artigo The New New Product Development Game, de Hirotaka Takeuchi e Ikujiro
Nonaka. Outros nomes esto envolvidos na conceituao e desenvolvimento da metodologia, dentre
eles Peter DeGrace e Leslie Hulet Stahl, autores de Wicked Problems, Righteous Solutions: A
Catalog of Modern Engineering Paradigms (onde o termo Scrum foi especificamente associado a
software). Jeff Sutherland, Ken Schwaber e Mike Beedle so outros nomes pelos quais voc pode
procurar no Google se quiser aprofundar seu conhecimento no assunto.
O Scrum um mtodo de trabalho para equipes pequenas e tempos curtos de desenvolvimento de
projeto. Voc trabalha com uma grande equipe e projetos que duram anos? Sem problemas, divida
as pessoas em equipes menores (entre cinco e dez pessoas) e seu projeto em subprojetos. O Scrum
trabalha com o conceito de "sprints", que o progresso do projeto no perodo de um ms (ou
menos). Os requerimentos dos projetos so trabalhados em uma lista de tarefas a serem cumpridas
(product backlog). As reunies com as pessoas da equipe so dirias e no devem durar mais do que
quinze minutos. Nelas so discutidas o acompanhamento das tarefas (sprint backlog) e,
preferencialmente, cada tarefa deve ser realizada dentro de um dia (se levar mais de um dia, deve
ser dividida em mais tarefas). Isto se faz para manter as coisas o mais simples possveis. Quando
aumenta a complexidade, aumentam as dvidas e o rudo na comunicao, o que atrasa o projeto e
arrisca os resultados finais. O coordenador geral do projeto o ScrumMaster, responsvel por
garantir a aplicao da metodologia e atuar como o representante do "cliente do projeto" quando ele
no est presente. A principal tarefa do ScrumMaster, porm, a de remover obstculos,
independente de sua natureza.
Uma equipe Scrum ter membros com especialidades variadas, de acordo com a necessidade do
projeto. Todos trabalham na equipe em tempo integral (talvez com a exceo do ScrumMaster, que
pode estar coordenando mais de uma equipe, ou membros que executem tarefas acessrias ao time
mas que devam estar comprometidas com o projeto). Os membros da equipe discutem entre si e se
auto gerenciam. No h nveis hierrquicos dentro de uma equipe. Durante cada sprint (o perodo de
um ms de projeto) os membros no sero trocados.
A principal razo de se dividir as entregas de um projeto em sprints mensais justamente a questo
de manter-se o controle sobre as surpresas. Dentro de um perodo de um ms, uma parte do sistema
ser projetada, codificada, testada e entregue ao cliente. Neste perodo no sero admitidas
mudanas de requisitos, pois isto ampliaria o tempo de desenvolvimento. Ao final do sprint, porm,
podem ser revistos os requisitos e uma nova lista de tarefas pode ser criada para a adequao do
produto dentro de um novo sprint. Isto tende a fazer com que os requisitos passem a ser cada vez
melhor definidos e a codificao para o atendimento dos mesmos cada vez mais refinada. As partes
acabam chegando em acordos de requisitos mnimos e imutveis, com os quais todos se
comprometem pelo perodo de um ms.
A lista de tarefas (product backlog) a lista de tudo o que necessrio no projeto (independente do
nmero de sprints que o ir compor). Ela deve contemplar o que no Extreme Programming
chamamos de User Stories (se no lembra disto, volte ao captulo sobre este assunto). Se no
Extreme Programming dissemos que as User Stories eram Use Cases "diet", na lista de tarefas elas
so ainda mais enxutas. Na medida do possvel, os itens da lista devem contemplar o que o cliente
(ou o usurio) deseja junto com as tarefas necessrias para atender estes desejos, de forma bastante
sinttica. As tarefas so priorizadas de acordo com o que o patrocinador (aquele que est "pagando"
pelo produto) deseja. Isso deve ser feito da forma mais simples possvel, permitindo a busca textual

Pgina 94 de 117
por tarefas, em um documento que possa ser acessado e alterado por todos os membros do projeto.
Desde um quadro branco at um wiki ou planilha no Gogle Docs servem para isto. O importante
que esta lista seja clara para voc e para os membros de sua equipe. A forma como ela
implementada no interessa.
Com o Product Backlog em mos, agora o mesmo ser subdividido em Sprint Backlogs. Como voc
j imaginou, o Sprint Backlog so listas de tarefas que ocorrero dentro de cada sprint, para uma
determinada equipe. Nada impede que voc subdivida as tarefas entre equipes distintas e tenha
sprints diversos ocorrendo simultaneamente. Com o Product Backlog devidamente priorizado,
busque subdividi-lo em temas que daro nome aos sprints. Imagine que voc est montando um
portal dinmico para a sua empresa. Uma das tarefas a disponibilizao de um servio de
acompanhamento de pedidos para os clientes da empresa. O sistema j existe mas os clientes s
podem acess-lo atravs do telefone. Este sprint pode se chamar "Acompanhamento de pedidos
atravs da web". Sua lista de tarefas incluir o design da interface para o cliente, a conexo com o
sistema ou a base de dados existente para o acompanhamento, testes, documentao e o que mais
for necessrio. Estas decises so tomadas na reunio de planejamento do sprint, com a presena da
equipe scrum, do ScrumMaster, o patrocinador do cliente, representantes dos usurios e gestores
envolvidos no processo. Em sua apresentao An Overview of Scrum86 a Mountain Goat Software
apresenta exemplos do Product Backlog, Sprint Backlog e d boas dicas sobre a reunio de
planejamento do sprint. Melhor ainda, a empresa permite que a apresentao seja usada e
modificada livremente por qualquer interessado, desde que seja mantida a referncia de autoria.

O que voc fez ontem?

Stephen Covey em seu livro O Oitavo Hbito diz (e muitos concordam com ele, inclusive eu) que a
melhor forma de aprender alguma coisa tentando ensin-la. Foi por esta razo que escrevi,
originalmente para o portal Dicas-L, esta srie de textos sobre Scrum. At comear a aprender sobre
o Scrum eu utilizava basicamente o e-mail para minha organizao diria. Era um mtodo que
funcionava bem para mim mas que, sou obrigado a reconhecer, pode no ser o ideal para todos.
Minha scia e colega de vrios projetos, a Joice Kfer, chegou a olhar para mim de um jeito "eu te
disse!" quando aprendemos que no Scrum os e-mails no substituem as reunies dirias de 15
minutos. Praticamente a partir do incio de nossa aprendizagem sobre esta metodologia j
comeamos a pratic-la, no sem fazer algumas adequaes.
Uma coisa que chamou-me a ateno no Scrum que h uma srie de prticas recomendadas para
reunies, mas no encontrei muita coisa sobre o que seria a reunio inicial, onde se define qual ser
o produto desejado ao final do projeto. A ficha comeou a cair quando assisti uma pequena
introduo ao Scrum disponvel no portal Scrum for Team System87. Nesta apresentao de Ken
Schwaber, autor do livro Agile Project Management with Scrum, ele diz que apesar do Scrum ser
muitas vezes chamado de "metodologia", na verdade ele no o considera como tal. Uma
metodologia deveria dizer "o que fazer". Comparado a um esporte ou a um jogo, o Scrum um
conjunto de regras para eles. Por isto, para a definio do projeto que deve levar ao "product
backlog" inicial, vale o que dizem outras metodologias que explicam melhor como fazer isto.
neste ponto, mais uma vez, que o Extreme Programming casa muito bem com o Scrum. Em
reunies com o cliente, construa as "user stories" e tudo o mais que for necessrio para definio do
projeto. Depois, com seu time, comece a dividir a execuo do projeto em sprints mensais.
A prtica e muitas leituras ensinaram-me que um projeto bem controlvel se ele dura at trs
meses. Caso dure mais do que trs meses, melhor divid-lo em mais projetos (ou em fases que

86 http://www.mountaingoatsoftware.com/scrum-a-presentation Procure pela traduo para o portugus, feita por

Cesar Brod
87 http://scrumforteamsystem.com/

Pgina 95 de 117
durem at trs meses). Como cada sprint dura um ms, ao final de cada trs sprints podemos
concluir cada projeto (ou suas fases). As ferramentas que o SCRUM recomenda, porm, no servem
s para controlar projetos bem definidos e delimitados, mas at tarefas constantes e dirias. Isto
deve tornar-se mais evidente quando mais adiante falarmos sobre as reunies dirias e
exemplificarmos algumas planilhas de controle e acompanhamento de projetos.
O SCRUM comea a ser aplicado no product backlog, que ir traduzir em uma planilha que define
as prioridades, a descrio breve e genrica de cada tarefa a ser executada, quem as executar e a
estimativa de tempos. O product backlog pode ser alimentado a partir das user stories do Extreme
Programming. Com isto em mos, parte-se para a primeira reunio de planejamento do sprint.
Cada sprint deve ter um "tema" que identifique as principais tarefas que nele sero executadas.
"Acompanhamento de pedidos atravs da web" foi o exemplo que utilizamos anteriormente. A
reunio de planejamento deve contar com a presena do patrocinador do produto, da equipe scrum,
dos gestores de projeto e do cliente ou usurios do produto que est sendo desenvolvido. Nesta
reunio sero discutidos e avaliados o que j est disponvel (se esta a primeira reunio, muito
pouco ou nada), quais as capacidades da equipe e o que cada pessoa estar fazendo, tecnologias
adotadas e quais os pontos do product backlog sero atendidos. O resultado da reunio ser o
objetivo do sprint (o que ser produzido) e o sprint backlog (a lista de tarefas especficas deste
sprint). Esta reunio pode ter um tempo de preparao, com o gestor de projeto (ScrumMaster)
fazendo perguntas aos integrantes, buscando saber de suas necessidades e habilidades.
A partir da, ocorrem reunies dirias, extremamente curtas (entre 15 minutos e meia-hora, sempre
buscando chegar mais perto dos 15 minutos), onde so feitas as seguintes perguntas para cada
membro do time:
1. O que voc fez ontem?
2. O que voc far hoje?
3. Quais os obstculos que impedem (ou podem impedir) seu trabalho?
Caber ao ScrumMaster (no se preocupe, ainda falaremos mais sobre o ScrumMaster) remover
estes obstculos. Esta reunio deve ser presencial e no pode ser substituda por uma lista de
discusses ou outra forma de encontro (ainda que eu no tenha encontrado nada sobre isto, creio
que na absoluta impossibilidade de um encontro real, algum mtodo de interao em tempo real -
videoconferncia, por exemplo - aceitvel). A idia de reunies dirias vem de nosso amigo Fred
Brooks Jr. Em seu livro O Mtico Homem-Ms ele diz que os projetos devem ser conduzidos "um
dia de cada vez". Atravs das reunies dirias, todos os membros da equipe tm acesso ao cenrio
completo do estado do desenvolvimento, ao ouvir seus pares responderem s trs perguntas acima
(isto fecha tambm com a ideia de equipes pequenas. Imagine uma reunio durar 15 minutos com
mais de cinco ou dez pessoas). Alm disto, a presena ajuda a criar a presso do compromisso de
cada um fazer o que se comprometeu a fazer para todo o sprint e todos os dias. Reunies dirias e
curtas acabam por tornar desnecessrias outras reunies.
Outro aspecto importante das reunies dirias que elas no so destinadas soluo de problemas.
Como no existe hierarquia entre os membros de um time scrum, cada pessoa deve procurar
resolver os problemas entre seus pares, acessando-os diretamente. Assim, se um desenvolvedor tem
alguma dvida sobre como implementar um determinado recurso, ele no precisa passar pelo
ScrumMaster ou qualquer outra pessoa: deve perguntar diretamente ao usurio, cliente ou ao
patrocinador do produto qual a interpretao deles de determinada tarefa ou funo.

Product Backlog
Desde que trabalhei em um projeto financiado pelo governo finlands, que buscava fortalecer a

Pgina 96 de 117
associao do uso de software livre gerao de emprego e renda, tive vontade de criar um portal
ibero-americano de colaborao na adoo, integrao de solues e desenvolvimento de softwares
livres e de cdigo aberto. A ideia, sobre a qual cheguei a conversar com vrias pessoas, buscaria o
financiamento de governos, instituies e empresas de vrios pases para manter um grupo pequeno
(entre cinco e dez pessoas) que trabalhasse tanto na pesquisa de necessidades quanto na articulao
de contatos que tornassem viveis projetos que pudessem ser teis vrias geografias. Em resumo,
se existisse um projeto na Argentina que pudesse atender a alguma necessidade especfica do
Mxico, Espanha e Brasil, seria criada uma rede entre os potenciais usurios e financiadores para
que o projeto se tornasse economicamente vivel e, mais do que isto, que pudesse gerar receita para
empresas envolvidas no seu suporte e desenvolvimento - com isto criando tambm novos postos de
emprego. A ideia no era to indita, mas buscava agregar boas prticas e vontades que
desenvolvemos no projeto sobre o qual falei inicialmente.
Enquanto pensava em como exemplificar as ferramentas de acompanhamento e controle de tarefas
do SCRUM conclu que o melhor era partir direto para a prtica e usar o "Portal Ibero-americano de
Colaborao e Desenvolvimento Tecnolgico" como base para este exerccio. Vamos ao projeto,
que foi escrito muito antes de eu pensar no uso do Scrum:
Descrio do Projeto
Este portal no pretende criar novamente o que j existe, mas, ao usar o mximo possvel
estruturas e sistemas existentes, quer que sua prpria implementao j sirva como uma
experincia de integrao entre projetos da comunidade. Assim, alguns elementos clssicos e
de sucesso entre a comunidade de software livre sero devidamente reconhecidos,
valorizados e agregados a este projeto.
Para o repositrio de software, ser usada a estrutura j implementada no CodigoLivre, o
maior repositrio latino-americano de software livre. Inicialmente, um espelho integral do
portal CodigoLivre ser montado na estrutura do Portal bero-Americano, com treinamento
equipe que estar envolvida nesse projeto.
Implementada a estrutura do CodigoLivre, trabalharemos na criao de uma nova interface
para o seu acesso, agregando ao prprio CodigoLivre funcionalidades que sero de interesse
do portal ibero-americano (para o qual ainda devemos criar um nome atrativo e
significativo). Esta interface deve permitir uma srie de funcionalidades:
1. Registro e hospedagem de projetos: ser utilizada a infraestrutura do CodigoLivre,
expandindo-a para a seleo da linguagem em que o registro do projeto ser feito
(inicialmente portugus e espanhol) e facilitando a hospedagem de projetos com um
"template bsico" para a criao de um stio web para o projeto, fruns de discusso e outros
itens que podem ser agregados posteriormente medida em que o desenvolvedor se torna
mais experiente com a ferramenta.

Nota: Aqui imagino um "auto-piloto", disponibilizando uma pgina bsica e uma seleo
guiada da incluso de ferramentas ou no, explicando uma a uma. O projeto Losango pode
servir como base ou referncia para isto.

Exemplo: Deseja criar listas de discusso para o seu projeto? Recomendamos, caso seja
usado este recurso, que se criem ao menos duas listas, uma para usurios e outra para
desenvolvedores de seu projeto. Se voc desejar, criaremos agora uma lista chamada
projeto-user e outra chamada projeto-devel, caso prefira escolher outro nome para as suas
listas ou acessar a configurao avanada, clique aqui...

Este "auto-piloto" poder ser chamado vrias vezes dentro da pgina de gesto do projeto,

Pgina 97 de 117
 mas no pode ser destrutivo. Ele sempre deve detectar o que o usurio j possui e apenas
oferecer novas ferramentas a serem agregadas.

Ao classificar um projeto, seu criador pode escolher categorias s quais o mesmo pertence,
mas um administrador do portal pode "recategorizar" o projeto de forma a garantir sua
correta exposio na busca por categorias e mesmo para "alinhar" projetos de natureza
similar, buscando a interao entre eles.

Projetos hospedados em outros stios podem ser categorizados tambm aqui, servindo este
portal, ento, como um apontador para outros repositrios como o SourceForge, Incubadora
Virtual da Fapesp, Savanah e outros. No caso do CodigoLivre, porm, isto ser feito de
forma automtica, garantindo j a exposio de todo o volume de projetos do CodigoLivre
no portal bero-americano.
2. Notcias: As notcias podem ser relativas aos projetos, de responsabilidade dos
desenvolvedores e publicadas com destaque na pgina principal (de todos os projetos), na
pgina do projeto (apenas as relativas a ele) e devem poder ser exportadas para outros stios
em formatos como o RSS.

Notcias postadas pela comunidade ibero-americana tambm sero aceitas de vrias formas,
com nveis de mediao. Notcias postadas anonimamente sempre passaro pelo crivo do
gerente de contedo. Notcias postadas por usurios registrados tero prioridade, mas
tambm passaro pelo crivo de um gerente de contedo. O gerente de contedo pode
autorizar alguns usurios a postarem notcias no portal sem a necessidade de mediao.

Notcias que vm de outros portais podem ser includas neste atravs de mecanismos como
RSS.
3. Multi-idiomas: Inicialmente, todo o portal ter sua interface em portugus e espanhol. Os
contedos podem ser disponibilizados em apenas uma lngua, havendo neste caso, quando
da exibio do contedo em uma lngua para o qual no foi traduzido, a opo para que o
leitor ou colaborador "envie uma traduo". Por exemplo, um projeto com desenvolvedores
brasileiros ir postar suas notcias e demais informaes em portugus. Quando algum de
lngua espanhola acessar uma informao no traduzida, a ler na lngua original, mas ter a
possibilidade de colaborar com uma traduo. Isto pode ser expandido para outros idiomas.
4. Gesto do ambiente e estrutura de suporte: Este portal visa ser referncia e ponto de
integrao no desenvolvimentos de software livre para a comunidade bero-americana. Alm
da ao prtica de hospedagem de projetos (ou apontadores para outros portais), ele ser a
base de uma ao de integrao e busca de recursos para desenvolvimentos que estejam
ligados gerao de emprego e renda, incluso social e resoluo de conflitos.

Desta forma, a fim de que o portal atinja o sucesso em suas metas, propomos a montagem de
uma estrutura que pode ser ampliada medida em que seu uso se intensifique:

Comit Gestor
Formado por membros da comunidade, mediante indicao dos financiadores deste portal e
com vagas abertas para a eleio democrtica de outros membros da comunidade bero-
americana.

Pgina 98 de 117
Equipe de suporte
Tradutor portugus-espanhol e vice-versa;
Gerente de contedo (para aprovar as notcias e negociar relaes com as fontes);
Analistas de suporte (2) - (para resolver questes tcnicas e cuidar da sade operacional do
sistema);
Diretor Executivo (representante do portal perante a comunidade, ligao entre o comit-
gestor e a equipe de suporte).
Ideias para o Cronograma de implantao
Fase 0: Implantao do espelho do CodigoLivre no portal bero-americano, treinamento dos
analistas de suporte
Fase 1: Criao das interfaces de registro de projetos baseadas no Fred, Losango interagindo
de forma transparente com o CodigoLivre, conforme leiaute definido pela equipe de arte
contratada parte
Fase 2: Sistema de notcias
Fase 3: Multi-idiomas
Testamos toda a interface em portugus e depois faz-se o porte para o espanhol,
deixando aberta a possibilidade de traduo para outras lnguas.
Fase 4: Suporte continuado
Numa estimativa inicial, cheguei a oito semanas de desenvolvimento para as fases 0 a 3, com o
envolvimento semi-integral de um gestor e o uso de pessoas contratadas para a escrita de cdigo.
Com estes dados, chegamos a um Product Backlog, exemplificado abaixo:

Brod Tecnologia - Product Backlog

Produto: Portal bero-Americano de Colaborao e Desenvolvimento Tecnolgico
Data: 30/10/2006
Estimativa
Prioridade Item Descrio (horas) Quem
Startup 242
Alta 1 Captao de recursos para o projeto 160 CB
Alta 2 Reunio
Contratao da equipe
de incio do projeto e definio do 1.o sprint 80 CB
Alta 3 backlog 2 CB
Design
Definio de leiautes, interfaces, levantamento de 40
Alta 4 necessidades e ferramentas a serem adotadas 40 CB
Setup 42
Alta 5 Aquisio
Diviso dedotarefas
equipamento "host", instalao, registro do 2 CB
Alta 6 domnio, implantao do espelho do CL
Auto-piloto com scripts diferenciados para a montagem 40 TBD
Desenvolvimento
das pginas do projeto de acordo com as caractersticas 240
Alta 7 Criao
do mesmo do interface
de sistema para
paraadisponibilizar
mediao deanotcias por
possibilidade 80 Devel1
Mdia 8 de
projeto e gerais,
tradues, incluindo
com publicao
mediao por RSS
de contedo como nas 80 Devel2
Alta 9 notcias 80 Devel3
Lanamento e Marketing
Reunio de lanamento com comit gestor e equipe de 42
Alta 10 suporte 2
Mdia 11 Lanamento para os meios de comunicao 40
Suporte continuado

Pgina 99 de 117
Sprint Backlog
Note que enquanto no Product Backlog fazemos a melhor estimativa das horas que gastaremos nas
tarefas, no Sprint Backlog que fazemos o registro destas horas e podemos confront-las com as
estimativas. Sprints podem ocorrer em paralelo, desde que tenhamos como segmentar as tarefas. No
nosso caso, poderamos ter as tarefas de definio de leiaute ocorrendo em paralelo s tarefas de
definio e aquisio de equipamentos. Aps a reunio que ir definir as tarefas do Sprint, o
ScrumMaster apenas acompanha o projeto, buscando eliminar qualquer obstculo que a equipe
tenha. O Sprint Backlog o guia que a equipe usa para sua auto-gesto. Ela mesma o preenche. Por
isto til t-lo no formato de um documento compartilhado.
Brod Tecnologia - Sprint Backlog
Produto: Portal bero-Americano de Colaborao e Desenvolvimento Tecnolgico
Sprint: Captao de recursos
Perodo: 30 dias a partir de 04/12/06

Esta a data
Preencha
limite para a
esta coluna A data em
entrega da Para cada linha de tarefas, o total de horas Total de
com a data que a
tarefa, e deve gastas naquela tarefa especfica dentro da horas do
em que a soluo foi
ser menor que semana especificada na coluna ms
tarefa foi entregue
a do final
submetida
deste sprint

Data de Data de Total de

Quem Descrio Data Limite Semana 1 Semana 2 Semana 3 Semana 4
entrada soluo horas

Total de horas utilizadas na semana (Preencha para cada semana o total

de horas utilizados na execuo das tarefas) 60 40 40 20 160
Desenvolvimento de
CB Material para a
Apresentao 4/12/2006 8/12/2006 8/12/2006 40

FI Contato com clientes

e agenda de reunies 4/12/2006 8/12/2006 8/12/2006 20
Apresentao aos
CB/JK
clientes 11/12/2006 22/12/2006 26/12/2006 40 40 20

Burndown Chart
Outro artefato importante do Scrum o Burndown Chart, complementando os backlogs e atuando
como seu elemento de realimentao e controle de qualidade. A forma mais simples de implement-
lo simplesmente adicionar uma coluna a mais na estimativa de horas do backlog, colocando ao
lado das horas estimadas as horas efetivamente realizadas na execuo de uma determinada tarefa.
Com isto possvel verificar o quanto a nossa estimativa inicial estava correta ou no, melhorando-
a continuamente a cada novo projeto.
De forma simples, para o nosso Sprint de quatro semanas, temos um total de 160 horas, que vo
sendo consumidas ao longo do tempo de acordo com a tabela abaixo:
Semana Horas Restantes Horas Estimadas
0 160 160
1 110 100
2 55 60
3 15 20
4 0 0

Aqui foram consideradas as horas totais de todas as pessoas envolvidas no projeto. A coluna relativa
horas estimadas corresponde ao Sprint Backlog acima. Comeamos a semana com 160 horas e,
idealmente, consumiramos 60 horas na primeira semana, 40 na segunda, mais 40 na terceira e,

Pgina 100 de 117

finalmente, 20 horas na quarta semana. De fato, tivemos uma boa surpresa e consumimos apenas 50
horas na primeira semana. Precisamos averiguar a razo disto, j que nossa estimativa estava errada.
Superestimamos o esforo? A tarefa no era to complicada quanto pensvamos? Ocorreu algum
fato novo que fez com que no precisssemos gastar todas as horas previstas? Este exerccio de
crtica das estimativas deve ocorrer constantemente, servindo como ferramenta de ajuste para
estimativas futuras. O grfico abaixo, montado a partir da tabela acima, mostra o quanto desviamos
de nossa previso, mas felizmente cumprindo o prometido dentro do prazo total para o Sprint.

Burndown Chart
180

160

140

120

100
Horas

Horas Restantes
80 Horas Estimadas
60

40

20

0
0 1 2 3 4
Semanas

A estimativa de um trabalho em horas, mesmo parecendo ser a mais direta, no , na maioria dos
casos, a ideal. A hora de um desenvolvedor nunca ser igual a de outro e a qualidade do resultado
do trabalho tambm varia. Um desenvolvedor competente pode resolver um determinado problema
em oito horas. Outro desenvolvedor, talvez mais criativo, pode ficar simplesmente pensando na
soluo por algumas semanas e, ao visualiz-la, escrever seu cdigo em alguns minutos e com
muito menos linhas que o primeiro. Em uma equipe de desenvolvimento procura-se nivelar a equipe
com padres de codificao e guias de melhores prticas mas, ainda assim, conta-se com
desenvolvedores com os mais variados graus de experincia. Mais adiante falaremos mais sobre
formas de estimar o trabalho de desenvolvimento.

ScrumMaster
Ao contrrio de um gestor de projetos tradicional, que responsvel por planejar, instruir e
coordenar os trabalhos de sua equipe, nas metodologias geis de desenvolvimento este gestor deve
principalmente ser um facilitador e motivador. O Scrum visa ser um conjunto simples e eficaz de
regras e ferramentas para maximizar resultados, gerando o mnimo possvel de sobrecarga
administrativa. O ScrumMaster deve garantir que estas regras e ferramentas sejam usadas e que
sempre estejam diretamente relacionadas melhoria dos processos, melhor retorno de investimento
e liberdade criativa para a equipe.

User Stories
Scrates: Homero no diz muitas vezes e muito sobre as tcnicas? Por exemplo, sobre a tcnica do auriga se
me recordares o verso, eu te direi.

on: Mas eu recitarei pois eu me recordo.

Scrates: Dize-me, ento, o que diz Nestor ao seu filho Antloco, quando o aconselha ficar atento a respeito da

Pgina 101 de 117

baliza, na corrida de cavalos em honra a Ptroclo.

on:

Inclina-te, diz , no carro bem polido

docemente para a esquerda dos dois: o cavalo da direita

estimula com a voz, cede-lhe as rdeas com as mos.

Na meta, certo, o cavalo da esquerda se lance,

a fim de que o cubo da roda bem feito

parea tocar a meta: mas evita tocar na pedra.

Scrates: Basta! Esses versos picos, on, se Homero diz corretamente ou no, quem conheceria melhor, um
mdico ou um auriga?

on: Um auriga certamente.

Scrates: E porque ele possui essa tcnica ou por algum outro motivo qualquer?

on: No, mas porque ele possui essa tcnica.

Scrates: Ento a cada uma das tcnicas foi dada por Deus uma funo de ser capaz de conhecer? Pois no
conhecemos pela tcnica do piloto o que conheceremos pela tcnica mdica.

on: No, certamente.

Scrates: E nem conhecemos com a tcnica mdica essas tambm que conheceremos na arquitetura.

on: No, certamente.

Scrates: Portanto assim tambm segundo todas as tcnicas, aquilo que conhecemos atravs de uma tcnica,
no conheceremos atravs de outra? Mas, responda-me isso primeiro: afirmas que as tcnicas diferem umas das
outras?

on: Sim.

Scrates: Ah, assim como eu estou conjecturando, quando uma cincia trata de umas coisas e outra trata de
outras, assim eu chamo uma tcnica de uma maneira, a outra de outra; e tu tambm fazes o mesmo?

on: Sim. Scrates: Se houvesse uma cincia das mesmas coisas, por que haveramos de dizer de uma maneira
diferente da outra, cada vez seria possvel saber as mesmas coisas atravs de ambas? Por exemplo: eu conheo
que esses dedos so cinco, tu tambm sabes, e, como eu, tu conheces as mesmas coisas a respeito deles. E se eu
te perguntasse se pela mesma tcnica que ns conhecemos isso, isto , pela aritmtica que eu e tu conhecemos
as mesmas coisas ou por outra tcnica, tu dirias certamente que pela mesma.

on: Sim.

Scrates: Dize-me agora, ento, o que a pouco eu estava a ponto de te perguntar: se te parece que ocorre assim
em todas as tcnicas, isto , que conhecemos uma mesma coisa necessariamente com uma tcnica, porm nunca
essa mesma coisa por outra tcnica; uma vez que se trate de uma tcnica diferente, necessrio que seja outro
o objeto do seu conhecimento.

Pgina 102 de 117

 on: Assim me parece, Scrates.

Scrates: Portanto, aquele que no possui uma tcnica no ser capaz de conhecer bem nem o que se diz nem o
que se faz dessa tcnica?

on: Dizes a verdade.

DILOGOS DE PLATO, ON
Traduo original de Humberto Zanardo Petrelli
Todo bom projeto comea com o pleno entendimento, por parte de uma equipe de desenvolvimento
ou de um fornecedor de solues, daquilo que o cliente realmente deseja. Isto deveria ser trivial,
simples, mas deixou de ser a partir do surgimento e domnio de uma srie de tecnologias aplicada
ao desenvolvimento de solues. Passamos a ter, de um lado, o usurio e, do outro, o conhecedor da
tecnologia.
O usurio precisa de uma soluo, mas no domina a tecnologia. Quem domina a tecnologia, por
outro lado, muitas vezes desconhece a real necessidade do usurio. Um dos textos de Plato,
descreve um dilogo entre Scrates e on, o rapsodo (artista popular ou cantor que, na antiga
Grcia, ia de cidade em cidade recitando poemas). Em certa parte do texto, Scrates discute com
on um poema de Homero no qual o pai recomenda ao filho cuidado em uma corrida de bigas. Um
cocheiro entenderia muito melhor este texto do que um mdico, ou um arquiteto, concordam os
dois.
Ao dominarmos uma tecnologia no podemos ter a pretenso de entender integralmente o negcio
ou as necessidades de nossos clientes. Ainda que nos esforcemos ao mximo para isto, o cliente
que detm esta compreenso, devendo ser o soberano na tomada de decises sobre a soluo que
deseja, mesmo que no entenda nada da tcnica a ser usada na construo desta soluo.
J mencionei, anteriormete, User Stories, ferramentas que envolvem o cliente e o
fornecedor/desenvolvedor na descrio da soluo. Mike Cohn, autor da clssica apresentao sobre
Scrum que traduzi, tambm autor de um dos melhores livros sobre User Stories: User Stories
Applied. Resumindo ao extremo, as User Stories permitem queles que conhecem a tcnica da
construo de uma soluo (linguagem de programao, ferramentas, bases de dados) guiar quem
necessita desta soluo no exerccio de descrev-la de forma simples e concisa.
As User Stories devem ter o usurio, aquele que necessita da soluo, como o foco da histria. No
se deve mencionar na histria algo como "melhorar a indexao da tabela de pedidos". Isto ser
grego para um usurio leigo, mas um analista de base de dados entender desta forma quando ler, na
linguagem do cliente: "aumentar a velocidade na impresso dos relatrios de pedidos". User Stories
devem ser perfeitamente explicveis em 30 segundos. Cada histria deve "caber" no trabalho a ser
executado em uma semana pela equipe de desenvolvimento, e deve ser facilmente testvel: o cliente
deve poder acompanhar o desenvolvimento do sistema lendo as User Stories que ajudou a escrever.
Usando dois acrnimos em ingls, o pessoal do xp123.com completa com mais boas dicas. INVEST
in Good Stories and SMART Tasks.
INVEST vem de Independent, Negotiable, Valuable, Estimable, Small, Testable. Cada User Story
deve ser, o mximo possvel, independente de outras histrias. Aquilo que ela descreve deve ser
perfeitamente negocivel entre o fornecedor e o cliente (de fato, ela deve poder ser traduzida,
posteriormente, em um plano de trabalho ou contrato de servios). O cliente deve perceber o valor
da User Story tanto como apoio compreenso na construo da soluo quanto na percepo real
da estimativa de seu investimento na mesma. E como j mencionei, cada histria deve ser pequena
e testvel.

Pgina 103 de 117

SMART vem de Specific, Measurable, Achievable, Relevant, Time-boxed. Quando auxiliamos o
cliente na construo de User Stories, devemos ter em mente que elas sero atendidas, na
construo da soluo, com a realizao de uma srie de tarefas. Ao saber como devem ser as
tarefas, saberemos orientar melhor cada histria. Cada tarefa deve ser especfica, contida em si,
bem definida e tambm independente. A tarefa deve poder ser medida para que seu custo possa ser
efetivamente avaliado. Obviamente, temos que definir tarefas que possam ser realizadas. Cada
tarefa deve ser relevante histria e, se na definio das tarefas, uma delas parecer no estar
relacionada com a histria (uma tarefa assessria no prevista inicialmente), ento a tarefa ou a
histria devem ser revistas. Por fim, um perodo de tempo deve ser definido para cada tarefa.
Muito bem, mas que tal um exemplo? O que considero mais simples, de fcil entendimento e
visualizao, o desenvolvido pela Universidade Estadual da Carolina do Norte, descrevendo o
projeto de uma cafeteira.
Ttulo: Estado de Espera
Teste de Aceite: Prioridade: 0 Story Points: 2
verificaOpes0
Quando a cafeteira no est em uso, ela fica aguardando a seleo do usurio. H seis diferentes
possibilidades de seleo: 1) Adiciona uma Receita; 2) Apaga uma Receita; 3) Edita uma Receita;
4) Adiciona Itens ao Estoque; 5) Verifica o Estoque; e 6) Adquire uma Bebida.

Ttulo: Adiciona uma Receita

Teste de Aceite: Prioridade: 1 Story Points: 2
adicionaReceita1
Apenas trs receitas podem ser adicionadas cafeteira. Uma receita consiste de um nome, preo,
doses de caf, doses de acar e doses de chocolate. Cada nome de receita deve ser nico na Lista
de Receitas. O preo deve ser tratado como um nmero inteiro. Uma mensagem de estado
exibida para mostrar se a receita foi adicionada com sucesso, ou no. Ao final, a cafeteira retorna a
seu estado de espera.

Ttulo: Apaga uma Receita

Teste de Aceite: apagaReceita1 Prioridade: 2 Story Points: 1
Uma receita pode ser apagada da cafeteira se ela existir na sua Lista de Receitas. As receitas so
listadas por ordem de nome. Ao final, uma mensagem de estado exibida e a cafeteira retorna a
seu estado de espera.

Ttulo: Edita uma Receita

Teste de Aceite: editaReceita1 Prioridade: 2 Story Points: 1
Uma receita pode ser editada se ela existir na Lista de Receitas da cafeteira. As receitas so listadas
por ordem de nome. Aps selecionar uma receita para editar, o usurio digita a nova informao da
mesma. Ao final, uma mensagem de estado exibida e a cafeteira retorna a seu estado de espera.

Pgina 104 de 117

Ttulo: Adiciona Itens ao Estoque
Teste de Aceite: Prioridade: 1 Story Points: 2
adicionaEstoque1
Itens de estoque podem ser adicionados cafeteira a partir do menu principal, sendo adicionados
ao estoque atual da mesma. Os tipos de itens so caf, leite, acar e chocolate. O estoque
medido em nmeros inteiros. Itens de estoque s podem ser removidos da cafeteira na aquisio de
uma bebida. Ao final, uma mensagem de estado exibida e a cafeteira retorna a seu estado de
espera.

Ttulo: Verifica o Estoque

Teste de Aceite: verificaEstoque Prioridade: 2 Story Points: 1
O estoque pode ser verificado a qualquer momento a partir do menu principal. Ao final, a cafeteira
retorna a seu estado de espera.

Ttulo: Adquire uma Bebida

Teste de Aceite: Prioridade: 1 Story Points: 2
adquireBebida1
O usurio seleciona uma bebida e insere uma quantidade de dinheiro. A quantidade de dinheiro
deve ser um nmero inteiro. Se a bebida consta do Livro de Receitas e o usurio inseriu uma
quantidade de dinheiro suficiente, a bebida ser entregue junto com a quantidade de troco (se
aplicvel). O usurio no poder adquirir uma bebida se no depositar dinheiro suficiente na
cafeteira. O dinheiro do usurio ser devolvido se no houver estoque suficiente para fazer sua
bebida. Ao final, uma mensagem de estado sobre a compra exibida e a cafeteira retorna a seu
estado de espera.

Na pgina do projeto da cafeteira88 da Universidade Estadual da Carolina do Norte estas User

Stories transformam-se em Casos de Uso, Diagramas de Sequncia e em cdigos de programas em
vrias linguagens. Recomendo fortemente esta leitura.

O jogo da estimativa
Estou bastante convencido que, uma vez que ele foi alm das questes que podem ser respondidas atravs de um
inqurito razovel, o projetista deve chutar ou, se voc preferir, postular um conjunto completo de atributos e
valores, com uma frequncia imaginada de distribuies, a fim de desenvolver modelos completos, explcitos e
compartilhados de usurio e usos.

Um chute calculado melhor do que uma premissa no verbalizada.

Muitos benefcios provm deste procedimento ingnuo:

Chutar os valores e frequncias fora o projetista a pensar muito cuidadosamente sobre a composio esperada
de usurios.

O PROJETO DO PROJETO DA MODELAGEM IMPLEMENTAO

FRED BROOKS, JR

88 http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/

Pgina 105 de 117

Voc deve ter observado nas User Stories da cafeteira, acima, uma clula contendo Story Points. Os
Story Points, ou Pontos de Histria, correspondem a um nmero mgico que reflete o esforo
necessrio para o desenvolvimento de cada uma das partes especficas que iro compor a soluo
completa. A estimativa deste esforo uma das partes mais difceis da elaborao de um projeto
se que no a parte mais difcil. Dela iro depender a alocao de pessoas, materiais,
equipamentos e tambm ela que definir, em grande parte, o valor necessrio para o investimento
no desenvolvimento da soluo.
J falamos sobre a dificuldade de se estabelecer a quantidade de horas necessrias para completar
uma determinada tarefa, j que cada pessoa e equipe trabalham de formas distintas, com nveis
diferentes de elegncia e qualidade. No fim das contas, o chute calibrado do projetista que ir
definir a quantidade necessria de esforos para a concluso de cada uma das tarefas. Este chute
to mais calibrado quanto maior for o seu histrico anterior de projetos. a experincia que acaba
calibrando a percepo para o bom chute. Segundo Mike Cohn89:
O Scrum no prescreve uma forma atravs da qual as equipes estimam seu trabalho. Entretanto, ele incentiva as
equipes a no fazer estimativas em termos de horas mas, ao invs disto, a usar uma mtrica mais abstrata para
quantificar o esforo. Mtodos comuns de estimativa incluem escalas numricas (1 a 10), nmeros de camisetas
(PP, P, M, G, GG, GGG, XG, XXG), a sequncia de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc) e at mesmo raas
de cachorros, na qual o chihuaua representa as histrias menores e um dinamarqus a maior. O importante
que a equipe compartilhe o entendimento da escala que usa, de forma que cada um de seus membros esteja
confortvel com seus valores.

Isto no fcil. Uma grande parte dos clientes, acostumados ao Grande Contrato, ainda tem sua
percepo de esforos necessrios ao desenvolvimento fortemente atrelada a um nmero de horas.
Mesmo quem est gerenciando o desenvolvimento de um projeto ter, na maioria das vezes, que
remunerar seus desenvolvedores em alguma forma de pagamento por dias ou horas de trabalho. H
aqui um paradigma estabelecido e que precisa ser mudado, j que o nmero de horas para o
desenvolvimento de um projeto tem muito pouco significado e uma relao muito frgil com a
qualidade final do projeto.
Uma linha de cdigo escrita em dois minutos por um desenvolvedor com muitos anos de
experincia e enorme criatividade tem mais valor do que 100 linhas de cdigo escritas em dez dias
por um outro desenvolvedor com muito menos experincia? Considere que o resultado produzido
pelo trabalho dos dois desenvolvedores idntico e que voc no consegue identificar, sem olhar o
cdigo, quem produziu uma soluo ou outra. Agora, imagine que voc no tem dez dias em seu
cronograma para entregar o resultado da tarefa. H uma subjetividade muito grande na estimativa
de esforos, recursos para a execuo da tarefa e valores que sero cobrados do cliente. Pense
tambm em um profissional que dedica cinco horas de seu dia ao seu trabalho de desenvolvimento e
outras trs a seu aprimoramento profissional atravs de cursos, leituras, conversas com seus pares.
Como embutir estas trs horas dirias no valor que cobra de seus clientes? Somado a todos estes
fatores est a concorrncia. Independente de qualquer estimativa, o valor cobrado de um cliente
deve ser competitivo o suficiente para que, considerando a relao entre custo e benefcio, ele
invista em nosso trabalho e no no trabalho de outros. Isto inverte completamente a equao da
estimativa: temos que fazer com que o que estimamos caiba no oramento disponvel para o
investimento do cliente.
No existe bala de prata. Por isso, a melhor sada realmente termos um mtodo de estimativa de
esforos com o qual a equipe esteja confortvel e, a partir dele, criarmos a nossa prpria relao
entre o oramento do cliente de um lado e o que pagamos a desenvolvedores e investimos em
recursos (maquinrio, capacitao, etc) de outro.
Uma forma de estimativa que eu acho especialmente til atribuir duas propriedades a cada tarefa:

89 http://scrummethodology.com/scrum-effort-estimation-and-story-points

Pgina 106 de 117

o valor do negcio (BV Business Value) definido pelo cliente do projeto; e a carga de trabalho (W
workload), que definida pelos desenvolvedores. A prioridade de cada tarefa o valor da diviso
BV/W. BV e W no so valores exatos, eles no representam horas ou dias, mas os nmeros 1, 2, 3,
5, 8, 13, 21 (a seqncia de Fibonacci). muito difcil avaliar exatamente uma tarefa. Ento, para
que seguir usando horas? mais fcil dizer que a tarefa A mais fcil que a tarefa B e atribuir
cargas de trabalho proporcionais, segundo os autores do Scrinch90, uma ferramenta auxiliar ao
desenvolvimento de projetos com o Scrum.
J dissemos que o clculo de horas para uma determinada tarefa , sempre, muito complexo. Ele
exige que se conhea muito bem a tecnologia com a qual se trabalha e a real produtividade de cada
membro da equipe. Como temos que estar sempre de olhos abertos a novas tecnologias e como os
membros de uma equipe podem no ser os mesmos no decorrer de todo o tempo da realizao de
um projeto, que tambm pode ter seus requisitos ajustados, as variveis para o clculo de horas so
tantas que essa ideia de usar a sequncia de Fibonacci como um fator de relao entre tarefas, ao
invs da atribuio inexata de um nmero de horas, no parece to absurda. " um tanto incmodo
no incio, mas bastante til no final", ainda segundo os autores do Scrinch.
Essa prtica de atribuir nmeros da sequncia de Fibonacci a uma tarefa tem suas origens no Poker
do Planejamento do Scrum, um jogo - e ao mesmo tempo um exerccio - de estimativa de
desenvolvimento de um projeto a partir da informao que se tem do cliente: as User Stories.
No Poker do Planejamento, cada membro da equipe fica com um conjunto de cartas numeradas de
acordo com a sequncia de Fibonacci. Todos analisam as User Stories, uma por vez, e jogam na
mesa uma carta de acordo com o que acreditam ser o grau de complexidade de seu
desenvolvimento. Quanto mais complexa a tarefa, maior o nmero de sua carta. A mdia dos
valores das cartas corresponde aos pontos para aquela User Story, seus Story Points. Caso, por
exemplo, a maioria dos membros da equipe jogue uma carta de valor alto e apenas um coloca uma
carta de valor baixo (ou vice-versa), a carta discrepante descartada da mdia. H ainda uma carta
com o sinal de interrogao (?), significando que a User Story no est suficientemente explicada
ou no foi completamente entendida.
Isto extremamente subjetivo, mas d a real dimenso comparativa entre a complexidade de
desenvolvimento entre uma histria e outra. Com a prtica possvel estabelecer relaes entre os
Story Points e o valor a ser cobrado do cliente e o que ser pago aos desenvolvedores.
Mike Cohn criou o PlanningPoker.Com, que permite que se faa a estimativa via internet, de graa,
desde que se faa o registro no site.
O Planning Poker legal para fomentar a interao entre a equipe de uma maneira divertida,
servindo tambm para o ScrumMaster e o Product Owner terem uma ideia dos perfis de estimativa
de cada um dos membros. Sempre existir aquele que mais ousado e acha possvel fazer tudo
muito fcil, assim como, no outro extremo, ter aquele que sempre vai encontrar pontos que devem
ser melhor esclarecidos em cada histria. Na prtica, o Planning Poker funciona como um nivelador
para a equipe, para aumentar o entrosamento e para ensinar o Scrum. Depois de alguns exerccios, o
Planning Poker torna-se intuitivo e as cartas acabam se aposentando.
O pessoal bacana na Blusoft disponibilizou o conjunto de cartas do Poker do Planejamento91 para
download, inclusive em um formato editvel no Corel, para que cada um possa modificar as suas.
H tambm o formato em pdf, para os que no querem ter esse trabalho e podem fazer uma
merecida propaganda para a empresa.
Caso voc tenha um bom histrico de seus projetos anteriores, experimente fazer uma retrospectiva
deles, tratando-os como novos e estimando-os novamente com o Poker do Planejamento. Revise ou
90 http://scrinch.sourceforge.net
91 http://bluesoft.wordpress.com/2007/11/07/scrum-planning-poker/

Pgina 107 de 117

crie as User Stories respectivas e estabelea os Story Points para cada uma delas. Avalie a
remunerao dos desenvolvedores, o quanto foi cobrado do cliente e o lucro obtido. Faa isto para
uns trs ou quatro projetos e tente estabelecer uma relao entre os valores financeiros e os Story
Points. Aplique esta relao a um outro projeto conhecido e verifique se ela real. Repetindo o que
diz o pessoal do Scrinch: " um tanto incmodo no incio, mas bastante til no final."

Ah, o cheirinho de Scrum pela manh!

justamente no dia-a-dia que o Scrum vai tornando-se mais importante. Depois de algum tempo
praticando, as ferramentas vo tornando-se um hbito. Em nossa empresa muito comum, j em
uma primeira reunio com um cliente, comearmos a pensar nos termos do Product Backlog,
imaginando como ser a formao da equipe e parceiros de desenvolvimento e nos Sprints que
ocorrero at a entrega do projeto. Quando a proposta feita, muitas vezes em conjunto com um ou
mais parceiros de negcios, ela traz embutida o Product Backlog e um cronograma que dar origem
ao Burndown Chart. O perigo de uma coisa que se torna cotidiana, porm, que essa coisa pode
comear a se deteriorar sem que a gente perceba. preciso prestar ateno aos cheiros do SCRUM
pra ver se no h algo de podre no reino da Dinamarca, como diria Hamlet.
Quem usou pela primeira vez o termo Code Smells (o fedor do cdigo) foi o Kent Beck, criador do
Extreme Programming, enquanto ajudava o Martin Fowler em seu livro sobre Refactoring. Segundo
Martin, "um mtodo muito extenso um bom exemplo - apenas de olhar para um cdigo meu nariz
comea a se contorcer se eu vejo mais do que uma dzia de linhas em Java".
A analogia com o "cheiro" bastante simples. Muitas vezes sabemos que h algo errado, algo est
cheirando mal, mas nem sempre fcil identificar a origem. Mike Cohn, que muitos j notaram ser
uma das minhas fontes preferidas, props um catlogo de cheiros do SCRUM em 2003, buscando
auxiliar na identificao de alguns problemas:
Perda de ritmo: acontece quando os Sprints comeam a ter durao varivel. muito
importante para o sucesso do Scrum que a equipe adquira a naturalidade em seu ritmo,
concluindo cada Sprint com algum incremento ao projeto. Se, por qualquer razo, um Sprint
tiver a durao de uma semana, outro de duas, mais outro de uma e assim por diante, ser
impossvel que o ritmo adquira uma naturalidade. Eu vejo a tendncia disso acontecer
quando o time formado por "porcos" que tm muitos outros compromissos. Porcos so
aqueles que entram com o "toucinho" no projeto, os que devem estar verdadeiramente
comprometidos. O ScrumMaster deve considerar a durao do Sprint algo sagrado e, se for
o caso, conversar com o patrocinador do projeto exigindo a participao do devido porco ou
at sugerindo a troca de porcos.
Galinhas falantes: na reunio diria do projeto, apenas os porcos podem falar. As galinhas,
que entram com os ovos, esto envolvidas, mas no comprometidas com o processo. O Mike
totalmente contra permitir que as galinhas se intrometam, mas concorda que elas podem
assistir s reunies. Eu concordo, mas tambm aceito que, na informalidade, uma galinha
tente transmitir a um porco suas ideias, desde que fora das reunies. Em raros casos, e
sempre entre o fim de um Sprint e o comeo de outro, aceito a indicao de um porco para
promover uma galinha a porco tambm.
Porcos que faltam: cada vez mais desenvolvedores trabalham em horrios flexveis. Isto
um problema quando se quer estabelecer um ritmo e tem a ver com o primeiro dos
problemas aqui colocados. As reunies dirias devem ser rpidas, de quinze minutos,
aproveitando ao mximo o tempo dos participantes. Os porcos escolhidos devem saber disso
e estarem de acordo logo no incio do projeto. O porco que faltar estar sujeito s decises
dos demais, sem poder negociar nada posteriormente. Mas, e com equipes que trabalham

Pgina 108 de 117

 remotamente? A eu sou mais flexvel, mesmo reconhecendo que essa flexibilidade , s
vezes, contraproducente e que o ScrumMaster acaba tendo a sobrecarga de ficar dando
puxes de orelha aqui e ali. Nesses casos, o que fao ter vivo um documento
compartilhado, onde as decises tm seu horrio de fechamento. Passado esse horrio, quem
no contribuiu sujeita-se s decises dos demais.
Hbitos persistentes: normal que cada grupo comece um projeto trazendo para ele seus
hbitos de trabalho individuais e em equipe mas importante que, quando um mau hbito
identificado, ele seja imediatamente corrigido. Um dos termmetros do Sprint o Burndown
Chart, o quadro de registro do consumo de horas do projeto. Quando as horas efetivamente
consumidas flutuam muito com relao s horas previstas, h algo de errado no
planejamento ou na execuo do projeto.
O ScrumMaster delega trabalhos: especialmente em equipes ainda no habituadas ao
Scrum, normal que exista uma expectativa que o ScrumMaster, como um gerente de
projetos, distribua os trabalhos a serem feitos. Isto errado. O ScrumMaster auxilia a
equipe, removendo os obstculos execuo do projeto. Cada membro da equipe deve
escolher as tarefas que executar, de acordo com a sua competncia e negociando com os
demais membros do grupo.
A reunio diria para o ScrumMaster: tambm um sintoma clssico da falta de
familiaridade com o Scrum, manifesta-se com a equipe fazendo para o ScrumMaster o relato
dos trabalhos. A reunio tem que ser para a equipe. Quando um membro compromete-se em
entregar uma tarefa, ele compromete-se com a equipe e no com o ScrumMaster. No
papel do ScrumMaster reclamar da entrega ou no de tarefas, mas entender os obstculos
que impediram a sua realizao e remov-los.
Cargos especializados: acontece quando as pessoas entram na equipe com cargos de
"testador", "chefe de desenvolvimento" e outros. Quando algum entra com o papel de
"testador", por exemplo, os demais podem ter a impresso de estar "liberados" de participar
de testes do projeto. Assim como um "chefe" de qualquer coisa pode dar uma falsa
impresso de hierarquia. Dentro de uma equipe Scrum, todos devem ter o esprito "estamos
nessa juntos" e assumir responsabilidades idnticas perante o projeto. Claro que vai ser
impossvel montar uma equipe formada apenas por generalistas, que saibam tudo de tudo,
mas o esprito esse. O que eu procuro fazer eliminar os ttulos e cargos na apresentao
da equipe, observar a escolha de tarefas de cada um (tipicamente, dentro das reas de maior
conforto) e tentar incentivar a colaborao especialmente quando h a identificao de
obstculos para os quais sinto que "o olhar de um outro colega" pode trazer nova luz s
dificuldades. Claro que sempre tomando o cuidado de no delegar tarefas.

Perguntas e Respostas
Durante o perodo em que adquiramos familiaridade com o Scrum durante o projeto do Interoplab,
com a equipe da Unicamp, os membros da equipe (em especial o Raul Kist e o Bruno Melo)
compilaram dvidas que foram discutidas ao longo do projeto. Destas, algumas tm se apresentado
com mais frequncia em outras implementaes do Scrum e, por isso, as reproduzo aqui.
Pergunta 1: Para utilizar o Scrum voc precisa saber aonde quer chegar. E quando pegamos aqueles
clientes que no sabem o que querem e constantemente tiram e colocam as mesmas coisas em um
projeto? Outra pergunta to inquietante : como precifica-se um projeto em algo que no sabemos o
que vai virar o fim, sem saber direito o tamanho do projeto? (j que prioridades e requisitos so
desbravados aos poucos, em fases).
Um projeto novo, sendo interno ou externo, comea com os "user stories", com foco total

Pgina 109 de 117

 em quem usar o sistema (ou uma nova funcionalidade dele) a ser desenvolvido. A partir
destas "histrias", estima-se o tempo de desenvolvimento e os recursos necessrios, que
entram no Product Backlog e no Burndown Chart.
A partir do Product Backlog que estima-se o preo do projeto. Mas a h uma questo: O
Scrum (assim como o XP e metodologias geis em geral) so para projetos de curta a mdia
durao. Trs meses o perodo mgico mximo. Se um projeto durar mais do que trs
meses, ele deve ser dividido em dois ou mais projetos. Ficando nestes trs meses, a
precificao e a "viso" do que ser feito no perodo relativamente fcil. Se passar disto,
comea o exerccio do "achismo". Em metodologias mais clssicas, independente do tempo
que o projeto levar, uma fase extensa de planejamento ir determinar recursos e
cronogramas, com o efeito colateral de que a prpria fase de planejamento ir adicionar
tempo e custos ao projeto, coisas que as metodologias geis buscam evitar na metodologia
gil, o planejamento e controle no devem ser sobrecarga no projeto. Eu busco resolver isto
da seguinte forma: comeo, sim, com os "user stories", tratando-os de forma mais ampla,
como uma "lista de desejos". Com base tambm em projetos anteriores (ajuda se eles
existirem), estimo o tempo de desenvolvimento e multiplico por dois (sim! e isto uma
recomendao do Fred Brooks Jr. em O Mtico Homem-Ms). Fao um Product Backlog
prvio, que incluir, de forma geral, o que ir compor os demais Product Backlogs, e a
precifico. Isto antes de comear o projeto e o primeiro Product Backlog e Burndown Chart.
Mas claro que o melhor sempre manter o projeto no escopo visvel de uns poucos meses.
O Burndown Chart simplesmente lista as horas a serem consumidas pelos recursos. Pode ser
montado de forma global (prefiro) ou para cada recurso a ser consumido. O ideal que as
horas previstas sejam equivalentes s consumidas. Se as consumidas forem menores, menos
mal. Se maiores, o projeto est consumindo recursos alm dos que foram propostos. Ele
serve, historicamente, para avaliar nossa capacidade de prever os recursos, e como guia para
que a ajustemos.
Temos que saber o que vai dar no fim sim, independente de mudanas de prioridades
posteriores. O "fim" tem que estar descrito no Product Backlog inicial.
Pergunta 2: O Scrum utitiliza uma teoria de membros auto gerenciveis, onde os esforo do
ScrumMaster quase unicamente facilitar e dar subsdios para a equipe (e no necessariamente
resolver os problemas existentes). Mas existem aqueles casos em que a equipe, nem por reza brava,
entra em acordo. O Scrum tem alguma sada nesse caso, dado que o ScrumMaster no deve
''gerenciar'' estas pessoas?
Se for um conflito "tcnico", o ScrumMaster resolve, em ltimo caso, ditatorialmente
mesmo. Se for algo relativo funcionalidade, a o dono do projeto (patrocinador, pagante)
quem decide.
Pergunta 3: O Scrum leva em considerao equipes que tem contato constante. Mas se isso no for
to ideal? Se os contatos (por horrios, por exemplo) no forem to acoplveis?
O contato "fsico" imprescindvel so as "stand up meetings", que deveriam ser dirias e
com a durao mxima de 15 minutos. Em alguns casos, isto pode ser invivel. A vale-se de
meios eletrnicos mesmo, como um dirio de bordo em que, assincronicamente, um possa
verificar e interferir no trabalho do outro. Um "wiki" ou um documento no Google Docs
podem ajudar neste sentido. A j no da metodologia, mas da aplicao prtica dela.
Eu e a Joice, minha scia, trabalhamos, quase sempre, um turno por dia juntos. Ao menos
um dia por semana reservamos para o nosso dia integral no qual, alm de fazer uma
discusso mais ampla de nossas atividades, estado dos clientes e planejamento futuro e
trabalharmos naquelas tarefas que requerem a presena fsica de ambos ainda exercitamos

Pgina 110 de 117

 nossos dotes culinrios na cozinha experimental da BrodTec. Tenho notado que uma
atividade extra-curricular como a culinria, um trabalho voluntrio conjunto ou at mesmo
um passeio (quando aproveitamos a visita clientes remotos para um eventual turismo
acidental) so importantes para aumentar os laos e compromissos em qualquer equipe.
As "stand-up meetings" na BrodTec ocorrem naturalmente e mais do que uma vez por dia.
Por vezes at pensamos em normalizar isto, oficializando um horrio, mas como est sendo
produtivo assim, mantemos desta forma. Alm disso, temos uma "Lista de Tarefas" no
Google Docs, acessvel por ambos, onde registramos as coisas mais importantes a serem
feitas, quer estejamos trabalhando juntos ou separados. Na nossa "lida", essa lista acabou
virando um borro eficaz de um Sprint Backlog. E sempre vale a mxima do Extreme
Programming: se a metodologia no couber ao trabalho, adequa-se a metodologia e no o
trabalho que est dando certo. Claro que a metodologia ajuda a avaliar se o trabalho est, ou
no, dando certo.
Pergunta 4: Em uma empresa que desenvolve projetos internos (para si mesma) e externos (para
clientes), cheguei a uma concluso: Scrum mais eficiente em projetos internos. Digo isso pois, os
riscos de um projeto interno normalmente so menores (nem sempre, admito) mas principalmente
porque cliente (prpria empresa), ScrumMaster e time de desenvolvimento esto juntos, com
contato mais prximo. Estou errado? At porque um sprint pode no sair se demasiadamente uma
atividade depender do cliente, e o cliente resolver sumir por algum tempo.
Quando se adota o Scrum, o cliente deve estar envolvido e estar sempre presente. No
mnimo, ao alcance de um e-Mail ou telefone. No pode "sumir". Por isto deve estar ciente
disto. Quanto a funcionar melhor para projetos internos ou externos, acho que no faz
diferena, mas isto no com base em minha experincia, mas na documentao de outros
autores.

Ferramentas
No h uma prescrio especfica de ferramentas a serem adotadas com o Scrum, mas
especialmente para a sua prtica e a implementao de seus artefatos h algumas disponveis na
web que podem ser de alguma ajuda. Uma ferramenta, porm, imprescindvel: o quadro branco.
Adiante falarei sobre o quadro branco e outras ferramentas que fomos utilizando ao longo do tempo.

Quadro branco e kanban

Uma equipe Scrum deve poder visualizar, o tempo inteiro, a evoluo de suas tarefas e a sua
agenda. Um kanban (a palavra significa registro em japons) consiste em uma tabela simples com
as tarefas planejadas na coluna esquerda, tarefas em execuo na coluna do meio e tarefas
completas na coluna esquerda. Uma implementao tpica de um kanban um conjunto de
etiquetas adesivas coloridas que so coladas e movidas entre as colunas de um quadro branco de
acordo com a evoluo de cada tarefa. As cores das etiquetas podem ser usadas para indicar a
prioridade das tarefas, o responsvel por ela ou ambos. Os demais espaos do quadro branco podem
conter a lista de obstculos ou impedimentos a serem levados ao ScrumMaster na prxima reunio,
a agenda da equipe e outras informaes pertinentes ao projeto. Uma sala Scrum pode ter uma
parede pintada com tinta impermevel, onde as colunas do kanban possam ser desenhadas e as
anotaes possam ser feitas e apagadas. Outras paredes podem ter as cpias dos backlogs para o
acompanhamento da equipe.
Caso a equipe trabalhe remotamente, uma simples tabela compartilhada no Google Docs pode fazer
s vezes de um quadro branco compartilhado entre todos os membros, mas h ferramentas livres
especficas para este tipo de implementao, como o heijunja-kanban (http://heijunka-

Pgina 111 de 117

kanban.sourceforge.net). Atravs dele possvel acompanhar as tarefas desde que so solicitadas,
at a sua configurao, execuo, teste e entrega ao cliente.

Google Docs
O Google Docs (http://docs.google.com) tem se mostrado, na nossa empresa, uma excelente
ferramenta para o acompanhamento e compartilhamento de informaes em um projeto Scrum,
tanto que no limitamos seu uso a trabalhos realizados com equipes remotas, usando-o tambm em
nossas tarefas dirias. As vrias folhas de uma planilha podem ser usadas para a criao do Product
Backlog e dos vrios Sprints Backlogs. Uma folha adicional pode servir como um kanban e mais
outra como um Burndown Chart.
Abaixo o exemplo de um Burndown Chart, com seus dados, em uma planilha compartilhada no
Google Docs, que pode ser acessada neste endereo: http://miud.in/e2V

Repare nas abas Tarefas, Resumo e Chart. Em Tarefas voc tm a descrio das tarefas para cada
desenvolvedor, com suas horas estimadas e efetivamente realizadas. Como vimos antes, ao invs de
horas poderamos ter usado Story Points. Repare nas frmulas usadas na planilha Tarefas, abaixo:

A planilha na aba Resumo construda automaticamente, a partir dos dados da aba Tarefas. O
grfico, por dua vez, construdo automaticamente a partir dos dados da aba Resumo. Ou seja, a
nica planilha que voc alterar durante a evoluo de seus Sprints a de Tarefas. Todas as demais
sero automaticamente atualizadas. Abaixo a planilha Resumo e suas frmulas:

Pgina 112 de 117

Para construir o grfico, basta voc selecionar todas as clulas da planilha Resumo, incluindo seu
ttulo, e clicar em Inserir Grfico (Insert Chart, caso voc esteja utilizando o Google Docs em
ingls). Selecione as opes de acordo com o esquema abaixo e est pronto o seu Burndown Chart.

O resultado, em nosso exemplo, o seguinte:

Pgina 113 de 117

Scrinch
Aqui no Brasil no estamos muito familiarizados com dois personagens que fazem parte do
imaginrio natalino norte-americano: Ebenezer Scrooge e o Grinch. O primeiro, criado por Charles
Dickens em 1843, um velho rabugento e po-duro. O segundo, criado pelo Dr. Seuss, uma
espcie de hermito que odeia os Whos, habitantes de uma pequena vila ao p da montanha onde
fica a caverna onde mora. Ambos tm em comum o fato de odiarem o Natal. Da, algum que um
Scrinch, mistura de Scrooge com Grinch, algum que odeia MUITO o Natal.
Toda a vez que falo sobre Scrum, dentre as vrias perguntas que me fazem, uma delas : "H algum
software que ajude no controle e implantao desses processos?". Minha resposta tpica sempre :
"um monte de post-its, um quadro branco, planilhas e documentos que possam ser compartilhados."
J dei exemplos de Product Backlog, Sprint Backlog e Burndown Chart que se valem desse tipo de
documentos. Uma busca por Scrum no Freshmeat ou no SourceForge tambm aponta para uma
srie de programas que podem ser teis, boa parte deles baseados em uma interface web, com maior
ou menor grau de complexidade. Um dos que mais gostei chama-se, justamente, Scrinch.

Pgina 114 de 117

O programa escrito em Java e, para comear a explor-lo basta fazer o download diretamente de
sua pgina oficial: http://scrinch.sourceforge.net. Por ser escrito em Java, o Scrinch
multiplataforma por natureza e poder ser utilizado no sistema operacional de sua preferncia. Se
voc tiver o Java Web Start instalado em sua mquina, voc no precisar de nenhum esforo
adicional para fazer o Scrinch rodar, caso contrrio, siga as instrues na pgina do projeto. O
manual, que encontra-se junto ao pacote de download do Scrinch, bastante prtico e sucinto. Os
relatrios (que incluem grficos) gerados para o acompanhamento do projeto podem ser exportados
para arquivos em PDF, facilitando o compartilhamento de informaes. Um projeto exemplo
tambm est disponvel para os preguiosos que, como eu, querem ver rapidinho tudo o que o
programa capaz de fazer antes de comear a brincar com ele.
Para aqueles que esto comeando a se aventurar com o Scrum, o Scrinch e seu manual podem ser
um bom ponto de partida, mantendo todos os artefatos e controles do processo em um ambiente
nico e consolidado. Para os que j conhecem o processo, ainda assim, vale a pena dar uma olhada
na ferramenta e seus exemplos.

Pgina 115 de 117

Bibliografia
Brooks, Frederick P. Jr. O Projeto do Projeto da modelagem implementao
Aquele com a histria da Apple que o Rubens me emprestou
Grahamm, Paul. Hackers and Painters - conferir
BROOKS, F. P. The Mythical Man-Month: essays on software engineering. Boston, MA:
Addison Wesley, 1995. ISBN 0201835959.
CASTELLS, M. A galxia da Internet: Reflexes sobre Internet, Negcios e Sociedade. Rio de
Janeiro: Jorge Zahar Editor, 2003. ISBN 9788571107403.
CONLON, M. P. An Examination of Initiation, Organization, Participation, Leadership, and
Control of Successful Open Source Software Development Projects. Slippery Rock, PA:
Information Systems Education Journal, 2007. Disponvel em:
<http://www.isedj.org/5/38/ISEDJ.5(38).Conlon.pdf >. Acesso em: 5 mai. 2009.
FABERLUDENS, Instituto de Design de Interao. Disponvel em:
<http://www.faberludens.com.br/pt-br/node/470>. Acesso em 05 mai. 2009.
FIORINI, S. T., et al. Engenharia de Software com CMM. Rio de Janeiro: Brasport, 1998.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. M. Design Patterns: Elements of
Reusable Object-Oriented Software. Boston, MA: Addison Wesley, 1995. ISBN 0201633612
LEE, G. K.; COLE, R. E. From a Firm-Based to a Community-Based Model of Knowledge
Creation: The Case of The Linux Kernel Development. Haas School of Business University of
California, Berkeley , 2003. Disponvel em: <http://www.stillhq.com/pdfdb/000501/data.pdf >.
Acesso em: 2 mai. 2009.
MOCKUS, A.; FIELDING, R. T.; HERBSLEB, J. D. Two Case Studies of Open Source Software
Development: Apache and Mozilla. ACM Transactions on Software Engineering and
Methodology, Vol. 11, No. 3, 2002.
RAYMOND, E. S. The Cathedral and The Bazaar: Musings on Linux and Open Source by an
Accidental Revolutionary. Sebastopol, CA: O'Reilly & Associates, 1999. ISBN 1565927249.
REIS, C. Caracterizao de um Modelo de Processo para Projetos de Software Livre . So
Carlos, SP, 2001. Disponvel em: <http://www.async.com.br/~kiko/quali/>. Acesso em: 11 mai.
2009.
TORVALDS, L.; DIAMOND, D. Just for Fun: The Story of an Accidental Revolutionary. New
York, NY: HarperCollins Publishers, 2001.
TUOMI, I. Internet, Innovation, and Open Source: Actors in the Network .The Finnish National
Fund for Research and Development, Berkeley, 2000. Disponvel em:
<http://flosspapers.org/12/1/Ilkka%2520Tuomi%2520-%2520Actors%2520in%2520the
%2520Network.pdf>. Acesso em: 8 mai. 2009.
VIA DIGITAL. Gesto de Projetos de Software Livre: Uma Abordagem de Prticas. Disponvel
em: <http://www.viadigital.org.br/docs/Praticas.pdf> Acesso em: 06 mai. 2009.
WILLIAMS, S. Free as in Freedom: Richard Stallman's Crusade for Free Software.
Sebastopol, CA: O'Reilly & Associates, 2002. ISBN 0596002874.
YOUNKER, J. Foundations of Agile Python Development. Berkeley, CA: Apress, 2008.
[New New Product Development Game by Hirotaka Takeuchi, Ikujiro Nonaka 10 pages.

Pgina 116 de 117

Publication date: Jan 01, 1986. Prod. #: 86116-PDF-ENG]
O Oitavo Hbito, Stephen Covey
Mike Cohn, User Stories Applied

Pgina 117 de 117