Download - 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
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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.
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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/22/2019 Lean Agil v8
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.
-
7/22/2019 Lean Agil v8
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.
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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].
-
7/22/2019 Lean Agil v8
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].
-
7/22/2019 Lean Agil v8
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:
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
15/26
-
7/22/2019 Lean Agil v8
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;
-
7/22/2019 Lean Agil v8
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;
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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.
-
7/22/2019 Lean Agil v8
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;
-
7/22/2019 Lean Agil v8
21/26
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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;
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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
-
7/22/2019 Lean Agil v8
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.