/#Ciclo de Aprendizagem 9 #

#Pergunta de impacto#

Você sabe o que significa metodologia ágil? E o que isso tem de diferente da
metodologia tradicional? O nome pode enganar, principalmente se formos
enganados pelo óbvio. Mas o mais importante não é saber o que é, mas como
melhor aplicar cada metodologia. Vamos lá?

#Significação#

Quando ouvimos pela primeira vez o termo metodologia ágil, é comum

associarmos a metodologia com agilidade. Consequentemente, ouvindo o
termo metodologia tradicional, associamos a algo conservador. Logo de cara,
temos associações que são, de certa forma, opostas: agilidade versus
conservadorismo. Nesse contexto, o termo agilidade acaba se estendendo para
flexibilidade e velocidade, ao passo que o termo conservadorismo passa a ser
sinônimo de demora e resistência para absorver mudanças.

#Mão na massa#

Para entender melhor o conceito relacionado à dicotomia entre metodologia

ágil e cascata (tradicional), vamos fazer um exercício. Imagine o projeto de um
prédio de 30 andares. Faz sentido fazer entregas parciais ao longo desse
projeto? Por exemplo, entregar para o cliente um andar de cada vez?

Imagine agora o projeto de um aplicativo de mensagens instantâneas que

integre várias plataformas, por exemplo: WhatsApp, Facebook, Instagram e
TikTok. Faz sentido ele demorar três anos para ser concluído e sem nenhuma
entrega parcial ao longo desse tempo?

Nesses dois cenários, imagine quais seriam as consequências das abordagens

tomadas.

#Reflexão#
Conseguiu perceber, no exercício anterior, qual seria o impacto em cada um
dos projetos? Vamos analisar o primeiro caso: fazer entregas parciais em um
projeto de um prédio não faz muito sentido, pois os moradores não vão querer
morar em um prédio incompleto. Além de ser um desconforto muito grande
(não haveria elevador, por exemplo), traria problemas de segurança. Nesse
caso, um projeto onde a entrega acontece somente no final do projeto seria o
mais adequado.

Agora no segundo projeto, muito provavelmente uma entrega muito demorada

faria com que o projeto perdesse seu valor, pois partes do sistema ficarão
desatualizadas, tornando o projeto parcialmente (ou até totalmente) obsoleto
ao final da entrega. Nesse caso, um projeto com entregas parciais e com
flexibilidade de adaptação do escopo é o que faz mais sentido.

Conseguiu perceber a diferença entre os dois casos? É assim que as

metodologias ágeis e tradicionais se comportam.

DIÁRIO DE BORDO
Tag padrão criada a fim de
orientar o aluno sobre como
utilizar o elemento.

#Conceitualização#

No exercício proposto, vimos que o gerenciamento de projetos tradicionais

pode ser pouco eficaz para projetos de software, uma vez que assume que os
eventos que afetam o projeto são previsíveis e com muita documentação,
seguindo um fluxo de um nível alto para um nível baixo, sendo necessário que
uma fase ou grupo de processos termine antes que outro possa ser iniciado de
forma orquestrada para que as fases do projeto sejam cumpridas dentro do
planejado. Além disso, antes de realizar a mudança é necessário aprovação,
por meio de um comitê que vai avaliar, e, uma vez confirmada, os processos de
planejamento devem ser refeitos.
Em contrapartida, nos projetos de software os requisitos são evasivos, voláteis
e sujeitos a alterações, pois normalmente parte do pressuposto que o cliente
não tem toda clareza do produto ou serviço no momento da contratação e
conforme o projeto avança a clareza vai surgindo e as alterações sendo
realizadas, isto é, os requisitos estão sujeitos a frequentes alterações durante o
ciclo de desenvolvimento do produto.

Assim, surge a necessidade de uma abordagem alternativa, mais flexível, que

permite modificações imediatas do produto, conforme os requisitos aparecem e
se tornam necessários, nasce então o Agile Project Management (APM), que
emergiu no setor de tecnologia da informação, principalmente a partir do
Manifesto Ágil para o desenvolvimento de software, em 2001, criado de forma
colaborativa por 17 profissionais (CRUZ, 2015).

Uma das bases das abordagens ágeis em projetos é não desperdiçar tempo e
recursos, pois o método ágil é um processo altamente iterativo e incremental,
no qual os desenvolvedores e as partes interessadas do projeto trabalham
ativamente em conjunto para entender o domínio, identificar o que precisa ser
construído e priorizar a funcionalidade (HASS, 2007). De acordo com Cruz
(2015), o Manifesto traz seus quatro valores, que sustentam e que também
formam a base das principais práticas ágeis, que são:

● Pessoas e interações entre elas é mais importante do que processos e

