UNICAMP Universidade Estadual de Campinas FT Faculdade de Tecnologia

Metodologias geis no contexto de desenvolvimento de software: XP, Scrum e Lean

Autores: Aline Cristine Fadel Henrique da Mota Silveira

Limeira - 2010

UNICAMP Universidade Estadual de Campinas FT Faculdade de Tecnologia

Metodologias geis no contexto de desenvolvimento de software: XP, Scrum e Lean

Autores: Aline Cristine Fadel Henrique da Mota Silveira

Orientador:

Prof. Dr. Marcos Augusto Francisco Borges

Limeira - 2010 2

Sumrio
Resumo .......................................................................................................................................... 4 Abstract ......................................................................................................................................... 4 1. 2. 3. 4. 5. 6. Introduo ............................................................................................................................. 5 Metodologias geis............................................................................................................... 5 Estudo de Caso .................................................................................................................... 20 Anlise e Discusso sobre as Metodologias geis Abordadas ........................................... 22 Consideraes Finais ........................................................................................................... 24 Referncias Bibliogrficas .................................................................................................. 25

Resumo
Este trabalho apresenta um estudo sobre metodologias geis, mais especificadamente os mtodos Lean Software Development (LSD), Scrum e eXtreme Programming. So apresentadas caractersticas, conceitos, formas de trabalho, alm de uma comparao entre essas metodologias, como pontos em comum e diferenas. Este trabalho remete-se a disciplina FT027 (Gesto e Qualidade de Projetos) do programa de Ps Graduao da Faculdade de Tecnologia da Universidade Estadual de Campinas.

Abstract
This paper presents a study about agile methodologies, more specifically the methods Lean Software Development (LSD), Scrum and eXtreme Programming. Characteristics are presented, concepts, ways of working, beyond of comparison between these methodologies, as commonalities and differences. This work refers to FT027 (Management and Quality Project) of program by Graduate School of Technology, State University of Campinas.

1. Introduo
Na busca por lucros e eficincia, as empresas desenvolvedoras de software esto procura por metodologias em que possam administrar melhor o seu tempo e seus recursos, para entregar produtos com qualidade. Para que as empresas entreguem os produtos esperados pelos clientes e no tempo adequado, a metodologia gil surge como uma inovao, onde ele traz a eficincia para a equipe, pois o fluxo de desenvolvimento est extremamente organizado, desenvolvendo um software com o mnimo de recursos desperdiados. Este trabalho est organizado da seguinte maneira: a seo 2 apresenta trs metodologias geis de desenvolvimento de software: Lean Software Development (LSD), Scrum e XP; a seo 3 descreve um estudo de caso do emprego da Metodologia gil; a seo 4 faz o comparativo entre as metodologias alm de discutir a viabilidade de implantao de cada uma; e as consideraes finais so apresentadas na seo 5.

2. Metodologias geis
Nesta seo, ser apresentada uma breve introduo sobre a origem dos mtodos geis alm de dar nfase em trs metodologias geis de desenvolvimento de software: Lean Software Development (LSD), Scrum e eXtreme Programming (XP).

2.1. Origem dos Mtodos geis

Filho [7, p. 22] sintetiza e coloca da seguinte maneira o modo pelo qual os mtodos geis surgiram: Durante a evoluo dos processos de Engenharia de Software, a indstria se baseou nos mtodos tradicionais de desenvolvimento de software, que definiram por muitos anos os padres para criao de software nos meios acadmico e empresarial. Porm, percebendo que a indstria apresentava um grande nmero de casos de fracasso, alguns lderes experientes adotaram modos de trabalho que se opunham aos principais conceitos das metodologias tradicionais. Aos poucos, foram percebendo que suas formas de trabalho, apesar de no seguirem os padres no mercado, eram bastante eficientes. Aplicando-as em vrios
5

projetos, elas foram aprimoradas e, em alguns casos, chegaram a se transformar em novas metodologias de desenvolvimento de software. Essas metodologias passaram a ser chamadas de leves por no utilizarem as formalidades que caracterizavam os processos tradicionais e por evitarem a burocracia imposta pela utilizao excessiva de documentos. Com o tempo, algumas delas ganharam destaque nos ambientes empresarial e acadmico, gerando grandes debates, principalmente relacionados confiabilidade dos processos e qualidade do software. De acordo com Beck [3], em 2001 um encontro entre 17 lderes que trabalhavam no contra-fluxo dos padres da indstria de software, foi discutido formas de trabalho, objetivando chegar a uma nova metodologia de produo de software, que pudesse ser usada por todos eles e em outras empresas, substituindo os modelos tradicionais de desenvolvimento. O grupo chegou ao consenso de que alguns princpios eram determinantes para a obteno de bons resultados. O resultado deste encontro foi a identificao de 12 princpios e a publicao do Manifesto gil [3] que os representa com quatro premissas: Indivduos e iteraes so mais importantes do que processos e ferramentas; Software funcionando mais importante do que documentao completa; Colaborao com o cliente mais importante do que negociao de contratos; Adaptao a mudanas mais importante do que seguir o plano inicial;

Kalermo e Rissanen [10] apontam os 12 princpios mencionados acima: 1. Prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado; 2. As mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente; 3. Frequentes entregas do software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo; 4. As pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;

5. Os projetos devem ser construdos em torno de indivduos motivados. Dando o ambiente e o suporte necessrio e confiana para fazer o trabalho; 6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face; 7. Software funcionando a medida primria de progresso; 8. Os processos geis promovem desenvolvimento sustentvel. Os

patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente; 9. Contnua ateno a excelncia tcnica e bom design aumentam a agilidade; 10. Simplicidade para maximizar, a quantidade de trabalho no realizado essencial; 11. As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizveis; 12. Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva, e ento, ajustar-se de acordo com seu comportamento. O Manifesto gil, segundo Filho [7], ressalta o que mais tem valor para as metodologias geis, a importncia de como saber lidar com pessoas, assim como ter o cliente colaborando para encontrar a melhor soluo, entregar o software com qualidade e do que se adaptar s mudanas. Isto oculta parte das dificuldades dos processos, contratos, documentao e planejamento para o desenvolvimento de um software [7].

2.2. Lean Software Development (LSD)

O sistema Toyota de Produo [12], tambm conhecido como Lean Manufacturing, surgiu no Japo, na fbrica de automveis Toyota, logo aps a Segunda Guerra Mundial. Nesta poca a indstria japonesa tinha uma produtividade muito baixa e uma enorme falta de recursos, o que naturalmente a impedia adotar o modelo de produo em massa. De acordo com o Lean Institute Brasil [11], Lean uma estratgia de negcios para aumentar a satisfao dos clientes atravs da melhor utilizao dos recursos. A Gesto Lean procura fornecer consistentemente valor aos clientes com os custos mais baixos (Propsito) atravs da identificao de melhoria dos fluxos de valor primrios e de suporte (Processos) por meio do envolvimento das pessoas qualificadas, motivadas e com iniciativa (Pessoas). O foco da implementao deve estar nas reais necessidades dos negcios e no na simples aplicao das ferramentas lean.
7

De acordo com Mary Poppendieck [14], o desenvolvimento de software Lean a aplicao dos princpios da Toyota product development system para o desenvolvimento de software. Quando ele aplicado corretamente, o desenvolvimento de alta qualidade, alm de ser realizado rapidamente e possuir um baixo custo. Alm disso, o desenvolvimento gil possui um grande sucesso devido ao Lean. 2.2.1 Princpios

O pensamento Lean foca em oferecer o que o cliente quer, onde e quando quiserem sem haver qualquer desperdcio. Para atingir esse objetivo, Lean possui alguns princpios. No trabalho publicado por Poppendieck Poppendieck [15], feito o mapeamento dos sete princpios de Lean para o desenvolvimento de software. Em conjunto todos esses princpios oferecem entregas rpidas, com mais qualidades e com baixo custo, ao mesmo tempo. A seguir cada princpio apresentado conforme o ponto de vista de Filho [7]. 2.2.1.1 Eliminar o desperdcio

O desperdcio em si pode acontecer sob vrios pontos de vista, dentre eles, desperdcio de: dinheiro, recursos, tempo, esforo e espao. Cada etapa e atividade realizada no processo deve necessariamente contribuir para que o produto final seja construdo mais rapidamente, com mais qualidade ou a um custo mais baixo. Filho [7] coloca uma srie de cenrios, a seguir, onde o desperdcio evidente. A existncia de funcionalidades incompletas gera desperdcio porque despendem esforos para serem iniciadas e no adicionam valor ao software. Pedaos de cdigo incompletos tendem a se tornar obsoletos, mais difceis de serem integrados e os programadores lembram menos a respeito da inteno inicial do cdigo. Excesso de processos um desperdcio porque eles demandam recursos e aumentam o tempo para a concluso das tarefas. A criao de documentos infla o processo e causa desperdcio, pois eles consomem tempo para serem produzidos, sem garantias de que algum ir l-los. Documentos ficam desatualizados e podem ser perdidos, tornam a comunicao mais lenta e reduzem o poder comunicativo, pois um meio de comunicao de via nica no qual no possvel que escritor e leitor interajam em tempo real. Alm disso, muitas vezes, documentos representam apenas formalismos burocrticos que no acrescentam valor ao software.
8

Processos complexos aumentam a quantidade de documentos, por isso tambm caracterizam desperdcio. Antecipar funcionalidades um desperdcio porque aumenta a complexidade do software desnecessariamente com mais cdigo, mais esforos com testes e mais integraes. Troca de tarefas uma forma de desperdcio porque um nmero excessivo de mudanas de contexto reduz a produtividade. Alocar desenvolvedores em mais de um projeto um desperdcio porque as necessidades de um projeto no levam em conta a situao dos outros. Esperas por requisitos, por testes, por aprovao ou por feedback retardam o fluxo do desenvolvimento ou a identificao de problemas. Defeitos so desperdcio porque o custo para corrigi-los aumenta com o tempo. medida que o projeto evolui, a complexidade do cdigo aumenta, com isso, a localizao e a remoo de um defeito torna-se mais difcil Portando, processos que envolvam comunicao e atividades de gerenciamento devem ser o mais simples e objetivo possvel, para que menos pessoas sejam necessrias, menos etapas sejam cumpridas at a concluso de um ciclo e, assim, o processo inteiro ser mais rpido e menos custoso [7]. 2.2.1.2 Amplificar o aprendizado

