Gesto de Projetos em Software Livre (Ttulo Provisrio) Cesar Brod com a colaborao de Joice Kfer

Pgina 1 de 117

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

Pgina 2 de 117

Apresentao

Pgina 3 de 117

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

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

Pgina 5 de 117

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

Pgina 6 de 117

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

Pgina 7 de 117

Como ler esse livro

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

Pgina 8 de 117

Vendendo a idia
Luciano, Carlos e Maurcio, Pensei bastante sobre a metodologia de implementao do novo Sistema Administrativo. Sei que nesta fase de estudo de uma nova ferramenta ainda podem surgir polmicas sobre o mtodo de migrao e a prpria ferramenta empregada, o que totalmente natural. Por isto mesmo, peo a vocs um voto de confiana na adoo das regras de desenvolvimento deste novo sistema e na linha mestra que adotaremos na implementao do mesmo. Aqui segue um primeiro "draft" para o desenvolvimento do novo Sistema Administrativo, que vocs devem transformar em um documento final. Sou flexvel em vrios aspectos, exceo das datas chaves do cronograma que devem ser mantidas a todo o custo. Projeto Interno Novo Sistema Administrativo Nome-cdigo: UniverSis Coordenador: Prof. Luciano Brando Objetivo: Migrao do Sistema Administrativo existente na Univates para uma estrutura baseada em Intranet, com bases de dados padro SQL e acesso dos clientes atravs de browsers padro de mercado. O novo UniverSis utilizar ferramentas de sistemas abertos e ser publicado para a comunidade acadmica que poder participar do projeto. Pr-requisitos: <NOTA> Sei que isto uma imposio, certamente passvel de questionamento. Aqui onde peo, justamente, o maior voto de confiana. </NOTA>

Pgina 9 de 117

1. A interface do usurio ser exclusivamente atravs de browser padro (Netscape, Internet Explorer ou outro) 2. A base de dados para o desenvolvimento inicial ser o MySQL <NOTA> A migrao para o Oracle ou outra base SQL deve ser tranquila, mas devemos comear com uma base na qual consigamos suporte da comunidade "OpenSource" com facilidade. </NOTA> 3. A base de dados de testes deve refletir a modelagem da atual, mas deve ser INDEPENDENTE da existente. <NOTA> Luciano, sei que tens crticas quanto a isto. Podemos discutir os malefcios e benefcios dos mtodos infinitamente. Quero evitar neste momento qualquer entrave no desenvolvimento que possa ter como raiz a migrao dos dados e os testes de volume. Confio que no meio do processo teremos um bom plano de migrao de bases de dados. </NOTA> 4. Todas as ferramentas utilizadas sero OpenSource, ou em ltimo caso OpenSource para o ambiente acadmico. Ferramentas adotadas SO Servidor: Linux SO Cliente: No importa, desde que use browsers padro Base de dados: MySQL - inicialmente, com possibilidade de porte para qualquer outra base padro SQL Linguagens: PHP (preferencialmente) e qualquer acessrio OpenSource necessrio. Cronograma: 20.11.99 - Documentao do projeto completa 01.12.99 - Publicao do projeto na Internet e contato com as principais Universidades do pas 01.12.99 - 01.03.00 - Definio de atribuies de colaboradores externos Pgina 10 de 117

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

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

Pgina 12 de 117

O que software livre?

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

# Programando em Python # Exemplo 3 - Cesar Brod # # modulo_conjuga.py # # Mdulo que conjuga verbos regulares em Portugus # verso 0.0 07/07/2001 20h17 # def conjuga(verbo): "Conjuga o tempo presente de verbos regulares" conjugado=[] conjuga_ar = ['o','as','a','amos','ais','am'] conjuga_er = ['o','es','e','emos','eis','em'] conjuga_ir = ['o','es','e','imos','is','em'] termina_em = verbo[-2:] if termina_em == 'ar': for terminacao in conjuga_ar: conjugado.append(verbo[:-2]+terminacao) elif termina_em == 'er': for terminacao in conjuga_er: conjugado.append(verbo[:-2]+terminacao) 3 http://www.microsoft.com 4 http://windowslicensing.msoem.com/portuguese/3mod_operating.asp#use (este link no est mais ativo, mas seu contedo est armazenado em http://web.archive.org/web/20020906180605/http://windowslicensing.msoem.com/portuguese/3mod_operating.asp)

Pgina 13 de 117

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

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

Verbo "amar" Na linha: if termina_em == 'ar': O programa passa a saber que as terminaes para o verbo "amar" so: conjuga_ar = ['o','as','a','amos','ais','am'] Em: for terminacao in conjuga_ar: conjugado.append(verbo[:-2]+terminacao) O que o programa faz pegar o verbo "amar" sem as duas ltimas letras - verbo[:-2] - e acrescentar a terminao que ele obtm da lista conjuga_ar. O resultado : amo, amas, ama, amamos, amais, amam

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

Pgina 14 de 117

sistemas operacionais proprietrios passaram a se tornar populares. Os sistemas operacionais proprietrios acabavam por prender seus usurios a um conjunto de ferramentas de produtividade e desenvolvimento que tinham que ser obtidas dos prprios fabricantes dos computadores ou de "software-houses" independentes. Em resumo, o software passou a ser vendido quando a margem de lucro no "hardware" (os computadores) diminuiu. A partir do incio dos anos 80, tornou-se comum a venda de computadores com software, cujo preo estava embutido no valor do equipamento. Um usurio leigo, mesmo nos dias de hoje, compra um computador sem saber que uma grande parcela do que paga no relativa ao equipamento, mas sim aos programas que o acompanham. Como o mercado de informtica muito novo, especialmente para o usurio domstico e pequenas empresas que apenas passaram a ter acesso aos computadores na ltima dcada, a lgica de mercado que se imps predominantemente a de que natural "alugar" um software como se aluga um apartamento. No incio dos anos 80, um programador do laboratrio de inteligncia artificial do MIT (Massachussets Institute of Technology), Richard Stallman, iniciou um movimento que busca conscientizar as pessoas de que programas de computadores so uma manifestao do conhecimento humano e, como tal, no podem ser propriedade de ningum. Em 1984 Richard criou a Free Software Foundation e a licena de uso de programas de computador GPL - General Public License. Um programa distribudo sob esta licena pode ser copiado, modificado e redistribudo. Muitos programadores concordaram com as ideias formatadas originalmente por Stallman e hoje existem programas e sistemas bastante complexos desenvolvidos totalmente em software livre. Dentre os mais populares esto o sistema operacional Gnu/Linux e o conjunto de aplicativos para escritrio OpenOffice.Org. Para que um programa possa ser copiado, basta que isto seja legalmente permitido, uma vez que qualquer pessoa que possui um computador dona dos meios de produo6 que permitem que a cpia seja efetuada. O que d o direito legal, ou no, de que o programa seja reproduzido sua licena de uso. As licenas de software proprietrio limitam, ou efetivamente impedem, que o mesmo seja copiado. A cpia de um software proprietrio constitui-se em uma ao ilegal chamada comumente de pirataria, cuja pena inclui multas altssimas e mesmo a priso do infrator7. A licena de um software livre8 garante a seu usurio o direito de copi-lo, assim, no existe pirataria em software livre. Para que um programa possa ser modificado, alm de que isto seja legalmente permitido por sua licena, necessrio que se tenha acesso a seu cdigo-fonte, sua receita. possvel, por exemplo, que meu programa "conjugador de verbos" seja estendido para outros tempos verbais, uma vez que temos acesso "receita" do programa original. Todo o software livre garante acesso a seu cdigofonte 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 10 11 12 13 14 15 16 17 18 http://www.univates.br http://penta.ufrgs.br/liane.html http://www.bewnet.com.br/ http://www.brod.com.br http://www.solis.coop.br Infra-estrutura para a implementao de bases de dados analtico-estatsticas usada no Banco de Dados Regional da Univates - http://www.bdr.univates.br Sistema de gesto de acervo, emprstimos e colaborao para bibliotecas - http://gnuteca.codigolivre.org.br http://www.miolo.org.br Sistema para a educao distncia - http://teleduc.nied.unicamp.br/teleduc/ Sistema para a criao de bases de conhecimento - http://www.rau-tu.unicamp.br