ferramentas: os processos e as ferramentas são necessários, porém não
devem substituir as interações humanas. Ainda, os processos e
ferramentas precisam ser, sempre que possível, simplificados e
minimizados para que não interfiram nas interações humanas e para que
sirvam de apoio ao desenvolvimento de produtos.
● Software funcionando é mais importante do que documentação
abrangente: um software funcionando e realizando exatamente o que o
seu cliente solicitou será sempre uma verdade absoluta. Entretanto, uma
documentação mínima necessária também é importante e possui seu
valor.
● Colaboração com o cliente é mais importante do que negociação de
contratos: colaborar com o cliente significa trazê-lo o mais próximo do
projeto, torná- -lo parte do Time de Desenvolvimento, envolvê-lo nas
 questões de sucesso, de riscos e de fracassos. Cabe destacar que, para
ambos os lados, negociar contratos com foco em cláusulas punitivas não
é positivo, por isso a orientação é para que o foco seja a colaboração e
não a negociação de contratos.
● Respostas rápidas a mudanças é mais importante do que seguir um
plano: atender a uma mudança e responder a ela no tempo certo, com a
rapidez adequada e na direção certa, é um benefício para qualquer
projeto e pode ser o que vai definir o sucesso e fracasso de um projeto.

#Explorando Ideias#

Princípios por trás do Manifesto Ágil

1. A maior prioridade é satisfazer o cliente por meio da entrega antecipada e

contínua.

2. Os processos ágeis se adequam rapidamente à mudança.

3. Entregar o software de trabalho com frequência, com o prazo mais curto.

4. Empresas e desenvolvedores devem trabalhar juntos diariamente ao longo

do projeto.

5. Construa projetos em torno de indivíduos motivados.

6. O método mais eficiente e eficaz de transmitir informações para um time de

desenvolvimento é a conversa cara a cara.

7. O software funcional é a principal medida de progresso.

8. Os processos ágeis promovem o desenvolvimento sustentável.

9. A contínua atenção à excelência técnica e ao bom design aumenta a

agilidade.

10. Simplicidade é essencial, reduza o trabalho que não precisou ser feito.

12. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-

organizadas.
13. Em intervalos regulares, para o time se tornar mais efetivo, ajuste seu
comportamento de acordo.

Fonte: adaptado de Agile manifesto ([2018], on-line)1 .

#Explorando Ideias#

O Gerente de Projeto precisa considerar suas forças pessoais, pois a aplicação

de métodos ágeis requer mais liderança e menos gerenciamento real. Com
uma maior ênfase na equipe (que inclui os clientes do projeto), tomando
decisões com base nas informações fornecidas pela equipe, as contribuições
do Gerenciador de Projeto estão mais focadas em “Remoção de barreiras”,
olhando para a frente no cronograma do projeto e antecipando e abordando as
ações que podem impedir o progresso da equipe do projeto (WEBSTER JR.;
KNUTSON, 2011).

Assim, a abordagem Ágil consiste em muitos ciclos de planejamento e

desenvolvimento iterativos rápidos, permitindo que uma equipe de projetos
avalie constantemente o produto em evolução e obtenha parecer imediato dos
clientes/ usuários ou partes interessadas (HASS, 2007). A autora destaca que
esta abordagem permite que a equipe aprenda e melhore o produto ou serviço,
bem como seus métodos de trabalho, de cada ciclo sucessivo.

A metodologia ágil é totalmente adaptável e aplicável a projetos de qualquer

natureza. Não existe uma resposta exata para qual metodologia é a melhor.
Tudo depende da maturidade da organização e da equipe do Projeto. Os
métodos ágeis normalmente são usados quando: o valor do projeto é claro; o
cliente participa ativamente ao longo do projeto; o cliente, os designers e os
desenvolvedores estão co-localizados; o desenvolvimento incremental de
recursos é possível; e a documentação visual é aceitável (HASS, 2007).

Diante disso, percebe-se que um dos pilares da agilidade é a comunicação e a

transparência entre as partes interessadas do projeto. Composta por equipes
enxutas, multidisciplinares e atuam de forma autogerida. Os métodos ágeis
quando aplicados exigem que cada colaborador seja um gerente responsável
pelas próprias ações a ele delegadas. Tornando-se capaz de aumentar o valor
do produto assumindo decisões de como fazer o trabalho.
Há uma grande diversidade de métodos ágeis que podem ser utilizados. Entre
os mais conhecidos, podemos citar o Scrum, a família Crystal, o FDD
(Feature Driven Development), o DSDM (Dynamic System Development
Method), XP (Extreme Programming), AUP (Agile Unified Process) e o Lean
Software Development.

Entre as diversas metodologias ágeis, o Scrum, para gerenciamento de

projetos, é a mais difundida. O Scrum, um framework dentro do qual pessoas
podem tratar de problemas complexos e adaptativos, pode ser utilizado
também para o planejamento, gerenciamento e desenvolvimento de qualquer
produto, principalmente por ser um framework iterativo e incremental (CRUZ,
2015).

A principal ideia do Scrum é controlar processos empíricos, por meio de três

pilares que emprega uma abordagem iterativa e incremental para otimizar a
previsibilidade e o controle de riscos: transparência, inspeção e adaptação.

A transparência garante que os aspectos do processo que afetam o resultado

sejam visíveis e conhecidos aos que controlam o resultado, para que todos
compartilharem um mesmo entendimento (CRUZ, 2015). Por exemplo: quando
uma etapa estiver descrita como finalizada, todos os integrantes devem saber o
que significa etapa finalizada (SCHWABER; SUTHERLAND, 2013).