Filho [7] afirma que lies devem ser extradas das experincias vividas pela equipe e incorporadas ao processo, fazendo com que as dificuldades passadas sejam fonte de conhecimento e contribuam para o amadurecimento da equipe e do processo. O uso de um processo definido engessa o aprendizado. Deming [5 apud [7, p. 78]] props um ciclo de melhoria contnua que pode ser aplicado neste cenrio, sendo que primeiro deve-se fazer a identificao o problema, localizar a sua causa, criar uma soluo, implementar, verificar os resultados e se adaptar nova realidade. 2.2.1.3 Adiar comprometimentos e manter a flexibilidade

Adiar decises permite que as escolhas sejam apoiadas por mais experincia e conhecimento adquiridos no decorrer do processo. Para retardar decises durante a construo de sistemas importante que a equipe crie a capacidade de absorver mudanas tratando os planejamentos como estratgias para atingir um objetivo e no
9

como comprometimentos. Assim, mudanas sero vistas como oportunidades para aprender e atingir as metas [7]. 2.2.1.4 Entregar rpido

De acordo com Filho [7], com ciclos rpidos o desenvolvimento caminha atravs de um processo iterativo no qual o cliente refina suas necessidades e as obtm implementadas j no prximo ciclo. Iteraes curtas trazem mais experincia para a equipe e aumentam a sua segurana para tomar decises. At recentemente, a rpida entrega de software no era valorizada, a estratgia de no cometer erros era vista como mais importante. Porm, o desenvolvimento rpido do software tem diversas vantagens, j que a velocidade de desenvolvimento tambm ajuda atender s necessidades atuais do cliente, alm de permitir adiar a tomada de decises para quando for acumulado conhecimento suficiente para tal [8]. 2.2.1.5 Tornar a Equipe Responsvel

Sendo que a equipe de desenvolvimento responsvel pela confeco do produto que entregue ou usado pelo cliente, o software, logo o conhecimento dos detalhes tcnicos deve ser levado em considerao na tomada de decises a na definio de processos [7]. Franco [8] coloca que envolver os desenvolvedores nas decises de detalhes tcnicos fundamental para atingir a excelncia. Quando dotados com a experincia necessria e guiados por um lder, eles tomaro decises tcnicas e de processos, melhores que qualquer outra pessoa poderia tomar por eles. Lean utiliza as tcnicas de produo puxada (pull) para agendar o trabalho e possuem mecanismos de sinalizaes locais, de forma a permitir que outros trabalhadores identifiquem o trabalho que necessita ser realizado. No desenvolvimento de software Lean, o mecanismo da produo puxada (pull) corresponde ao acordo de entregar verses refinadas e incrementais do software em intervalos regulares. A sinalizao local feita atravs de grficos visuais, reunies dirias, integraes freqentes e testes automatizados [8]. Franco [8] apresenta dois exemplos de representaes grficas (Figuras 1 e 2). A Figura 1 ilustra um quadro que pode ser utilizado para distribuir as funcionalidades a serem realizadas em cada iterao, semelhante ao kanban do da metodologia Lean. utilizado para nivelar e controlar o fluxo de produo, definindo a quantidade de trabalho a ser realizado em cada iterao. As colunas representam a segmentao do trabalho a ser realizado atravs das iteraes. Em cada coluna acrescentado um carto
10

que corresponde ao objetivo da iterao (Carto Tema), e abaixo deles so colocados cartes correspondentes aos requisitos a serem implementados. Estes cartes podem ser relacionados arquitetura ou s funcionalidades do produto. O nivelamento da produo feito atravs da quantidade de trabalho a ser realizado para transformar os requisitos descritos nos cartes em incrementos do produto; o esforo alocado para cada iterao deve ser homogneo, no podendo haver grandes variaes entre elas.

Figura 1. Quadro de cartes de funcionalidades [15 apud [8, p. 49]].

A Figura 2 ilustra um exemplo dos controles visuais utilizados para acompanhar a execuo do projeto. A curva azul representa a estimativa de esforo necessrio para finalizar as tarefas remanescentes na iterao atual e a linha amarela corresponde quantidade de funcionalidades remanescentes para serem codificadas e incorporadas ao incremento do produto a ser entregue no fim da iterao.

Figura 2. Exemplo de grfico do tipo burndown [8, p. 50].

11

2.2.1.6

Construir Integridade

De acordo com Filho [7], a equipe de desenvolvimento deve elaborar solues que a deixem segura de que esto construindo um produto de qualidade. Por isso existe a necessidade da utilizao de uma arquitetura adequada, mantendo uma alta cobertura de testes automatizados e preservando a flexibilidade para mudanas, adaptaes e extenses so formas de trazer segurana e motivao para alcanar nveis mais elevados de qualidade. Dessa maneira, ao invs de se gastar tempo para encontrar e corrigir defeitos, mais investimento e esforos devem ocorrer na preveno atravs de vrios tipos de teste. De acordo com Franco [8], o software necessita de um nvel adicional de integridade e precisa manter sua utilidade ao longo do tempo. O software que possui integridade possui uma arquitetura coerente, facilidade satisfatria de uso, atende aos propsitos para o qual foi proposto, manutenvel, adaptvel e extensvel. 2.2.1.7 Visualizar o Todo

Para Franco [8], para que haja a obteno da integridade nos sistemas de grande complexidade preciso um conhecimento profundo de diversas reas. Filho [7] coloca que a criao de grandes sistemas envolve solues integradas que devem prover bons resultados perante uma anlise global do software. Os pontos de vista dos clientes e dos usurios equivalem a vises de alto nvel do sistema. Otimizaes macro canalizam os esforos para aumentar a satisfao dos usurios finais atravs de um produto consistente. Lean ainda recomenda a escolha de mtricas de alto nvel que sejam representativas para identificar a evoluo. Essas mtricas devem levar em considerao tambm a qualidade e a satisfao do cliente, pois a partir delas ser possvel avaliar quais trocas so vantajosas.