Pgina 19 de 117

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

O Grupo de Usurios Gnurias

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

Pgina 20 de 117

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

Sagu Workshop e SDSL

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

Pgina 21 de 117

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

A Univates como referncia, no como proprietria

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

instituies, como o Teleduc e o Rau-Tu.

Pgina 23 de 117

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

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

A arquitetura inicial do Sagu

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

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

Pgina 25 de 117

Arquitetura Miolo
Com o Sagu j em produo, na segunda metade do ano 2000 iniciamos a produo de um sistema para o Banco de Dados Regional do Vale do Taquari22, hospedado na Univates. Durante o desenvolvimento deste sistema acabamos aproveitando muito do cdigo desenvolvido para o Sagu e comeamos a sistematizar melhor o nosso desenvolvimento. Em 2001 convidamos algumas pessoas externas instituio, como o desenvolvedor Alessandro Binhara, o Prof. Leandro Pompermayer e o consultor Thomas Sprietersbach (que nos ajudou tambm em inmeras outras ocasies) para que tomassem conhecimento do que estvamos desenvolvendo e pudessem contribuir com suas sugestes. O resultado concreto deste workshop interno de transferncia de tecnologia foi o framework de desenvolvimento Miolo, base da nova verso do Sagu e de praticamente todas as solues desenvolvidas pela Univates e posteriormente pela Solis. Durante o desenvolvimento do Miolo tivemos tambm a honra de ter contribuies diretas de Rasmus Lerdorf, criador da linguagem PHP, que trabalhou com nossa equipe, em Lajeado, por cerca de dez dias. As seguintes premissas foram a base para o desenvolvimento do Miolo:

a documentao do sistema deveria ser clara e criada de maneira dinmica, ao mesmo tempo em que o sistema desenvolvido; o framework deveria tratar todas as questes de segurana e perfis de usurios, isolamento e comunicao entre os mdulos desenvolvidos com ele; os mdulos funcionais que compem os sistemas a serem desenvolvidos deveriam refletir a necessidade de negcio que atendem, de tal maneira que, quem os programe, no precise necessariamente conhecer a base de dados; a construo da interface de usurio deveria poder ser feita por um webdesigner, que no necessitasse conhecer a fundo as caractersticas internas do sistema.

Desta forma, conseguiramos dividir melhor as tarefas de desenvolvimento do Sagu e de outros sistemas. Um designer, por exemplo, poderia concentrar-se em criar uma interface agradvel para o usurio, sem ter que conhecer a base de dados. Um administrador de base de dados poderia concentrar-se em aspectos de performance da base, no necessitando conhecer profundamente os programas que a acessam. Assim, a nova arquitetura proposta para o Sagu, com o framework Miolo, passou a ser a seguinte:

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

Pgina 26 de 117

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

Pgina 27 de 117

Gnuteca um teste de conceito para o Miolo

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

Pgina 28 de 117

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

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

Pgina 29 de 117

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

Mas o que a UML afinal?

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

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

Pgina 30 de 117

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

Pgina 31 de 117

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

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

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

Pgina 33 de 117

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

Pgina 34 de 117

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

Pgina 35 de 117

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

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

Pgina 36 de 117

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

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

Pgina 37 de 117

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

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

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

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

Pgina 39 de 117

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

Controles de interface com o usurio, escritos em PHP e renderizados em HTML

35 www.miolo.org.br

Pgina 40 de 117

Autenticao de usurios Controle de permisso de acesso Camada de abstrao para acesso a bancos de dados Camada de persistncia transparente de objetos Gerenciamento de sesses e estado Manuteno de logs Mecanismos de trace e debug Tratamento da pgina como um webform, no modelo event-driven Validao de entrada em formulrios Customizao de layout e temas, usando CSS Gerao de arquivos PDF

Voc no precisa entender o que cada uma destas funes significam, mas caso queira aprofundar-se no framework Miolo, a pgina do projeto oferece um bom tutorial sobre sua utilizao. O fato que, com o uso do Miolo, estimamos uma economia de mais de dois teros no tempo de desenvolvimento e um notvel aumento de qualidade na escrita de cdigo, vinda naturalmente da necessidade de um padro de escrita exigido pelo framework. As figuras abaixo exemplificam o cdigo html necessrio para a exibio de uma tabela e, a seguir, o cdigo para a mesma finalidade utilizando o Miolo: [Joice, j vou te dar um trabalhinho aqui... ao invs de usar as figuras, reescrever este cdigo, pode ser?]

Pgina 41 de 117

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

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

Pgina 42 de 117

Plano Diretor de TI Um modelo

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

O ndice
O ndice j diz bastante coisa sobre o documento. Comento aqui, brevemente, cada um de seus componentes. 0. Histrico de Revises Este item deve ser obrigatrio em todos os documentos que recebem contribuies de vrias pessoas e passam por um processo de reviso e aprovao. Ele conta a histria sucinta da evoluo do documento e deve ser bem simples. Basta uma tabela que conste a alterao do documento, sua pgina, a razo da alterao (incluso, deleo) e o autor desta alterao. Similar ao Resumo (ou Abstract) de um trabalho acadmico, ele deve descrever em um pargrafo a finalidade do documento. No PDTI Univates este item composto pelo captulo Ecologia do Conhecimento, que funciona como um prembulo para o resgate histrico que vem no captulo seguinte. necessrio posicionar o leitor da evoluo at o momento,

1. Resumo

2. Introduo

3. Histrico

Pgina 43 de 117

antes de partir para propostas para o futuro e pedidos de novos investimentos. No PDTI Univates ele o captulo A Informtica na Univates, a evoluo para um Ecossistema, composto de vrias sees. 4. Economia Qual foi a economia obtida com os investimentos em TI? Esta parte especialmente importante para os responsveis pelos investimentos e constitui-se em forte argumento quando da solicitao de novos recursos. Aqui a proposta para o futuro, sempre embasada naquilo que foi desenvolvido at o momento. Quanto mais fundamentados e documentados estiverem os itens anteriores, melhor a possibilidade de aprovao no que proposto neste captulo. Mais um resumo, agora levando em considerao que o leitor (ou o pblico que assistiu a apresentao do documento) esto cientes de toda a informao at aqui exposta. Um documento como este um ser vivo, sempre alimentado por ideias daqueles a quem apresentado. Por isso ele deve, at seu derradeiro momento, contar com a lista de coisas que ainda devem fazer parte dele. Este item pode ser excludo das verses de apresentao e distribuio, mas deve ser mantido parte como guia para futuras verses.

5. Plano Diretor de Tecnologia da Informao PDTI

6. Concluso

Todo List

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

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

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

