adoção de scrum em uma fábrica de desenvolvimento

8/14/2019 Adoo de scrum em uma fbrica de desenvolvimento

1/8

Adoo de SCRUM em uma Fbrica de Desenvolvimento

Distribudo de Software

Felipe S. Furtado Soares, Leila M. Rodrigues de Sousa Mariz, Yguarat C.

Cavalcanti, Joseane P. Rodrigues, Mrio G. Neto, Petrus R. Bastos, Ana Carina M.

Almeida, Daniel Thiago V. Pereira, Thierry da Silva Arajo, Rafael S. M. Correia,

Jones Albuquerque

Centro de Informtica Universidade Federal de Pernambuco (UFPE)Caixa Postal 7851, Cidade Universitria 50.732-970 Recife PE Brasil

{fsfs, lmrsm, ycc, jpr, mgn, prb, acma2, dtvp, tsa, rsmc

joa}@cin.ufpe.br

Abstract. The use of agile software development methodologies has become a

demand in distributed software teams. This work has the objective to reportthe experiences acquired on the adaptation of a distributed development

process based on SCRUM executed by an open source software factory.

Resumo. O uso de metodologias geis de desenvolvimento de software tem se

tornado uma demanda em equipes distribudas de software. Este trabalho tem

por objetivo relatar as experincias obtidas na adaptao de um processo de

desenvolvimento distribudo com base no SCRUM realizado por uma fbrica

de software open source.

1. Introduo

Ao longo dos ltimos anos, organizaes esto cada vez mais motivadas a aderir aomodo de desenvolver software de forma distribuda. Boa parte dessa motivao vem dosucesso adquirido por grandes projetos de software open source, como Linux e OpenOffice, os quais tm como uma das principais caractersticas a distribuio geogrfica deseus membros.

Outro fator com influncia relevante no desenvolvimento distribudo o avanodas comunicaes atravs da Internet e o crescente surgimento de ferramentas voltadaspara Engenharia de Software, as quais visam administrar de forma mais organizada eeficiente o desenvolvimento distribudo de software. Em [Martin e Hoffman 2007] feito um levantamento de como tais ferramentas (como controladores de verses,ferramentas de triagem de bugs, fruns de discusso, listas de e-mail etc) tm sido

utilizadas por times distribudos na empresa Kitware para desenvolver software. Algunssites tambm oferecem todas essas ferramentas gratuitamente, como o caso doSourceForge.net [SourceForge 2004].

Como conseqncia direta desse novo modo de desenvolvimento de software,temos a diminuio de custos e uma maior agilidade e praticidade na hora de encontrarmo-de-obra. Contudo, como grande parte dos desafios na Engenharia de Software no limitada apenas a aspectos tcnicos [Kontio 2004], o desenvolvimento distribudo desoftware ainda deixa muitas dvidas quanto a sua real eficcia, como: times distribudostm a mesma eficincia que times centralizados? A comunicao distribuda, e muitas


2/8

vezes assncrona, to eficiente quanto comunicao sncrona? Os processos desoftware atuais so capazes de lidar com as caractersticas do desenvolvimentodistribudo e ao mesmo tempo garantir a qualidade do produto?

Em paralelo a essa discusso estamos vivendo a partir do ano 2000 umatendncia para o desenvolvimento gil de aplicaes devido a um ritmo acelerado demudanas e inovaes na tecnologia da informao, em organizaes e no ambiente denegcios [Boehm 2006].

Boehm cita, ainda, que no final dos anos 90 acompanhamos o surgimento devrios mtodos geis, entre eles: Adaptive Software Development, Crystal, DynamicSystems Development, eXtreme Programming (XP), Feature Driven Development eScrum. Todos esses mtodos empregam princpios geis, tais como ciclos iterativos,entrega rpida de software funcionando e simplicidade, como definido no Manifestopara Desenvolvimento gil [Beck et al. 2001] publicado em 2001. A essncia dessemovimento a definio de novo enfoque de desenvolvimento de software, calcado naagilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecernovos produtos e servios de valor ao mercado, em curtos perodos de tempo[HighSmith 2004].

Inserido neste contexto de desenvolvimento distribudo de software, estetrabalho apresenta a aplicao do Scrum em um processo de desenvolvimento de umafbrica de software open source a qual possui fortes caractersticas de desenvolvimentodistribudo.