2.3. Scrum
Inicialmente o Scrum foi concebido para gerenciamento de projetos de fabricao de automveis e de produtos de consumo, por Takeuchi e Nonaka no artigo The new product development game, em janeiro-fevereiro de 1986, pela Universidade de Harvard. Neste artigo, Takeuchi e Nokada notaram que em projetos com equipes pequenas e multidisciplinares produziam melhores resultados, e associaram isto a formao Scrum do Rugby. Em 1995, o Scrum teve sua definio formalizada por Ken Schwaber, que trabalhou para consolid-lo como mtodo de desenvolvimento de software por todo o mundo [1] [16].
12

O Scrum no define uma tcnica especfica para o desenvolvimento de software durante a etapa de implementao, ele se concentra em descrever como os membros da equipe devem trabalhar para produzir um sistema flexvel, num ambiente de mudanas constantes. A idia central do Scrum que o desenvolvimento de sistemas envolve diversas variveis (ambientais e tcnicas) e elas possuem grande probabilidade de mudar durante a execuo do projeto (por exemplo: requisitos, prazos, recursos, tecnologias etc.). Estas caractersticas tornam o desenvolvimento do sistema de software uma tarefa complexa e imprevisvel, necessitando de um processo flexvel e capaz de responder s mudanas [8]. 2.3.1.1. Elementos de Apoio

Filho [7] descreve os elementos de apoio do Scrum, sendo que os nicos elementos que a equipe produz para seguir a prticas de Scrum so cartes com as funcionalidades e grficos de acompanhamento. Os cartes agrupados formam o Backlog do Produto e outros backlogs. Os grficos so atualizados freqentemente e devem refletir o estado do projeto. Estes so listados a seguir [7]: Backlog do Produto: Lista de todos os cartes de funcionalidades que o produto deve possuir e que ainda no foram desenvolvidas; Backlog Selecionado: Um subconjunto de funcionalidades que o cliente escolheu a partir do backlog do produto para ser implementado no sprint atual e que no pode ser modificado durante o sprint; Backlog do Sprint: Lista priorizada, obtida a partir da quebra dos cartes do backlog selecionado em tarefas menores; Backlog de Impedimentos: Lista dos obstculos identificados pela equipe que no pertencem ao contexto do desenvolvimento; Grficos de Acompanhamento: Grficos que medem a quantidade de trabalho restante (burndown charts) so os preferidos em Scrum. recomendado faz-los para vrias esferas do projeto: para o produto, para a release e para o sprint. 2.3.1.2. Papis e Responsabilidades

De acordo com Franco [8], os papis no Scrum que possuem tarefas e propsitos diferentes durante o processo e suas prticas so apresentados a seguir:

13

Cliente: participa das tarefas relacionadas definio da lista de funcionalidade do software sendo desenvolvido ou melhorado, elaborando os requisitos e restries do produto final desejado.

Gerente: encarregado pela tomada das decises finais, utilizando as informaes visuais disponibilizadas graficamente pelos padres e

convenes a serem seguidas no projeto. Ele tambm responsvel por acordar, junto aos Clientes, os objetivos e requisitos do projeto. Equipe Scrum: a equipe de projeto que possui autoridade de decidir sobre as aes necessrias e de se organizar para poder atingir os objetivos preestabelecidos. A Equipe Scrum envolvida, por exemplo, na estimativa de esforo, na criao e reviso da lista de funcionalidade do produto, sugerindo obstculos que precisam ser removidos do projeto. Scrum Master: responsvel por garantir que o projeto esteja sendo conduzido de acordo com as prticas, valores e regras definidas no Scrum e que o progresso do projeto est de acordo com o desejado pelos Clientes. O Scrum Master interage tanto com a Equipe Scrum, como com os Clientes e o Gerente durante o projeto. Ele tambm responsvel por remover e alterar qualquer obstculo ao longo do projeto, para garantir que a equipe trabalhe da forma mais produtiva possvel. Responsvel pelo Produto: oficialmente responsvel pelo projeto, gerenciamento, controle e por tornar visvel a lista de funcionalidade do produto. Ele selecionado pelo Scrum Master, Clientes e Gerente. Ele tambm responsvel por tomar as decises finais referentes s tarefas necessrias para transformar a lista de funcionalidades no produto final, participando na estimativa do esforo de desenvolvimento necessrio e responsvel pelo detalhamento das informaes referentes lista de funcionalidade utilizada pela Equipe Scrum. 2.3.1.3. Entregas Contnuas

A metodologia proposta pelo modelo Scrum aplica um sistema de entregas contnuas. Nesta metodologia com os backlogs definidos (que so os requisitos funcionais do sistema), um sprint programado (tempo predeterminado no qual ser dividido o trabalho para efetuao de uma entrega, tendo como padro o prazo dentre duas a quatro semanas), reunies dirias (de 10 minutos para acompanhar se o projeto
14

est de acordo com o planejamento) e, ao final de cada sprint, uma reunio de retrospectiva e planejamento do prximo sprint (Figura 3) [1].

Figura 3. Ciclo de desenvolvimento Scrum [1, p. 3].

2.3.1.4.