O conhecimento a capacidade de pessoas e das comunidades de continuamente gerar e renovar, de modo a responder a novos desafios e oportunidades. As pessoas que desenvolvem conhecimentos podem ser inspiradas e apoiadas, mas dificilmente podero ser "gerenciadas" como meras extenses de mquinas, como na Era Industrial. A ecologia do conhecimento um campo interdisciplinar da prtica gerencial que surgiu da confluncia de estratgias de gesto, comunidades de prtica, sistemas adaptativos complexos e gesto do conhecimento. um corpo cada vez maior de conhecimento e prticas que focam na contnua melhoria das relaes, ferramentas e mtodos para criar, integrar, compartilhar, usar e alavancar conhecimento. Maria Alice Capocchi Ribeiro, Msc37

A Informtica na Univates, a evoluo para um Ecossistema

No muito diferente de outras instituies, at 1999 a informtica na Univates era usada de forma no integrada, com poucas estaes de trabalho em rede utilizando aplicativos de escritrio e um sistema administrativo que evoluiu de uma aplicao em Cobol para um ambiente baseado na plataforma MS-Access. Este ambiente, em 1999, serviu de base para a migrao para o SAGU (Sistema Aberto de Gesto Unificada), que usado at hoje na instituio.
37 http://www.rh.com.br/ler.php?cod=3762&org=2

Pgina 45 de 117

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

Pgina 46 de 117

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

Figura 2 Evoluo do acesso Internet

Pgina 47 de 117

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

Acompanhamento de chamados tcnicos

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

Pgina 48 de 117

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

Figura 4 Evoluo do atendimento dos chamados tcnicos Ainda que tenhamos conseguido manter um nmero de usurios crescente em relao ao nmero de analistas, o grfico acima mostra que, mesmo com aes de manuteno preditiva, h uma tendncia ao crescimento dos chamados no atendidos ao final de cada ms (a partir de maro de 2004), o que mostra que o nmero de analistas est subdimensionado. Nota: Repare que os dados factuais, comprovados, j servem de argumento para a solicitao de um aumento da equipe.

Software livre na Academia

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

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

Escola Aberta e o grupo Gnurias Graas ao grupo Gnurias vrias crianas que ficavam em casa sem ter o que fazer, agora esto tendo a oportunidade de aprender a lidar com o COMPUTADOR, ter uma noo do que um COMPUTADOR, porque hoje em dia a TECNOLOGIA est muito avanada, cada dia esto sendo criadas coisas novas, como por exemplo: computadores cada vez mais potentes com a capacidade de criar, fazer, inventar e descobrir coisas novas, coisas que os nossos antepassados nunca imaginacem (sic) que poderiam ser inventadas! Para algumas crianas,apenas tocar em um computador j maravilhoso. Neste projeto ESCOLA ABERTA, ns crianas estamos tendo a oportunidade, de mostrar o talento que temos em todas oficinas. Estamos aprendendo muito. Eu, j sabia lidar com um computador, mas resolvi me aprofundar mais, aprender mais! Eu no poderia deixar de agradecer ao GRUPO GNURIAS tudo o que estou aprendendo a mais, mas no agradecer s por mim, mas por todos que esto tendo esta oportunidade! A vocs o MEU MUITO OBRIGADO! Vanessa Helena Barbon Corbelini 12 anos, 6 srie (texto copiado e colado do original digitado pela Vanessa em uma oficina na Univates)

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

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

Software Livre na bagagem

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

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

Na Austrlia pude aprimorar meus conhecimentos em outra lngua (ingls). Em todas as viagens conheci diversas pessoas importantes, com as quais troquei idias e, nesta troca, sempre se aprende algo. Certamente me tornei mais independente: na Austrlia tive que me virar sozinha... e foi bastante difcil esta sensao. Ainda na viagem de ida para a Austrlia, eu chorava de saudade, medo e preocupao. Afinal, era a minha primeira viagem internacional. Uma mulher sentada ao meu lado, colocou a mo no meu ombro e no falou nada, s sorriu como quem diz: "Vai passar" e ficou encantada que na minha idade eu j estava indo sozinha para um lugar to distante e para falar sobre um trabalho to legal. Eu ia apresentar os projetos das Gnurias com o uso do Software Livre no ensino fundamental e mdio. A mulher era parapelgica e estava indo para o Uruguai, fazer um tratamento para tentar voltar a caminhar. Na hora, dei-me conta que eu estava chorando por problemas to pequenos perto do dela, que estava muito confiante. Na juventude, ela tinha lutado pela causa feminista e se identificou com o nosso trabalho. Ela me disse que, uma viagem destas, na minha idade, equivalia a uma Universidade inteira. Concordo com ela. As viagens e a participao em eventos me ajudaram principalmente na questo de falar em pblico. Cada vez mais os medos vo sumindo... Joice Kfer

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

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

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

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

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

O que Ecossistema?

Pgina 53 de 117

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

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

Economia
Ainda que no seja o aspecto mais importante para a adoo de uma ou outra tecnologia, h que se convir que recursos limitados para investimentos exigem a constante necessidade de se trabalhar com solues criativas e com o menor custo possvel. A adoo do software livre, especialmente na administrao da Univates, permitiu que adaptssemos e desenvolvssemos solues com domnio da tecnologia, alm da imediata economia em funo de no haver a necessidade de se pagar por licenas de uso. A seguir, o documento elaborado para a Univates apresenta o levantamento de todo o parque instalado e a economia feita ao no se utilizar softwares proprietrios. A tabela abaixo apresenta um exemplo do que pode ser feito, com os nmeros omitidos, j que os mesmo podem variar bastante. Para a economia vinda do uso do Sagu, Gnuteca, Teleduc, Agata Report e outros foram consideradas, na poca, as opes equivalentes mais baratas, mesmo que no atendessem a totalidade das necessidades da Univates.

Sumrio da Economia em Licenas

Pgina 54 de 117

Descrio n desktops rodando exclusivamente softwares livres m desktops com Sistema Operacional proprietrio e OpenOffice Sobrevida de x computadores que seriam obsoletos com software proprietrio Uso de software livre nos servidores Uso de bases de dados livres No necessidade de licenas de acesso s bases de dados Uso do Sagu Uso do Gnuteca Uso do Teleduc Uso do Agata Report Uso de estrutura em software livre para correio eletrnico Total

Total Economizado

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

Aproveitamento de cdigo e colaboraes

Mais difcil de mensurar a economia indireta obtida a partir da prpria cultura de aproveitamento de cdigo e colaborao que existe na comunidade de software livre. Com softwares proprietrios, como ns mesmos temos o exemplo a partir de nosso ERP, ficamos na maior parte do tempo merc de implementaes ou solues vindas de um fornecedor nico (ainda que, at neste caso, tenhamos buscado alternativas). No quadro abaixo, ilustramos os principais cdigos alheios que utilizamos na construo dos nossos sistemas, assim como colaboraes que recebemos. Cdigo da Comunidade PEAR O que faz Onde foi utilizado Estimativa de economia de tempo (um desenvolvedor) 2 meses

Camada de abstrao

Agata Report39

Pgina 55 de 117

Cdigo da Comunidade

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor)

de base de dados, permitindo a conexo com diferentes sistemas de bases de dados JPGraph Biblioteca e aplicativos Agata Report, Scotty40, para a criao dinmica GnuData41, Fred42 de Grficos Gera documentos no formato OpenOffice (XML) dinamicamente Gera documentos no formato PDF dinamicamente Autenticao OpenLdap diretamente atravs do PHP Editor grfico em JavaScript para a autoria web Gesto de contedo web Agata Report 6 meses

PHPDocWriter

12 meses

FPDF

Agata Report

6 meses

Yala

Internet, solicitao de conta de e-Mail Fred

ms

HTMLArea

2 meses

phpNuke

Os temas (visual) do PhpNuke foram utilizados ou usados como base em vrios ambientes web Fred

1 ms

Phpopenchat

Salas de bate-papo para a web (no liberado para uso geral por limitao de recursos) Aproveitado o cdigo para nosso WebMail Estrutura que permite

1 ms

WebMiau Gettext

Fred Todos

3 meses -

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

Pgina 56 de 117

Cdigo da Comunidade

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor)

que nossos sistemas sejam traduzidos em outras lnguas ImageMagik Redimensionamento dinmico de imagens para a exibio nos portais web Algoritmos, formatao e exemplo de cdigo Ferramenta para a gerao de textos em mltiplos formatos Classe para exibir diferenas entre verses de um mesmo texto Fred 3 meses

Twiki DocBook

MioloWiki43 MioloWiki

1 ms 6 meses

Diff

MioloWiki

1 ms

Total aproximado

44 meses

Colaboraes da Comunidade(diretame nte em nossos produtos)

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor, considerado apenas o tempo que serviu diretamente Univates)44 1 ms

Bruno Depero (Itlia)

Testes e melhorias na conexo com bases de dados distintas, traduo para o italiano Uso de mltiplas buscas secundrias (subqueries) e melhorias no cdigo

Agata Report

Jeffrey Buchbinder (Frana)

Agata Report

ms

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

Pgina 57 de 117

Colaboraes da Comunidade(diretame nte em nossos produtos)

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor, considerado apenas o tempo que serviu diretamente Univates)

fonte usado na mesclagem de documentos (merge) Thomas Sprietersbach (Alemanha, Brasil) Luciano Stein (Brasil) Melhoras no sistema de traduo e traduo para o alemo Implementaes de funcionalidades para a conexo com bases SQL Server e Oracle e testes com o Windows Traduo para o Sueco Melhorias na gerao de documentos PostScript Agata Report ms

Agata Report

1 ms

Johannes Schill (Frana) Brad McCrorey

Agata Report Agata Report

ms

Christian Etuy (Frana) Traduo para o Francs Tarique Nagpur e Girish Nair (ndia) Steph Fox (Estados Unidos) Frank Krommann (Estados Unidos) Andrew M. Yochum Verso para o MySQL e testes Auxlio com o PhpGtk e com a traduo para o ingls Ajuda na conexo com a base de dados FrontBase Ajuda na conexo com a base de dados Sybase

Agata Report Agata Report Agata Report

ms 1 ms

Agata Report

Agata Report Agata Report Agata Report

ms

Flavio Jose Fonseca de Ajuda na conexo com Souza (Brasil) a base de dados mssql Brice Vissiere (Brasil) Soluo de problema na quebra de coluna

Pgina 58 de 117

Colaboraes da Comunidade(diretame nte em nossos produtos)

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor, considerado apenas o tempo que serviu diretamente Univates) -

Eduardo Fernandes (Brasil) Tomas Cox (Brasil) Lucas Di Pentima (Espanha) Yannick Warnier Unicamp (vrios)

Ajuda na conexo com a base de dados SQL Server Auxlio com o uso do PEAR DB Traduo para o Espanhol Documentao e correo de erros Modelagem da base de dados do sistema de ramais telefnicos e inscries em eventos via web Vrias contribuies na criao da PsLib Converso de nossa biblioteca psLib para classes em PHP, o que permitiu seu uso em mais programas Alinhamento de texto e suporte a documentos colorido Adio de novas funcionalidades, soluo de problemas diversos, verso na linguagem C e criao de extenses para outras linguagens

Agata Report

Agata Report Agata Report Tulip45 Fred

ms ms 1 ms

Uwe Steinman(Alemanha) Ericson C. Smith (Estados Unidos)

PsLib46 PsLib

1 ms ms

Jay Haugen (Alemanha) Joel Leon (Estados Unidos) Jos Paulo B. da Silva e outros

PsLib

ms

PsLib

2 meses

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 Comunidade(diretame nte em nossos produtos)

O que faz

Onde foi utilizado

Estimativa de economia de tempo (um desenvolvedor, considerado apenas o tempo que serviu diretamente Univates)

(Python, TCL e Perl) Rudinei Pereira Dias, Unilassale Ely Matos48, UFJF Gerao de cdigo de barras Mltiplas contribuies na rea de segurana, orientao a objetos e melhorias diversas Miolo47 Miolo ms 6 meses

Total aproximado

16 meses

47 O Miolo (www.miolo.org.br) o ambiente de desenvolvimento de praticamente todos os programas desenvolvidos pela Univates/Solis 48 O Ely Matos o desenvolvedor externo mais ativo para o framework Miolo.

Pgina 60 de 117

Desenvolvimento pago por outras instituies

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

Plano Diretor de Tecnologia da Informao PDTI

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

Pgina 61 de 117

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

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

Comit de Tecnologia da Informao

Com a idia de melhorar o processo de tomada de deciso na disponibilizao e planejamento futuro de recursos e sistemas de informtica, sugerimos a criao de um Comit de TI, presidido pelo Consultor de Tecnologia e formado por representantes de usurios de nosso ambiente de rede e sistemas, de tomadores de deciso (reitoria), dos principais fornecedores de servios, dos corpos docente e discente. Inicialmente este comit ter reunies mensais onde sero apresentados os projetos em andamento, necessidades, limites de recursos, prioridades, e discutidas formas de atender a todos atravs de melhores prticas e acordos. O formato destas reunies e o encaminhamento dos assuntos nelas tratados deve ser feito no mesmo formato j utilizado nas reunies de gesto da qualidade. Quem Consultor de Tecnologia Resumo das Atribuies Preside o Comit e com base em suas deliberaes administra o oramento destinado TI. Administra conflitos e tem o voto de Minerva nos casos de impasse. Atua como secretrio do Comit, redigindo a ata das reunies e 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

Coordenador do CPD Univates

Quem

Resumo das Atribuies modelagem de sistemas.

Representante da Reitoria

Faz com que as discusses e deliberaes do Comit estejam alinhadas ao Plano Estratgico da Univates, e leva reitoria questes do comit e a realimentao para o Plano Estratgico.

Representantes dos grupos Traz ao grupo necessidades especficas relativas aos vrios sistemas de usurios de sistemas disponibilizados na Univates (Sagu, Gnuteca, gata, Portais, e internos outros) e auxilia na priorizao de novos desenvolvimentos. Recomenda-se aqui que os grupos de usurios busquem ter suas reunies em separado, com os tcnicos responsveis pelos sistemas, para que a discusso no Comit seja sempre mais estratgica do que operacional. Representante do corpo docente Aponta necessidades de uso e desenvolvimento de TI necessrios rea acadmica, e busca aliar oportunidades de desenvolvimento busca de conhecimentos que podem ser aproveitados na experincia educacional, em projetos de pesquisa (especialmente as que podem obter financiamento externo) e no envolvimento de alunos atravs de estgios e bolsas. Traz ao grupo os interesses dos alunos, tanto como usurios dos servios oferecidos como na busca de oportunidades de envolvimento atravs de estgios e bolsas. (DCE) Acompanha a evoluo de necessidades de investimentos e servios em infra-estrutura e traz informaes sobre novas construes e instalaes que podem influenciar a estrutura de TI, ou depender dela.

Representante do corpo discente Representante do setor de apoio Representante da rea de infraestrutura de telecomunicaes Convidados especiais Representante de fornecedores

Convidados pelo Comit sempre que um determinado assunto ou conhecimento pode se beneficiar de ajuda externa. Convidados pelo Comit a participar de reunies ou parte delas, respondendo e orientando em questes especficas aos produtos e servios fornecidos.

Comit Interinstitucional de Tecnologia da Informao

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

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

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

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

Pgina 64 de 117

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

Planejamento de Capacidade Equipamentos

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

