Beruflich Dokumente
Kultur Dokumente
(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
Projeto Interno
Nome-cdigo: UniverSis
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>
<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>
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:
Pgina 10 de 117
- a cada ms, teste de mdulos principais -
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
Verbo "amar"
Na linha:
if termina_em == 'ar':
conjuga_ar = ['o','as','a','amos','ais','am']
Em:
O resultado :
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
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.
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.
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.
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.
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.
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
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.
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.
5. Plano Diretor de Tecnologia da Aqui a proposta para o futuro, sempre embasada naquilo
Informao PDTI 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.
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
Pgina 44 de 117
Ecologia do Conhecimento
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.
Pgina 46 de 117
Figura 1 Evoluo do acesso Intranet
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.
Figura 3 Evoluo dos chamados tcnicos, entre agosto de 2002 e julho de 2003
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).
Nota: Repare que os dados factuais, comprovados, j servem de argumento para a solicitao de
um aumento da equipe.
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.
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!
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!
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.
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.
Joice Kfer
Ambiente de rede
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
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
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.
Pgina 54 de 117
Descrio Total Economizado
Uso do Sagu
Uso do Gnuteca
Uso do Teleduc
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.
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
Pgina 56 de 117
Cdigo da O que faz Onde foi utilizado Estimativa de
Comunidade economia de tempo
(um desenvolvedor)
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)
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)
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)
Pgina 60 de 117
Desenvolvimento pago por outras instituies
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.
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.
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 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 da rea de
infraestrutura de
telecomunicaes
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.
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
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.
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.
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.
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.
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.
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.
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.
Pgina 85 de 117
Drupal CVS e Git
OpenOffice CVS
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
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
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.
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.
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.
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.
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.
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.
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:
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
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,
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.
Scrates: Dize-me, ento, o que diz Nestor ao seu filho Antloco, quando o aconselha ficar atento a respeito da
on:
Scrates: Basta! Esses versos picos, on, se Homero diz corretamente ou no, quem conheceria melhor, um
mdico ou um auriga?
Scrates: E porque ele possui essa tcnica ou por algum outro motivo qualquer?
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.
Scrates: E nem conhecemos com a tcnica mdica essas tambm que conheceremos na arquitetura.
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.
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?
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.
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.
Chutar os valores e frequncias fora o projetista a pensar muito cuidadosamente sobre a composio esperada
de usurios.
88 http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/
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
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
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.
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: