DESENVOLVIMENTO

DE SOFTWARE COM
METODOLOGIAS
ÁGEIS

Camila Nascimento Barcellos

Métodos ágeis e
linhas de produto
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Descrever aplicação de gerenciamento de produtos ao desenvolvi-

mento de software.
 Identificar vantagens da implementação de uma LP de software.
 Demonstrar como a interseção de diferentes métodos ágeis pode
favorecer o gerenciamento de linhas de produto.

Introdução
Devido à sua natureza intangível, o gerenciamento de software é subs-
tancialmente diferente da gestão de outros produtos comercializados.
Na área da Tecnologia, é preciso criar um produto que de fato só será
concretizado e validado quando o usuário final tiver acesso a ele, além
de o software passar por modificações e melhorias contínuas ao longo
do seu tempo de uso e por todo o período em que o software existir.
Alguns dos entregáveis em software são códigos produzidos pelos
desenvolvedores, além da documentação do que foi produzido, que
precisa ser sempre atualizada. Considerando as características atípicas
desse produto, há algumas dificuldades a serem enfrentadas em times
de desenvolvimento, como sua intangibilidade, sendo relevante conhecer
as melhores práticas de gestão, as metodologias ágeis mais utilizadas no
mercado e as formas de levar mais maturidade às equipes nas melhorias
dos seus processos. Um time de desenvolvimento integrado e bem geren-
ciado pode trazer resultados mais rápidos e melhores, evitar despender
tempo com tarefas desnecessárias e aumentar a motivação e as entregas
ao cliente. Devido aos fatores específicos que envolvem o caminho a
ser traçado para construir um software, colocá-lo em funcionamento
e realizar suas manutenções periódicas, existem métodos de gestão
2 Métodos ágeis e linhas de produto

próprios e específicos que são utilizados em times de desenvolvimento

por seus líderes e equipes.
Além dos fatores já citados, a engenharia de software aponta métodos
de utilização de reuso, chamados linha de produto (LP) de software,
que são formas de replicar um software já construído, de modo que
seja possível desenvolver um novo software a partir de outro existente,
apenas modelando e o ajustando àquilo que é necessário de acordo
com os requisitos do cliente.
Neste capítulo, você vai entender como o gerenciamento de produtos
é relevante para desenvolver um software e quais são as formas utilizadas
para gerenciá-lo e replicá-lo.

1 Gestão em desenvolvimento de produto

software
Ries (2011, p. 50) relata do que se trata o gerenciamento de produto com uma
situação fática:

Mark explicou: “Tradicionalmente, o gerente de produto diz: ‘Quero isso’.

Em resposta, o engenheiro afirma: ‘Vou desenvolver isso’. Mas, ao contrário,
pressiono minha equipe para primeiro responder a quatro perguntas:
1. Os consumidores reconhecem que têm o problema que estamos tentando
solucionar?
2. Se houvesse uma solução, eles comprariam?
3. Comprariam de nós?
4. Conseguimos desenvolver uma solução para esse problema?”
A tendência comum do pessoal de desenvolvimento de produto é pular direto
para a quarta pergunta e desenvolver uma solução antes de confirmar que os
clientes têm o problema.

O gerenciamento de produto de software deve ser entendido como toda a

trajetória necessária para a entrega desse produto, como: o levantamento das
necessidades, os problemas de um consumidor/cliente, as soluções pretendidas,
a definição da arquitetura do software, os prazos de entrega, as métricas de
acompanhamento e a dinâmica de testes de funcionamento com o intuito de
entregar com eficiência e agilidade o produto software. Atualmente, a gestão
contínua do software é realizada por meio de metodologias ágeis, de forma
antagônica ao modelo cascata, que foi muito utilizado no passado. O modelo
cascata é uma sequência concatenada de etapas de levantamento de requisitos,
 Métodos ágeis e linhas de produto 3

estabelecimento de prazos para entrega, escrita de código, realização de testes

