Embed Size (px)
Citation preview
1
Universidade Estadual de Campinas Faculdade de Tecnologia
Adaptação do Scrum ao Modelo Incremental
Leonardo Bertholdo
Lidia Regina de Carvalho Freitas Barban
2
Leonardo Bertholdo
Lidia Regina de Carvalho Freitas Barban
Adaptação do Scrum ao Modelo Incremental
Monografia apresentada à Unicamp, junto à Faculdade
de Tecnologia, como pré-requisito para conclusão da
Disciplina FT027 – Tópicos em Computação (Gestão de
Projetos e Qualidade) sob orientação do Prof. Dr.
Marcos Augusto F. Borges.
LIMEIRA – SP
2010
3
Bertholdo, Leonardo; Barban, Lidia R. C. F.
Adaptação do Scrum ao Modelo Incremental, Limeira, 2010, 18 p. Monografia apresentada à Unicamp, junto à Faculdade de Tecnologia, como pré-requisito para conclusão da Disciplina FT027 – Tópicos em Computação (Gestão de Projetos e Qualidade).
4
Professor Dr. Marcos Augusto F. Borges -----------------------------------------------------------
5
SUMÁRIO
1 – INTRODUÇÃO ............................................................................................................... 1 1.1 – Contexto ....................................................................................................................... 1 1.2 – Justificativa .................................................................................................................. 1 1.3 – Objetivos ...................................................................................................................... 2 1.4 – Organização do Trabalho ............................................................................................ 2
2 – MODELO INCREMENTAL............................................................................................... 3
3 – SCRUM ............................................................................................................................... 5
4 – ESTUDO DE CASO ........................................................................................................... 9 4.1 – Ambiente do Estudo de Caso .......................................................................................... 9 4.2 – Métodos Utilizados ......................................................................................................... 9 4.3 – Descrição do Estudo de Caso ....................................................................................... 10 4.4 – Resultados e Constatações ............................................................................................ 10
5 – TRABALHOS RELACIONADOS ................................................................................... 12
6 – CONCLUSÃO .................................................................................................................. 13
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 14
6
LISTA DE FIGURAS
Figura 2.1: Modelo incremental ................................................................................................ 3 Figura 3.1: Visão do processo na metodologia Scrum ........................................................... 8 Figura 4.1: Modelo Incremental no produto Gerência da Planta ............................................ 9
7
RESUMO
Devido à crescente competitividade do mercado atual e aos prazos cada vez mais restritos impostos por seus clientes, as empresas de desenvolvimento de software vem buscando metodologias mais ágeis para gestão do desenvolvimento de software. Há alguns anos, para mitigar os efeitos dessa demanda, muitas empresas adotaram o modelo incremental, cujo principal conceito é o desenvolvimento e a entrega incrementais do software. Recentemente, surgiu uma nova abordagem, denominada Scrum, que procurou otimizar ainda mais a entrega do produto de software aos clientes. Pela experiência dos últimos anos, metodologias ágeis, como o Scrum, muitas vezes precisam ser adaptadas às reais necessidades da empresa. Como este tipo de adaptação foi ainda pouco estudado, o principal objetivo desta pesquisa é contribuir para os estudos de viabilidade relacionados à adaptação do Scrum a metodologias mais tradicionais como o modelo incremental. Para isso, é apresentado um estudo de caso, que mostra as principais dificuldades e benefícios decorrentes dessa adaptação. Palavras-chave: Modelo incremental, métodos ágeis, Scrum.
ABSTRACT
Due to the increasing competitiveness of the current market and the increasingly strict deadlines imposed by their customers, companies software development has been seeking methodologies more agile for management of software development. A few years ago, to mitigate the effects of this demand, many companies have adopted the incremental model, whose main concept is the incremental development and delivery of software. Recently, came a new approach, called Scrum, which sought to further optimize the delivery of the software product to customers. For the experience of recent years, agile methods, like Scrum, often need to be adapted to real companies needs. As this type of adaptation was still little studied, the main objective this survey is to contribute to feasibility studies related to adapting Scrum to more traditional methods such as the incremental model. For this, it is presented a case study that shows the main difficulties and benefits resulting from this adaptation. Keywords: Incremental model, agile methods, Scrum.
1
1 – INTRODUÇÃO
Nesse capítulo são apresentados o contexto em que se insere este trabalho acadêmico,
bem como os propósitos que levaram à sua realização. Também é mostrada uma breve
descrição da estrutura do trabalho desenvolvido.
1.1 – Contexto
Nos últimos anos, devido a mudanças no ambiente de negócios, as empresas de
desenvolvimento de software começaram a sofrer crescentes pressões para reduzir o time-to-
market. Isso se deveu principalmente à competitividade do mercado atual e aos prazos cada
vez menos flexíveis impostos pelos clientes. Visando atender às novas exigências, essas
empresas começaram a buscar modelos mais ágeis para gestão de projetos de
desenvolvimento de software.
Como alternativa, muitas empresas adotaram o modelo incremental, que combina
conceitos do modelo clássico, também conhecido como modelo em cascata, com a abordagem
evolucionária da prototipação e da iteração de processo. Conforme Sommerville (2007), No
modelo incremental, um sistema é dividido em incrementos que possuem conjuntos de
funcionalidades. O primeiro incremento é definido com as funcionalidades mais prioritárias, e
os incrementos subsequentes são definidos com as funcionalidades adicionais. Cada
incremento desenvolvido e validado é entregue ao cliente, que pode colocá-lo em operação e
assim começar a usufruir antecipadamente de parte do sistema solicitado.
Há poucos anos, surgiu uma nova abordagem para gestão de projetos de
desenvolvimento de software denominada Scrum. Trata-se de uma metodologia ágil que
utiliza conceitos semelhantes aos contemplados no modelo incremental, porém introduz uma
série de elementos que procuram otimizar ainda mais a entrega periódica de incrementos
funcionais do produto aos clientes. Entre as principais peculiaridades do Scrum estão: a
organização dos recursos em equipes pequenas e multidisciplinares, as iterações dos
incrementos (chamadas de sprints) normalmente mais curtas e o forte envolvimento do cliente
durante todo o processo de desenvolvimento.
1.2 – Justificativa
A implantação de metodologias formatadas, como o modelo incremental e o Scrum,
nem sempre são a melhor opção para uma empresa de desenvolvimento de software que
deseja otimizar suas entregas e a satisfação de seus clientes. Em alguns casos, nem todos os
2
conceitos utilizados em uma metodologia podem ser implementados no ambiente da empresa,
e outros conceitos considerados importantes para a empresa podem não ser contemplados pela
metodologia escolhida. Em situações como essa, o que normalmente ocorre é uma adaptação
da metodologia às necessidades da empresa. Esta adaptação muitas vezes acaba por criar uma
abordagem híbrida própria da empresa, que pode envolver inclusive conceitos de diversas
metodologias.
A adaptatividade é uma das características mais marcantes de metodologias ágeis
como o Scrum. No entanto, a adaptação dessas metodologias aos modelos tradicionais de
desenvolvimento de software é relativamente recente e, por este motivo, ainda pouco
pesquisada. Somando-se a este cenário a forte demanda por processos de desenvolvimento de
software mais ágeis, nota-se a importância da disseminação das recentes experiências de
combinação entre os modelos tradicionais e as novas metodologias ágeis.
1.3 – Objetivos
O principal objetivo deste trabalho é contribuir para a evolução dos conhecimentos
relacionados aos processos de adaptação de metodologias ágeis a modelos tradicionais de
desenvolvimento de software. Mais especificamente, tem como intuito obter informações
sobre a viabilidade da adaptação do Scrum ao modelo incremental.
Para isso, além de estudar as duas metodologias, foi utilizado como embasamento, um
caso real de adaptação da metodologia Scrum ao modelo incremental. Com isso, foi possível
elencar as principais dificuldades enfrentadas durante a transição do modelo formatado
(Incremental) para o modelo híbrido (Incremental/ Scrum), além dos benefícios decorrentes
dessa adaptação.
1.4 – Organização do Trabalho
Este trabalho contém uma introdução que é composta pelo contexto, a justificativa, o
objetivo e a organização do trabalho. No segundo capítulo, é apresentado o modelo
incremental de desenvolvimeno de software com suas principais características. O capítulo 3
descreve os conceitos mais importantes da metodologia para gestão de projetos de
desenvolvimento de software Scrum. O quarto capítulo expõe um estudo de caso, onde ocorre
a adaptação do Scrum ao modelo incremental vigente em uma empresa. O capítulo 5 cita
alguns trabalhos relacionados a esta pesquisa. Por fim, o último capítulo apresenta às
conclusões obtidas com este trabalho.
3
2 – MODELO INCREMENTAL
Podemos definir o modelo incremental como um processo de ciclo de vida iterativo
e incremental com características do ciclo de vida seqüencial (TRAMMELL, 1996). No
modelo em cascata as fases são seqüenciais: os requisitos são definidos, o projeto do sistema
é criado, implementado e testado, é feita a integração e teste de sistema para finalmente
entrar em produção.
“O modelo incremental combina elementos do modelo em cascata aplicado de maneira
iterativa” (PRESSMAN, 2006), ou seja, a cada incremento é fornecida uma parte do sistema
aos clientes. O cliente define quais são os serviços principais e a partir da identificação dos
serviços é feito o levantamento de requisitos e mapeado o primeiro incremento.
Os processos de especificação, projeto, implementação e testes são feitos a cada
incremento até o produto final ser entregue ao cliente gerando um sistema completo,
conforme mostra a Figura 2.1.
Figura 2.1: Modelo incremental
“Quando um modelo incremental é usado, o primeiro incremento é freqüentemente
chamado de núcleo do produto” (PRESSMAN, 2006) . O núcleo do produto serve de base
para os outros incrementos.
4
A cada incremento entregue ao cliente é desenvolvido um plano para o próximo
incremento. Este processo é feito a cada termino e início dos incrementos e tem por objetivo
alterar o núcleo do produto para atender o cliente (PRESSMAN, 2006).
A interação do usuário é primordial no desenvolvimento incremental principalmente
na definição dos principais serviços e no retorno (feedback) da utilização do sistema.
As principais características do modelo incremental segundo Sommerville (2007) são:
Os processos de especificação, projeto e implementação são concorrentes.
O sistema é desenvolvido em uma série de incrementos.
Ferramentas de apoio ao desenvolvimento interativo.
De acordo com Sommerville (2007), as vantagens do desenvolvimento incremental
são:
Entrega dos incrementos ao cliente, ou seja, partes do sistema em funcionamento.
Participação dos clientes ou usuários no processo de desenvolvimento incremental.
Alguns dos problemas do desenvolvimento incremental segundo Sommerville (2007)
são:
Problemas no gerenciamento de grandes sistemas
Problemas em montar um contrato para atender ambas as partes interessadas
5
3 – Métodologias Ágeis e SCRUM
Em 2001 um grupo de pesquisadores se reuniu com o intuito de criar melhores práticas
para o desenvolvimento de software. Do resultado da reunião criou-se “O Manifesto para
Desenvolvimento Ágil de Software” (MANIFESTO ÁGIL, 2001), modificando a importância
dos valores aplicados no desenvolvimento de software:
“Estamos descobrindo melhores modos de desenvolvimento de software fazendo-o e
ajudando outros a fazê-lo. Por meio deste trabalho passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano”
O manifesto também apresentou 12 princípios:
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para
o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto
por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o
suporte necessário e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe
de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.
6
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade é essencial e deve ser assumida em todos os aspectos do projeto.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-
organizadas.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então
refina e ajusta seu comportamento de acordo com a necessidade.
Definir um processo como “ágil” significa permitir que a equipe possa adaptar e
aperfeiçoar tarefas, manter apenas os trabalhos essenciais implementados, simplificar os
trabalhos essenciais, fazer entregas incrementais do software funcionando ao cliente o mais
rápido possível (PRESSMAN, 2006).
Scrum é uma metodologia ágil de desenvolvimento de software, seu nome está
relacionado a uma atividade que ocorre durante o jogo de rugby onde o grupo de jogadores se
juntam ao redor da bola e trabalham juntos para mover a bola pelo campo (PRESSMAN,
2006).
Os princípios do Scrum são compatíveis com o manifesto ágil:
Pequenas equipes.
O processo precisa ser adaptado para garantir que o melhor produto seja produzido.
Produzir incrementos de software.
Trabalho de desenvolvimento dividido.
Teste e documentação são realizados durante todo o desenvolvimento.
Os princípios do Scrum norteiam o processo de desenvolvimento de software que tem
as seguintes atividades: levantamento de requisitos, análise, projeto, evolução e entrega.
[Pressman, 2006]
Os papéis no Scrum são: Product Owner, Scrum Master e Time.
Scrum Master: Responsável por garantir o entendimento do processo do Scrum,
responsável por motivar e treinar a equipe.
Product Owner: Responsável pela priorização de requisitos que devem ser
implementados, ou seja, responsável pelo gerenciamento do Product Backlog (lista
de funcionalidades que serão implementadas no projeto).
7
Time (Equipe): Responsável pela execução e implementação das funcionalidades.
Eventos com duração fixa empregados no Scrum:
Sprint Planning Release: Reunião de Planejamento da Release
Sprint Planning Meeting: Reunião de Planejamento da Sprint
Sprint
Daily Scrum: Reunião Diária
Sprint Review: Revisão da Sprint
Sprint Retrospective: Restrospectiva da Sprint
O principais artefatos do Scrum são:
O Sprint: É uma interação de duas a quatro semanas, todas as sprint tem como
resultado um incremento do produto que pode ser entregue.
O Product Backlog: Lista priorizada do que o produto precisa ou pode ter.
Backlog da Sprint: Lista de tarefas para produzir o Backlog do Product em um
incremento entregável.
Burndown: É uma medida, pode variar dentro do contexto. Podemos ter um
Burndown de Sprint para medir o quanto falta ds tarefas dentro do tempo do Sprint.
Relacionamento entre os papéis, artefatos e eventos descritos na Figura 3.1:
O Product Owner, juntamente com o Scrum Master são responsável por manter a
lista priorizada de requisitos que devem ser implementados do Product Backlog.
A cada Sprint, o time decide quais itens do Product Backlog serão implementados
Sprint Backlog em uma reunião especial denominada Sprint Planning Meeting.
O time é responsável por implementar a funcionalidade escolhida e demostrar ao
Product Owner do Sprint – Sprint Review.
No final do Sprint o time faz uma revisão do trabalho – Retrospectiva do Sprint.
Uma reunião diária de 15 minutos denominada Daily Scrum é realizada. Na Daily
Scrum, cada desenvolvedor deve responder a três perguntas:
O que eu fiz desde a última Daily Scrum?
8
O que eu vou fazer hoje?
Existe algum obstáculo que me impeça de fazer o trabalho?
Figura 3.1: Visão do processo na metodologia Scrum
9
Projeto GP-5.2
Versão 5.2
Patch 5.2.2
Patch 5.2.1
Versão 5.2 Versão 5.2
Patch 5.2.1
4 – ESTUDO DE CASO
O propósito deste estudo de caso é adquirir conhecimento e experiência nos processos
de adaptação de metodologias ágeis a modelos tradicionais de desenvolvimento de software
por meio de um caso real. Em particular, espera-se contribuir com novas informações sobre a
viabilidade da adaptação do Scrum ao modelo incremental tradicional.
4.1 – Ambiente do Estudo de Caso
O ambiente escolhido para esse estudo de caso foi o de uma empresa de grande porte
que atua, entre outros segmentos, no desenvolvimento de aplicações voltadas para a área de
telecomunicações.
Esta empresa desenvolve um produto de software denominado Gerência da Planta, o
qual tem como principais clientes grandes operadoras do setor de telecomunicações.
Basicamente, este produto tem como finalidade gerenciar todas as informações relacionadas à
infra-estrutura da rede de telefonia instalada em campo, bem como os serviços que esta infra-
estrutura provê aos assinantes da operadora.
Até pouco tempo, a empresa utilizava o modelo incremental “puro” nos projetos de
evolução e manutenção deste produto, conforme ilustra a Figura 4.1. No entanto, há alguns
meses, passou a introduzir alguns conceitos da metodologia ágil Scrum em seu processo de
desenvolvimento de software.
Figura 4.1: Modelo Incremental no produto Gerência da Planta
4.2 – Métodos Utilizados
Devido à introdução do Scrum ainda estar em um estágio experimental, não foram
encontradas fontes textuais que explanassem detalhadamente como está se dando a adoção
deste novo paradigma.
10
Por este motivo, para coletar os dados para a análise do estudo de caso foi utilizada a
técnica de entrevistas. Os entrevistados foram escolhidos de acordo com o conhecimento e a
vivência que tinham nos projetos de evolução e manutenção deste produto. São eles: dois
coordenadores de projeto e dois líderes de equipe (equivalente ao papel de Scrum Master).
4.3 – Descrição do Estudo de Caso
Conforme foi dito, os projetos relacionados ao produto Gerência da Planta utilizavam
o processo de desenvolvimento baseado no modelo incremental. Com base nas entrevistas
realizadas, foram observadas as seguintes mudanças com a introdução de conceitos da
metodologia Scrum:
Os recursos passaram a ser divididos em equipes, sendo que cada uma delas passou
a ser responsável por uma feature do projeto dentro de um sprint do projeto. Essas
equipes são pequenas (até 10 pessoas) e multidisciplinares, envolvendo pessoas das
áreas de requisitos, desenvolvimento, banco de dados e testes.
Cada equipe passou a contar com um líder de equipe (algo equivalente ao papel do
Scrum Master), que atua como uma facilitador removendo eventuais obstáculos.
Cada feature do conjunto de features do projeto (Product Backlog) passou a ser
desenvolvida em um sprint que normalmente dura até 4 semanas.
Passaram a ser realizadas as Daily Meetings, que na verdade ocorrem em dias
alternados.
O gráfico Burndown Chart, que mostra a quantidade de horas restantes para a
conclusão do sprint em função do tempo, passou a ser utilizado.
4.4 – Resultados e Constatações
Pode-se notar que apenas alguns conceitos do Scrum foram utilizados puramente;
alguns foram adaptados e outros não implementados. Mesmo com a implementação parcial
desta metodologia, já foi possível observar alguns impactos positivos decorrentes da quebra
do paradigma do modelo incremental “puro”. A análise dos resultados desta mudança ainda
está na fase de coleta de indicadores, porém já foi percebida uma considerável melhora na
interação entre os membros das diferentes áreas (requisitos, codificação, banco de dados e
testes) envolvidas nos projetos. De acordo com as análises iniciais, outro efeito positivo foi
uma pequena redução nos esforços.
11
Uma das constatações desse estudo de caso está relacionada à multidisciplinaridade da
equipes que é recomendada pelo Scrum. Em outras palavras, cada um dos integrantes da
equipe deveria teoricamente possuir conhecimento genérico das diferentes áreas, que
abrangem a especificação, a construção e a validação do software. O ponto negativo dessa
característica é que muitas vezes um especialista pode acabar se envolvendo com assuntos que
não são de seu domínio, o que faz com que seu potencial não seja totalmente aproveitado.
Outra consideração a ser feita com relação aos recursos humanos, é que o líder da
equipe (papel que equivale ao Scrum Master) normalmente é um especialista da área de
codificação, e o ideal seria que fosse alguém com conhecimento genérico de outras áreas
também, como requisitos e testes. Ainda relacionado à questão da liderança, foi constatado
que apesar de existir um papel semelhante ao do Scrum Master – e um dos conceitos do
Scrum ser o autogerenciamento das equipes –, no modelo adaptado deste estudo de caso ainda
persiste o papel do coordenador de projeto.
Nesse modelo, as equipes e os sprints são organizados por feature do projeto (o
conjunto dessas features equivale ao Product Backlog). Pelo Scrum, ao final de cada sprint,
deveria ser entregue ao cliente um software com valor de negócio agregado. No entanto,
como as funcionalidades do produto em questão são grandes e muito interdependentes torna-
se difícil organizar os sprints de modo que cada um deles consiga entregar um software com
real valor de negócio. Por exemplo: no sprint 1 será desenvolvida a funcionalidade A, porém
esta funcionalidade somente faz sentido se for integrada à funcionalidade B, a qual será
desenvolvida no sprint 2. Nesse exemplo, pode-se ver que não faz sentido entregar o software
no sprint 1, já que esta entrega não agregará nenhum valor ao seu negócio para o cliente.
Devido a esta forte interdependência entre as funcionalidades do produto, os resultados dos
sprints intermediários não são entregues ao cliente.
Também pode-se notar que, por motivos de disponibilidade, não há envolvimento do
cliente (papel que seria equivalente ao Product Owner) em tempo integral. Para simular este
papel, quando é necessário tratar alguma questão referente ao produto que está sendo
desenvolvido, existe uma pessoa da área de requisitos que faz a interface com o cliente.
Por fim, como os integrantes que compõem as equipes não trabalham próximos
fisicamente, também foi observado que a falta de um leiaute adequado pode dificultar
relativamente a comunicação interna da equipe.
12
5 – TRABALHOS RELACIONADOS
Fagundes (2008) faz uma comparação entre os processos propostos pelos métodos
ágeis Scrum, XP (Extreme Programming), FDD (Feature Driven Development) e ASD
(Adaptive Software Development), visando a auxiliar a equipe de desenvolvimento na escolha
do método que melhor se adapte a suas expectativas. Para fazer a comparação, foram
utilizadas as tradicionais atividades do modelo incremental. Para cada atividade é apresentada
uma descrição da tarefa correspondente em cada método analisado.
Marçal (2008) apresenta um mapeamento entre o CMMI e a metodologia ágil Scrum,
mostrando as diferenças entre eles e identificando como as organizações estão adotando
práticas complementares em seus projetos para tornar essas duas abordagens mais integráveis.
A pesquisa pode ser útil para organizações que seguem o modelo CMMI e estão planejando
melhorar a agilidade dos seus processos, ou para ajudar as organizações a definir um novo
modelo de gestão do projetos baseando-se em ambas as metodologias.
Szimanski (2009) expõe um estudo de caso onde ocorre a extensão da metodologia
ágil Scrum para as áreas de processo do MPS.BR nível G aplicada em uma pequena fábrica de
software. Segundo os autores, o estudo realizado pode contribuir de forma relevante para
organizações que desejam promover a melhoria da qualidade dos seus produtos, por meio da
introdução de práticas ágeis no seu processo de desenvolvimento de software mantendo a
compatibilidade com o MPS.BR.
13
6 – CONCLUSÃO
Esta pesquisa foi realizada com a finalidade de contribuir para a evolução dos
conhecimentos relacionados aos processos de adaptação de metodologias ágeis a formas
tradicionais de desenvolvimento de software, como o modelo incremental. De certa forma,
podemos considerar o modelo incremental como um precursor do Scrum, pois um dos
principais conceitos desta última metodologia – a entrega periódica de software com valor de
negócio – está alinhado com a essência do modelo incremental.
Com o estudo de caso foram levantadas algumas questões que merecem reflexão
como: a dificuldade notória em se implantar integralmente os conceitos de metodologias ágeis
em um ambiente que utiliza um modelo mais tradicional, as possíveis desvantagens da
multidisciplinaridade das equipes e a dificuldade em se implementar de forma confiável e
eficiente o autogerenciamento das equipes. Também foi possível notar alguns obstáculos
existentes para se realizar entregas com real valor de negócio e de forma incremental, em
situações onde as funcionalidades do produto são grandes e muito interdependentes.
Baseado no estudo realizado, pode-se concluir que a decisão de adotar metodologias
ágeis no processo de desenvolvimento de software depende de vários fatores como: a
complexidade do produto de software, a maturidade e o comprometimento das equipes, a
disponibilidade do cliente, a cultura da empresa, entre outros. Como não existem prescrições
prontas que considerem as inúmeras combinações destas variáveis, a adoção dessas
metodologias demandará sempre uma análise aprofundada em cada caso, para avaliar quando
e como deverá ser implantada ou adaptada a metodologia escolhida.
14
REFERÊNCIAS BIBLIOGRÁFICAS
FAGUNDES, P. B.; DETERS, J. I.; SANTOS, S. S. Comparação entre os processos dos métodos ágeis: XP, SCRUM, FDD e ASD em relação ao desenvolvimento iterativo incremental. E-Tech: Atualidades Tecnológicas para Competitividade Industrial. Florianópolis, v. 1, n. 1, p. 37-46, 1º. sem. 2008.
MANIFESTO ÁGIL. Apresenta texto sobre o manifesto ágil. Disponível em: <http://agilemanifesto.org/>. Acesso em: 15 jun. 2010.
MARÇAL, A. S. C. et al. Blending Scrum practices and CMMI project management process areas. Innovations in Systems and Software Engineering, Londres, v. 4, n. 1, p.17-29, abr. 2008.
PRESSMAN, R. S. Engenharia de Software. 6ª ed. Rio de Janeiro: McGraw-Hill, 2006. 40, 41, 60, 69, 70 p.
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson, 2007. 552 p.
SZIMANSKI, F.; ALBUQUERQUE, J.; FURTADO, F. Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 161-170.
TRAMMELL, C. J. et al. The incremental development process in Cleanroom software engineering. Decision Support Systems 17, 1996, 55-71 p.
![[qCon Rio 2015] Arquitetura Incremental](https://img.document.onl/doc/110x75/5876fe0a1a28abf3398b6bd7/qcon-rio-2015-arquitetura-incremental.jpg)
