Lean Agil v8

7/22/2019 Lean Agil v8

1/26

UNICAMP Universidade Estadual de CampinasFT Faculdade de Tecnologia

Metodologias geis no contexto dedesenvolvimento de software:

XP, Scrum e Lean

Autores:Aline Cristine FadelHenrique da Mota Silveira

Limeira - 2010


2/26

UNICAMP Universidade Estadual de CampinasFT Faculdade de Tecnologia

Metodologias geis no contexto dedesenvolvimento de software:

XP, Scrum e Lean

Autores: Aline Cristine FadelHenrique da Mota Silveira

Orientador: Prof. Dr. Marcos Augusto Francisco Borges

Limeira - 2010


3/26

Sumrio

Resumo

Abstract

1. Introduo

2. Metodologias geis

3. Estudo de Caso

4. Anlise e Discusso sobre as Metodologias geis Abordadas

5. Consideraes Finais

6. Referncias Bibliogrficas


4/26

Resumo

Este trabalho apresenta um estudo sobre metodologias geis, mais especificadamente os

mtodosLean 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.


5/26

1. IntroduoNa 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 softwarecom 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 Metodologiagil; 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 geisNesta 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 geisFilho [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 ospadres no mercado, eram bastante eficientes. Aplicando-as em vrios


6/26

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 serusada 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 desoftware com valor agregado;

2. As mudanas nos requisitos so bem-vindas, mesmo tardiamente nodesenvolvimento. Processos geis tiram vantagem das mudanas visando

vantagem competitiva para o cliente;

3. Frequentes entregas do software funcionando, de poucas semanas a poucosmeses, com preferncia menor escala de tempo;

4. As pessoas de negcio e desenvolvedores devem trabalhar diariamente emconjunto por todo o projeto;


7/26

5. Os projetos devem ser construdos em torno de indivduos motivados. Dandoo ambiente e o suporte necessrio e confiana para fazer o trabalho;

6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre umaequipe de desenvolvimento atravs de conversa face a face;

7. Softwarefuncionando 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 auto-organizveis;

12.Em intervalos regulares, a equipe deve refletir sobre como tornar-se maisefetiva, 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 softwarecom 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 produoem massa.

De acordo com oLeanInstituteBrasil [11], Lean uma estratgia de negcios para

aumentar a satisfao dos clientes atravs da melhor utilizao dos recursos. A Gesto

Leanprocura 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 necessidadesdos negcios e no na simples aplicao das ferramentas lean.


8/26

De acordo com Mary Poppendieck [14], o desenvolvimento de software Lean a

aplicao dos princpios da Toyotaproduct development systempara 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 aoLean.

2.2.1 Princpios

O pensamentoLeanfoca 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 incompletasgera desperdcio porque despendem

esforos para serem iniciadas e no adicionam valor ao software.

Pedaos de cdigo incompletostendem 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 documentosinfla 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.


9/26

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.

Esperaspor requisitos, por testes, por aprovao ou por feedbackretardam 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 seraplicado 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 absorvermudanas tratando os planejamentos como estratgias para atingir um objetivo e no


10/26

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 softwareno era valorizada, a estratgia de

no cometer erros era vista como mais importante. Porm, o desenvolvimento rpido do

softwaretem 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 softwareem 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 kanbando 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


11/26

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 iteraodeve 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].


12/26

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. ScrumInicialmente 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].