autenticao, Teleduc) e a criao de uma estrutura de replicao mnima de ambiente para a rpida retomada de servios em caso de pane generalizada e o aumento da autonomia no uso de energia eltrica com a aquisio de um grupo gerador (especialmente levando em conta que j sofremos por causa disto em momentos como matrcula de calouros). Nota: A seguir, o documento oficial apresenta uma srie de dados sobre o crescimento estimado da instituio nos prximos anos e, com base na capacidade atual, prope a aquisio ordenada de equipamentos para os prximos trs anos. Estes dados foram omitidos aqui por questes de confidencialidade. H que se levar em conta ainda, especialmente com constante diminuio do custo dos computadores e do acesso Internet, com sua crescente popularizao, que observaremos nos prximos anos uma utilizao maior dos servios que oferecemos de forma remota. de se esperar tambm que mais alunos venham instituio com equipamentos que tenham capacidade de conexo rede sem fio (pdas e notebooks wireless), e isto deve at ser incentivado. O prprio contedo multimdia oferecido nos cursos distncia, e que passa a ser gerado por nossos cursos na rea de comunicao ir trazer impactos para a nossa estrutura de rede e servidores. Ainda neste ano estaremos testando vdeo-conferncias atravs da web, e isto deve gerar um trfego adicional que necessita ser medido e avaliado. Novos servios desejados podem entrar em calendrio de testes e implementao, com seu consumo de capacidade agora devidamente medido, e novos investimentos avaliados e planejados de acordo pelo Comit de TI. Dentre os novos servios desejados esto (sem se limitar a eles):

