02/06/2020 Versão para impressão

Informática para Internet

Metodologia de projeto
Métodos ágeis
Até recentemente, o desenvolvimento de aplicações de
tecnologias da informação (TI) era feito seguindo o método cascata.
Nesse método, tudo era feito de modo sequencial: entendimento da
demanda, definição do projeto, planejamento, desenvolvimento, teste
e entrega. Porém, o método cascata acabou demonstrando diversas
falhas, como problemas de desenvolvimento e de conformidade do
que foi feito com a solicitação do usuário, além de gerar retrabalho.

Isso ocorre devido ao fato de ele ser um método em que um

processo depende essencialmente do anterior para iniciar, devendo
tudo ser entregue em uma única vez, sem uma demonstração inicial e
uma validação. Como o retrabalho exigia que todo o processo fosse
feito novamente, os custos acabavam sendo muito elevados para a
concepção do projeto.

Com isso, Ken Schwaber, Jeff Sutherland, Mike Beedle e Mike

Cohn criaram o scrum, que é a principal ferramenta quando o assunto
se refere a métodos ágeis. Contudo, antes é preciso abordar o
Manifesto Ágil, que descreve o tipo de abordagem que se deve ter
durante o desenvolvimento de software.

Á
1/23
02/06/2020 Versão para impressão

Manifesto Ágil
O manifesto foi criado em fevereiro de 2001 em uma reunião que
aconteceu na estação de esqui de Snowbird, no estado de Utah,
Estados Unidos. Ao todo, assinaram o manifesto 17 líderes
representantes de ideias, metodologias e processos que, em contraste
com as práticas predominantes na época, estavam trazendo valor para
os seus clientes por meio de abordagens leves e empíricas para
projetos de desenvolvimento de software.

Nesse encontro histórico, não havia entre os participantes a

intenção de unificar as suas formas de trabalhar. A expectativa de
chegar a qualquer tipo de consenso era limitada e variada. No entanto,
apesar das diferentes práticas defendidas, os participantes
encontraram um conjunto de valores em comum e, ao final de três
dias, estabeleceram o termo “ágil” para representar o novo movimento.

O manifesto estabelece, no decorrer do texto, os próprios

valores:

Indivíduos e interação entre eles, mais do que

processos e ferramentas

Software em funcionamento, mais do que

documentação abrangente

Colaboração com o cliente, mais do que negociação de

contratos

Resposta a mudanças, mais do que seguir um plano

Ainda, é possível ver no manifesto os 12 princípios do

desenvolvimento de software ágil:

1. A maior prioridade é satisfazer o cliente, por meio da

entrega adiantada e contínua de software de valor.

2/23
02/06/2020 Versão para impressão

2. As mudanças de requisitos devem ser aceitas, mesmo no

fim do desenvolvimento. Processos ágeis se adequam a
mudanças, para que o cliente possa tirar vantagens
competitivas.

3. O software precisa estar funcionando com frequência, na

escala de semanas até meses, com preferência aos
períodos mais curtos.

4. As pessoas relacionadas a negócios e desenvolvedores

devem trabalhar em conjunto e diariamente, durante todo
o curso do projeto.

5. Os projetos devem ser construídos em torno de indivíduos

motivados, dando a estes o ambiente e o suporte
necessários e confiando que todos farão o seu trabalho.

6. O método mais eficiente e eficaz de transmitir

informações, interna ou externamente, para um time de
desenvolvimento é uma conversa franca, cara a cara.

7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os

patrocinadores, os desenvolvedores e os usuários devem
ser capazes de manter passos constantes.

9. Contínua atenção à excelência técnica e bom design

aumentam a agilidade.

10. A simplicidade é essencial, pois é a arte de maximizar a

quantidade de trabalho que não precisou ser feito.

11. Os melhores requisitos, designs e arquiteturas surgem de

times auto-organizáveis.

12. Em intervalos regulares, o time deve pensar em formas de

ficar mais efetivo. Então, os membros da equipe se
ajustam e otimizam o seu comportamento conforme as
decisões tomadas.

O modelo em cascata (ou waterfall)

3/23
02/06/2020 Versão para impressão