13/26

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 demudar 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 ApoioFilho [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 Backlogdo 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 oproduto deve possuir e que ainda no foram desenvolvidas;

Backlog Selecionado: Um subconjunto de funcionalidades que o clienteescolheu a partir do backlogdo produto para ser implementado no sprintatual e

que no pode ser modificado durante o sprint;

Backlog do Sprint: Lista priorizada, obtida a partir da quebra dos cartes dobacklogselecionado em tarefas menores;

Backlogde Impedimentos:Lista dos obstculos identificados pela equipe queno pertencem ao contexto do desenvolvimento;

Grficos de Acompanhamento:Grficos que medem a quantidade de trabalhorestante (burndown charts) so os preferidos em Scrum. recomendado faz-los

para vrias esferas do projeto: para o produto, para a releasee para o sprint.

2.3.1.2. Papis e ResponsabilidadesDe acordo com Franco [8], os papis no Scrum que possuem tarefas e propsitos

diferentes durante o processo e suas prticas so apresentados a seguir:


14/26

Cliente: participa das tarefas relacionadas definio da lista defuncionalidade do software sendo desenvolvido ou melhorado, elaborando os

requisitos e restries do produto final desejado.

Gerente: encarregado pela tomada das decises finais, utilizando asinformaes visuais disponibilizadas graficamente pelos padres econvenes 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 sobreas 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 ContnuasA 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


15/26


16/26

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 projetopodem 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 quepossa 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;


17/26

Feedback:todo problema deve ser evidenciado o mais cedo possvel para quepossa 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, parasolicitar 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 osdemais valores funcionem. Sem respeito, a Comunicao e o Feedbacksero

pouco eficientes e a Coragem de um membro poder ser nociva aos demaispor 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 econciso 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 quandocada requisito foi satisfeito. O cliente tambm define a prioridade de

implementao de cada requisito;


18/26

Testador:ajuda o cliente a escrever os testes funcionais. Ele tambm realizaos 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 aconformidade das estimativas feitas pela equipe de desenvolvimento (porexemplo, 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. Umprofundo conhecimento do XP importante para este papel, pois ele queguiar os outros envolvidos no projeto a executar o processo de forma

adequada;

Consultor: um membro externo com conhecimento tcnico especficonecessrio para o projeto. O consultor auxilia a equipe a resolver problemas

especficos;

Chefe: responsvel pelas tomadas de decises. Para isso, ele comunica-secom a equipe de projeto para determinar a situao atual e para identificarqualquer 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 oCliente 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 noprojeto (Clientes, Programadores, Gerente etc.) explicar como o sistema

funciona. Ela cria uma viso comum e sugere uma estrutura de como o


19/26

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 simplespossvel 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 deunidade 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 decdigo, melhorando a comunicao, simplificando e adicionandoflexibilidade;

Programao em pares: dois programadores escrevem o cdigo em umnico computador;

Propriedade coletiva: qualquer programador pode alterar qualquer parte docdigo 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 horaspor 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 acordocom regras que enfatizam a comunicao durante a codificao. Antes doincio 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.


20/26

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 CasoO 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 peloLeangil no desenvolvimento de seus produtos

de software.

Antes de qualquer ao ela necessitou reorganizar seus processos, e para isso utilizouos 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 projetosao mesmo tempo;

Execuo manual dos casos de testes sem os benefcios da automao;


21/26


22/26

4. Anlise e Discusso sobre as Metodologias geis AbordadasAs 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 poucadocumentao 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

Leanpodem 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 fasescompletamente 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 ametodologia escolhida e as habilidades da equipe. Desta forma, o processo


23/26

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 podereceber 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

permitefeedbackrpido 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 produtofinal 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;


24/26

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 paraatingir 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 FinaisO 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


25/26

desenvolvimento. Mesmo

sprint/desenvolvimento ite

game e assim por diante.

princpios, valores e ferra

apresenta a diagramao pr

Figu

6. Referncias Biblio[1] ARAUJO, R. C., GALINde Software, sob a PerspectiLeopoldo RS Brasil. 2007

[2] BECK, K.: Extreme ProWesley, 244 p. 1999.

[3] BECK, K., et al.: Man

. Acesso em Junho de 2010.

nvel em < www.standishgroup.com>. Acesso e

of the Crisis: Quality, Productivity, and Co1986.

, T.: What do we know about Agile Softwuter Society. 2009.

rincias com desenvolvimento gil. InstitutoSo Paulo (Dissertao de Mestrado). 2008.

Scrum/XP como

anning/planning

um conjunto de

igura 5 a seguir

Desenvolvimentos (Unisinos). So

, Mass., Addison-

. Disponvel em

Junho de 2010.

petitive Position.

re Development?

de Matemtica e


26/26

[8] FRANCO, E. F.: Um modelo de gerenciamento de projetos baseado nas metodologias geisde desenvolvimento de software e nos princpios da produo enxuta. Escola Politcnica daUniversidade de So Paulo (Dissertao de Mestrado). 2007.

[9] LEAN SOFTWARE INSTITUTE.: Introducing Lean Software Development. Disponvel em. 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 . Acesso emMaro de 2010.

[12] TOYOTA MOTOR MANUFACTURING. Disponvel em. Acesso em Maro de 2010.

[13] PARNELL-KLABO, E.: Introducing Lean Principles with Agile Practices at a Fortune 500Company. Proceedings of AGILE 2006 Conference. 2006.

[14] POPPENDIECK, M.: Lean Software Development. 29th International Conference onSoftware Engineering. IEEE. 2007.

[15] POPPENDIECK, M., POPPENDIECK, T.: Lean Software Development: An Agile Toolkitfor Software Development Managers. Primeira Edio. Boston: Addison-Wesley Professional.2003.

[16] SCHWABER, K.; BEEDLE, M. Agile Software Development With Scrum. PrimeiraEdio. Upper Saddle River: Prentice-Hall. 2001.

Documents

Lean Agil v8