Planejando as interaes (entregas)

Na metodologia Scrum para se planejar uma interao (uma entrega) deve-se seguir a seguinte seqncia de atividades, segundo Araujo e Galina [1]: Discutir uma estria; Decompor uma estria em tarefas; Desenvolvedor deve aceitar a responsabilidade por cada tarefa; Aps todas as estrias terem sido discutidas e todas as tarefas aceitas, os desenvolvedores individualmente estimam as tarefas aceitas para ter certeza de que eles no esto se comprometendo com algo que no podem cumprir. 2.3.1.5. Desempenho da equipe e Escopo de Utilizao

O desempenho da equipe ser definido com base no histrico de entregas e concluses de projetos anteriores, aes que iram definir o quanto em pontos a equipe consegue atingir. Atravs de um sistema de pontuao cada desenvolvedor atinge em mdia 20 pontos por sprint de durao de duas semanas. Tal desempenho pode ser afetado por diversos fatores, os quais que devem ser trazidos para discusso na reunio de retrospectiva e planejamento. Nesta reunio, deve-se abordar a apresentao de problemas e dificuldade encontrados, buscando assim resolues, melhorias no processo

15

de desenvolvimento de software e conseqentemente objetivando a velocidade de concluso dos prximos sprints [1]. O Scrum uma metodologia destinada a pequenas equipes com menos de dez pessoas. Schwaber e Beedle [16 apud [8]] sugerem que a equipe seja composta de cinco a nove integrantes, se mais pessoas estiverem envolvidas no projeto, devem-se formar mltiplas Equipes Scrum.

2.4. Extreme Programming (XP)

Segundo Franco [8], a metodologia Extreme Programming (XP) surgiu como uma tentativa para solucionar os problemas causados pelos ciclos de desenvolvimento longos dos modelos de desenvolvimento tradicionais. O XP composto por prticas que se mostraram eficientes nos processos de desenvolvimento de software nas ltimas dcadas. Depois de aplicado e obtido sucesso num caso real, o XP foi formalizado atravs de princpios chaves e doze prticas [2]. Quando analisadas individualmente, as prticas que compem o XP no so novas. No XP estas prticas foram reunidas e alinhadas de tal forma a criar uma interdependncia entre elas, e assim, deu origem a uma nova metodologia de desenvolvimento de software. De acordo com Franco [8], os quatro princpios chaves do XP so a Comunicao, Simplicidade, Feedback e a Coragem. Filho [7] complementa estes princpios com mais um item: Respeito. A seguir estes so detalhados: Comunicao: muitos dos problemas que ocorrem no decorrer do projeto podem ser relacionados com problemas de comunicao entre a equipe ou entre a equipe do projeto e o prprio cliente. Uma pessoa pode deixar de comunicar um fato importante outra pessoa, um programador pode deixar de levantar uma questo importante ao cliente etc. O XP mantm o fluxo de comunicao atravs de algumas prticas que no podem ser realizadas sem comunicao. Exemplos disto so: testes de unidade, programao em pares e estimativa do esforo de cada tarefa; Simplicidade: deve-se sempre selecionar a alternativa mais simples que possa funcionar. O XP se baseia no fato que mais barato fazer algo mais simples e alter-lo conforme as necessidades forem surgindo do que tentar prever as necessidades futuras, introduzindo uma complexidade que possa vir a no ser necessria no futuro;
16

Feedback: todo problema deve ser evidenciado o mais cedo possvel para que possa ser corrigido imediatamente. Toda a oportunidade descoberta o mais cedo possvel para que possa ser incorporada de forma rpida ao produto que est sendo construdo;

Coragem: preciso coragem para apontar um problema no projeto, para solicitar ajuda quando necessrio, para simplificar o cdigo que j est funcionando (podendo introduzir novos defeitos), comunicar ao cliente que no ser possvel implementar um requisito no prazo estimado e, at mesmo, para fazer alteraes no processo de desenvolvimento.

Respeito: necessrio entre as pessoas, sendo a pea principal para que os demais valores funcionem. Sem respeito, a Comunicao e o Feedback sero pouco eficientes e a Coragem de um membro poder ser nociva aos demais por no estar alinhada com os interesses da equipe. Todos os participantes devem manter o respeito entre si e em relao aos seus trabalhos. Desvalorizar algum, a funo que exerce ou a qualidade de seu trabalho so formas de falta de respeito que minam a sinergia da equipe. Uma forma de respeito de cada um para com a equipe assumir responsabilidades que sero capazes de cumprir e da equipe para com seus membros confiar que cada um far o melhor trabalho possvel. XP considera que os desenvolvedores tambm so pessoas e preocupa-se com suas necessidades pessoais e profissionais atravs dos princpios da humanidade e da diversidade, estabelecendo compromissos com o princpio da aceitao da

responsabilidade.

2.4.1.

Papis e Responsabilidades

Existem diferentes papis sugeridos pela metodologia XP para diferentes fases, prticas e ferramentas necessrias ao longo do projeto. A seguir, de acordo com Beck [2], estes papis so descritos: Programador: escrevem testes e mantm o programa o mais simples e conciso possvel. A primeira caracterstica que torna o XP possvel a habilidade de comunicao e coordenao com outros membros da equipe; Cliente: escreve as estrias e os testes funcionais, alm de decidir quando cada requisito foi satisfeito. O cliente tambm define a prioridade de implementao de cada requisito;
17