O método tradicional mais conhecido para desenvolver software

é o modelo em cascata (ou waterfall). Esse modelo foi inicialmente
descrito por Winston W. Royce, em 1970, e nada mais é do que uma
sequência de fases de desenvolvimento, em que cada fase somente
inicia quando a anterior encerra, e a saída de uma fase é a entrada da
fase seguinte. Royce (1970), no entanto, criticava o modelo, afirmando
que, para o desenvolvimento de software, o uso do modelo em
cascata era arriscado.

Os métodos tradicionais são fortemente prescritivos e, de forma

geral, focam em planos detalhados definidos no princípio do projeto,
como custo, escopo, cronograma detalhado, microgerenciamento,
poder centralizado, processos cada vez mais complicados e extensa
documentação. Mudanças são fortemente indesejadas. Acreditava-se
que, pelo uso desses métodos, seria possível tratar o desenvolvimento
de software como um processo previsível, sendo que, quanto mais
falhavam, mais pesados e complexos esses métodos se tornavam.

Sendo assim, com a leitura realizada até aqui, já é possível

iniciar o estudo sobre desenvolvimento de software com métodos
ágeis, com foco no scrum. Atualmente, inclusive outras áreas
profissionais têm adotado o scrum em seus processos, devido à sua
maturidade e ao seu sucesso comprovado principalmente ao longo da
última década.

Para iniciar, uma definição comum para “ágil” pode ser: “que se
movimenta com facilidade; ligeiro, leve”.

O adjetivo “ágil” foi escolhido para representar um movimento que surgiu em

meados dos anos 1990 em resposta aos pesados métodos de gerenciamento de
desenvolvimento de software que predominavam na época, chamados aqui de
“métodos tradicionais”.

4/23
02/06/2020 Versão para impressão

Scrum e extreme programming, por exemplo, são “ágeis”, pois,

assim como outros métodos, metodologias e frameworks, a utilização
de ambos deve seguir os princípios e os valores do Manifesto para o
Desenvolvimento Ágil de Software.

Scrum
No scrum, o ciclo de desenvolvimento de software é dividido em
ciclos. Antes, porém, de seguir adiante com os ciclos, é essencial
detalhar os papéis dentro do scrum e também desmistificar uma
afirmação cada vez mais popular, que é a de que o scrum faz o dobro
de trabalho na metade do tempo. Tal afirmação, muitas vezes, é
entendida de forma incorreta.

Gerentes tendem a entender que o scrum faz com que os colaboradores

produzam com mais agilidade, o que é um engano. O scrum retira algumas
formalidades que engessam o processo de desenvolvimento de software, o que
acaba diminuindo o tempo de desenvolvimento deste.

Outro fator é que, como o scrum funciona em ciclos, ele acaba

gerando valor antes em comparação ao modelo em cascata.

Fluxo de trabalho no scrum

Dentro do scrum, há os papéis, que deixam clara a posição de cada

pessoa dentro do projeto, para que assim também fique claro para
todos o processo completo.

5/23
02/06/2020 Versão para impressão

Product owner
O product owner (PO) (em português, “dono do produto”) vem para
trazer o entendimento do stakeholder (usuário). Garantir que o time de
desenvolvimento entenda o projeto como um todo e traduzir o desejo
do usuário são funções do product owner. Ele também é responsável
pelo aceite do projeto (apenas ele pode dizer se o projeto está em
conformidade com o que foi solicitado). Caso seja necessária alguma
alteração, apenas o product owner pode solicitá-la no escopo do
projeto.

Scrum master
Scrum master é a pessoa que conhece o método e é responsável por
garantir que todas as cerimônias sejam respeitadas dentro dos ciclos.
O scrum master também é responsável por filtrar o que chega para o
time de desenvolvimento. Muitos dizem que ele é um facilitador dentro
do método, o que pode ser uma verdade, mas não absoluta, porque o
time pode, sim, funcionar sem um scrum master. Ele é responsável
ainda pela aplicabilidade do método, mas, como ao longo do tempo o
time vai amadurecendo, tal papel acaba sendo distribuído dentro do
time.