Servidor de DataWarehousing para a extrao de relatrios a partir de espelhos das bases de sistemas de produo, minimizando o impacto a eles; Sistema de autenticao e acesso para PDAs para a disponibilizao de servios web como o controle de presenas e notas tambm para PDAs sem fio (e posterior expanso para um controle automtico de ponto e freqncia com smartcards ou identificao rdio-identificada; Expanso da oferta de contedo multimdia via web em todas as salas (especialmente vdeo-conferncia); Sala dedicada vdeo-conferncia Sistema de digitalizao, arquivo e busca de documentos (facsmile digital)

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

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

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

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

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

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

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

Pgina 69 de 117

O portal Cdigo Livre

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

O cdigo que produzamos era liberado logo de incio e sempre. De fato, o controle de verses ficava aberto viso de todos. Com isto, nosso desenvolvimento estava sempre aberto crticas e sugestes, que vinham das mais variadas formas. Olhos suficientes e problemas tona. Um verdadeiro incentivo a uma limpeza constante do cdigo.

Uma coisa interessante que passou a acontecer foi que, cada vez mais, nossa equipe recebia solicitaes de servios e suporte daqueles que comeavam a experimentar nossos sistemas, em especial o Sagu e o Gnuteca. Isto nos obrigou a pensar em uma forma melhor de estruturar estes servios e esta foi, em grande parte, a origem da Solis.

Pgina 70 de 117

Cooperativismo e Software Livre Um modelo de negcios

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

Pgina 71 de 117

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

Pgina 72 de 117

Trs anos de Microsoft

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

Pgina 73 de 117

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

Pgina 74 de 117

Engenharia de Software para Software Livre

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

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

O envolvimento de empresas de tecnologia renomadas como a Sun e a IBM, respectivamente nos projetos OpenOffice.Org e Apache, que esto entre os discutidos neste artigo, tambm aproximou tcnicas e processos tradicionais de Engenharia de Software a projetos de software livre e aberto.

Software aberto e software livre

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

Fundao considera os softwares como um produto cientfico e cultural que deve estar disponvel para todos. Com esta filosofia, a FSF propiciou um entorno de desenvolvimento comunitrio, incentivando a produo de programas alternativos aos comerciais que estavam disponveis e protegendo-os legalmente atravs de licenas como a GPL (General Public License), que, segundo WILLIAMS (2002), garante aos usurios destes programas quatro liberdades: A liberdade de executar o programa para qualquer propsito; A liberdade de estudar como o programa funciona e adapt-lo s suas necessidades. Acesso ao cdigo-fonte um pr-requisito para esta liberdade; A liberdade de redistribuir cpias, permitindo a ajuda ao prximo; A liberdade de aperfeioar o programa e liberar estes aperfeioamentos, de modo que toda a comunidade se beneficie. Acesso ao cdigo-fonte um pr-requisito para esta liberdade. No final dos anos 90, empresas de tecnologia de ponta, especialmente do Vale do Silcio na Califrnia, comearam a utilizar de uma forma mais ampla softwares livres na criao de seus produtos. Esta foi a poca do estouro comercial das distribuies Linux (pacotes que incluam o ncleo do sistema operacional e uma srie de aplicativos que podiam substituir sistemas comerciais existentes), quando vrias empresas abriram seu capital e passaram a atuar de forma mais agressiva no mercado.

Software livre a traduo do termo, em ingls, free software. A palavra free, entretanto, na lngua inglesa tem dois significados. Richard Stallmann (WILLIAMS op. cit.) distingue-os com os exemplos free as in free beer (free como em cerveja de graa) e free as in freedom (free como em liberdade). Assim software livre diz respeito liberdade e no gratuidade. Em funo da dualidade da palavra free, Eric Raymond passou a liderar a defesa do uso do termo open source software (software de cdigo aberto). Este termo tambm era benfico s empresas que comeavam a utilizar software livre mas tinham receio de seu cunho ideolgico. At hoje o debate entre o uso dos termos open source software ou free software continua. Para o escopo deste trabalho considera-se indistintamente os termos software livre e aberto, levando-se em conta que os projetos aqui considerados tm seu cdigo fonte aberto e o mesmo disponibilizado de forma livre.

Modelos de desenvolvimento de software: a Catedral e o Bazar

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

Pgina 76 de 117

Figura 1 Estilos de desenvolvimento Catedral e Bazar (FABERLUDENS) No lado esquerdo da ilustrao est o modelo Catedral onde uma equipe de desenvolvedores entrega um programa compilado, ou seja, sem disponibilizar o seu cdigo fonte, aos usurios. A indisponibilidade do cdigo fonte impede a colaborao externa equipe. direita est o modelo Bazar, no qual notam-se imediatamente duas diferenas fundamentais: o cdigo fonte disponibilizado para que outros desenvolvedores (hackers) possam conhec-lo e modific-lo; h um processo de realimentao do qual tanto os desenvolvedores quanto os usurios participam (atravs de listas ou fruns de discusso, ambientes colaborativos e outros), contribuindo para a melhoria contnua do programa desenvolvido. A popularizao do Linux e de outros softwares livres acabou por mostrar o poder do modelo Bazar e muitas empresas passaram a utiliz-lo em maior ou menor grau. Alguns produtos de software migraram do controle de empresas de tecnologia para comunidades de desenvolvimento. Dois exemplos bastante significativos so o navegador web Firefox, originado do Netscape que pertencia empresa AOL, e o conjunto de aplicaes para escritrio OpenOffice, que resultou da abertura do cdigo do StarOffice pela Sun Microsystems.

O contrrio tambm acontece. Produtos originados de comunidades de desenvolvimento tm hoje papel importante dentro de grandes empresas. O servidor web da IBM tem por base o software livre Apache e o Google grande usurio e contribuidor de projetos livres como a linguagem Python. A necessidade de um controle das contribuies recebidas e a utilizao de software livre de forma crescente em um ambiente profissional e empresarial levou as comunidades de desenvolvimento utilizao de uma srie de prticas de organizao e controle, visando garantir a qualidade dos produtos desenvolvidos. Na prxima Seo sero abordadas algumas prticas adotadas por comunidade de desenvolvimento elencadas neste artigo.

Processo de desenvolvimento de software livre

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

estilo comercial de desenvolvimento de software: sistemas abertos so construdos por potencialmente centenas ou milhares de voluntrios, ainda que alguns destes "voluntrios" tenham seu trabalho patrocinado por suas empresas; o trabalho no designado, os desenvolvedores escolhem as tarefas que querem executar; no h um projeto detalhado do sistema; no h um plano de projeto, cronograma ou lista de entregas. Com o amadurecimento da utilizao e do desenvolvimento de softwares livres tambm em ambientes comerciais, porm, possvel encontrar um melhor detalhamento de projetos, incluindo sua especificao, documentao, cronogramas e listas de entregas.

O desenvolvimento de software livre, em sua maioria, se d em comunidades de desenvolvedores e usurios. Alguns projetos, porm, tm empresas como suas mantenedoras, com maior ou menor envolvimento da comunidade. O projeto MySQL53, por exemplo, tem como sua principal mantenedora, hoje, a Sun Microsystems, com forte envolvimento da comunidade. A brasileira Solis54, uma cooperativa de desenvolvimento e integrao de softwares livres, possui uma srie de produtos que, por sua especificidade, mesmo distribudos sob licenas no restritivas, no agregam uma grande comunidade de desenvolvimento em seu entorno. Nas Sees seguintes sero abordadas as prticas e ferramentas utilizadas em algumas comunidades de desenvolvimento de software livre.

Prticas das comunidades de desenvolvimento de SL

Com o objetivo de verificar as prticas utilizadas em projetos de naturezas diversas, mas todos desenvolvidos em software livre, foi feita uma anlise sucinta baseada na documentao disponvel nos prprios portais web das comunidades e, sempre que possvel, em trabalhos de outros autores. As comunidades elencadas foram as seguintes:

kernel Linux; servidor web Apache; linguagem de programao Python; sistema gerenciador de banco de dados PostgreSQL; framework de desenvolvimento Ruby on Rails; gestor de contedo web Drupal; conjunto de aplicativos de produtividade para escritrio OpenOffice.Org.

Linux

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

O tempo mostrou que o desenvolvimento, estilo Bazar (RAYMOND op. cit.), do Linux foi capaz de aglomerar um grande nmero de desenvolvedores, usurios e mesmo empresas que exploram comercialmente o sistema.
53 http://www.mysql.com 54 http://www.solis.coop.br

Pgina 78 de 117

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

Figura 2 - Origens do Linux (TUOMI, 2000) De fato, a grande maioria dos projetos em software livre tem sua origem em projetos anteriores, de maneira direta ou indireta, sendo possvel observar elementos destes ancestrais no novo projeto. O desenvolvimento do Linux ainda fortemente baseado em listas de discusses, mantidas inicialmente no Usenet55. Elas foram e ainda so a base do desenvolvimento do Minix, do Gnu e, por sua vez, derivaram dos RFCs (Request for Comments Pedidos de Comentrios), documentos que formaram a base de toda a estrutura da Internet. O modelo de desenvolvimento do Linux foi herdado da cultura do Unix, na qual existe um conjunto de ferramentas, que podem ser facilmente reutilizadas e combinadas como componentes de novas ferramentas. O anncio do Linux na lista de discusses deu incio a uma comunidade virtual que, em sua grande parte, no tinha interaes sociais diretas e confiava totalmente na Internet como a base de suas ferramentas de desenvolvimento. Com o nmero de contribuies e registros de problemas, vindos de todas as partes do mundo, era claro que um controle maior sobre isto era necessrio. No incio dos anos 90 ferramentas como JitterBug e CVS eram usadas, respectivamente, para o registro de problemas e o controle de verses. Mais recentemente elas foram substitudas pelo BugZilla56 e o Git57. Outra ferramenta adicional o PatchWork58, usado para o controle de contribuies oferecidas pela comunidade de desenvolvedores e administradas por cada um dos mantenedores dos vrios mdulos do kernel Linux que tm o direito de colocar o cdigo diretamente no sistema de controle de verses. A distribuio do kernel Linux inclui dois arquivos que informam sobre os mantenedores dos vrios mdulos (MAINTAINERS) e sobre os autores das vrias contribuies recebidas (CREDITS) (LEE, COLE, 2003). Estes arquivos mostram a hierarquia do desenvolvimento do Linux. A rigor, qualquer pessoa pode contribuir para o cdigo do Linux, mas ele precisa passar pelo crivo e aprovao do mantenedor do mdulo em questo e, posteriormente, ser includo no ramo estvel da distribuio (depois de passar pelos estgios de desenvolvimento).
55 56 57 58 Usenet (do ingls Unix User Network) um sistema de discusses distribudo disponvel na Internet. http://www.bugzilla.org/ http://git.kernel.org 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 60 61 62 63 http://httpd.apache.org http://hoohoo.ncsa.illinois.edu/ http://httpd.apache.org/dev/styleguide.html http://wiki.apache.org/httpd/ 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 65 66 67 68 http://www.python.org/dev/intro/ http://roundup.sourceforge.net/ http://subversion.tigris.org/ http://www.postgresql.org/ 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 70 71 72 73 74 75 Em12/05/2009, http://www.postgresql.org/community/contributors/ http://wiki.postgresql.org/wiki/Development_information http://pgfoundry.org/ http://gforge.org/ http://www.nongnu.org/cvs/ http://rubyonrails.org 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 tornouse 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 77 78 79 80 81 https://rails.lighthouseapp.com http://wiki.rubyonrails.org/ http://planetrubyonrails.com/ http://search.twitter.com/search?q=rails http://drupal.org http://api.drupal.org/api/file/developer/topics/oop.html/6

Pgina 83 de 117

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

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

A Engenharia de Software e o Software Livre

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

Para entender melhor quais prticas de Engenharia de Software esto evidenciadas no desenvolvimento de SL, a Figura 3 resume a cadeia de valor formada pelas comunidades, prticas executadas e ferramental de apoio que resultam em projetos de SL.
82 http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt em maio de 2009 83 http://wiki.services.openoffice.org

Pgina 84 de 117

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

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

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

Figura 3 - Corrente de valor para produo de projetos de SL (VIA DIGITAL) Projeto Kernel Linux Apache Python PostgreSQL Ruby on Rails Ferramenta Git Subversion Subversion CVS Git Pgina 85 de 117

Drupal OpenOffice

CVS e Git CVS Tabela 1 Ferramentas de Gerncia de Configurao

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

Apache

Python

PostgreSQL

Ruby on Rails Drupal OpenOffice

Pgina 86 de 117

IssueTracker Tabela 2 Ferramentas de Coordenao

Gerncia de Evoluo e Manuteno

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

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

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

Teste e Garantia da Qualidade

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

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

Prticas de desenvolvimento gil

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

Alm disto, algumas fases e prticas do Extreme Programming, por exemplo, podem ser aplicadas diretamente s comunidades de SL:

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

Padres de Projeto (Design Patterns)

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

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

Pgina 89 de 117

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

Mais adiante, o prprio Fred conclui:

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

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

Pgina 90 de 117

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

Pgina 91 de 117

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

A ordem nascida do Caos

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

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

Pgina 92 de 117

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

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

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

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

O que voc fez ontem?

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

Pgina 95 de 117

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

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

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

mas no pode ser destrutivo. Ele sempre deve detectar o que o usurio j possui e apenas oferecer novas ferramentas a serem agregadas. Ao classificar um projeto, seu criador pode escolher categorias s quais o mesmo pertence, mas um administrador do portal pode "recategorizar" o projeto de forma a garantir sua correta exposio na busca por categorias e mesmo para "alinhar" projetos de natureza similar, buscando a interao entre eles. Projetos hospedados em outros stios podem ser categorizados tambm aqui, servindo este portal, ento, como um apontador para outros repositrios como o SourceForge, Incubadora Virtual da Fapesp, Savanah e outros. No caso do CodigoLivre, porm, isto ser feito de forma automtica, garantindo j a exposio de todo o volume de projetos do CodigoLivre no portal bero-americano. 2. Notcias: As notcias podem ser relativas aos projetos, de responsabilidade dos desenvolvedores e publicadas com destaque na pgina principal (de todos os projetos), na pgina do projeto (apenas as relativas a ele) e devem poder ser exportadas para outros stios em formatos como o RSS. Notcias postadas pela comunidade ibero-americana tambm sero aceitas de vrias formas, com nveis de mediao. Notcias postadas anonimamente sempre passaro pelo crivo do gerente de contedo. Notcias postadas por usurios registrados tero prioridade, mas tambm passaro pelo crivo de um gerente de contedo. O gerente de contedo pode autorizar alguns usurios a postarem notcias no portal sem a necessidade de mediao. Notcias que vm de outros portais podem ser includas neste atravs de mecanismos como RSS. 3. Multi-idiomas: Inicialmente, todo o portal ter sua interface em portugus e espanhol. Os contedos podem ser disponibilizados em apenas uma lngua, havendo neste caso, quando da exibio do contedo em uma lngua para o qual no foi traduzido, a opo para que o leitor ou colaborador "envie uma traduo". Por exemplo, um projeto com desenvolvedores brasileiros ir postar suas notcias e demais informaes em portugus. Quando algum de lngua espanhola acessar uma informao no traduzida, a ler na lngua original, mas ter a possibilidade de colaborar com uma traduo. Isto pode ser expandido para outros idiomas. 4. Gesto do ambiente e estrutura de suporte: Este portal visa ser referncia e ponto de integrao no desenvolvimentos de software livre para a comunidade bero-americana. Alm da ao prtica de hospedagem de projetos (ou apontadores para outros portais), ele ser a base de uma ao de integrao e busca de recursos para desenvolvimentos que estejam ligados gerao de emprego e renda, incluso social e resoluo de conflitos. Desta forma, a fim de que o portal atinja o sucesso em suas metas, propomos a montagem de uma estrutura que pode ser ampliada medida em que seu uso se intensifique: Comit Gestor Formado por membros da comunidade, mediante indicao dos financiadores deste portal e com vagas abertas para a eleio democrtica de outros membros da comunidade beroamericana.

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 comitgestor e a equipe de suporte). 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