Este trabalho est organizado da seguinte maneira: a Seo 2 apresenta umaviso geral de desenvolvimento open source; na Seo 3, descrita uma viso geral doScrum; a Seo 4 compreende o estudo de caso com as principais adaptaes do Scrumno processo distribudo; na Seo 5 so apresentadas as lies aprendidas e concluses

finais.

2. Viso Geral de Desenvolvimento de Software Open Source

A cada dia observado um crescente movimento em torno do desenvolvimento desoftware livre, caracterizando, dessa forma, o desenvolvimento de projetos por equipesgeograficamente distribudas. Alm disso, a crescente demanda de mercado porsoftware livre a ser comercializado necessita que sejam satisfeitas restries de custo,prazo e qualidade [Hecker 2000]. Dessa forma, o processo deve ser definido com ainteno de ser o mais leve possvel, mantendo, entretanto, a formalidade necessriapara o desenvolvimento distribudo.

Raymond [Raymond 1998] relata que software open source desenvolvido por

times auto-organizados e distribudos, que raramente se renem presencialmente ecoordenam suas atividades atravs de comunicaes baseadas em computadores. Eleainda descreve um trabalho relevante sobre o processo de software open source quandoassocia o desenvolvimento nas comunidades de software livre, desprovido de qualquerprocesso formalizado, a um Bazar no qual as contribuies ocorrem ad hoc. Enquantoque o modelo de desenvolvimento de software tradicional est associado a umaCatedral e possui um processo formal bem definido.


3/8

Conforme descrito por Gonzlez e Robles em [Gonzlez et al 2003], muitos soos benefcios do modelo de desenvolvimento open source, como a realizao dosreleases mais freqentes; o baixo custo dos projetos, visto que desenvolvedores etestadores trabalham de forma voluntria; alta qualidade e confiabilidade, visto que so

muitas pessoas revisando e testando o mesmo cdigo, em arquiteturas e ambientesdistintos, aliado ao fato de que os usurios so tratados como co-desenvolvedores e, emmuitos casos, ao deparar-se com o erro, j identifica a soluo e envia o pacote com oproblema solucionado.

3. Viso Geral do SCRUM

O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland e destaca-se dos demaismtodos geis pela maior nfase dada ao gerenciamento do projeto. Rene atividades demonitoramento efeedback, em geral, reunies rpidas e dirias com toda a equipe, visando identificao e correo de quaisquer deficincias e/ou impedimentos no processo dedesenvolvimento [Schwaber 2004].

O mtodo baseia-se ainda em princpios como: equipes pequenas de, nomximo, sete pessoas; requisitos que so pouco estveis ou desconhecidos; e iteraescurtas. Divide o desenvolvimento em intervalos de tempos de no mximo, trinta dias,tambm chamados de Sprints.

O Scrum implementa um esqueleto iterativo e incremental atravs de trs papisprincipais [Schwaber 2004]: Product Owner: representa os interesses de todos no projeto;Time: desenvolve as funcionalidades do produto; ScrumMaster: garante que todossigam as regras e prticas do Scrum, alm de ser o responsvel por remover osimpedimentos do projeto.

Um projeto no Scrum se inicia com uma viso do produto que ser desenvolvido[Schwaber 2004]. A viso contm a lista das caractersticas do produto estabelecidas

pelo cliente, alm de algumas premissas e restries. Em seguida, o Product Backlog criado contendo a lista de todos os requisitos conhecidos. O Product Backlog entopriorizado e dividido em releases. O fluxo de desenvolvimento detalhado do Scrum mostrado na Figura 1.

Todo o trabalho no Scrum realizado em iteraes chamadas de Sprints.Schwaber [Schwaber 2004] explica que cada Sprint inicia-se com uma reunio deplanejamento (Sprint Planning Meeting), na qual o Product Ownere o Time decidemem conjunto o que dever ser implementado (Selected Product Backlog). A reunio dividida em duas partes. Na primeira parte (Sprint Planning 1) o Product Ownerapresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados.O Time ento define, colaborativamente, o que poder entrar no desenvolvimento da