Team
O time de desenvolvimento deve ser composto por integrantes que
sejam autossuficientes para a conclusão do projeto. Logo, ele deve ser
composto por arquitetos, desenvolvedores, analistas e testadores, que
são basicamente os principais integrantes. Contudo, caso haja
necessidade, podem ser incluídos administradores, administradores
de banco de dados, redes etc., tudo que for necessário para entregar
o projeto.

O time de desenvolvimento não pode ter mais que 12

integrantes, segundo recomendações. Quanto mais enxuto, mais fácil
é gerenciá-lo, ainda mais porque dentro do scrum o time deve ser

6/23
02/06/2020 Versão para impressão

autossuficiente e autogerenciável. Logo, todos os integrantes devem

ser multi skill (diversos conhecimentos), pois, caso seja necessário,
uma pessoa que normalmente é testador do projeto também pode ser
desenvolvedor, caso o time entenda a necessidade e a pessoa se
sinta à vontade com a situação.

A equipe deve ser composta por pessoas responsáveis, pois os

prazos são definidos por ela. Portanto, os membros são totalmente
responsáveis com os prazos, o que gera um senso de compromisso.

Quanto ao funcionamento do scrum, existem algumas atividades

e alguns conceitos que devem ser entendidos para que o método seja
aplicado com o máximo de eficácia.

Sprint
A sprint pode durar de 15 a 30 dias (de preferência 15 dias, para que o
ciclo seja rápido).
Designer/Diagramador: caixa de destaque com ícone de importante
Ao iniciar uma sprint, o time deve ter uma visão clara dos objetivos
dela (tudo que deve ser entregue ao final dos 15 dias), e o scrum
master deve tomar decisões para que os 15 dias sejam
potencializados e respeitados, para que os prazos e os objetivos
sejam cumpridos.
Dentro do ciclo da sprint, existem ainda os microciclos, que são os
dias. O time de desenvolvimento deve saber claramente o que
acontecerá diariamente, para que, ao final dos 15 dias, todos os
objetivos tenham sido alcançados.

Nesse ponto, a maturidade do time e do product owner é muito

importante. Preferencialmente, o product owner não pode intervir com
alterações, novas solicitações ou problemas sem muito impacto
durante a sprint, e o time deve ter cuidado para que a sprint não fique
com prazos apertados, ocasionando que tudo seja feito apenas nos
últimos dias.

7/23
02/06/2020 Versão para impressão

A sprint, ao contrário do que muitos pensam, não é totalmente

fixa. Como o objetivo é sempre o usuário, caso surja um problema ou
uma necessidade extrema para atender o usuário, o time se reúne,
retira algum item e coloca a demanda nova dentro da sprint – por isso
é muito importante um time com elevado conhecimento.
Backlog do produto
Backlog do produto é, essencialmente, uma lista de necessidades do
projeto. Tal lista é feita pelo product owner com o apoio do time, que
tem todo o conhecimento técnico. Ademais, a lista não é fixa, podendo
sempre ser incrementada conforme a necessidade do projeto. Ela
deve ser ordenada por ordem de prioridade e relevância para o
projeto. Essa ordem é montada pelo product owner, mas monitorada
pelo time, para os casos de dependência técnica, por exemplo. Então,
sempre que um item é adicionado, a ordem deve ser revisada para
que ele seja encaixado conforme a necessidade do usuário.

Backlog da sprint
Backlog da sprint é a lista de itens que devem ser atendidos na
próxima sprint. A lista deve ser refinada pelo product owner, afinal, ele
sabe quais são a prioridade e a necessidade de cada item. Essa lista
também deve estar ordenada por prioridade, seguindo o que já foi
definido na montagem do backlog de produto.

8/23
02/06/2020 Versão para impressão

TO DO LIST
Story Priority
As a user I want to be able to reset my
1 1
password
As a user I want to edit items 3 2
As a user I want to export data 2 3
As an administrator I want to define KPI’s for
4 4
my sales team
As a user I want to view my data on mobile 5 5
As an administrator I want to send alerts when
2 6
new leads come in
5 7
As a user I want to create a report of data
As a user I want to update my reminder
3 8
settings when a date is added
As a user I want filtering enhacements 4 9
As an administrator I want to configure views
5 10
of data
Total 34