A inspeção é parte da auto-organização do Time, logo os processos devem ser

totalmente inspecionados com uma frequência suficiente para que as variações
possam ser detectadas, considerando que o processo pode ser modificado
pelo próprio ato de inspecionar. Contudo, a inspeção não deve ser tão
frequente a ponto de atrapalhar a própria execução (CRUZ, 2015).

A adaptação seria o ajuste a ser realizado rapidamente, caso durante a

inspeção for verificada uma variação fora dos limites aceitáveis em um ou mais
aspectos do processo, e que o produto resultante será inaceitável (CRUZ,
2015). Para isso, o Scrum possui quatro eventos formais: a reunião de
planejamento da Sprint; reunião diária; reunião de revisão da Sprint; e a
retrospectiva da Sprint.
Na Reunião de Planejamento (Sprint Planning), realizada pelo Scrum Master
com no máximo oito horas, é que se define com toda equipe o trabalho a ser
realizado para a Sprint de um mês de duração. Nesta reunião, define-se “o que
será feito” e “como”. Normalmente, estas reuniões são diárias e duram entre 15
a 20 minutos e sempre no mesmo local e horário, para que a equipe de
desenvolvimento possa se organizar e criar um plano até a próxima reunião do
dia seguinte.

De acordo com Cruz (2015), o foco das perguntas é um alinhamento do que foi
e do que será realizado, e o que poderá agregar valor aos trabalhos dos outros
membros.

A Revisão da Sprint é a revisão do Product Owner, ou do cliente, em todos os

itens concluídos pelo Time. Esta cerimônia é um evento de quatro horas, em
que será possível conferir e avaliar o que foi considerado pronto, levando em
conta o que está sendo entregue versus o que deveria ter sido entregue
(SCHWABER; SUTHERLAND, 2013).

A Retrospectiva da Sprint, uma reunião de 3 horas, é uma oportunidade para o

Time Scrum voltar no tempo, inspecionar a si próprio e criar um plano para
melhorias a serem aplicadas na próxima Sprint de um mês (SCHWABER;
SUTHERLAND, 2013). Esta é a reunião que mais influencia e provoca a
melhoria contínua nos projetos e no Time (CRUZ, 2015).

Cabe destacar, que “[...] o framework Scrum consiste nos times do Scrum
associados a papéis, eventos, artefatos e regras. Cada componente dentro do
framework serve a um propósito específico e é essencial para o uso e sucesso
do Scrum” (SCHWABER; SUTHERLAND, 2013, p. 3). O Time Scrum é
composto pelo Product Owner (dono do projeto), o Time de Desenvolvimento e
o Scrum Master (responsável pela aplicação do Scrum).

Cruz (2015) destaca que o ciclo de vida de um projeto Scrum tem sua
estrutura, seu sequenciamento e seu ritmo ditados pelas Sprints com início,
conteúdo, execução e fim. Os Projetos podem possuir fases, e estas podem
ser divididas por Sprints ou por um conjunto delas. Conforme observado na
Figura 1.
Cabe destacar que o Backlog é uma lista de todas as características, funções,
tecnologias, melhorias e correções que constituem o produto a ser entregue.
Assim, o Backlog do produto: é o que será trabalhado ao longo do projeto e o
Backlog da Sprint é somente a parte do backlog considerada “preparada” e
selecionada para ser trabalhada na versão da Sprint (CRUZ, 2015). Ainda, ao
analisar a Figura 1, verifica-se que o ciclo de vida Scrum permite a execução
de um projeto em iterações menores, em um modelo sequencial e repetitivo,
gerando incrementos do produto até o encerramento completo do projeto
(CRUZ, 2015).

#Explorando Ideias#

Embora o Scrum possa ser aplicado em qualquer projeto, seus resultados

positivos são com facilidade alcançados em projetos de natureza tecnológica e
com equipes enxutas, compostas geralmente por três a sete pessoas. Um fator
relevante é que o Scrum não possui referências para o gerenciamento de áreas
como custos ou aquisições, tampouco para etapas como iniciação ou
encerramento de projetos, pois ele é aplicado de forma direcionada e focado
apenas na etapa de execução rápida dos projetos. Para que os projetos sejam
bem executados e tenham bons resultados, uma das regras é que o time seja
auto-organizável e multidisciplinar: se o Time não for experiente o suficiente
para se auto-organizar com eficiência e eficácia ou se não receber mentoria ou
coaching externos, a complexidade da sua aplicação e do seu gerenciamento
poderá ser aumentada em muitas vezes, inviabilizando os objetivos do projeto
ou comprometendo a confiabilidade do uso do próprio Scrum.

#Explorando Ideias#

Você verá que muitos valores, princípios e práticas da metodologia Crystal se