Testador: ajuda o cliente a escrever os testes funcionais. Ele tambm realiza os testes funcionais regularmente, comunicando os resultados dos testes e mantm o conjunto de testes;

Monitor: fornece a realimentao para a equipe do projeto. Ele acompanha a conformidade das estimativas feitas pela equipe de desenvolvimento (por exemplo, estimativas de esforo) e fornece comentrios de quanto acuradas elas esto, para poder melhorar futuras estimativas. Ele tambm acompanha o progresso de cada iterao e avalia se o objetivo vivel dentro das limitaes de tempo e recursos, ou se alguma mudana necessria no processo;

Treinador: a pessoa responsvel pelo processo como um todo. Um profundo conhecimento do XP importante para este papel, pois ele que guiar os outros envolvidos no projeto a executar o processo de forma adequada;

Consultor: um membro externo com conhecimento tcnico especfico necessrio para o projeto. O consultor auxilia a equipe a resolver problemas especficos;

Chefe: responsvel pelas tomadas de decises. Para isso, ele comunica-se com a equipe de projeto para determinar a situao atual e para identificar qualquer dificuldade ou deficincia do processo.

2.4.2.

Prticas

Assim como papis e responsabilidades, existe na metodologia XP um conjunto de prticas formado por doze itens, que de acordo com Franco [8], so descritos a seguir: Jogo de planejamento: nesta prtica existe uma grande interao entre o Cliente e os Programadores. Os Programadores estimam o esforo necessrio para implementar as estrias definidas pelo Cliente e este, decide sobre o escopo e durao das iteraes; Incrementos curtos e pequenos: um incremento simples e funcional gerado rapidamente pelo menos uma vez a cada dois ou trs meses. Desta forma possvel ter um retorno por parte do Cliente em tempo hbil para poder incorporar mudanas e corrigir o produto sendo desenvolvido; Metfora: elaborado uma descrio que permite todos envolvidos no projeto (Clientes, Programadores, Gerente etc.) explicar como o sistema funciona. Ela cria uma viso comum e sugere uma estrutura de como o
18

problema e a soluo so percebidos no contexto do sistema sendo produzido. Ela tambm auxilia os envolvidos a compreender os elementos bsicos do sistema e seus relacionamentos, criando um vocabulrio comum para o projeto; Projeto simples: o sistema deve ser projetado da forma mais simples possvel de acordo com as necessidades atuais do projeto. As complexidades desnecessrias so removidas assim que so descobertas; Testes: o desenvolvimento do software dirigido por testes. Os testes de unidade so desenvolvidos antes da codificao e so executados continuamente. Os testes funcionais (aceitao) so escritos pelo Cliente; Reestruturao: melhoria do sistema atravs da remoo de duplicaes de cdigo, melhorando a comunicao, simplificando e adicionando

flexibilidade; Programao em pares: dois programadores escrevem o cdigo em um nico computador; Propriedade coletiva: qualquer programador pode alterar qualquer parte do cdigo em qualquer lugar do sistema a qualquer momento; Integrao contnua: o sistema integrado e so geradas verses internas, diversas vezes ao dia, sempre que uma estria finalizada; Semanas de 40 horas: no se devem trabalhar mais do que quarenta horas por semana, isto deve ser encarado como uma regra; Cliente no local: um usurio real do produto (Cliente) deve ser adicionado equipe de programadores. Ele deve estar disponvel em tempo integral para responder as eventuais dvidas; Padro de codificao: os programadores escrevem todo o cdigo de acordo com regras que enfatizam a comunicao durante a codificao. Antes do incio do projeto deve ser definido um padro que dever ser seguido por toda a equipe de Programadores. As prticas do XP, segundo Franco [8], so agrupadas em quatro grupos de acordo com sua finalidade, comeando da elipse central para a extremidade: Codificao; Equipe; Processo; e Produto.
19

A Figura 4 apresenta uma ilustrao grfica do agrupamento das prticas do XP, descritas anteriormente.

Figura 4. Agrupamento das prticas do XP [8, p. 32].

3. Estudo de Caso
O estudo de caso foi retirado de Introducing Lean Principles with Agile Practices at a Fortune 500 Company e foi elaborado por Emma Parnell-Klabo (2006). A Capital One uma grande empresa do setor financeiro e est no ranking da Fortune. Porm ela necessitava diminuir os seus custos e aumentar a competividade no mercado, baseado nisso ela optou pelo Lean gil no desenvolvimento de seus produtos de software. Antes de qualquer ao ela necessitou reorganizar seus processos, e para isso utilizou os princpios DMAIC do Seis Sigma. Utilizando os princpios do Lean, foram identificados pontos fortes de desperdcios: transporte, inventrio, espera, processamento, e os defeitos (retrabalho). Os fatores que deveriam ser mais trabalhados eram: Aperfeioamento do tempo de recurso com atribuio de trs ou mais projetos ao mesmo tempo; Execuo manual dos casos de testes sem os benefcios da automao;
20

Paradas freqentes no processo de desenvolvimento que acarretavam atrasos de alguns dias e at semanas nos produtos; Os executantes do processo possuam pouca visibilidade de todas as outras tarefas; Redundncia e sobreposio de papis entre os departamentos; Expectativas pouco claras dos clientes; Baixo nvel de interao entre os clientes e o time de desenvolvedores; Atribuir os recursos mais qualificados e conhecedores tcnicos para coordenar o trabalho em vez de utiliz-los para contribuir no processo de desenvolvimento;