Tabela 1 – Exemplo de user story

Fonte: <https://www.smartsheet.com/best-advice-scrum-and-agile-
experts-managing-your-product-backlog>

Existem algumas cerimônias e algumas práticas dentro do scrum

que foram pensadas para facilitar a comunicação. São elas:

Daily
Daily é a cerimônia que banalizará o andamento da sprint. A daily
deve ser respeitada, e alguns cuidados na sua condução devem ser
tomados, pois, como ela ocorre normalmente todos os dias, não pode
ser uma reunião longa, para não gerar aborrecimentos e desprezo por
parte da equipe. Especialistas indicam que a daily deve ter no máximo
15 minutos. Para tanto, o scrum master deve cuidar alguns detalhes,
dentre eles a resposta de três perguntas básicas:

9/23
02/06/2020 Versão para impressão

O que fiz ontem?

O que farei hoje?

Eu tenho algum impedimento/problema que pode

impactar a entrega?

O time deve fazer com que todos respondam a essas questões,

pois muitos pensam que elas são feitas para monitorar a equipe, mas,
na verdade, são perguntas para entender o andamento da sprint e
conduzir a equipe para o objetivo. Em resumo, com essas perguntas,
o scrum master poderá notar gargalos ou problemas de entendimento,
atuando, assim, de forma precisa e antes da finalização da sprint.

Assuntos externos ou complexos não devem ser abordados na

daily, pois isso aumentaria o seu tempo. Os integrantes devem apenas
responder às perguntas, e, em caso de problemas ou impedimentos,
ações serão direcionadas para após a daily. As pessoas envolvidas
devem conversar após a daily, para que qualquer problema seja
solucionado, mas sem que todos sejam envolvidos sem necessidade.

Sprint planning
Sprint planning é uma cerimônia com duração média de duas a quatro
horas e serve para que o time se reúna com o product owner,
definindo o backlog da sprint. No sprint planning, o time também define
o nível de dificuldade e o tempo que cada um levará para fazer cada
item (caso isso não tenha sido feito no groomming). Assim, o time
poderá adicionar ao backlog exatamente o que será atendido, sem
excesso ou faltas.

Na teoria, tudo parece simples, mas, na prática, o time precisa de

muita maturidade e muito conhecimento para acertar. Por isso,
normalmente o time escolhe mais itens e deixa o backlog da sprint

10/23
02/06/2020 Versão para impressão

“inflado”, para caso haja a necessidade de ter itens a serem atendidos

dentro da sprint.

Para que tudo ocorra naturalmente e para que todos entendam,

devem ficar claros os itens realmente necessários para a sprint e os
extras. O sprint planning deve acontecer no primeiro turno do primeiro
dia da sprint, para que o time já inicie com a visão de toda a sprint.

Sprint review
Normalmente, a review dura de 30 a 60 minutos e deve acontecer ao
final da sprint. Muitos indicam que a review deve ser realizada no
último turno do último dia. Contudo, como nem sempre as pessoas
conseguem tal precisão, devido à agenda, o indicado é mesmo o
último dia, pois assim o time já finalizou ou tentou finalizar todos os
itens da sprint e já pode começar a pensar na próxima.

Aqui o time apresenta para o product owner e para os

stakeholders tudo que foi feito durante a sprint que passou. Para a
apresentação acontecer, o product owner já deve ter dado o aceite.
Sendo assim, muitos times acabam adotando o método de showcase
para essa cerimônia, com apresentação mais animada e prática.
Porém, deve sempre ser frisado que ela deve apresentar os detalhes
dos itens para os seus usuários e também o funcionamento na prática.
Respeitando isso, a review será um sucesso.

Sprint retrospective
Sprint retrospective é uma cerimônia que reúne todos os envolvidos no
projeto (product owner, scrum master e time), devendo ser realizada
ao final da sprint.

Popularmente, a sprint retrospective é conhecida como uma cerimônia

para discutir alguns pontos mal resolvidos. Nela, todos devem expor
problemas que ocorreram dentro da sprint, individuais ou do time,
insatisfações, elogios ou metas para as próximas sprints. A sprint