e entrega e manutenção do produto finalizado, tudo acontecendo um a um
como uma cascata, sendo que uma etapa precisa estar absolutamente concluída
antes de a próxima começar a acontecer.
Pelo fato de o modelo cascata, mais antigo no desenvolvimento de software,
ser demorado nas entregas, devido à vagarosidade em seu funcionamento, e
pouco flexível com as mudanças ocorridas durante o trajeto da realização do
projeto, esse modelo se tornou obsoleto por conta da dificuldade de avaliar
todas as necessidades do produto em seu início sem que ocorram mudanças
durante a realização. Além disso, é possível que o produto final só seja palpável
e verificável realmente muito próximo do seu fim, sendo este um dificultador
no sentido de realizar algum tipo de entrega prévia para que o cliente saiba
como anda o desenvolvimento do produto que adquiriu.
Dessa forma, e considerando a grande necessidade de rapidez, agilidade,
mudanças e flexibilização de requisitos, necessidades e prazos da entrega
do software, a partir do Manifesto Ágil, em 2001, surgiram novas formas
de gerenciar o produto software, que são as chamadas metodologias ágeis,
como: Scrum, Extreme Programming (XP), Feature Driven Development
(FDD), MSF, DSDM.
Segundo Olsen (2015, p. 202), ao tratar sobre os aspectos das mudanças
ocorridas no desenvolvimento de software do método cascata para uso de
metodologias ágeis:

Antes da adoção do desenvolvimento ágil, a maioria dos produtos software

era construída usando o modelo cascata – que utilizava de procedimentos
sequenciais. O time primeiro definia todos os requisitos, então fazia o design
do produto. Então implementam o produto, seguido pelos testes de verificação,
se havia o funcionamento conforme foi planejado. A característica chave do
modelo cascata é que o time não progride ao próximo passo até que a etapa
anterior esteja 100% concluída. Em outras palavras: nenhum design acontece
até que todos os requisitos estejam definidos, nenhum código acontece até
que todo o produto esteja desenhado.

Assim, após a virada da utilização do modelo cascata, a metodologia ágil

mais utilizada no gerenciamento de produto software atualmente é o Scrum, que
consiste em um método de gerenciamento de software, criado especialmente
para esse fim, visando a atender justamente às peculiaridades dos sistemas
software e às suas necessidades.
Conforme Schwaber e Jeff (2013), criadores do Scrum Guide, as possíveis
mudanças que ocorrerem durante o projeto de um software são informadas na
4 Métodos ágeis e linhas de produto

reunião de planejamento do sprint (período de tempo em que se trabalhará em

uma tarefa até, de fato, entregá-la), na reunião diária do Scrum, na revisão e
na retrospectiva do sprint. Dessa forma, o desenvolvedor sempre terá a chance
de realizar as adaptações necessárias, informar as dificuldades e solicitar
auxílio nas tarefas.
Algo muito relevante no Scrum para os times é a forma de realizar as
atividades de desenvolvimento, sempre separando-as em pequenas partes,
constantes do product backlog (repositório em que estão as tarefas, as pen-
dências e as entregas já realizadas em relação ao software), e as entregando
também em pequenas partes. Tais entregas, pequenas e parciais, próprias do
Scrum, são importantes na agilidade do produto software para que sempre seja
verificado o funcionamento, as dificuldades e as necessidades de melhorias,
também de forma parcial, o que facilita bastante a coesão na entrega final.
Caso fosse necessário desenvolver todo o software e só ao final realizar uma
grande entrega, ocorreria o gargalo dificultador do modelo cascata, que não
permite a flexibilização em relação às mudanças de objetivos, os ajustes de
falhas, a implantação de inovações no projeto e toda a sorte de modificação
necessária ao longo do desenvolvimento do produto.
Ainda entre os princípios do Scrum, que sempre norteiam as atividades
realizadas, estão a transparência (todos no time devem saber o que é impor-
tante no projeto e como fazê-lo), a inspeção (para a realização da melhoria
contínua) e a adaptação (correções e ajustes são realizados conforme os
desvios ocorridos na trajetória de desenvolvimento).
No Scrum, recomenda-se que sejam utilizados protótipos para a verificação
de uso do produto conforme as entregas parciais, verificando-se, frequente-
mente, quais são as aplicações necessárias, as expectativas de usabilidade e as
funções do software, conforme as entregas sejam realizadas. A metodologia
ágil preza por intensa aproximação do desenvolvimento junto ao cliente, que
participa opinando e interferindo em todos os momentos do projeto para que
o trabalho possa ser entregue conforme o seu desejo, e do usuário final ao
qual o cliente irá atingir.
Segundo Cruz (2018, p. 52), o Scrum nada mais é do que uma ferramenta
utilizada nos times de desenvolvimento:

O Scrum não é um processo, técnica ou método definitivo, e sim um fra-