Uma anlise no projeto verificou que o cdigo (projeto e desenvolvimento) representa apenas 10 % de todo o projeto. Ou seja, havia muito desperdcio em outras tarefas. Aps a aplicao do desenvolvimento gil Scrum, o time de desenvolvimento diminuiu em 50% o nmero de tarefas. Na escolha de um projeto piloto, o time focou em dois pontos: O projeto precisaria ser similar em tamanho e complexidade de outros projetos j entregues; Os membros do time necessitariam possuir diferentes conhecimentos e habilidades. Os resultados desse piloto foram: 30% menos na codificao e testes, e 15% menos com os custos com recursos, alm da durao do projeto ser 40% menor. Apesar de todos esses ganhos, o time de desenvolvimento enfrentou algumas dificuldades, como a falta de apoio do executivo. Diante desses resultados foi observado que a juno de Lean e gil forneceram bons resultados, porm, antes da aplicao dos princpios do Lean e tcnicas de software gil, as ferramentas Lean devem ser utilizadas para remover resduos, aps todos os processos estarem organizados.

21

4. Anlise e Discusso sobre as Metodologias geis Abordadas

As metodologias geis utilizadas em desenvolvimento de software quebram o paradigma do desenvolvimento em cascata, e outros processos mais tradicionais, porm elas no so uma substituio aos processos j existentes, mas sim uma complementao ou uma alternativa. A cada nova iterao um subprojeto elaborado, onde so realizadas todas as etapas como: planejamento, requisitos, codificao e testes. E essas iteraes duram poucas semanas, o que leva a resultados rpidos, principalmente para os clientes. Os subprojetos entregues frequentemente possuem funcionalidades j em operao. Os grupos de desenvolvimento geis geralmente so pequenos, facilitando a comunicao, a qual normalmente ocorre em tempo real, o que resulta em pouca documentao do projeto, sendo isso um ponto desfavorvel. O cliente parte da equipe de desenvolvimento, realiza sugestes e melhorias, participa do planejamento do escopo de cada iterao, e aprova cada entrega. O projeto tem grandes ganhos com a participao do cliente, pois as mudanas podem ocorrer no incio de cada fase sem comprometer a qualidade e os custos do desenvolvimento. O desenvolvimento Scrum foi criado inicialmente para o gerenciamento de projetos. J o XP utilizado no desenvolvimento, devido aplicao de suas tcnicas e ferramentas. O Lean no uma prtica de desenvolvimento ou um gerenciamento de projetos, mas sim um conjunto de princpios, valores e ferramentas que tornam o desenvolvimento enxuto. Com essas observaes, pode-se afirmar que XP, Scrum e Lean podem ser utilizados como metodologias complementares. Em suma, Franco [8] aponta as caractersticas comuns entre as metodologias geis da seguinte forma: Testes: Mtodos tradicionais tratam a implementao e os testes como fases completamente distintas. Em mtodos geis, esta segmentao tende a desaparecer. Implementao e testes acontecem muitas vezes juntos, onde o mesmo programador que cria o cdigo, tambm o testa; Desenvolvimento Iterativo: O desenvolvimento acontece em ciclos (iteraes), que tm o objetivo de produzir e integrar partes do software. Cada iterao pode durar desde alguns meses at poucas horas, conforme a metodologia escolhida e as habilidades da equipe. Desta forma, o processo
22

torna-se flexvel para acomodar mudanas funcionais e de prioridade durante a construo do sistema. No fim de cada ciclo, o software pode ser entregue ao cliente para que o restante do desenvolvimento seja direcionado pelo seu feedback. Desenvolvimento Incremental: Durante as iteraes, o software pode receber incrementos funcionais de duas formas: 1) acrescentando funcionalidades medida que o software cresce, ou 2) evoluindo as funcionalidades junto com o sistema. Na primeira, as funcionalidades so implementadas completamente e entregues uma por vez, no segundo caso elas so criadas de forma simplificada para entrarem em produo rapidamente e, se preciso, so completadas ou melhoradas nas prximas iteraes; Colaborao: Clientes e usurios esto mais prximos dos desenvolvedores e acompanham a evoluo do produto. O contato constante com o cliente permite feedback rpido e facilita a comunicao. Com mais comunicao, a viso dos participantes sobre o andamento do projeto torna-se mais apurada, evitando que surpresas aconteam no fim do projeto. A identificao e resoluo de problemas tornam-se mais rpidas e as prioridades, o escopo e os detalhes da implementao podem ser negociados com mais facilidade; Estimativas: Mtodos geis usam estimativas ao invs de predies. Estimativas so compostas por uma dupla de valores < v, p >, onde v um palpite sobre determinado evento ou atividade e p a probabilidade de v acontecer. Equipes geis baseiam-se na comunicao e na transparncia. Ao invs de tratar suas estimativas como fatos, admitem que existe uma incerteza associada ao valor estimado e evidenciam isso para que o cliente e outros envolvidos tambm tomem cincia do grau de dificuldade de cada tarefa. Estimativas de longo prazo geralmente possuem graus maiores de incerteza associados. medida que o tempo passa e o conhecimento sobre o assunto aumenta, as estimativas podem ser refeitas considerando um nvel maior de detalhes e associando probabilidades de sucesso mais altas; Negociao: No desenvolvimento de software, o planejamento e o produto final esto relacionados com quatro variveis interdependentes: tempo, custo, escopo e qualidade. Essas variveis se relacionam de forma que a alterao do valor de qualquer uma delas influencia as outras;
23