11/23
02/06/2020 Versão para impressão

retrospective é uma cerimônia muito importante para o andamento do

scrum no projeto, porque nela os membros da equipe debatem os
acontecimentos, buscando uma evolução, e as pessoas têm que se
desprender de cargos e possíveis retaliações. É um momento de
feedback do projeto, com duração, em média, de uma a duas horas.

Cronograma e custos
Dentro dos métodos ágeis, existem alguns apoiadores na
elaboração de cronograma, pois o scrum, especificamente, apresenta
uma organização de cronograma muito clara.

O scrum, em si, serve para facilitar o cronograma, já que a cada

15 dias haverá uma entrega. Logo, conforme a lista de itens e a sua
ordenação, a equipe saberá passar o cronograma para o usuário final.

Alguns apoiadores são:

Realizar uma estimativa de tempo

Há várias ferramentas dentro das tarefas para apoiar o time na hora
de montar estimativas. O planning poker pode ser uma delas. Nele, o
time terá cartas, nas quais cada uma representa um tamanho de
estimativa. O scrum master fala sobre o item, e o time apresenta, ao
mesmo tempo, a carta que cada um acredita representar aquele item.
O integrante que apresentar a maior estimativa e o que apresentar a
menor explicam o motivo, e assim o time discute se concorda com a
maioria dos integrantes, com o integrante que apresentou a menor
estimativa ou com o integrante que apresentou a maior.

Dentro dos métodos, há ainda o brainstorming (ou “tempestade

de ideias”), no qual todos acabam discutindo e sugerindo alguns
pontos. Sendo assim, o time acaba chegando a um consenso. Porém,
tal técnica tende a inibir os mais tímidos e a destacar os mais
experientes, não dando voz realmente a todos.

12/23
02/06/2020 Versão para impressão

Conhecer a velocidade do time

Conhecer a velocidade do time, por ser uma técnica obtida por meio
das médias de pontos das histórias aprovadas nas últimas sprints,
auxilia na avaliação de desempenho. Com base na análise das últimas
sprints, a equipe tem a capacidade de entender quantos pontos de
sprints ela consegue fazer dentro daquele período.

Ainda pode ser usado, por exemplo, o método de contagem de

pontos por função, que auxilia no entendimento do tamanho de cada
item, podendo-se medir, assim, a velocidade do time em pontos. Logo,
ao longo do tempo, o time saberá quantos pontos (itens) entregar por
sprint.

Prever os custos do projeto ágil

Utilizando a metodologia scrum, é possível definir o produto mínimo
viável (minimum viable product – MVP), o que ajuda os
empreendedores a iniciarem o processo, otimizarem a velocidade de
aprendizagem e, consequentemente, darem uma noção maior aos
custos do projeto ágil.

Calcular previsão de custos extras nas sprints

Mesmo havendo características multifuncionais no time, existe a
possibilidade de haver gastos extras nas sprints. Os gastos devem ser
mapeados e levantados para prever o custo de iteração. Tudo isso
deve ser visto no planning, para que o scrum master já pense em
soluções.

Aplicar um fator de arrasto para possíveis atrasos nas

iterações
A aplicação de um fator de arrasto para possíveis atrasos nas
iterações pode ser feita por meio de estudos dos projetos anteriores

13/23
02/06/2020 Versão para impressão

do time. O cálculo da função de arrasto é uma taxa média de erros das

sprints anteriores. Em geral, não se recomenda diminuir a taxa de
erro. Por fim, adicionar um tempo de bônus ajuda na entrega eficiente
e dentro do cronograma.

Com todos os fatores mencionados dentro do método, quem for

gerenciar os custos dentro do time entenderá quanto custa por mês
um time focado no projeto e quanto custa em média os itens de
projeto, conseguindo, dessa forma, elaborar melhor uma planilha de
custos mais clara e assertiva.

Desenvolvimento do escopo no contexto

ágil
Em um contexto ágil, nota-se que o desenvolvimento do escopo
deve ser dividido em pequenas partes, como já visto anteriormente.
No scrum, o processo produtivo é dividido em pequenas fases/ciclos,
comumente chamadas de “sprints”. Ao final de cada sprint, é
necessário obrigatoriamente ter alguma entrega relevante.