mework dentro do qual podem ser empregados diversos processos ou técnicas,
sendo complementado com ferramentas e abordagens para melhor atender
às necessidades de produtos, times, ambientes e empresas. Seu papel é fazer
transparecer a eficácia relativa das suas práticas de desenvolvimento para
que seja possível melhorá-las, enquanto provê um arcabouço dentro do qual
 Métodos ágeis e linhas de produto 5

possam ser desenvolvidos produtos. De maneira simplista, o Scrum é leve

em conteúdo, com regras, cerimônias, papeis e responsabilidades simples de
entender e extremamente difícil de dominar e aplicar na totalidade. Uma de
suas características é deixar clara a eficácia relativa das práticas de gerencia-
mento e desenvolvimento de produtos, de modo que seja possível melhorá-las
ao longo do uso e do tempo.

Além do Scrum, há outras formas de gestão de times e produtos software,

as quais são utilizadas de acordo com o contexto do software que se deseja
produzir. As metodologias se diferenciam, basicamente, pelos seus princípios,
suas formas específicas de trabalhar e suas maiores preocupações em relação a
determinado aspecto do projeto. No Extreme Programming (XP), por exemplo,
outra metodologia ágil que pode, inclusive, ser usada de forma complementar
ao Scrum, há uma maior preocupação quanto à satisfação do cliente, sendo
assim, são realizadas entregas parciais para que ele aprove as realizações em
pequenas partes do software.
Segundo Cruz (2018, p. 209), conceituando XP:

O eXtreme Programming, também conhecido como Programação Extrema

ou simplesmente pela sigla XP, é uma metodologia ágil direcionada a times
de tamanho pequeno e médio que desenvolvem softwares frente a requisitos
vagos, desconhecidos ou em mudança constante. De maneira geral, o XP
ajuda a criar sistemas de melhor qualidade, produzindo softwares em menos
tempo e de forma mais econômica.

No Extreme Programming, diz-se que há, principalmente, uma intensa

colaboração entre o time, os gerentes e os clientes, de modo que todos colabo-
ram para entregar o projeto. Na metodologia XP, há cinco princípios básicos
norteadores:

1. comunicação;
2. simplicidade;
3. feedback;
4. respeito;
5. coragem.

Segundo Sommerville (2011, p. 44), no livro Engenharia de software, ao

explicar sobre as peculiaridades da metodologia:

Em Extreme Programming, os requisitos são expressos como cenários (cha-

mados de estórias do usuário), que são implementados diretamente como
6 Métodos ágeis e linhas de produto

uma série de tarefas. Os programadores trabalham em pares e desenvolvem

testes para cada tarefa antes de escreverem o código. Quando o novo código
é integrado ao sistema, todos os testes devem ser executados com sucesso.
Há um curto intervalo entre os releases do sistema.

Outro exemplo de metodologia ágil para software em desenvolvimento

ou manutenção é o Microsoft Solutions Framework (MSF). Trata-se de uma
metodologia que é utilizada por pequenos grupos de desenvolvedores, também
com seus princípios e valores próprios, como: valorização da comunicação
entre a equipe, visão transparente e compartilhada quanto às tarefas, capaci-
tação e melhoria contínua da equipe, agilidade para concretizar mudanças,
alto grau de adaptabilidade, qualidade e aprendizado contínuo. Já o Feature
Driven Development (FDD), metodologia igualmente integrável ao Scrum, visa
precipuamente à rapidez no desenvolvimento, sendo realizado por pequenas
partes que somarão no todo mediante a visão global do negócio. O FDD tem
características próprias, como, por exemplo, o desenvolvimento que ocorre
por funcionalidades. O desenvolvedor é responsável por uma funcionali-
dade que será integrada às outras. Além disso, o controle de qualidade se faz
presente em todas as etapas. Há, também, a metodologia de gestão Crystal
Family, mais voltada à gestão de pessoas, que está focada nas habilidades e
nos talentos do time. Sua característica principal é se ajustar a cada projeto
conforme a necessidade dele. O nome Crystal Family se deve ao fato de
ser uma metodologia que não existe sozinha, ou seja, há várias soluções,
cada uma para uma necessidade, sendo alguns elementos comuns a todas as
ferramentas, mas com práticas específicas a cada utilização. Por fim, há um
framework (ferramenta de gestão) chamada Dynamic System Development
Model (DSDM) que se utiliza de perspectivas de iteração (progresso sucessivo)
e incremento (projeto realizado por partes em oposição ao modelo cascata).
A intenção, nessa metodologia, é que o projeto seja melhorado conforme as
entregas forem acontecendo.
Segundo os autores Massari e Vidal (2018, p. 20), ao explorar o funcio-
namento do DSDM:

O DSDM (Dynamic Systems Development Method) é uma metodologia ágil

que considera que um projeto tem um ciclo de vida com cinco fases:
1.Pré-projeto. Definir os motivadores de negócio e objetivos em alto nível,
que justifiquem um estudo de viabilidade.
2.Estudo de viabilidade. Avaliar as características de negócio, tipo de projeto,
problemas organizacionais e de pessoas. Após essas análises, é tomada a
decisão de utilizar ou não o DSDM.
 Métodos ágeis e linhas de produto 7

3.Iteração do modelo funcional. Determinar as funcionalidades que serão im-

plementadas e definir um modelo funcional. A partir desse modelo funcional
serão executadas iterações até ser gerado um protótipo funcional.
4.Iteração de design e construção. Identificar requisitos funcionais e não
funcionais e iniciar o desenvolvimento da iteração. Serão executadas quantas
iterações forem necessárias para a entrega do produto final.
5.Implementação (pós-projeto). Usuários finais aprovam o sistema testado
e o sistema é liberado para utilização e sofre constante evolução através de
manutenções, melhorias e ajustes de acordo com os princípios do DSDM.

Conclui-se, portanto, que todas essas metodologias são maneiras de as

empresas em desenvolvimento de software (aplicativos) se tornarem mais
competitivas, frente às suas concorrentes, e se prepararem para o futuro,
sendo mais modernas, produtivas e rentáveis e atendendo às demandas e
expectativas do cliente ao criar software mais robustos e adequados, com
soluções inovadoras, e entregar, ao mercado e aos clientes, aquilo que estes
precisam, mostrando-se como uma área e atividade em franco crescimento
que se mantém, apesar de crises e obstáculos, com um grande potencial. As
formas específicas de gerenciamento próprias do desenvolvimento de software
precisam trazer essa leveza, atendendo às necessidades de adaptabilidade,
rapidez e aceitação de mudanças de toda natureza de acordo com o software
que for desenvolvido ou mantido, com o objetivo de dar a segurança necessária
aos times e às empresas.
Na Figura 1 é possível ver como são feitas as entregas parciais presentes
na gestão inovadora, mediante a informação presente no product backlog
(repositório em que constam as tarefas), a definição das prioridades da reunião
de sprint, o estabelecimento de metas na sprint backlog, a realização da entrega
do trabalho e a revisão contínua. A Figura 2 apresenta um exemplo de ciclo
de tarefa na metodologia XP, no qual as estórias dos usuários são os casos de
uso. Ela representa a necessidade de existir alguma funcionalidade naquele
software que será desenvolvida pelo time de software.
8 Métodos ágeis e linhas de produto

Product Sprint Shippable

backlog backlog product
1 Sprint 1 Sprint
2 planning 2 Working review
3 meeting 3 meeting
4 4 Daily
5 standup
6
7

Sprint
retro-
spective

Figura 1. Product backlog > sprint backlog > entrega parcial. Trajetória para a realização
do Scrum.
Fonte: Adaptada de Olsen (2011).

Selecionar estórias
Dividir estórias
do usuário para Planejar release
em tarefas
este release

Desenvolver/
Avaliar Liberar
integrar/
sistema software
testar software

Figura 2. O ciclo de um release em Extreme Programming.

Fonte: Adaptada de Sommerville (2011).

A metodologia ágil mais utilizada atualmente é o Scrum, o qual está voltado para o
gerenciamento do projeto.
 Métodos ágeis e linhas de produto 9

2 Benefícios de implementação da linha de

produto software
A LP de software basicamente é a estratégia de reutilização reiterada de um
grupo de produtos software semelhantes, seja por atender um mesmo cliente ou
ter valores na mesma faixa, seja pelo fato de solucionar um mesmo problema.
Considerando a necessidade de gerar redução de custos e aumento de lucros e
aumentar a rapidez na entrega e a produtividade da equipe, pode se dizer que a
LP de software é uma forma de massificar a produção e a venda de software.
A forma de realizar tal massificação do produto é por meio da reutilização de
todo o software construído, ou somente de partes do software, além do reuso
de código. É possível adequar o software reutilizável a cada necessidade do
cliente, conforme a sua refatoração.
Para entender à lógica por trás da LP de software, é possível elencar diversos
benefícios que podem ser observados com o reuso dos códigos: é mais fácil
manter um software reutilizado, pois já há os módulos prontos, sendo inseridos
ou excluídos apenas aqueles que interessarem ou não interessarem ao cliente.
Além disso, como será feito o reaproveitamento de um software que já está
construído, tem-se uma rapidez muito maior na entrega do produto.
Sommerville (2011, p. 296) relata do que se trata o reuso de software, que
é utilizado na LP de software:

A engenharia de software baseada em reúso é uma estratégia da engenharia

de software em que o processo de desenvolvimento é orientado para o reúso
de softwares existentes. Apesar de o reúso ter sido proposto como uma estra-
tégia de desenvolvimento há mais de 40 anos (McILROY, 1968), só em 2000
o ‘desenvolvimento com reúso’ se tornou a norma para novos sistemas de
negócios. A mudança para o desenvolvimento baseado em reúso foi uma res-
posta às exigências de menores custos de produção e manutenção de software,
entregas mais rápidas de sistemas e softwares de maior qualidade. Cada vez
mais empresas consideram o software como um ativo valioso. O reúso tem
sido promovido para aumentar o retorno sobre os investimentos em software.

Dessa forma, ao se aprofundar no tema, entende-se que a qualidade do

software e a reutilização deste, para alcançar mais escalabilidade, depende
da avaliação de quem o analisa. Por isso é necessário que os desenvolvedores
estejam em sinergia com o cliente e com o foco na solução dos problemas que
se dispuseram a resolver. Toda essa modelagem e preparação para como o
software que será produzido resulta em um produto menos defeituoso e mais
estável, eficiente e duradouro.
10 Métodos ágeis e linhas de produto

Segundo Böckle, Pohl, van der Linden (2005), existem dois processos
necessários no desenvolvimento de LPs: engenharia de domínio e engenharia
de aplicação.

 Engenharia de domínio: esse processo é responsável por estabelecer a

plataforma reutilizável e, portanto, define a uniformidade e a variabi-
lidade da LP. A plataforma consiste em todos os artefatos (requisitos,
design, realização, testes, etc.). Os vínculos de rastreabilidade entre esses
artefatos facilitam a reutilização sistemática e consistente do software.
 Engenharia de aplicação: esse processo é responsável por derivar as
aplicações das LPs, além de explorar a variabilidade de LPs e garantir
a ligação da variabilidade de acordo com as necessidades específicas
das variações.

Em princípio, o engenheiro de software estabelece a parte reutilizável do

programa, define qual parte será reutilizável e desenvolve somente a parte
faltante, reutilizando todo o resto. Diante dessas informações, é possível variar
os software conforme as necessidades contratuais. O processo então se molda
para concentrar os componentes reutilizáveis do código, em contraponto ao
gasto normal de desenvolvimento de um software desde o seu início. Essa
forma mais produtiva e reduzida de desenvolver o software tem diversos be-
nefícios. Entre eles, citam-se o aumento da qualidade, a redução do tempo de
desenvolvimento e a criação de software mais especializado devido ao fato de
que serão produzidos apenas os componentes que farão seu diferencial perante
o software base. Todos esses fatores benéficos ocorrem porque será utilizada
parte de um software já construído e será então desenvolvida somente a parte
do software que se precisa de acordo com a necessidade de diferenciá-lo em
relação ao software já existente.
Segundo Böckle, Pohl e van der Linden (2005 apud LUZ, 2013, p. 21), há
diversos benefícios em utilizar uma LP de software:

Redução do custo de desenvolvimento: Umas das principais justificativas

para o uso de LPS é a redução de custo. Quando os artefatos da platafor-
ma são reutilizados em diferentes sistemas, o custo de cada sistema reduz.
Para realizar a criação desses artefatos, é necessário que a plataforma seja
planejada e desenvolvida, para isso será necessário que seja realizado um
investimento inicial, permitindo a criação desses artefatos para posterior
reuso em outros sistemas;
Melhoria da qualidade: os artefatos produzidos são revisados e testados em
muitos produtos. Dessa forma, a possibilidade de encontrar um defeito aumen-
ta, o que possibilita uma rápida correção do artefato para todos os produtos;
 Métodos ágeis e linhas de produto 11

Redução do time-to-market: um produto utilizando LPS tem o potencial de