Priorizao: Mtodos geis baseiam-se fortemente na adaptao a mudanas. As estratgias de planejamento focam em planos detalhados para o curto prazo e mais superficiais para o futuro distante. Desta forma, possvel uma viso panormica para guiar as decises no longo prazo e preciso nas atividades do dia-a-dia. As duas principais vantagens desta abordagem so: 1) economia de esforo ao abrir mo do detalhamento de longo prazo, pois difcil fazer previses sobre o futuro e a alta chance de mudanas durante a execuo invalida facilmente especificaes minuciosas; 2) detalhes no longo prazo trazem a falsa sensao de certeza, pois os indivduos passam a tratar previses detalhadas como predies. Equipes geis revem seus planos constantemente. A cada planejamento, elas tm a oportunidade de avaliar as condies do projeto e, baseadas nesses fatos, traar o melhor caminho para atingir seus objetivos. Esta estratgia mantm os planos e a execuo sempre adequados realidade, que inevitavelmente esto em mutao, significando identificar prioridades para cada momento do projeto.

Diante da mudana de cultura que o desenvolvimento gil causa nas empresas desenvolvedoras de software, algumas dificuldades podem surgir em sua

implementao como: apoio das instncias superiores, interao com outros departamentos e com os clientes.

5. Consideraes Finais
O desenvolvimento de software tradicional no possui um histrico de bons resultados, como mostrado no Chaos Report [4], onde uma pesquisa realizada em projetos de TI mostrou que a grande parte dos projetos entregue fora do prazo e ou do custo. E tambm se notou que o uso das funcionalidades disponibilizadas baixssimo. O resultado so projetos com grandes desperdcios e clientes insatisfeitos. As metodologias geis so interativas e incrementais, resultando em um produto desenvolvido com base na melhoria contnua, e como o cliente participa de todo o projeto, a sua satisfao normalmente garantida. Este trabalho conclui as metodologias geis apresentadas neste poderiam ser aplicadas de maneiras complementar ou alternativa s metodologias tradicionais. Conclui-se tambm que o Scrum, XP e o Lean Software Development poderiam ser empregados de maneira complementar entre si. O Scrum um framework focado principalmente em planejamento e gerncia. J o XP mais focado em prticas de
24

desenvolvimento. Mesmo assim, vrias prticas so coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game e assim por diante. O Lean Software Development entra como um conjunto c de princpios, valores e ferramentas para um desenvolvimento enxuto. enxuto. A Figura 5 a seguir apresenta a diagramao proposta: proposta

Figura 5. Complementaridade dos mtodos geis.

6. Referncias Bibliogrficas
[1] ] ARAUJO, R. C., GALINA, T. C.: Anlise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva gil. Universidade do Vale do Rio dos Sinos (Unisinos). So Leopoldo RS Brasil. 2007. [2] BECK, K.: Extreme Programming explained: Embrace change. Reading, Mass., AddisonAddison Wesley, 244 p. 1999. [3] ] BECK, K., et al.: Manifesto for Agile Software Development. Development 2001. Disponvel em <http://www.agilemanifesto.org>. Acesso em Junho de 2010. [4] CHAOS REPORT. . Disponvel em < www.standishgroup.com>. Acesso em Junho de 2010. [5] ] DEMING, W. E.: Out of the Crisis: Quality, Productivity, and Competitive Position. Cambridge ambridge University Press .1986. [6] DYBA, T., DINGSYR, DINGSYR T.: What do we know about Agile Software Development? Published by the IEEE Computer Society. 2009. [7] ] FILHO, D. L. B.: Experincias com desenvolvimento gil. Instituto de Matemtica e Estatstica da Universidade de So Paulo (Dissertao de Mestrado). Mestrado) 2008.

25

[8] FRANCO, E. F.: Um modelo de gerenciamento de projetos baseado nas metodologias geis de desenvolvimento de software e nos princpios da produo enxuta. Escola Politcnica da Universidade de So Paulo (Dissertao de Mestrado). 2007. [9] LEAN SOFTWARE INSTITUTE.: Introducing Lean Software Development. Disponvel em <http://www.leansoftwareinstitute.com/art_ilsd.php>. Acesso em maio de 2010. [10] KALERMO, J., RISSANEN, J.: Agile software development in theory and practice. Universidade de Jyvskyl, Finlndia (Dissertao de Mestrado). 2002. [11] LEAN INSTITUTE BRASIL. Disponvel vem <http://www.lean.org.br>. Acesso em Maro de 2010. [12] TOYOTA MOTOR MANUFACTURING. Disponvel <http://www.toyotageorgetown.com/history.asp >. Acesso em Maro de 2010. em

[13] PARNELL-KLABO, E.: Introducing Lean Principles with Agile Practices at a Fortune 500 Company. Proceedings of AGILE 2006 Conference. 2006. [14] POPPENDIECK, M.: Lean Software Development. 29th International Conference on Software Engineering. IEEE. 2007. [15] POPPENDIECK, M., POPPENDIECK, T.: Lean Software Development: An Agile Toolkit for Software Development Managers. Primeira Edio. Boston: Addison-Wesley Professional. 2003. [16] SCHWABER, K.; BEEDLE, M. Agile Software Development With Scrum. Primeira Edio. Upper Saddle River: Prentice-Hall. 2001.

26