Portanto, é imprescindível entender conceitos como MVP, pronto

do scrum e estratégias de comunicação, pois, como uma entrega deve
ser realizada a cada 15 dias, por exemplo, é preciso saber claramente
o que está acontecendo dentro do time e como organizar e dividir as
demandas de desenvolvimento para que realmente haja algo relevante
para entregar ao usuário.

MVP

Para que o scrum seja aplicado e entendido, um conhecimento

deve ser abordado, qual seja o MVP.

14/23
02/06/2020 Versão para impressão

MVP é a sigla para mínimo produto viável, algo que gere valor
para o usuário. Em métodos antigos, o sistema era entregue como um
todo, o que gerava retrabalho, pois o usuário só teria contato com o
sistema quando já estivesse finalizado.

Consequentemente, às vezes isso acarretava uma série de

questionamentos, porque, no pensamento do usuário, o sistema seria
de uma forma, mas, quando finalizado, ele não havia ficado como
esperado.

É muito importante dividir o projeto em pequenas partes, mínimas e funcionais,

para que o usuário possa validá-las, agregando algum valor para ele. Dessa
forma, fica fácil remodelar ou alterar algo e pensar em alternativas e soluções,
porque a alteração será mínima, e não um projeto completo. Com isso, além de
ser gerado um valor rápido para o usuário, o retrabalho em excesso é reduzido,
porque as entregas são rápidas (15 a 30 dias).

O trabalho em MVP é muito importante na usabilidade, pois ela

deve ser entendível e impactante para o público desde a primeira
versão. A imagem a seguir apresenta um exemplo de usabilidade no
contexto de MVP:

Figura 1 – Modos certo e errado de criar MVP

Fonte: <https://www.quickscrum.com/Article/ArticleDetails/5174/1/Why-
start-up-should-focus-on-Minimum-Viable-Product>

Pronto

15/23
02/06/2020 Versão para impressão

Todos os envolvidos no projeto devem ter clara a definição de

“pronto”, mas apenas o product owner pode dizer se o que foi feito
está realmente pronto ou não, normalmente por meio de aceite. O
pronto está ligado aos requisitos de solicitação e expectativa do
usuário, e os itens devem estar em total conformidade com o que foi
solicitado.

Normalmente, tal processo ocorre no último dia da sprint.

Contudo, para melhor organização em grandes projetos, o pronto pode
ser definido de acordo com o andamento da sprint. O product owner, a
cada item finalizado, avalia e diz se os itens estão prontos ou não. O
pronto deve ocorrer sempre ao final da sprint. Caso um item necessite
de um prazo mais longo, o time deve analisar uma quebra no item ou
um maior esforço (mais pessoas do time trabalhando no item), para
que ele seja entregue dentro da sprint.

Estratégias de comunicação
Ainda, existem dentro do scrum algumas cerimônias e algumas
práticas que foram pensadas justamente para facilitar a comunicação
entre a equipe e também com o usuário.

As cerimônias são importantes para o andamento e a entrega do

projeto. Todas são monitoradas e conduzidas pelo scrum master, que
deve conhecer totalmente cada uma delas, para que sejam aplicadas
corretamente.

Para ajudar na comunicação, além das práticas indicadas

anteriormente no fluxo de trabalho do scrum, há o gromming, que deve
ocorrer para que o product owner apresente os detalhes do projeto e
os itens da próxima sprint. Sendo assim, é gerado um debate com a
equipe para que todos discutam soluções, técnicas a serem utilizadas
e gaps (possíveis faltas de informação). Aqui também pode ser feito
um levantamento prévio do backlog da sprint.

16/23
02/06/2020 Versão para impressão

Algumas das práticas indicadas para auxiliar a comunicação

serão abordadas a seguir.

Kanban
O kanban é um método que foi incorporado ao scrum. Portanto,
pode-se dizer que muitos confundem e acham que o scrum é o
kanban, ou vice-versa. Contudo, a verdade é que os dois são métodos
diferentes, mas que, juntos, geram um resultado interessante.