aproximam do Scrum e aumentam a robustez da aplicação da agilidade em
projetos de desenvolvimento de software (CRUZ, 2015). Desenvolvido por
Alister Cokburn, um dos idealizadores do movimento de Desenvolvimento Ágil
de Softwares, no ano de 2000. A Família Crystal é voltada para a gestão de
pessoas, com foco na interação, comunidade, habilidades, talentos e
comunicações, assim acreditando que estes princípios são os que têm efeito
no desempenho.
Os membros da equipe têm conjunto diferente de talentos e habilidades, ou
seja, a exclusividade de processos sobre medida para as equipes. Logo, é
muito sensível aos fatores humanos, focando nas habilidades e talentos das
pessoas. O método tem como característica se ajustar a cada projeto de
acordo com a sua complexidade, adotando um conjunto de processos para
cada situação a partir da análise de três fatores:

1. A carga de comunicação que é de acordo com o número de pessoas na

equipe.

2. A criticidade do sistema está relacionada com os riscos que um sistema

pode causar, quanto mais crítico for o projeto, maior a carga de processos.

3. A prioridade do projeto se dá pela importância do projeto para organização e

suas pessoas, quanto mais prioritário for o projeto maior atenção é dada a ele
(CRUZ, 2015).

A família Crystal é conhecida por ser pouco definida e por variar de acordo com
o projeto. Diante disso, utilizam-se cores (Figura 2) para indicar a complexidade
(ou “dureza”) da metodologia que deve ser aplicada (Cruz, 2015).
De acordo com Cruz (2015), quanto mais escura a cor, maior é a sua
complexidade e maior será o peso dos métodos. A escolha da cor, isto é, o tipo
de metodologia se dá pela análise da quantidade de pessoas dentro da equipe
versus a criticidade do projeto. Por exemplo, a cor:

● Crystal Clear é uma metodologia leve, para equipes de duas a oito

pessoas, podendo ser eficiente com até doze em casos especiais.
 ● Crystal Yellow funciona bem para equipes por volta de dez a vinte
membros.
● Crystal Orange e a variante Orange Web é mais apropriado para
equipes de vinte a cinquenta integrantes.
● Crystal Red para equipes de cinquenta a cem membros (CRUZ, 2015).

O Feature Driven Development (FDD), criado em 1997 para um banco em

Singapura, é uma Metodologia iterativa e incremental de gerenciamento e
desenvolvimento de software. Cabe destacar que algumas práticas podem não
se encaixar muito bem no Times Scrum, tais como a propriedade individual e
as equipes por funcionalidade, pois o Scrum busca times generalistas enquanto
o FDD objetiva a especialização das equipes (CRUZ, 2015).

Por outro lado, outras práticas do FDD se encaixam muito bem no Times
Scrum, e exige que a equipe se torne ainda mais eficiente no desenvolvimento
de software. Isso porque a FDD possui práticas como transparência do
progresso, o gerenciamento de configurações, as inspeções de qualidades, as
integrações frequentes e a modelagem com base no negócio (CRUZ, 2015).

O FDD “[...] é uma metodologia ágil que tem como foco principal a modelagem,
utilizada como artefato de planejamento e medição das funcionalidades que
agregam valor ao cliente” (CRUZ, 2015, p. 337). Isto é realizado por meio de
quatro processos principais (Figura 3):

1. Desenvolver um protótipo de produto: análise de requisitos, orientado

por objetos e outras técnicas.
2. Elaborar uma lista de funcionalidades: decomposição funcional do
domínio, em áreas de negócio, atividades de negócio e funcionalidades.
3. Planejar cada uma das funcionalidades: planejamento, ordenação e
estimativa das atividades da equipe e complexidade do produto.
4. Desenvolver e entregar cada funcionalidade: definição de padrões e
esqueletos de código e preparar o produto de entrega funcional.
Para o desenvolvimento orientado à funcionalidade, sugere-se a aplicação de
oito práticas que vão auxiliar a realizar os quatro processos principais da FDD
de forma eficiente (CRUZ, 2015):

1. Equipes modelam com base no negócio: não há divisão entre a

equipe de negócio e a equipe de desenvolvimento. Logo, toda equipe
trabalha em conjunto no atendimento do negócio do cliente, bem como
nas suas expectativas, focando na resolução do problema.
2. Desenvolvimento por funcionalidades: foco no desenvolvimento de
entregas em intervalos curtos de tempo, com inspeções e feedback
frequentes, além da identificação e mitigação de riscos e o tratamento
rápido de problemas e mudanças.
3. Propriedade individual: todo código escrito é de apenas um “dono”. A
ideia é que a própria pessoa mexa no código que construiu, permitindo
com isso maior rapidez na implementação de códigos associados,
complementares ou de correção.
4. Equipes trabalham por funcionalidade: equipes são montadas para
trabalharem em uma determinada funcionalidade e podem ser
organizadas por temas. Por exemplo:
a. A equipe A é responsável pela funcionalidade de clientes, e todos
os códigos associados são de propriedade da A.
b. A equipe B trabalha com a funcionalidade de produtos, sendo a
“dona” de todos os códigos associados (CRUZ, 2015, p. 339).
 5. Inspeções de qualidade: o objetivo é de prevenir problemas ou erros e
