Processo Incremental de Desenvolvimento Ágil

Prévia do material em texto

Conteudista: Prof. Me. Artur Ubaldo Marques Junior
Revisão Textual: Prof.ª Esp. Lorena Garcia Aragão de Souza
Material Teórico
Material Complementar
Referências
Conceituação do Processo Incremental Ágil
Muitos alunos, quando em início de carreira ou mesmo ainda em sala de aula, fazem a
seguinte pergunta: “Professor, para que tanto modelo de desenvolvimento de software se o que
interessa para o patrão é que o sistema esteja desenvolvido e funcionando? Acho isso uma
grande perda de tempo.”
Bem, infelizmente estamos diante de uma visão míope e simplista, não apenas do
funcionamento do mundo, mas de toda uma pro�ssão que se iniciou há muito tempo, lá na
década de 1960, do século XX: a engenharia de software.
As metodologias servem para que possamos criar nosso software segundo alguns tipos de
receita, dependendo da resposta para algumas perguntas. Claro que logo no início havia um
grande arcabouço metodológico que prometia servir para tudo e que na época serviu muito
bem. Estamos falando do famoso Método em Cascata ou Waterfall. Essa metodologia serviu tão
bem, que até uns 15 anos atrás, ainda era a metodologia hegemônica em todo o planeta. Mas
as coisas mudaram: houve, ainda em meados da década de 1960 do século XX, a famosa crise
1 / 3
Material Teórico
 Objetivo da Unidade:
Conhecer os fundamentos do processo incremental de software aplicado ao
desenvolvimento ágil.
do software, a qual trouxe novas alternativas metodológicas para a criação de softwares
melhores, mais rápidos, com menores riscos, mais participativos ao cliente,
fundamentalmente mais baratos e que agregavam valor perceptível ao cliente, levando em
conta a possibilidade de mudanças no decorrer do período de desenvolvimento, a�nal um
negócio não é estático e a adaptação é o que manda no jogo do desenvolvimento de software.  
 