A palavra “kanban” vem do japonês “registro” ou “placa visível”. Tal ferramenta

foi originalmente criada por Taiichi Ohno, da Toyota, com a intenção de encontrar
um sistema de melhoria que mantivesse um alto nível de produção.

O kanban é um sistema geralmente representado por um quadro

e organizado por um software ou até mesmo uma folha de papel, no
qual cartões que representam o trabalho seguem um fluxo
preestabelecido de estágios. À medida que o trabalho evolui, os
cartões vão mudando de estágio, e, sempre que um novo trabalho é
identificado, um novo cartão é criado.

O kanban procura identificar oportunidades de melhoria, criando

uma cultura kaizen na equipe, na qual a melhoria contínua é
responsabilidade de todos.

Os princípios básicos em torno do kanban são:

17/23
02/06/2020 Versão para impressão

Visualização da cadeia de valor: visualiza as fases do

produto (por exemplo: um software, algo material ou até
mesmo um serviço).

Desenvolvimento evolucionário (adaptativo): por meio

de gestão de mudanças simples, permite adaptar-se de
forma ágil, entregando o que tem mais valor antes. A
palavra “ágil”, muitas vezes confundida com “rapidez”,
aqui significa capacidade de se adaptar às mudanças com
mais facilidade, mais agilidade.

Restrição do trabalho e progresso dele em torno de

seus estágios: permite medição, controle e melhoria
contínua.

Alguns exemplos de kanban podem ser vistos a seguir:

Figura 2 – Kanban simples

18/23
02/06/2020 Versão para impressão

Figura 3 – Funcionamento do kanban

Fonte: <https://targetteal.com/pt/blog/metodo-kanban/>.

Usabilidade no contexto ágil

Atualmente, a usabilidade é uma questão muito abordada, devido
à alta concorrência no mercado e à globalização. Logo, as empresas
precisam alinhar os pilares da usabilidade – eficiência, eficácia,
segurança, utilidade, facilidade de aprendizagem e facilidade de se
lembrar como se usa (PREECE, 2008, p. 35) – para garantir que o
produto concorra no mercado de forma segura.

Com isso, as equipes ágeis acabam garantindo um retorno de

investimento, já que a disputa no mercado se dá muito pela facilidade
do usuário em entender e em aceitar as ferramentas. Conforme
Nielsen (2003):

A partir de dados coletados em 863 projetos de design que

incluíam atividades de usabilidade (…), chegou-se à
conclusão de que em média 10% do orçamento dos
projetos eram destinados à usabilidade (…), valor que
dobrava o número de usuários de um sistema. (NIELSEN,
2003)

19/23
02/06/2020 Versão para impressão

As pesquisas realizadas pelo Nielsen Norman Group foram de

grande valia para que cada vez mais empresas agregassem a
usabilidade a seus projetos. Como fica evidente no estudo, quanto
maior a usabilidade, mais usuários da ferramenta. É isso que um
analista ou um líder de equipe deve ter em mente.

Mesmo assim, “desenvolvedores devem determinar técnicas

apropriadas para o desenvolvimento de interface dos usuários antes
do projeto para obter resultados otimizados e facilitar projeções de
análise de custos” (AARON, 2002, p. 15).

É importante, nessa projeção, que a usabilidade seja trabalhada por

um profissional da área desde o estágio inicial do projeto. A qualidade
está presente do início ao fim do projeto. Anteriormente, pensava-se
que a qualidade era a última etapa, como um setor de auditoria, mas
hoje, com as práticas ágeis, fica evidente que, dentro do time, deve
haver pessoas especializadas em todas as fases, para que o produto
seja pensado, feito e validado com o máximo possível de usabilidade.

Conforme Patton (2002, p. 4), “em muitos casos, se tentássemos

praticar o design centrado no usuário, nossa empresa seria acusada
de remexer no mesmo material que já foi discutido pelo marketing e/ou
pela diretoria do projeto”. Portanto, cabe ao líder conscientizar a
empresa, levando o conceito de usabilidade e demonstrando que o
retorno de investimento acontece.

Preparar um bom material que ressalte que “análises de custo-