antecipar possíveis entregas com má qualidade.
6. Integrações e builds frequentes: as funcionalidades finalizadas devem
ser integradas às existentes com a possibilidade de serem apresentadas
ao cliente, permitindo assim a verificação de erros e gerando uma
versão atual do sistema.
7. Gerenciamento de configuração: o gerenciamento de configuração
proporciona segurança para os desenvolvedores, gestores e cliente.
Isso porque, com o gerenciamento de configuração, tem-se a
documentação sobre tudo o que foi realizado, permitindo históricos
completos de tudo que aconteceu no ciclo de vida de desenvolvimento
de um software.
8. Transparência do progresso: tem como finalidade deixar todos a par
do que está acontecendo com o projeto, isto é, permitir que todos
conheçam o progresso e os resultados do projeto sempre que for
necessário. Apresentando avanços, realizações ou até problemas e um
projeto sempre que solicitado ou necessário.

A metodologia DSDM (Dynamic System Development Method) também pode

ser aplicada de forma complementar com o Scrum no desenvolvimento de
sistemas. O DSDM foi criado na Inglaterra, na década de 90, por uma
organização sem fins lucrativos que reuniu membros de várias organizações. O
DSDM é uma metodologia de desenvolvimento de software originalmente
baseada em “Desenvolvimento Rápido de Aplicação” (RAD), que tem como
finalidade entregar softwares no tempo e orçamento “apertados”, por meio do
controle e ajuste de requisitos ao longo do desenvolvimento (TEIXEIRA et al.,
2005, on-line).

As quatro fases do DSDM (estudo de viabilidade, modelo funcional, Design e

construção e implementação) são antecedidas pelo pré-projeto e sucedidas
pelo pós-projeto, conforme a Figura 4.
No processo DSDM, o Pré-projeto tem como finalidade decidir se o projeto será
ou não implementado, analisando questões orçamentárias e um plano de
estudo de viabilidade. Por sua vez, o Pós-Projeto visa a manutenção do
sistema desenvolvido, por meio da realização de tarefas de alteração no
sistema no mesmo formato aplicado para o desenvolvimento (CRUZ, 2015).

O Estudo de viabilidade busca verificar se o DSDM é a solução mais

apropriada, avaliando quais processos serão afetados e quais são as
necessidades de informação para definição do escopo desenvolvimento
(CRUZ, 2015). O Modelo funcional, de forma básica e resumida, monta uma
lista de itens priorizados, que são documentados em formato de protótipo. O
Design e construção é a fase em que todos os requisitos são detalhados, tendo
como objetivo desenvolver o sistema, testando-o inteiramente e obtendo um
sistema pronto. Por fim, a Implementação se refere à transição do sistema do
ambiente de desenvolvimento para o de produção (CRUZ, 2015).
O XP (Extreme Programming), criado por Kent Beck no final da década de 90
nos Estados Unidos, é uma abordagem amplamente utilizada no mundo para o
desenvolvimento de software com qualidade, período curto de tempo,
reduzindo os custos e transtornos causados aos envolvidos no projeto. O XP
também pode complementar o Scrum, fornecendo princípios e práticas que
podem torná-lo ainda mais eficiente. De acordo com Foggetti (2014, p. 85-86),
os valores do XP são:

● Comunicação: entre os integrantes da equipe e cliente.

● Simplicidade: arquitetura simples é mais fácil de ser implementada.
● Coragem: a equipe deve estar comprometida.
● Feedback: antecipar o feedback evita retrabalho.
● Respeito: o respeito com a equipe é fundamental para execução de um
bom trabalho.

Cada membro da equipe XP assume responsabilidades conforme a sua

especialidade. O método XP preza por qualidades técnicas e de negócio para
desenvolver o software em questão (FOGGETTI, 2014). Nesta perspectiva, o
cliente é tido como aquele que conhece as regras do negócio e, por isso, deve
ser mantido no ambiente de desenvolvimento com os programadores, para
resolver dúvidas e dar feedback do que já foi construído (FOGGETTI, 2014).

Ainda, o autor destaca que os papéis do Coach e do Tracker são fundamentais

para garantir a qualidade das entregas. O primeiro garante a aplicação da
metodologia e avisa se algo não está de acordo. O segundo fica responsável
pela coleta e divulgação das informações atualizadas diariamente sobre o
andamento dos projetos. Assim, a programação extrema baseia-se em 14
princípios (FOGGETTI, 2014):

1. Humanidade – a produção depende dos programadores.

2. Economia – prioridades que agregam o máximo de valor no menor
tempo possível.
3. Melhoria – melhoria constante, por meio de soluções simples.
4. Benefício mútuo – desenvolver atividades como testes e refatorações.
5. Semelhanças – utilizar estruturas padrões.
6. Diversidade – a equipe deve possuir habilidades variadas.
 7. Passos pequenos – entregas pequenas para garantir a qualidade.
8. Reflexão – a equipe deve refletir sobre o trabalho.
9. Fluxo – a qualidade do trabalho deve ser linear, isto é, sem ociosidade
ou sobrecarga.
10. Oportunidade – equipe disposta a melhorar e aprender.
11. Redundância – testar bastante reduz erros.
12. Falha – aprendendo com erros.
13. Qualidade – pode-se negociar o tempo e escopo, nunca a qualidade.
14. Aceitação das responsabilidades – não há responsabilidades impostas.