Quanto mais valor, mais entrega aos clientes no mercado. Fato este que nos dias de hoje, com
a concorrência globalizada, convenhamos, é fundamental. Então, podemos resumir a situação
da seguinte maneira: existem alguns cenários em que o cliente precisa que o produto de
software seja desenvolvido passo a passo. Ou seja, implantação básica do produto na primeira
etapa, com possibilidade de que o cliente queira, posteriormente, desenvolver o produto
completo. Seria uma situação ideal, na qual não há mudanças, o cliente sabe passar o que quer
e os analistas de negócios e de sistemas conseguem entender esse “querer”, executando,
assim, o serviço corretamente.
Bem, essa “situação ideal” é raríssima de acontecer e para dizer a verdade, você di�cilmente a
verá.
O normal de acontecer é: o cliente ainda não saber ou não ter certeza do que quer, no tocante
ao negócio em si, o que torna tudo mutável e passível de sofrer mudanças a qualquer instante.
Então, o modelo de processo citado no parágrafo anterior (a situação ideal) não nos serve,
uma vez que no mundo em que vivemos, a mudança é a única certeza que temos. Nesse caso,
temos que ter outros métodos que possam representar o que ocorre no mundo atual e o que é
necessário para se desenvolver sistemas que estejam em um ambiente altamente incerto e
volátil. O processo incremental pode ser um desses métodos.
Processo Tradicional (Cascata ou Waterfall)
Vou descrever de forma rápida, pois aqui faremos isso apenas para contextualizar e situar o
modelo incremental, para que você já possa perceber criticamente as diferenças entre eles.
O modelo em cascata é um modelo clássico usado no ciclo de vida de desenvolvimento de
sistema para criar um produto de software, utilizando uma abordagem linear e sequencial. É
denominado em cascata porque o modelo se desenvolve sistematicamente de uma fase para
outra, de forma descendente. Esse modelo é dividido em diferentes fases e a saída de uma fase
é usada como entrada da fase seguinte. Cada fase deve ser concluída antes do início da
próxima fase e não há sobreposição entre elas.
As fases sequenciais descritas no modelo em cascata são:
Coletar requisitos. Todos os requisitos possíveis são capturados nos documentos de
requisitos do produto. Presume-se que TODOS foram elicitados e são conhecidos, porque
não há possibilidade de “mudança de requisitos” após essa fase.
Analisar o requisito e com base nessa análise, de�nir os esquemas, modelos e regras de
negócio.
Projetar o sistema baseado na análise do projeto da arquitetura do software.
Desenvolver a implementação do software nas pequenas unidades com teste funcional.
Integrar e realizar o teste de integração de cada unidade desenvolvida na fase anterior,
bem como o teste de pós-integração de todo o sistema, para corrigir eventuais falhas.
Implantar o sistema. Colocar o produto no ambiente de produção após a conclusão de
todos os testes funcionais e não funcionais.
Manter ou corrigir problemas e lançar novas versões com os patches de problemas
corrigidos, conforme necessário.
Figura 1 – Modelo Waterfall ou Cascata
Processo Incremental
O principal objetivo do modelo incremental é desenvolver um produto com recursos básicos
na primeira etapa e desenvolver o produto ou adicionar novos recursos nas etapas seguintes.
Utilizamos esse processo quando:
Os requisitos são claramente especi�cados. No entanto, alguns requisitos precisam de
tempo para serem aclarados;
Quando houver demanda para o lançamento antecipado do produto ou necessidade de
colocar o produto no mercado antecipadamente;
Quando a equipe de engenharia de software não é altamente quali�cada ou os recursos
com o conjunto de habilidades necessárias não estão disponíveis;
Quando pessoas de alto risco (partes interessadas complexas ou con�itantes) estão
envolvidas;
Quando for o desenvolvimento de produto por empresa própria com base no produto;
Quando uma nova tecnologia é usada;
Quando os recursos e objetivos são de alto risco;
Quando os projetos têm cronogramas de desenvolvimento longos e há alto grau de
incerteza (risco).
No modelo incremental, todo o requisito é dividido em várias compilações. Múltiplos ciclos de
desenvolvimento ocorrem aqui, tornando o ciclo de vida um ciclo de múltiplas cascata. Os
ciclos são divididos em módulos menores e mais fáceis de gerenciar.
Primeiro, um sistema de trabalho simples implementando apenas alguns recursos básicos é
criado e em seguida entregue ao cliente. Depois, muitas interações ou versões sucessivas são
implementadas e entregues ao cliente, até que o sistema desejado seja liberado.
Para você que gosta de de�nições, vamos lá: o modelo incremental é um processo de
desenvolvimento de software onde os requisitos são divididos em vários módulos autônomos
do ciclo de desenvolvimento de software. Nesse modelo, cada módulo passa pelas fases de
requisitos (design, implementação e teste). Cada versão subsequente do módulo adiciona
função à versão anterior. O processo continua até que o sistema completo seja alcançado.
Como Sommerville (2019) bem descreve, não é tarefa simples implementar o modelo
incremental, principalmente em grandes empresas com procedimentos de engenharia
padronizados e em organizações onde o desenvolvimento de software é terceirizado para um
contratante externo, por isso ele descreve as di�culdades encontradas:
“Problemas de gerenciamento: As estruturas de gerenciamento de software para grandes
sistemas são con�guradas para lidar com um modelo de processo de software que gera
entregas regulares para avaliar o progresso. Os sistemas desenvolvidos de forma incremental
mudam rapidamente, por isso não é econômico produzir muita documentação do sistema.
Além disso, o desenvolvimento incremental às vezes pode exigir o uso de tecnologias
- SOMMERVILLE, 2019, p. 1
desconhecidas para garantir a entrega rápida do software. Os gerentes podem achar difícil usar
a equipe existente em processos de desenvolvimento incrementais porque eles não têm
conhecimento e experiência dessas tecnologias.
Problemas contratuais: O modelo contratual normal entre um cliente e um desenvolvedor de
software ébaseado em uma especi�cação de sistema. Quando não há especi�cação, pode ser
difícil projetar um contrato para o desenvolvimento do sistema. Os clientes podem �car
insatisfeitos com um contrato que simplesmente paga aos desenvolvedores pelo tempo gasto
no projeto, pois isso pode levar ao aumento de funções e estouros de orçamento; os
desenvolvedores provavelmente não aceitarão um contrato de preço �xo porque não podem
controlar as alterações solicitadas pelos usuários �nais.
Problemas de validação: Em um processo baseado em especi�cações, a veri�cação e a
validação têm como objetivo demonstrar que o sistema atende às suas especi�cações. Uma
equipe V&V – Veri�cação e Validação,  independente pode começar a trabalhar assim que a
especi�cação estiver disponível e pode preparar testes em paralelo com a implementação do
sistema. Os processos de desenvolvimento iterativo tentam minimizar a documentação e
intercalar a especi�cação e o desenvolvimento. Consequentemente, a validação independente
de sistemas desenvolvidos incrementalmente é difícil.
Problemas de manutenção: A mudança contínua tende a corromper a estrutura de qualquer
sistema de software. Isso signi�ca que qualquer pessoa além dos desenvolvedores originais
pode achar o software difícil de entender. Uma maneira de reduzir esse problema é usar a
refatoração, em que as estruturas de software são continuamente aprimoradas durante o
processo de desenvolvimento.
Problemas de tecnologia: Se a tecnologia (ferramentas e ambientes) for instalada para dar
suporte ao desenvolvimento incremental, o processo de desenvolvimento dependerá do
suporte contínuo para essa tecnologia. Se o fornecedor de tecnologia retirar o suporte ou
fechar as portas, o processo de desenvolvimento incremental será interrompido. ”
Em tempo, quando nos referimos à refatoração, queremos dizer que não se altera a
funcionalidade, mas a otimizamos deixando um código mais limpo, mais e�ciente e menos
custoso ao sistema como um todo, em outras palavras, leve e e�ciente.
Existem paradigmas de engenharia de software como o XP – Extreme Programming que tem
como um de seus princípios a refatoração de código levada ao extremo, exatamente para
deixar o código inteligível e útil.
Ciclo de vida (natureza e características)
O modelo incremental é o processo de desenvolvimento de software no qual os requisitos
seriam divididos em vários desenvolvimentos independentes do ciclo de desenvolvimento de
software.
Cada incremento é tratado como um subprojeto e segue todas as fases do ciclo de vida do
SDLC – Software Development Life Cycle (Ciclo de Vida de Desenvolvimento de Software). Nesse
caso, o processo incremental segue todas as fases de requisitos (análise, design,
desenvolvimento, teste e implementação). A funcionalidade de desenvolvimento em cada
incremento é uma adição à funcionalidade desenvolvida anteriormente. Esses ciclos de
incrementos são repetidos até que o software de destino esteja totalmente desenvolvido. Cada
incremento é atribuído com uma prioridade e os requisitos de alta prioridade do software
tratado são feitos primeiro. Depois que o incremento é desenvolvido, o incremento especí�co
é congelado e passa para os próximos requisitos de incremento.
 Importante!