Ideias para o Cronograma de implantao

Numa estimativa inicial, cheguei a oito semanas de desenvolvimento para as fases 0 a 3, com o envolvimento semi-integral de um gestor e o uso de pessoas contratadas para a escrita de cdigo. Com estes dados, chegamos a um Product Backlog, exemplificado abaixo:

Brod Tecnologia - Product Backlog

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

Quem CB CB CB CB CB TBD Devel1 Devel2 Devel3

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: Sprint: Perodo: Portal bero-Americano de Colaborao e Desenvolvimento Tecnolgico Captao de recursos 30 dias a partir de 04/12/06 Esta a data Preencha limite para a esta coluna A data em entrega da com a data que a tarefa, e deve em que a soluo foi ser menor que tarefa foi entregue a do final submetida deste sprint Data de entrada Data de soluo

Para cada linha de tarefas, o total de horas gastas naquela tarefa especfica dentro da semana especificada na coluna

Total de horas do ms

Quem

Descrio

Data Limite

Semana 1 Semana 2 Semana 3 Semana 4

Total de horas 160

Total de horas utilizadas na semana (Preencha para cada semana o total de horas utilizados na execuo das tarefas) CB Desenvolvimento de Material para a Apresentao

60

40

40

20

4/12/2006

8/12/2006

8/12/2006

40

FI CB/JK

Contato com clientes e agenda de reunies 4/12/2006 Apresentao aos clientes 11/12/2006

8/12/2006

8/12/2006

20 40 40 20

22/12/2006 26/12/2006

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 implementlo 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, melhorandoa 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 0 1 2 3 4 Horas Restantes 160 110 55 15 0 Horas Estimadas 160 100 60 20 0

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

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

Burndown Chart
180 160 140 120

Horas

100 80 60 40 20 0 0 1 2 3 4

Horas Restantes Horas Estimadas

Semanas

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

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

User Stories
Scrates: Homero no diz muitas vezes e muito sobre as tcnicas? Por exemplo, sobre a tcnica do auriga se me recordares o verso, eu te direi. on: Mas eu recitarei pois eu me recordo. Scrates: Dize-me, ento, o que diz Nestor ao seu filho Antloco, quando o aconselha ficar atento a respeito da

Pgina 101 de 117

baliza, na corrida de cavalos em honra a Ptroclo. on: Inclina-te, diz , no carro bem polido docemente para a esquerda dos dois: o cavalo da direita estimula com a voz, cede-lhe as rdeas com as mos. Na meta, certo, o cavalo da esquerda se lance, a fim de que o cubo da roda bem feito parea tocar a meta: mas evita tocar na pedra. Scrates: Basta! Esses versos picos, on, se Homero diz corretamente ou no, quem conheceria melhor, um mdico ou um auriga? on: Um auriga certamente. Scrates: E porque ele possui essa tcnica ou por algum outro motivo qualquer? on: No, mas porque ele possui essa tcnica. Scrates: Ento a cada uma das tcnicas foi dada por Deus uma funo de ser capaz de conhecer? Pois no conhecemos pela tcnica do piloto o que conheceremos pela tcnica mdica. on: No, certamente. Scrates: E nem conhecemos com a tcnica mdica essas tambm que conheceremos na arquitetura. on: No, certamente. Scrates: Portanto assim tambm segundo todas as tcnicas, aquilo que conhecemos atravs de uma tcnica, no conheceremos atravs de outra? Mas, responda-me isso primeiro: afirmas que as tcnicas diferem umas das outras? on: Sim. Scrates: Ah, assim como eu estou conjecturando, quando uma cincia trata de umas coisas e outra trata de outras, assim eu chamo uma tcnica de uma maneira, a outra de outra; e tu tambm fazes o mesmo? on: Sim. Scrates: Se houvesse uma cincia das mesmas coisas, por que haveramos de dizer de uma maneira diferente da outra, cada vez seria possvel saber as mesmas coisas atravs de ambas? Por exemplo: eu conheo que esses dedos so cinco, tu tambm sabes, e, como eu, tu conheces as mesmas coisas a respeito deles. E se eu te perguntasse se pela mesma tcnica que ns conhecemos isso, isto , pela aritmtica que eu e tu conhecemos as mesmas coisas ou por outra tcnica, tu dirias certamente que pela mesma. on: Sim. Scrates: Dize-me agora, ento, o que a pouco eu estava a ponto de te perguntar: se te parece que ocorre assim em todas as tcnicas, isto , que conhecemos uma mesma coisa necessariamente com uma tcnica, porm nunca essa mesma coisa por outra tcnica; uma vez que se trate de uma tcnica diferente, necessrio que seja outro o objeto do seu conhecimento.

Pgina 102 de 117

on: Assim me parece, Scrates. Scrates: Portanto, aquele que no possui uma tcnica no ser capaz de conhecer bem nem o que se diz nem o que se faz dessa tcnica? on: Dizes a verdade.

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

Pgina 103 de 117

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