De acordo com Foggetti (2014), um projeto XP se inicia com o entendimento

das características do produto a ser desenvolvido, que acontece por fases.
Inicialmente o cliente expõe a sua necessidade iniciando a fase de exploração
em que serão discutidas soluções possíveis, realizando também pesquisas e
experimentações para verificar a melhor solução a ser adotada. Na sequência,
inicia-se a fase do planejamento, que ocorre de forma interativa e incremental
com a escrita dos cartões, priorização e estimativas. E, por fim, chega na fase
de releases e iterações – release é uma versão do software que entra em
produção e a iteração é um ciclo em que algumas funcionalidades são
desenvolvidas e entregues para o cliente (FOGGETTI, 2014).

Cabe destacar que, ao acrescentar novas funcionalidades constantemente,

exige que o código seja simples. Para isso é necessário a realização de testes
automatizados e refatorações, em que são necessárias a padronização do
código, programação em pares e propriedade coletiva (FOGGETTI, 2014).

Uma abordagem simplificada, o Agile Unified Process (AUP), ou processo

unificado ágil (UP – Unified Process), é um processo para o desenvolvimento
de software com base no IBM Rational Unified Process – RUP. O ciclo de vida
AUP é composto por iniciação, elaboração, construção e transição, de forma
sequencial, iterativo e disponibiliza versões incrementais ao longo do tempo,
conforme visão geral que pode ser observada na Figura 5.
A fase de iniciação tem como finalidade identificar o escopo de um projeto e a
possível arquitetura de um projeto que, se for aprovado, passa para a fase de
elaboração, a qual é responsável por construir um protótipo do sistema para
verificar se a equipe consegue desenvolvê-lo de forma a atender os requisitos
das partes interessadas (CRUZ, 2015).

Na fase de construção, por sua vez, escreve-se os códigos do sistema de

forma incremental atendendo os requisitos e expectativas das partes
interessadas. Isto é, a priorização e entendimento dos requisitos são o
suficiente para transformá- -los em funcionalidades, realizar a modelagem e
codificação, bem como os testes do sistema construído (CRUZ, 2015). Por fim,
a fase de transição é responsável por validar e implantar o sistema no
ambiente de produção. Logo, esta fase se concentra em entregar o sistema
pronto e funcional (CRUZ, 2015).

Cruz (2015) destaca que o AUP pode ser utilizado como complemento do
framework Scrum, sugerindo otimizadas documentações RUP, bem como
etapas de testes bem definidas, além do gerenciamento de configuração,
projetos e ambientes preparados para o Time trabalhar.

[...] os marcos de verificação das fases do AUP podem deixar a

inspeção do Scrum mais robusta, proporcionando mais artefatos
e documentos de entrada para as cerimônias de adaptação e
promovendo iterações futuras melhoradas e otimizadas (CRUZ,
2015, p. 362).

Isto porque cada uma das fases do AUP tem no final um marco que sinaliza
que a equipe finalizou a fase com êxito. Assim, a AUP possui 4 marcos (CRUZ,
2015):

O primeiro marco se refere aos objetivos do Ciclo de Vida (LCO – Life Cycle
Objectives), pois, na fase de iniciação, as partes interessadas devem concordar
a respeito dos seguintes pontos:

● Escopo.
● O conjunto de requisitos levantado corretamente.
● Plano adequado, incluindo as estimativas iniciais de custo e
cronograma.
● Aceitação dos riscos identificados e estratégias de resposta aos riscos.
● Aceitação do processo AUP.
● Viabilidade do projeto em todas as perspectivas.
● Plano de projeto adequado para a próxima fase de elaboração.
● Adequação do projeto ao portfólio e à estratégia organizacional da
empresa.

O segundo marco é a arquitetura do Ciclo de Vida (LCA – Life Cycle

Architecture), pois, na fase de elaboração, as partes interessadas devem
concordar a respeito dos seguintes pontos:

● O projeto tem visão estabilizada e realista.

● A arquitetura é estável o suficiente para satisfazer os requisitos.
● Aceitação dos riscos com as estratégias de resposta.
● Viabilidade do projeto em todas as perspectivas.
● Plano de projeto adequado para a próxima fase de construção.
 ● Arquitetura do sistema está em conformidade com a realidade da
arquitetura empresarial.

O terceiro marco se refere à Capacidade Operacional Inicial (IOC – Initial

Operating Capacity), pois, na fase de construção, as partes interessadas
devem concordar a respeito dos seguintes pontos:

● O sistema e a sua documentação de apoio são aceitáveis do ponto de

vista de estabilidade e maturidade para que o sistema seja implantado.
● Os stakeholders estão preparados e prontos para a implantação do
sistema.
● Assiduidade da aceitação dos riscos.
● As despesas decorrentes do projeto estão de acordo com o custos e
cronogramas planejados.
● Plano de projeto está adequado para a próxima fase de construção. Os
trabalhos estão de acordo com as normas empresariais.