ter o seu tempo de desenvolvimento reduzido, uma vez que os principais
artefatos já foram desenvolvidos.
Evolução planejada e organizada: à medida que novos produtos são desenvol-
vidos, novos artefatos poderão ser incorporados à plataforma.
Satisfação do cliente: pois o prazo de entrega e custo é menor.

Considerando que de fato os custos de desenvolvimento serão reduzidos, é

preciso entender que haverá a necessidade de um investimento inicial. Apesar
disso, como se demonstrou, os benefícios de utilizar a LP de software são
inúmeros, principalmente em relação à redução dos custos de desenvolvimento
e à menor necessidade de componentes de software que precisam ser averigua-
dos, concebidos, concretizados e validados. Há, ainda, maior confiabilidade
do software, pois bugs e problemas são encontrados e resolvidos com mais
facilidade. O trabalho da equipe fica mais específico e focado, pois esta irá
desenvolver, precipuamente, a parte do software que será adaptável à nova
necessidade do cliente, frente a um software já existente. Por fim, a aceleração
na entrega de software torna a empresa desenvolvedora mais competitiva no
mercado, na medida em que este exige resultados rápidos e entregas rápidas.

A LP de software possibilita que uma empresa de desenvolvimento seja responsável

por atender às demandas dos mais variados clientes, pois pode usar um software base
e readaptá-lo conforme as necessidades de outro.

3 Integração de diferentes métodos ágeis e

favorecimento à linha de produto de software
LPs de software são muito utilizadas nas empresas que desenvolvem software
adaptável e que têm vários clientes com demandas diferentes. Dessa forma,
elas podem utilizar uma mesma estrutura de software ou código em outros
produtos, de forma massificada, mais rápida, produtiva e barata.
Cada metodologia ágil, de forma integrada, pode contribuir para o sucesso
do projeto como um todo, haja vista que cada uma se propõe a realizar determi-
nada atividade dentro do projeto de desenvolvimento. O Scrum é a metodologia
ágil mais utilizada para gerir um projeto em si, seja em desenvolvimento de
12 Métodos ágeis e linhas de produto

software ou não. Já o XP, por exemplo, foca no desenvolvimento do software

e da equipe, segundo seus princípios de cultura de testes, na reunião em pé
(para ser rápida e focada no que se precisa resolver), na posse coletiva do
código (na qual todos são donos do projeto em que estejam trabalhando), na
melhoria e na integração contínua.
Utilizando a integração de Scrum com FDD, por exemplo, que está mais
focado nas funcionalidades do sistema, é possível perceber que se parte de
uma perspectiva macro (Scrum) caminhando para o desenvolvimento do
software (XP) e de suas funcionalidades (FDD). O FDD prioriza a realização do
trabalho de desenvolvimento individual, ao passo que no XP há um incentivo
ao trabalho coletivo.
As metodologias ágeis se completam com o intuito de massificar o desen-
volvimento de software. É necessário estar atento, ainda, à necessidade de
mudança na cultura da empresa e às mudanças no desenvolvimento do produto,
sendo, para tanto, preciso que a equipe se comprometa a realizar tais mudanças
em constante avaliação dos benefícios e das dificuldades encontradas.
A concretização da linha de desenvolvimento de produto software pode se
dar com a integração do Kanban. Segundo Olsen (2015, p. 211):

Outra forma popular de desenvolvimento ágil é o Kanban processo adaptado do

Sistema Toyota para beneficiar seus carros. O Sistema Toyta foca na produção
just-in-time e eliminação de perdas. Estudei o sistema Kanban e manufatura
enxuta, os quais inspiraram o movimento de desenvolvimento de software
enxutono meu programa de graduação em Virginia. Funcionários da manufa-
tura usam cartões Kanban como sinal físico quando trabalho adicional deva
ser inserido no sistema. Estes cartões foram adaptados no desenvolvimento
de software como cartões virtuais, em que cada um representa um item de
trabalho, mas não gera um sinal de que deve ser inserido. Em vez disso, os
representantes do time devem inserir o próximo trabalho proativamente. Um
princípio do Kanban é a visualização do trabalho. Cada cartão representa
uma história de usuário, ou uma tarefa de desenvolvimento que realiza uma
história de usuário. Os cartões ficam dispostos no quadro Kanban, que consiste
num conjunto de colunas, um para cada estágio do trabalho. As colunas são
organizadas da esquerda para direita na ordem em que o trabalho anda. Este
quadro Kanban possui colunas que seguem da esquerda pra direita: “Acumu-
lado”, “Pronto”, “Em Desenvolvimento”, “Desenvolvimento Concluído”, “Em
Teste”, “Teste Realizado” e “Implantado”, definidos a seguir:
- Acumulado: Itens que podem ser trabalhados, sorteados conforme prioridade;
- Pronto: Itens selecionados do “Acumulado” e estão prontos a serem de-
senvolvidos;
- Em Desenvolvimento: Itens que o desenvolvedor começou a trabalhar.
- Desenvolvimento Concluído: Itens que o desenvolvedor terminou de trabalhar
mas ainda não foram testados.
 Métodos ágeis e linhas de produto 13