Incremento entregue é CONGELADO (ou seja, não se
mexe mais);
Em qualquer momento especi�cado, o plano se
concentra no incremento atual apenas sem ter qualquer
Figura 2 – Visão geral do Processo Incremental
Como você deve ter observado na �gura 2, o processo nada mais é do que uma série de
versões que vão sendo acrescentadas como camadas, complementando o produto de
tipo de plano de longo prazo;
A cada incremento seguindo esse processo há uma
revisão completa para decidir se continuará para a
próxima fase ou não;
Se o incremento passou no teste ou �uxo de validação,
passa-se para o próximo incremento da �la, de acordo
com a prioridade (os incrementos podem ter suas
prioridades modi�cadas; mas se o incremento está
iniciado, não se mexe mais, vai-se até o �nal).
software até que ele esteja completo e o produto �nal seja apresentado.
Então, sob o aspecto daquele primeiro ciclo de vida tradicional que escrevi como sendo o
Modelo Cascata (Waterfall), podemos inferir que o processo incremental é simplesmente
(guardando as devidas considerações) uma sequência de pequenas cascatas, representadas na
Figura 2, do “Incremento 1” ao “Incremento n”. Isso foi uma resposta bastante engenhosa na
época para “agilizar” o ciclo de desenvolvimento tradicional que tomava muito tempo, pois
como as fases eram sequenciais, “tentava-se adivinhar” todos os requisitos de uma só vez, a
�m de fazer tudo de uma vez e depois entregar. Porém, o que acontecia era que mais da
metade dos requisitos e necessidades dos clientes mudavam completamente, dilacerando o
software ao ponto dele não “servir para quase nada”. 
Com pequenas entregas sustentáveis e úteis (que chamamos de “versões”), o cenário �cou
sensivelmente melhor, claro que não ainda o ideal, caso contrário, não teríamos tantos outros
métodos. Mas, uma coisa é certa: foi um embrião perceptível das metodologias ágeis que
estariam por vir.
Figura 3 – Analogia dos Incrementos
Na Figura 3, A, B, C e D são módulos de Produto de Software que são desenvolvidos e entregues
de forma incremental. Portanto, a última entrega em D deve completar o produto de software.
Não obstante, você deve ter percebido também que cada incremento entrega uma parte do
software totalmente funcional para o cliente, sendo que os outros vão gerando acréscimos que
vão complementando até a entrega �nal.
Vamos conhecer um pouco de cada fase do ciclo:
Requisitos – o analista de negócios participa das reuniões com o cliente para
levantamento dos requisitos. Depois, ele converte os requisitos de negócios em
requisitos técnicos com a ajuda de membros seniores da equipe, como especialistas no
assunto e líderes de equipe. Os requisitos técnicos são documentados e reunidos em um
documento denominado documento SRS – Software Requirement Speci�cation ou em
português ERS – Especi�cação de Requisitos de Software. Lembre-se, não é um processo
ágil atual, no qual os requisitos são levantados a partir de narrativas de usuário nos
cartões de história, portanto, é um documento formal.
O SRS consiste em todos os requisitos técnicos para todos os sistemas envolvidos, incluindo
aplicativos inter-relacionados, se houver. Portanto, é bastante diferente de um método ágil
moderno, no qual os requisitos são levantados para uma ou duas sprints (no máximo), que
leva em conta a descoberta conforme o sistema evolui, detalhando quando as próximas
sprints tiverem vez de se desenvolver. O documento SRS deve ser enviado para aprovação do
cliente (ou do especialista responsável do cliente) para prosseguir com as próximas fases.
Design e desenvolvimento – fase de design que transforma os requisitos do ERS em um
plano de design denominado DDS - Design Document Speci�cation ou em português DED -
Documento de Especi�cação de Design. Os desenvolvedores pegam os requisitos do ERS e
criam seus designs preliminares (modelos de trabalho), especi�cam como o
software funciona, como o novo design se parece, como o �uxo de controle de tela para
tela acontecerá, entre outros. A fase de design também inclui a arquitetura, a interface do
usuário, plataformas, programação, comunicações e segurança. Portanto, a arquitetura
geral do sistema é projetada de�nindo sua funcionalidade para cada módulo que inclui
sua interação com sistemas cruzados. Então os Devs começam a programar com o código
seguindo os padrões de codi�cação da organização ou algum Padrão de Design como GOF
– Gang of Four ou MVC – Modeling, View, Control. Uma vez que a codi�cação é concluída,
compilamos e depuramos os programas para veri�car se o novo código está funcionando
ou não.
Testes – depois que a codi�cação é concluída, o código é testado para veri�car se está
funcionando conforme o esperado ou não. O desenvolvedor executaos testes de unidade
(ou teste de integração) antes de passar o código para a equipe de teste. Os vários testes
que a equipe realizará são os de qualidade, de sistema, de aceitação e de aprovação.
Implementação – depois que o software for totalmente testado e não tiver defeitos ou
erros, os resultados do teste serão revisados pelo cliente que fornecerá a aprovação para
a implantação. Depois que o software foi implantado na produção, a nova funcionalidade
estará disponível para os usuários �nais que estão usando o sistema.
Por �m, vamos entender as vantagens, desvantagens e principalmente onde podemos usar,
a�nal haverá casos em que você precisará re�etir e com certeza pedirão a sua opinião sobre o
caso.
Vantagens do modelo incremental:
Gerar software funcional de forma rápida e precoce durante o ciclo de vida do software.
Maior �exibilidade e menor dispêndio de recursos para alterar o escopo e os requisitos.
É mais fácil testar e depurar durante uma iteração menor.
Nesse modelo o cliente pode responder a cada construído.
Reduz o custo de entrega inicial.
Mais fácil de gerenciar o risco porque as partes arriscadas são identi�cadas e tratadas
durante a iteração.
Desvantagens do modelo incremental:
Precisa de um bom planejamento e design, o que requer uma equipe com maior
experiência.
Precisa de uma de�nição clara e completa de todo o sistema antes que possa ser
decomposto e construído de forma incremental.
O custo total é maior do que a cascata.
Quando usar o modelo incremental:
Esse modelo pode ser usado quando os requisitos do sistema completo são claramente
de�nidos e compreendidos.
Os principais requisitos devem ser de�nidos; no entanto, alguns detalhes podem evoluir
com o tempo.
É necessário colocar um produto no mercado o quanto antes.
Uma nova tecnologia está sendo usada.
Recursos com o conjunto de habilidades necessárias não estão disponíveis.
Existem alguns recursos e metas de alto risco.
O Modelo Ágil e suas Metodologias 
Vamos colocar alguma informação para que você possa entender e diferenciar o processo
incremental que acabamos de ler. 
O Modelo Ágil é um processo iterativo contínuo, focado nas pessoas e nos resultados, que
envolve as atividades de desenvolvimento e teste juntas ao longo do Ciclo de Vida de
Desenvolvimento de Software. 
É uma combinação dos modelos Iterativo e espiral de Boehm. No modelo Ágil, cada projeto é
dividido em versões e cada versão é dividida em pequenos intervalos de tempo chamados
iterações ou sprints, dependendo do modelo ágil adotado. 
Cada iteração dura de duas a quatro semanas. Para desenvolver e implementar a metodologia
Ágil, as equipes que trabalham no modelo devem estar prontas para seguir os Princípios
Básicos do Modelo Ágil.
De acordo com o site Agile Alliance:
Isso, para ser executado, exige forte comprometimento comportamental dos indivíduos,
criando o que se chama de mentalidade ágil, que envolve aceitar e adotar mudanças úteis e que
gerem valor.
- AGILE ALLIANCE, 2019
“Agile é a capacidade de criar e responder às mudanças. É uma maneira de lidar e, �nalmente,
ter sucesso em um ambiente incerto e turbulento. Enquanto isso, “Desenvolvimento ágil de
software é um termo genérico para um conjunto de estruturas e práticas baseadas nos valores
e princípios expressos no Manifesto para software ágil. ”
Vejamos o sistema de gerenciamento de projeto de software: confundido rotineiramente como
um processo de desenvolvimento, pelos menos informados. Na verdade, scrum é um sistema
de gestão e não de engenharia. Mas, como os outros métodos ágeis pecavam nisso, nada mais
justo que o SCRUM esteja disseminado por todos os cantos do mundo atual.
Conforme o site Scrumguides.org (2018), a partir do início dos anos 1990, o Scrum começou a
ser amplamente utilizado em todo o mundo, para desenvolver software, hardware, software
embarcado, redes de funções interativas, veículos autônomos, escolas, governo, marketing,
gerenciamento da operação de organizações e quase tudo o que usamos em nossas vidas
diárias, como indivíduos e sociedades.
À medida em que as complexidades tecnológicas (de mercado e ambientais) e suas interações
aumentam rapidamente, a utilidade do SCRUM em lidar com a complexidade é comprovada
diariamente.
Em essência, quando falamos de SCRUM estamos tratando de uma equipe pequena (entre
cinco e nove pessoas) quando você inclui o dono do produto; já o Scrum Master trata-se de
algo entre sete e onze pessoas (tente não ultrapassar isso) altamente �exíveis e adaptáveis,
que colaboram e interoperam por meio de so�sticadas arquiteturas de desenvolvimento e
ambientes de liberação de destino, ou seja, versionamento de softwares e funcionalidades.
Para trabalharmos com SCRUM há um guia mantido por dois dos pro�ssionais que elaboraram
e participaram ativamente não apenas do manifesto ágil, mas do desenvolvimento de
metodologias, que hoje são o arcabouço da agilidade no geral e do SCRUM, em particular: Ken
Schwaber e Je� Sutherland, portanto os criadores do SCRUM.
Figura 4 – Característica circular do SDLC Ágil (Ciclo de
Vida do Desenvolvimento de Software Ágil)
Fonte: Adaptada de Getty Images
Lembrando rapidamente os componentes de uma equipe SCRUM:
Scrum Master – é responsável pela criação da equipe, pela reunião do sprint e por remover
os obstáculos ao progresso do projeto.
Product Owner (Proprietário do produto) – cria um backlog do produto, prioriza o backlog e
é responsável pela entrega da funcionalidade a cada iteração.
Equipe Scrum – gerencia seu próprio trabalho e organiza o trabalho para concluir o
sprint ou ciclo.
Há alguns princípios que são importantes conhecer:
“A equipe é auto-organizada: O Guia Scrum é bastante claro sobre isso, a�rmando que
"Ninguém (nem mesmo o Scrum Master) diz à Equipe de Desenvolvimento ...”  como realizar o
trabalho. A equipe é composta por indivíduos motivados, competentes e deve possuir
con�abilidade da empresa. O que frequentemente encontramos é alguém fora da equipe dizer
a equipe o que fazer, e esse alguém é o Scrum Master. Por vezes, é o gerente de
desenvolvimento ou, outra gerente funcional. De qualquer forma, a equipe não é con�ável ou
con�gurada para operar sem essa dependência. Portanto, essa falta de autonomia prejudica a
adesão e a motivação dos membros da equipe.
O Scrum Master é um líder servo que ensina a equipe do Scrum como se auto-organizar. O papel
do Scrum Master é amplamente mal compreendido. Como o nome indica, o Scrum Master deve
dominar o SCRUM. Eles não são gerentes de projetos. Em vez disso, eles são um tutor que
ensina a todos o SCRUM e ajuda a equipe a se auto-organizar. Se bem-feito, o Scrum Master
sairia do trabalho à medida que a equipe aprende e cresce. Vemos frequentemente o Scrum
Masters que não conhecem SCRUM, não saberem atuar nem como tutores e nem como líderes
e portanto, não sabem como ajudar as equipes a se auto-organizarem. Eles geralmente vêm
de outros papéis e carregam a bagagem desses papéis. Eles frequentemente se sentem
compelidos a tomar decisões e a dizer à equipe o que fazer. Em vez de tornar a equipe
independente, esses Scrum Masters se fazem tornar indispensáveis.
O Scrum Master não precisa participar do Daily Scrum. Essa é uma regra interessante que se
alinha à regra anterior. O pensamento tradicional é que uma pessoa - normalmente o gerente
do projeto - hospeda e dirige a reunião de status. Não é assim que as coisas funcionam no
Scrum. O Daily Scrum não é uma reunião de status, é uma reunião para os membros da equipe
coordenarem seu trabalho e garantirem que estão no caminho certo para alcançar seu objetivo
da sprint. O motivo pelo qual o Scrum Master não pode participar da reunião é porque eles não
são necessários na reunião. Scrum Masters novos ou inábeis podem realmente fazer mais mal
comparecendo do que bem.
O Scrum Master é responsável por garantir que a Reunião diária do Scrum ocorra, que seja e�caz
e que seja mantida dentro do prazo de 15 minutos. A equipedeve ter a reunião,
independentemente de o SM estar presente ou não. As equipes de Scrum devem trabalhar de
forma multifuncional sem transferências. As equipes tradicionais trabalham como se
estivessem realizando uma corrida de revezamento: membros especializados da equipe
entregam o trabalho em uma fase a diferentes especialistas na próxima fase. As transferências
entre os silos são geralmente a maior área de risco. Espera-se que as equipes
Scrum colaborem e trabalhem de forma multifuncional em um ou alguns itens de cada vez.
Dentro da equipe Scrum, você não deve ouvir os membros da equipe falando sobre a "equipe
de front end" ou a "equipe de controle de qualidade". A equipe do Scrum deve estar operando
como um todo.
Realize eventos do Scrum ao mesmo tempo e local. Os eventos do Scrum devem estar no
calendário e realizados ao mesmo tempo e colocar cada sprint. Essa prática ajuda a criar
consistência e evitar o desperdício associado ao reagendamento de reuniões ou à reserva
dupla de pessoas e salas. O que vemos ocorrendo é que as reuniões são remarcadas, mantidas
fora de sequência ou simplesmente canceladas. Muitas organizações operam em um ciclo
contínuo de combate a incêndios e não veem que a adesão a uma estrutura como o SCRUM os
ajudaria a minimizar esses incêndios. Além disso, faça as reuniões na sequência correta, da
maneira como foram projetadas. Eu observei uma reunião de que foi realizada no meio do
sprint. Os membros da equipe já haviam esquecido o que aconteceu no sprint anterior e não
foram capazes de incorporar melhorias na próxima.
O proprietário do produto é a única fonte de trabalho para a equipe. O objetivo desta regra é ter
um tomador de decisão que priorize o trabalho para a equipe. Ninguém mais pode dizer à
equipe o que fazer, e a equipe não deve agir de acordo com o que os outros dizem. O
proprietário do produto possui a lista de pendências e todo o trabalho é re�etido na lista de
pendências. Existem algumas maneiras pelas quais as organizações quebram essa regra.
Alguns não atribuem o proprietário de um produto. Alguns têm um proprietário do produto,
mas não permitem que o proprietário do produto seja o proprietário e priorize a lista de
pendências; em vez disso, o Scrum Master, o gerente de projetos ou o gerente funcional o
Vamos descrever de forma fundamental o Processo Ágil. 
A etapa principal em todo o processo ágil é a iteração. Cada iteração tem diferentes fases para
entregar o software ou produto funcional em cada iteração. O processo Ágil tem diferentes
etapas no tratamento do projeto. Esses são:
Conceito – selecionar o projeto, priorizando-o e adicionando-o à �la de desenvolvimento
com o cronograma e planejando os cronogramas do projeto.
Início – iniciar o projeto. Identi�car a equipe e o conceito de alto nível do projeto que foi
discutido com os membros da equipe.
Sprints/Iteração – a equipe trabalha para entregar software funcional com base em
requisitos de iteração e feedback.
Implantação – implantar o produto em produção. Depois que o produto desenvolvido é
aprovado em todos os casos de teste no �nal da iteração, ele é implantado na produção.
Se não for aprovado, será movido para a próxima iteração para resolver os problemas.
Manutenção – atividades pós-implantação.
Portanto, as fases do modelo ágil são especi�cadas da seguinte maneira:
- MERSINO, 2018, p. 2-3
fazem. Às vezes, há um proprietário do produto priorizando o trabalho, mas os membros da
equipe ainda são orientados a trabalhar em outros itens.
Não há títulos na equipe SCRUM além do desenvolvedor. O motivo dessa regra é incentivar o
comportamento multifuncional, evitar subequipes e promover a propriedade da equipe. O
SCRUM procura evitar as ine�ciências dos líderes de equipe e subequipes especializadas dentro
da equipe. Cada membro da equipe é responsável por participar totalmente da equipe. As
equipes do Scrum trabalham como equipes de Rugby, com o único objetivo de mover a bola
para o campo.”
Figura 5 – Representação do modelo ágil
Fonte: Adaptada de Getty Images
Para não deixar dúvidas, o escopo e os requisitos do projeto são de�nidos no início do
processo de desenvolvimento. Os planos relativos ao número de iterações, a duração e o
escopo de cada iteração são claramente de�nidos com antecedência.
Quanto às fases:
Levantamento de requisitos – nessa fase, você deve de�nir os requisitos. Você deve explicar
as oportunidades de negócios e planejar o tempo e o esforço necessários para construir o
projeto. Com base nessas informações, você pode avaliar a viabilidade técnica e econômica.
Projete os requisitos – depois de identi�car o projeto, trabalhe com as partes interessadas
para de�nir os requisitos. Podemos usar um diagrama UML de alto nível para mostrar o
trabalho de novos recursos e mostrar como ele se aplicará ao seu sistema existente.
Sprint/iteração – quando a equipe de�ne os requisitos, o trabalho começa. Designers e
desenvolvedores começam a trabalhar e codi�car, sempre visando implantar um produto
funcional. O produto passará por vários estágios de aprimoramento, por isso inclui uma
funcionalidade simples e mínima.
Teste – nessa fase, a equipe de Garantia de Qualidade examina o desempenho do produto e
procura por algum erro ou anomalia comportamental.
Implantação – nessa fase, a equipe lança um produto para o ambiente de trabalho do usuário.
Feedback – depois de lançar o produto, a última etapa é o feedback. Nele, a equipe recebe um
retorno sobre o produto e trabalha por meio de melhoria contínua para a próxima iteração ou
sprint.
Há muitos modelos derivados desse SDLC Ágil descrito. Exemplos incluem (mas não se
esgotam) em:
Scrum - Ken Schwaber e Je� Sutherland
Cristal - Alistair Cockburn
Método de Desenvolvimento Dinâmico de Software (DSDM)
Desenvolvimento orientado a recursos (FDD) - Je� De Luca
Desenvolvimento orientado a testes (TDD) - Kent Beck
Desenvolvimento Lean de Software
Programação Extrema (XP) - Kent Beck
Indicações para saber mais sobre os assuntos abordados
nesta Unidade:
Vídeos
LORENZ, W. G. Engenharia de Software - Desenvolvimento Incremental.
2 / 3
Material Complementar
Engenharia de Software - Desenvolvimento Incremental
https://www.youtube.com/watch?v=oN3gZ5uogR0
Leitura
CORDEIRO, E. dos S. Modelagem descritiva iterativa e incremental de processo de software:
uma experiência em uma microempresa de desenvolvimento de software. 
MONTINI, D. et al. Estudo de caso de uma estratégia de desenvolvimento incremental de
sistema de banco de dados corporativos. 
ResearchGate
ACESSE
LOURENÇO, F. L. M.; BENINE, M. A. Estudo do ciclo de vida do software em uma empresa de
desenvolvimento de sistema. Linguagem Acadêmica, Batatais, v. 1, n. 2, p. 183-201, jul./dez.
2011. 
https://www.researchgate.net/publication/267338270_ESTUDO_DE_CASO_DE_UMA_ESTRATEGIA_DE_DESENVOLVIMENTO_INCREMENTAL_DE_SISTEMA_DE_BANCO_DE_DADOS_CORPORATIVOS
XDOCS 
ACESSE
https://xdocs.com.br/doc/manual-de-alguma-coisa-para-conseguir-baixar-6nw12lvm1p81
AGILE ALLIANCE. O que é Agile? AGILE ALLIANCE, 2019. Disponível em:
<https://www.agilealliance.org/agile101/>. Acesso em: 05/08/2021.
MERSINO, A. Sucesso com scrum: não quebre estas 7 regras. Project Management Institute
Portland, 2018. Disponível em: <https://pmi-portland.org/news-and-content/758-7-rules-
of-scrum>. Acesso em: 05/08/2021.
SOMMERVILLE, I. Engenharia de Software. 10. ed. IAN SOMMERVILLE, 2019. Disponível em:
<https://iansommerville.com/software-engineering-book/static/web/ 
incremental-development/> Acesso em: 05/08/2021.
Schwaber, K.; Sutherland, J. Guia do SCRUM - Um guia de�nitivo para o Scrum: as regras do
Jogo. Scrumguides.org, 2017. Disponível em:
<https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-
Brazilian.pdf>. Acesso em: 05/08/2021.
3 / 3
Referências