Por fim, o quarto e último marco é o Lançamento do Produto (PR – Product

Release), pois, na fase de transição, deve ter as seguintes concordâncias por
parte dos interessados no projeto:

● As partes interessadas satisfeitas e aceitam o sistema.

● Os responsáveis pela operação do sistema estão satisfeitos com os
procedimentos e as documentações.
● Os responsáveis pelo suporte ao sistema estão satisfeitos com os
procedimentos e as documentações.
● As despesas decorrentes do projeto estão conforme as estimativas para
custos e cronogramas futuros.

Cabe destacar, também, que AUP se difere do Scrum por ter fases e
disciplinas bem definidas (modelo, implementação, teste, implantação,
gerenciamento de configuração, gerenciamento de projetos em ambiente).
Cada disciplina é composta por um conjunto de atividades sugeridas para
aplicação durante as iterações (CRUZ, 2015).

Lean Software Development

O pensamento Lean iniciou-se na Toyota por Fiji Toyoda e Taiichi Ohno entre
1945 e 1975. Apenas na década de 90 passou a ser disseminado e
reconhecido internacionalmente por ser uma filosofia que tem por objetivo a
redução do desperdício de forma gradual e flexibilidade de produção dentro
das organizações. A partir do ano 2003, uniu-se os princípios de fabricação
enxuta com práticas ágeis.

De acordo com Jeff Sutherland, fundador do método ágil Scrum, os métodos

ágeis são aplicações do pensamento Lean para software (GOMES, 2017, on-
line)3 . Todavia, o Lean vai além do desenvolvimento ágil, oferecendo uma
perspectiva mais abrangente que permite resultados ainda melhores (GOMES,
2017, on-line)3 . Desta forma, o desenvolvimento de software Lean se
concentrou nessas áreas:

1. Crie o que é certo: compreenda a visão de interesse do cliente e forneça

valor real a eles. Uma equipe de produtos focada na resolução de
problemas reais de clientes integrará continuamente o conhecimento de
diversos membros da equipe, para garantir que a perspectiva do cliente
seja verdadeiramente compreendida e efetivamente abordada.
2. Crie-o rapidamente: um foco na eficiência do fluxo é o ingrediente
secreto do desenvolvimento de software enxuto. Logo, reduza
drasticamente o tempo de entrega da solução do cliente para a entrega.
3. Crie a coisa certa: garanta qualidade e velocidade com testes,
integração e implantação automatizados. O código de implantação com
frequência em pequenos lotes é a melhor maneira de reduzir o risco e
aumentar a estabilidade de bases de código complexas grandes.
4. Aprenda com o feedback: evolua o design do produto com base em
feedback de ponta a ponta precoce e frequente.

Assim, os princípios Lean Software Development estão relacionados à

eliminação de desperdícios de atividades que não agregam valor para o cliente,
por exemplo, repetições de atividades ou de ciclos de correção e
funcionalidades extras de um software em que o cliente nem vai utilizar.
Desenvolver certo desde a primeira vez também é um princípio muito
importante, evitando assim retrabalhos.
A metodologia lean incentiva a criação de conhecimento, por meio de
construção diária de feedbacks. Além do respeito às pessoas, é importante
entregar rápido e otimizar o fluxo de valores dentro do ambiente empresarial.

#Roda de Conversa - Podcast#

Autor: Rodrigo Eiti Kimura

Disciplina: Gestão de Projetos

Tema: O Pensamento Lean

Conceito: Uma crescente, não só na gestão de projetos, mas no mundo

corporativo como um todos, vem sendo a aplicação de estratégias lean para
gestão. Um exemplo de aplicação dessa vertente na gestão de projetos é a
metodologia Lean Software Development.

Objetivo: Entender os conceitos da filosofia lean e como isso pode ser

aplicado à gestão de projetos.

#Roda de Conversa - Podcast#

#Eu Indico#

Agile Practice Guide

Project Management Institute (PMI)

Editora: Project Management Institute

O livro apresenta as regras, práticas e técnicas

envolvidas no Scrum, apresentado como um processo
simples de gerenciar projetos complexos. Apesar de
serem poucas, diretas e fáceis de aprender, as regras
do Scrum podem acabar fazendo os usuários iniciantes
voltarem aos velhos hábitos do gerenciamento tradicional. Para isso, o livro
apresenta vários cases - de sucesso e fracasso - do ponto de vista de do co-
criador e evangelista do Scrum, Ken Schwaber.

# Eu Indico#

#Para que serve?#

O conhecimento das metodologias ágeis fará de você, aluno e futuro gerente
de projetos, um profissional atualizado e capaz de aplicar técnicas que
permitam gerenciar projetos que possuem um grau maior de incertezas e
alterações de escopo. Esse tipo de conhecimento lhe será útil em áreas como:
desenvolvimento de produtos, gestão de processos, gestão da inovação e
muitas outras.
#Para que serve?#

#Avaliação#

Olá, aluno! Esse é o momento de exercitarmos e verificarmos a sua

aprendizagem. Elabore um Mapa Mental com as principais características das
metodologias ágeis. Evidencie os pontos fortes dessa abordagem e as
diferenças com a metodologia tradicional.