- Em Teste: Itens em processo de serem testados.

- este Realizado: Itens que foram testados com sucesso, mas ainda não foram
implantados.
- Implantado: Itens que foram lançados.

O Kanban não é considerado por todos como uma metodologia ágil, mas
é uma ferramenta para readequar os processos. O trabalho com Kanban é
realizado de forma visual, pelo chamado Work in Progress, conforme as
tarefas a fazer (to do): sendo wip em progresso e done quando for concluído.
As histórias/tarefas são realizadas conforme estes 3 progressos, conforme
pode ser visto na Figura 3.
No desenvolvimento de software, o Kanban gerencia a execução de ativi-
dades e simplifica a gestão das tarefas. Há uma rapidez na identificação de
pendências, o que torna o trabalho mais eficaz, qualitativo e rápido. O Kanban
ajuda a identificar quais atividades devem ser priorizadas, melhorando, com
isso, consideravelmente os seus processos.
As metodologias Kanban e Scrum também são intercambiáveis, o que gerou,
inclusive, a nomenclatura Scrumban, a qual foi criada por Corey Ladas para
demonstrar a combinação das duas, juntando o melhor dos dois mundos. A
combinação de Scrum, Kanban e outras metodologias ágeis auxilia a equipe
de desenvolvimento a melhorar a satisfação do cliente, além de concretizar
a entrega de produto software de alta qualidade e enfatizar o melhoramento
contínuo, minimizando desperdícios e reduzindo o tempo das atividades.

4 3 2
Backlog Ready Development Testing Deployed

In dev Done In testing Done

F D C B A

Figura 3. Kanban.
Fonte: Adaptada de Olsen (2015).
14 Métodos ágeis e linhas de produto

BÖCKLE, G.; POHL, K.; VAN DER LINDEN, F. A framework for software product line engi-
neering. In: BÖCKLE, G.; POHL, K.; VAN DER LINDEN, F. Software product line engineering.
Berlin: Springer, 2005. p. 19–38.
CRUZ, F. Scrum e Agile em projetos: guia completo. 2. ed. Rio de Janeiro: Brasport, 2018.
LUZ, M. A. Uma linha de produto de software para aplicações web. 2013. Trabalho de
Conclusão de Curso (Tecnólogo em Análise e Desenvolvimento de Sistema) — Curso
de Análise e Desenvolvimento de Sistemas, Universidade do Vale do Rio dos Sino, São
Leopoldo, 2013. Disponível em: https://kleinnerfarias.github.io/pdf/graduation-work/
tcc-maicon-2014-1.pdf. Acesso em: 30 out. 2020.
MASSARI, V. L.; VIDAL, A. Gestão ágil de produtos. Rio de Janeiro: Brasport, 2018.
OLSEN, D. The lean product playbook. New Jersey: John Wiley & Sons, 2015.
RIES, E. A startup enxuta. São Paulo: Lua de Papel, 2011.
SCHWABER, K.; SUTHERLAN, J. The scrum guide. [S. l.: s. n.], 2013. Disponível em: https://www.
scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf. Acesso em: 30 out. 2020.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Prentice Hall, 2011.

Leituras recomendadas
CONH, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com
sucesso. Porto Alegre: Bookman, 2011.
KRUEGER, C. W. Software reuse. ACM Computing Surveys, [s. l.], v. 24, n. 2, p. 131–183, 1992.
Disponível em: http://sunnyday.mit.edu/16.355/kruger.pdf. Acesso em: 30 out. 2020.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a
rede é extremamente dinâmica; suas páginas estão constantemente mudando de
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade
sobre qualidade, precisão ou integralidade das informações referidas em tais links.