prxima Sprint, considerando sua capacidade de produo. Na segunda parte (SprintPlanning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que so as tarefasnecessrias para implementar as funcionalidades selecionadas no Product Backlog. Nasprimeiras Sprints, realizada a maioria dos trabalhos de arquitetura e de infra-estrutura.A lista de tarefas pode ser modificada pelo Time ao longo da Sprint, e as tarefas podemvariar entre quatro e dezesseis horas para a sua concluso.

Durante a execuo das Sprints, diariamente o time faz uma reunio de quinzeminutos para acompanhar o progresso do trabalho e agendar outras reunies necessrias.


4/8

Na reunio diria ( Daily Scrum Meeting), cada membro do time responde a trsperguntas bsicas: O que eu fiz no projeto desde a ltima reunio? O que irei fazer at aprxima reunio? Quais so os impedimentos?

Figura 1. Viso geral do processo do Scrum (adaptada de [Gloger 2007])

No final da Sprint realizada a reunio de reviso (Sprint Review Meeting) para que oTime apresente o resultado alcanado na iterao ao Product Owner. Neste momento, asfuncionalidades so inspecionadas e adaptaes do projeto podem ser realizadas. Em seguida, oScrumMasterconduz a reunio de retrospectiva (Sprint Retrospective Meeting), com o objetivode melhorar o processo/time e/ou produto para a prxima Sprint.

4. Estudo de Caso - Uso do Scrum no Processo Distribudo

O estudo de caso aqui apresentado foi realizado por uma fbrica de desenvolvimento desoftware open source [O3S 2007]. Esta fbrica formada por dez alunos do curso dePs-Graduao do Centro de Informtica da Universidade Federal de Pernambuco.Todos os integrantes so do curso de mestrado e fazem parte da estrutura organizacionalda fbrica, conforme ilustra a Figura 2. Essa estrutura composta por um ComitGestor, responsvel pelas principais decises estratgicas da Fbrica e cinco Unidadesde Produo, cada uma com atribuies bem definidas e complementares, trabalhando

juntas com os clientes e a comunidade externa.

O projeto executado est inserido na rea de sade coletiva/pblica, denominadoANKOS (A New Kind Of Simulator) [ANKOS 2007], que surge como um sistemacapaz de organizar as informaes coletadas por pesquisadores em reas de estudo da

esquistossomose, bem como as imagens de satlite da regio, em um banco de dadosgerencivel e com possibilidade de consultas, recuperao e indexao da informao,formando uma base slida para a aplicao de autmatos celulares que possibilitem agerao de cenrios capazes de levar a tomada de aes estratgicas de combate epreveno da doena.


5/8

Figura 2 Estrutura Organizacional da Fbrica O3S

O processo da fbrica O3S um tailor do Hukarz Process [Moraes 2007],focado nas melhores prticas de engenharia de software, no RUP [RUP 2003] e noManifesto gil [Beck, K. et al. (2001)]. um processo evolucionrio orientado amanuteno, baseado em esforo colaborativo e em gerncia comunitria. Alm de serexecutado de forma distribuda, assncrona e descontnua, caracterizando, assim umprocesso social, diferentemente dos processos tradicionais.

O processo foi definido baseado em alguns princpios fundamentais: ciclo de

vida iterativo e incremental; planejamento nas fases iniciais do projeto; menorquantidade de documentao; certo caos, porm controlvel durante o desenvolvimento;adaptao comunicao remota; desenvolvimento centrado na arquitetura e adaptvelde acordo com a necessidade do projeto.

O processo foi descrito baseado em polticas [Johnson K 2001] que definem asdiretrizes bsicas a serem adotados por todos os projetos da fbrica de software. Elasesto voltadas para o desenvolvimento de software com caractersticas open source, ouseja, cdigo compartilhado, equipe distribuda, desenvolvimento colaborativo edescentralizado:

O projeto de software deve ser modular para facilitar o desenvolvimentoconcorrente;

A prototipao deve ser fechada: um pequeno grupo desenvolve a versoinicial do produto antes de liberar para a comunidade externa; A melhoria do produto iterativa e incremental; O desenvolvimento concorrente em vrios nveis. Vrias atividades de

fases diferentes podem ser realizadas em paralelo; A reviso de cdigo deve ser realizada em larga escala. Vrios usurios

revisam e inspecionam o cdigo de outros usurios; Os requisitos tambm podem ser oriundos da comunidade. Os usurios e

desenvolvedores definem, coletivamente, as funcionalidades do software;


6/8

Ferramentas de controle de verso e controle de mudanas so necessriaspara a boa comunicao entre a equipe. Todo projeto deve ter um repositrio,sob gerncia de configurao, para armazenar a documentao e o cdigofonte;

A forma de comunicao principal assncrona; A informao deve ser compartilhada: cdigo fonte, listas de discusses,

reportagem de erros, solicitao de novos requisitos etc; A colaborao descentralizada; A liderana deve ser compartilhada; A motivao para contribuio deve ser incentivada pelo desejo de

aprendizado, pela criao de uma comunidade, pela disseminao detecnologia e inovao.

Diversos aspectos do Scrum puderam ser utilizados para o desenvolvimentodistribudo. Primeiramente, o comit da fbrica de software realizou o estudo de

viabilidade baseada na viso apresentada pelo cliente (product owner). Em seguida, umaproposta comercial foi descrita com todo oproduct backlog inicialmente negociado coma lista dos requisitos da aplicao. Este product backlog foi priorizado e dividido nassprints do projeto. Cada sprintfoi dividida em quinze dias, onde, ao final de cada uma,um conjunto de novo produto era disponibilizado.

Dentro de cada sprint, eram realizadas reunies assncronas com o productowner para que este indicasse os itens do backlog com maior valor de negcio. Emseguida, a equipe analisava colaborativamente atravs de fruns e lista de discusses,qual a complexidade desses itens e o que caberia dentro da sprintem funo de suacapacidade de produo. A tcnica de estimativa de Pontos de Casos de Uso foiutilizada sempre considerando uma produtividade mdia das ltimas sprints realizadas.

Em seguida, os requisitos eram detalhados e, ento, a partir da o time

selecionava os itens de backlog priorizados, dividindo-os em tarefas de at 1 semana porparticipante. Essas tarefas eram cadastradas numa ferramenta de planejamento eacompanhamento de projetos para projetos que utilizam mtodos geis [XPlanner2002].

Durante os quinze dias da sprint, a equipe fazia uso do frum e lista dediscusses para simular oDaily Scrum Meeting. De tal forma que, diariamente, todos dotime sabiam o andamento das atividades e os impedimentos encontrados at o momento.Era responsabilidade de um integrante do comit da fbrica exercer o papel do Scrum

Masterno sentido de resolver todos os impedimentos reportados por qualquer membrodo time.

Assim como a comunicao da equipe, durante a sprinta comunicao entre a

equipe e o product ownerera realizada atravs do frum, e-mail ou ferramentas decomunicao assncrona, seja para aprovao de documentos, seja para o esclarecimentode dvidas ou alinhamento do andamento da sprint.

No final da sprint, uma reunio sncrona, atravs de Skype ou MSN, erarealizada com o objetivo de apresentar ao product owneros resultados obtidos at opresente momento. Em seguida, todos os integrantes do time eram convidados aparticipar da retrospectiva da sprint, que na maioria das vezes era uma reunio realizadade forma presencial. Uma reunio de lies aprendidas era conduzida por um integrante


7/8

do time que ficava responsvel por coletar os pontos fortes, fracos e sugestes demelhoria de cada participante.

Algumas mtricas foram coletadas e analisadas ao longo de cada sprintcom oobjetivo de otimizar o uso do processo adaptado. Duas delas referem-se a variao de

esforo de desenvolvimento e a produtividade da equipe. Ambas tm o objetivo deverificar a eficcia do processo de estimativas de esforo adotado. A variao mdia doesforo realizado pela equipe por sprint tem sido em torno de 15% do valor estimado.Enquanto que a produtividade teve uma melhora significativa: iniciando o projeto comuma estimativa de 18 homem-hora para cada ponto de caso de uso e estabilizando em 10homem-hora para cada ponto de caso de uso produzido.

5. Concluses e Lies Aprendidas

Este trabalho apresentou um estudo de caso sobre a aplicao de mtodos geis,particularmente baseado na abordagem proposta pelo Scrum, em um processo paradesenvolvimento de software open source com fortes caractersticas de desenvolvimento

distribudo.Ao longo do desenvolvimento do projeto foi percebido que nem todas as prticas

do Scrum eram diretamente aplicadas ao contexto de desenvolvimento distribudo desoftware. Os seguintes aspectos apresentaram os maiores desafios para o uso dasprticas geis:

O Scrum defende a unidade da equipe de desenvolvimento. Isso est fortementerelacionado com a presena fsica do time e com as iteraes dirias. Naexperincia aqui relatada, o time geograficamente distribudo conseguiu superareste desafio com o uso sistemtico do frum, listas de discusses e ferramentasde chat que permitiam uma boa iterao da equipe;

As reunies dirias de quinze minutos previstas no Scrum para que todosrespondam s trs perguntas bsicas foram substitudas pela comunicaoassncrona semelhante ao item anterior;

O Scrum focado em equipes auto-organizadas e auto-gerenciveis, alm deprever a questo motivacional como principal aspecto de sucesso do projeto.Esses mesmos aspectos puderam ser percebidos no desenvolvimento distribudo,onde a equipe poderia ser formada por qualquer membro da comunidade opensource que por vontade prpria quisesse fazer parte do projeto. Cada integrante quem escolhia qual atividade do backlog iria desenvolver;

No Scrum, o product ownerdeve participar ativamente de vrios pontos doprocesso: viso, sprintplanning, release etc. No desenvolvimento distribudo,

nem sempre possvel ter essa participao sistemtica devido ao alto ndice decomunicao assncrona. Em alguns casos, foi necessrio que o time tivesse umapostura pr-ativa para tomar algumas decises sem envolver oproduct owner;

Outro ponto de adaptao foi em relao s responsabilidades do Scrum Masterque, neste contexto, alm de ter parte de seu tempo dedicado ao gerenciamentodos impedimentos reportados pelo time, tambm fazia parte do time dedesenvolvedores.


8/8

Apesar do Scrum no cobrir todas as caractersticas especficas para equipesgeograficamente distribudas, foi possvel fazermos uso de diversos aspectos dedesenvolvimento gil sem, no entanto, comprometer as particularidades exigidas poresses tipos de projetos.

Referncias

ANKOS (2007) A New Kind Of Simulator, http://sourceforge.net/projects/ankos/,2007.

Boehm, B. (2006), A View of 20th and 21st Century Software Engineering, ICSE 2006.

Beck, K. et al. (2001), Manifesto for Agile Software Development, http://www.agilemanifesto.org/, Dezembro 2006.

Gloger, B. (2007), The Zen of Scrum, http://www.glogerconsulting.de.

Gonzles, J. e Robles, G.(2003) Free Software Engineering : A Field to Explore,

Upgrade - Software Engineering State of Art, Novtica, volume IV, N. 4.Hecker, F. (2000) Setting Up Shop: The Business of Open-Source Software, IEEE

Software.

Highsmith, J. (2004) Agile Project Management Creating Innovative Products, AddisonWesley.

Johnson, K. A. (2001) Descriptive Process Model for Open-Source SoftwareDevelopment, Master Thesis, Univ. Calgary, Alberta.

Kontio, J., Hglund, M., Rydn, J. and Abrahamsson, P. (2004) "ManagingCommitments and Risks: Challenges in Distributed Agile Development,". InProceedings of the 26th International Conference on Software Engineering,pp. 732-733.

Martin, K. and Hoffman, B. (2007). An open source approach to developing softwarein a small organization. IEEE Software, 24(1):4653.

Moraes, A. (2007). Open Source Development Process-like in the Enterprise,Dissertao de Mestrado, Universidade Federal de Pernambuco.

O3S (2007) O3S Open Source Software Solutions, http://www.yguarata.org/o3s/,2007.

Raymond, E. S. (1998) The Cathedral and the Bazaar, Disponvel em:http://www.firstmonday.org/issues/issue3_3/raymond/, Acessado em Maio/2007.

RUP (2003) "Rational Unified Process," R. S. Corporation, Ed., 2003.06.01 ed, 2003.

Scacchi, W. (2001) Understanding the Requirements for Developing Open SourceSoftware Systems. In IEE Proceedings Software, volume 148, number 1, pp. 24-39.

Schwaber, K. (2004), Agile Project Management With Scrum, Microsoft.

SourceForge (2004) SourceForge.net, https://sourceforge.net/, Acessado emJulho/2007.

XPlanner (2002) Project planning and tracking tool for agile development teams,http://www.xplanner.org/, Acessado em Julho/2007.

adoção de scrum em uma fábrica de desenvolvimento

Documents