#Avaliação#

#Agora é com você#

1. Há duas abordagens em gerenciamento de projetos, a ágil e a
tradicional. E gerenciamento de projetos tradicionais pode ser ineficaz
para projetos de software. Assinale a alternativa correta.
a. A abordagem tradicional possui pouca documentação e alta
flexibilidade, o que atrapalha no desenvolvimento dos projetos de
softwares.
b. A abordagem ágil é indicada no gerenciamento de projetos de
software, pois o cliente não tem toda a clareza do que quer ou
precisa.
 c. No desenvolvimento de projetos software ágeis, o cliente tem
pouca flexibilidade a mudanças.
d. Um dos fundamentos das abordagens ágeis em projetos é
desperdiçar tempo e recursos.
e. A abordagem tradicional parte de um processo altamente iterativo
e incremental.
2. O ciclo de vida do projeto é uma série de estágios pelas quais um
projeto passa, do seu início ao término. Estágios esses representados
por atividades ordenadas de forma lógica. Assinale a alternativa correta.
a. O ciclo de vida pode ser chamado de ciclo de desenvolvimento
que podem ser orientado para um plano ágil, iterativo e
incremental.
b. O ciclo de vida ágil é caracterizado pelo planejamento detalhado
de todo projeto.
c. O ciclo de vida deve ser rígido ao lidar com fatores incluídos no
projeto.
d. O ciclo de vida preditivo pode ser chamado de híbrido.
e. O ciclo de vida é igual para todos os projetos.
3. A Retrospectiva da Sprint, é uma reunião de grande importância para
o Time Scrum. Sobre a Retrospectiva da Sprint, assinale a alternativa
correta:

a. Costuma ser uma reunião rápida, de 50 minutos para

planejamento do que será realizado na Sprint atual.

b. É uma reunião de 3 horas que acontece no início do projeto.

c. É uma oportunidade para o Time Scrum voltar no tempo,

inspecionar a si próprio e criar um plano para melhorias a serem
aplicadas na próxima Sprint de um mês.

d. Não possui grande relevância na execução do projeto.

e. É uma reunião focada na eliminação de desperdícios com o

gerenciamento do projeto.

#Agora é com você#

#Orientação de resposta#
1. B. O pressuposto em projetos de software é de que o cliente possui
incertezas com relação ao escopo do produto e, por isso, a metodologia
ágil é adequada.
2. A.
3. C.

#Orientação de resposta#

#Referências#
CRUZ, F. Scrum e Agile em Projetos: Guia Completo. Rio de Janeiro:
Brasport, 2015.

DO VALLE, A. B. et al. Fundamentos do gerenciamento de projetos. 2. ed.

Rio de Janeiro: Editora FGV, 2010.

DO VALLE, J. A. S. Identificação e análise de fatores relevantes para a

implantação de escritórios de gerenciamento de projetos de construção
civil pelo conceito do Project Management Office. 2010. Tese de Doutorado
em Engenharia Civil, Universidade Federal Fluminense, Niterói/RJ, Brasil.

FOGGETTI, C. Gestão ágil de projetos. São Paulo: Education do Brasil, 2014.

Coleção Bibliografia Pearson.

HASS, K. B. The blending of traditional and agile project management. PM

world today, v. 9, n. 5, p. 1-8, 2007.

KEIDANN, G. L. Utilização de Mapas Mentais na Inclusão Digital. II Encontro

de Educomunicação da Região Sul. Ijuí/RS, jun. 2013. Disponível em: .
Acesso em: 01 ago. 2018.

MEREDITH, J. R.; MANTEL JR, S. J. Project management: a managerial

approach. John Wiley & Sons, 2009.
PMI (Project Management Institute). Um Guia do Conjunto de
conhecimentos de Gerenciamento de Projetos (Guia PMBOK® ). 6. ed.
Newtown Square, 2017.

SEBRAE. Como elaborar um plano de negócios. Brasília. 2013. Disponível

em:
<http://www.bibliotecas.sebrae.com.br/chronus/ARQUIVOS_CHRONUS/bds/bd
s.nsf/5f6dba19baaf17a98b4763d4327bfb6c/$File/2021.pdf>. Acesso em: 01
ago. 2018.

SCHWABER, K.; SUTHERLAND, J. Guia do Scrum–Um guia definitivo para

o Scrum: As regras do jogo. 2013. Disponível em:
<https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-
BR.pdf> . Acesso em: 01 ago. 2018.

TEIXEIRA, D. D. et al. DSDM–Dynamic Systems Development

Methodology. Faculdade de Engenharia da Universidade do Porto. v. 27, p.
05-09, 2005. Disponível em: <https://paginas.fe.up.pt/~aaguiar/es/artigos
%20finais/es_final_14.pdf>. Acesso em: 01 ago. 2018.

WEBSTER JUNIOR, F. M., KNUTSON, J. What Is Project Management?

Project Management Concepts and Methodologies. In: DINSMORE, P. C.;
CABANIS-BREWIN, J. (Ed.). The AMA handbook of project management.
AMACOM Div American Mgmt Assn, 2011.

#Referências#