benefício mostram retornos saudáveis e consistentes nos dólares
investidos em usabilidade” é uma estratégia. “Na medida em que mais
empresas entendem os benefícios significantes da usabilidade e
fazem a justificação de custos cuidadosamente, as técnicas de
usabilidade se tornarão padrão” (AARON, 2002, p. 15). Assim, hoje já
existe um modelo:

20/23
02/06/2020 Versão para impressão

1. Identificar os participantes (equipe e cliente)

2. Livrar-se de preconcepções, para então rever o projeto

3. Seguir para a definição dos papéis dos usuários e dos

seus modelos

4. Definir tarefas e modelos de tarefas

5. Definir contextos de interação

6. Detalhar as tarefas dos usuários

7. Criar um protótipo abstrato do projeto e um wireframe da

interface do usuário

8. Testar os contextos de interação

O processo citado ajuda a identificar que “um desenvolvimento

centrado nos usuários implica descobrir muitas coisas sobre os
mesmos e suas tarefas e utilizar essas informações para alimentar o
design” (PREECE, 2008, p. 299). Como toda mudança é relativamente
dolorosa, quando aplicado, deve-se ter em mente que o processo é
lento e que alguns cuidados devem ser tomados. “As pessoas
estavam acostumadas com uma pessoa indo para uma sala fechada
para escrever especificações funcionais, e não este processo longo e
colaborativo” (PATTON, 2002, p. 5).

É importante ressaltar que esse processo longo dura no máximo

dois dias, de acordo com o próprio autor. Contudo, de fato, se
comparado com o modelo feito por uma pessoa em uma tarde, dois
dias equivalem a três vezes mais tempo gasto.

Mesmo assim, Patton (2002, p. 5) menciona que, “ainda que a

colaboração em um grupo grande fosse cansativa, quando terminam,
o volume de conhecimento tácito do grupo é insubstituível. Todos

21/23
02/06/2020 Versão para impressão

entenderam quem são os usuários e quais são os seus objetivos”.

Novamente, defende-se o design centrado no usuário desde o estágio
inicial do desenvolvimento do projeto.

Segundo Nielsen (2009, p. 6), “os métodos ágeis oferecem muitas oportunidades
para prever possíveis problemas de usabilidade que os métodos tradicionais de
desenvolvimento impediam no passado”. Isso quer dizer que os métodos ágeis
possibilitam a intervenção do profissional desde o estágio inicial, enquanto, em
outros processos de desenvolvimento, a usabilidade muitas vezes era abordada
apenas no primeiro protótipo.

Outro ponto-chave é que “os praticantes de experiência do

usuário, pela natureza de seus trabalhos, interagem tanto com os
representantes dos clientes quanto com o time de desenvolvimento”
(NIELSEN, 2009, p. 30), atuando como “pontes” ou intermediários.

Então, como visto, os métodos ágeis, especificamente o scrum,

definiram alguns padrões dentro do desenvolvimento de projetos que
acabam auxiliando não apenas o time no desenvolvimento de sistema,
mas também os seus líderes e os seus gestores na organização da
empresa.

O scrum facilita a elaboração de um cronograma mais

assertivo, algo que sempre foi um problema na área de
desenvolvimento de software, pois os prazos normalmente não eram
cumpridos. Portanto, o scrum ajuda na elaboração de custos. Como
nos modelos anteriores não se tinha ideia de tempo (cronograma),
planejamento e engajamento do time, as lideranças não podiam
montar um planejamento de custos e, consequentemente, acabavam
errando na hora da cobrança.

Como o scrum tem em si claramente como acontecem as entregas, quais são os

papéis dentro dos times e com o que o time deve se comprometer, fica fácil
saber, de forma mais assertiva, quando o projeto será entregue e quanto custará
o seu desenvolvimento.

22/23
02/06/2020 Versão para impressão

Hoje em dia, um profissional com conhecimento ágil é

destaque em qualquer processo seletivo, não apenas em
processos para times de desenvolvimento, mas também em processos
para vagas de lideranças e até em outras áreas, porque a abrangência
é tão grande que o scrum começou a ser aplicado em setores
administrativos, na indústria e até no comércio.

Voltar ao topo

23/23