Quando a cafeteira no est em uso, ela fica aguardando a seleo do usurio. H seis diferentes possibilidades de seleo: 1) Adiciona uma Receita; 2) Apaga uma Receita; 3) Edita uma Receita; 4) Adiciona Itens ao Estoque; 5) Verifica o Estoque; e 6) Adquire uma Bebida. Ttulo: Adiciona uma Receita Teste de Aceite: adicionaReceita1 Prioridade: 1 Story Points: 2

Apenas trs receitas podem ser adicionadas cafeteira. Uma receita consiste de um nome, preo, doses de caf, doses de acar e doses de chocolate. Cada nome de receita deve ser nico na Lista de Receitas. O preo deve ser tratado como um nmero inteiro. Uma mensagem de estado exibida para mostrar se a receita foi adicionada com sucesso, ou no. Ao final, a cafeteira retorna a seu estado de espera. Ttulo: Apaga uma Receita Teste de Aceite: apagaReceita1 Prioridade: 2 Story Points: 1 Uma receita pode ser apagada da cafeteira se ela existir na sua Lista de Receitas. As receitas so listadas por ordem de nome. Ao final, uma mensagem de estado exibida e a cafeteira retorna a seu estado de espera. Ttulo: Edita uma Receita Teste de Aceite: editaReceita1 Prioridade: 2 Story Points: 1 Uma receita pode ser editada se ela existir na Lista de Receitas da cafeteira. As receitas so listadas por ordem de nome. Aps selecionar uma receita para editar, o usurio digita a nova informao da mesma. Ao final, uma mensagem de estado exibida e a cafeteira retorna a seu estado de espera.

Pgina 104 de 117

Ttulo: Adiciona Itens ao Estoque Teste de Aceite: adicionaEstoque1 Prioridade: 1 Story Points: 2

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

O usurio seleciona uma bebida e insere uma quantidade de dinheiro. A quantidade de dinheiro deve ser um nmero inteiro. Se a bebida consta do Livro de Receitas e o usurio inseriu uma quantidade de dinheiro suficiente, a bebida ser entregue junto com a quantidade de troco (se aplicvel). O usurio no poder adquirir uma bebida se no depositar dinheiro suficiente na cafeteira. O dinheiro do usurio ser devolvido se no houver estoque suficiente para fazer sua bebida. Ao final, uma mensagem de estado sobre a compra exibida e a cafeteira retorna a seu estado de espera. Na pgina do projeto da cafeteira88 da Universidade Estadual da Carolina do Norte estas User Stories transformam-se em Casos de Uso, Diagramas de Sequncia e em cdigos de programas em vrias linguagens. Recomendo fortemente esta leitura.

O jogo da estimativa
Estou bastante convencido que, uma vez que ele foi alm das questes que podem ser respondidas atravs de um inqurito razovel, o projetista deve chutar ou, se voc preferir, postular um conjunto completo de atributos e valores, com uma frequncia imaginada de distribuies, a fim de desenvolver modelos completos, explcitos e compartilhados de usurio e usos. Um chute calculado melhor do que uma premissa no verbalizada. Muitos benefcios provm deste procedimento ingnuo: Chutar os valores e frequncias fora o projetista a pensar muito cuidadosamente sobre a composio esperada de usurios.

O PROJETO DO PROJETO DA MODELAGEM IMPLEMENTAO FRED BROOKS, JR

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

Pgina 105 de 117

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

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

Pgina 106 de 117

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

Pgina 107 de 117

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

Ah, o cheirinho de Scrum pela manh!

justamente no dia-a-dia que o Scrum vai tornando-se mais importante. Depois de algum tempo praticando, as ferramentas vo tornando-se um hbito. Em nossa empresa muito comum, j em uma primeira reunio com um cliente, comearmos a pensar nos termos do Product Backlog, imaginando como ser a formao da equipe e parceiros de desenvolvimento e nos Sprints que ocorrero at a entrega do projeto. Quando a proposta feita, muitas vezes em conjunto com um ou mais parceiros de negcios, ela traz embutida o Product Backlog e um cronograma que dar origem ao Burndown Chart. O perigo de uma coisa que se torna cotidiana, porm, que essa coisa pode comear a se deteriorar sem que a gente perceba. preciso prestar ateno aos cheiros do SCRUM pra ver se no h algo de podre no reino da Dinamarca, como diria Hamlet. Quem usou pela primeira vez o termo Code Smells (o fedor do cdigo) foi o Kent Beck, criador do Extreme Programming, enquanto ajudava o Martin Fowler em seu livro sobre Refactoring. Segundo Martin, "um mtodo muito extenso um bom exemplo - apenas de olhar para um cdigo meu nariz comea a se contorcer se eu vejo mais do que uma dzia de linhas em Java". A analogia com o "cheiro" bastante simples. Muitas vezes sabemos que h algo errado, algo est cheirando mal, mas nem sempre fcil identificar a origem. Mike Cohn, que muitos j notaram ser uma das minhas fontes preferidas, props um catlogo de cheiros do SCRUM em 2003, buscando auxiliar na identificao de alguns problemas:

Perda de ritmo: acontece quando os Sprints comeam a ter durao varivel. muito importante para o sucesso do Scrum que a equipe adquira a naturalidade em seu ritmo, concluindo cada Sprint com algum incremento ao projeto. Se, por qualquer razo, um Sprint tiver a durao de uma semana, outro de duas, mais outro de uma e assim por diante, ser impossvel que o ritmo adquira uma naturalidade. Eu vejo a tendncia disso acontecer quando o time formado por "porcos" que tm muitos outros compromissos. Porcos so aqueles que entram com o "toucinho" no projeto, os que devem estar verdadeiramente comprometidos. O ScrumMaster deve considerar a durao do Sprint algo sagrado e, se for o caso, conversar com o patrocinador do projeto exigindo a participao do devido porco ou at sugerindo a troca de porcos. Galinhas falantes: na reunio diria do projeto, apenas os porcos podem falar. As galinhas, que entram com os ovos, esto envolvidas, mas no comprometidas com o processo. O Mike totalmente contra permitir que as galinhas se intrometam, mas concorda que elas podem assistir s reunies. Eu concordo, mas tambm aceito que, na informalidade, uma galinha tente transmitir a um porco suas ideias, desde que fora das reunies. Em raros casos, e sempre entre o fim de um Sprint e o comeo de outro, aceito a indicao de um porco para promover uma galinha a porco tambm. Porcos que faltam: cada vez mais desenvolvedores trabalham em horrios flexveis. Isto um problema quando se quer estabelecer um ritmo e tem a ver com o primeiro dos problemas aqui colocados. As reunies dirias devem ser rpidas, de quinze minutos, aproveitando ao mximo o tempo dos participantes. Os porcos escolhidos devem saber disso e estarem de acordo logo no incio do projeto. O porco que faltar estar sujeito s decises dos demais, sem poder negociar nada posteriormente. Mas, e com equipes que trabalham Pgina 108 de 117

remotamente? A eu sou mais flexvel, mesmo reconhecendo que essa flexibilidade , s vezes, contraproducente e que o ScrumMaster acaba tendo a sobrecarga de ficar dando puxes de orelha aqui e ali. Nesses casos, o que fao ter vivo um documento compartilhado, onde as decises tm seu horrio de fechamento. Passado esse horrio, quem no contribuiu sujeita-se s decises dos demais.

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

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

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

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

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

Quadro branco e kanban

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

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

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

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

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

Pgina 112 de 117

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

O resultado, em nosso exemplo, o seguinte:

Pgina 113 de 117

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

Pgina 114 de 117

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

Pgina 115 de 117

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

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

Pgina 117 de 117