Projeto Ágil

Prévia do material em texto

DEFINIÇÃO
Fundamentos da agilidade representados pelos valores e princípios do Manifesto Ágil assinado em
2001, Conceitos e características de dois métodos ágeis muito utilizados mundialmente, Extreme
Programming (XP) e Scrum.
PROPÓSITO
Compreender a essência do conceito de agilidade, que possui em seu cerne a cultura de frequente
entrega de valor, com qualidade e foco em pessoas, seja o cliente ou quem produz o produto.
Compreender as principais características dos métodos ágeis XP e Scrum.
OBJETIVOS
MÓDULO 1
Reconhecer valores e princípios do Manifesto Ágil
MÓDULO 2
Identificar as principais características do método Extreme Programming
MÓDULO 3
Reconhecer as principais características do framework Scrum
INTRODUÇÃO
O tema apresenta inicialmente o conceito da agilidade baseada nos valores e princípios do Manifesto
Ágil, com o objetivo de ressaltar que, antes de pensarmos em métodos, temos que entender a cultura de
entrega de valor no desenvolvimento de produtos, com ciclos curtos de feedback, para validação
frequente da expectativa do usuário. Após este entendimento, apresentaremos as principais
características dos métodos ágeis Extreme Programming e Scrum.
MÓDULO 1
 Reconhecer valores e princípios do Manifesto Ágil
Foto: NicoElNino / Shutterstock.com
LIGANDO OS PONTOS
Você sabe o que é um Alinhamento de Valores e Princípios em um Projeto Ágil? Você, como gerente de
projetos, conseguiria conduzir um projeto baseado na Metodologia Ágil em que não está totalmente claro
para o cliente quais são os principais valores e princípios de um Projeto Ágil e como todas as entregas
serão realizadas até o final do projeto? Para entendermos esse conceito na prática, vamos analisar o
case da empresa SPE – Serviço Brasileiro de Suporte a Empresas.
A empresa SPE é uma entidade privada que promove o desenvolvimento sustentável e a
competitividade das empresas brasileiras, atuando há mais de 30 anos com foco no fortalecimento e na
aceleração do processo de formalização da economia por meio de parcerias entre o sistema público e
privado. As soluções desenvolvidas pela empresa atendem desde o pequeno empreendedor que deseja
abrir seu primeiro empreendimento até empresas consolidadas e que buscam um novo posicionamento
no mercado. A SPE oferece consultorias, cursos, seminários e outros tipos de assistências para
empresas de diversas áreas de negócio. A empresa possui sua própria área de TI, que é responsável
pelo desenvolvimento de alguns sistemas internos, manutenção de todos os sistemas existentes e todo
o suporte que se faz necessário para as demais áreas de negócio da empresa.
Durante sua longa trajetória, a empresa SPE contratou diversas consultorias externas para desenvolver
parte dos seus sistemas de informação e muitos projetos fracassaram. A maioria dos projetos
conduzidos pelas consultorias externas seguia o modelo cascata, também conhecido como modelo
waterfall, em que todas as atividades do projeto são divididas entre etapas que costumam ser longas e
cada fase somente será iniciada após a conclusão e entregas da etapa anterior, fazendo com que o
cliente espere um longo tempo até que de fato receba software funcionando como entregável. Como nos
métodos ágeis as entregas ocorrem de forma rápida e contínua em que o principal foco é naquilo que
gera valor ao cliente (software), a empresa SPE estava bem otimista com relação à nova consultoria
externa que foi contratada e que desenvolveria um software seguindo a Metodologia Ágil, mas seria
necessário um alinhamento dos valores e princípios do Manifesto Ágil no início do projeto, para que
todos entendessem como o novo Projeto Ágil seria conduzido.
APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS
CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?
1. QUAL O PRINCIPAL OBJETIVO DE UM ALINHAMENTO DE VALORES E
PRINCÍPIOS?
A) Deixar claro para o cliente como as regras do projeto serão impostas pelo fornecedor.
B) Tem como objetivo o mapeamento de todos os processos de negócio da organização.
C) Esse tipo de alinhamento é necessário somente no início do projeto para que todos fiquem alinhados
de como os processos serão conduzidos do início ao fim do projeto.
D) É extremamente importante para que o cliente e o fornecedor fiquem alinhados de como os
processos serão conduzidos do início ao fim do projeto. Durante esse alinhamento, pode ser identificada
a necessidade de treinamentos como pré-requisitos para que se inicie o projeto. O Alinhamento de
Valores e Princípios poderá ocorrer sempre que houver algum desentendimento da forma como o
projeto está sendo conduzido.
E) É uma reunião entre cliente e fornecedor que ocorre somente no início do projeto, na qual serão
alinhados todos os processos legais necessários para a realização de um Projeto Ágil.
2. QUAIS OS PRINCIPAIS BENEFÍCIOS DE UM PROJETO ÁGIL COM RELAÇÃO A
UM PROJETO BASEADO NO MODELO TRADICIONAL (CASCATA –
WATERFALL)?
A) Processos mais flexíveis e sem burocracia.
B) Entregas contínuas e adiantadas de software com valor agregado com menor foco em documentação
e maior foco no que realmente gera valor ao cliente.
C) Maior liberdade em desenvolver um projeto sem documentação.
D) Comunicação mais eficiente durante todo o processo.
E) O custo do projeto será mais acessível, pois não será produzida uma documentação extensa.
GABARITO
1. Qual o principal objetivo de um Alinhamento de Valores e Princípios?
A alternativa "D " está correta.
Um dos maiores motivos que levam qualquer tipo de projeto ao fracasso é a falta de comunicação. A
comunicação entre todos deve ser clara e objetiva. Todas as equipes envolvidas no processo devem
possuir um vocabulário único. Gerenciar as expectativas e a comunicação de todas as partes
interessadas é um dos maiores desafios de um gerente de projetos que conduz um projeto por meio de
Metodologia Ágil ou Cascata. O gerente de projetos não precisa ser um especialista na Metodologia Ágil,
mas sempre que houver qualquer tido de “ruído” com relação aos processos seguidos e durante a
condução de qualquer projeto, ele deverá requisitar a presença do especialista em processos para que
se realize qualquer tipo de alinhamento necessário com toda a equipe envolvida. Um dos maiores riscos
de qualquer projeto é a falta de alinhamento e comunicação, por isso é fundamental o alinhamento de
valores e princípios do Manifesto Ágil.
2. Quais os principais benefícios de um Projeto Ágil com relação a um projeto baseado no
modelo tradicional (cascata – waterfall)?
A alternativa "B " está correta.
Um dos principais benefícios de um Projeto Ágil com relação a um projeto tradicional, com certeza, é a
entrega contínua de software com valor agregado ao cliente. Possuir um menor foco em documentação
não significa dizer que nenhuma documentação será produzida ao longo do processo. Muito pelo
contrário, toda documentação necessária e que agregue valor à entrega final do projeto deve ser
produzida. O que deve ser descartado é documentação desnecessária e que não agregue nenhum valor
ao projeto. É um erro muito comum acreditar que em projetos ágeis existe a liberdade de não seguir
processos e que não haverá nenhuma burocracia. Em qualquer tipo de projeto, os processos devem ser
seguidos para que se alcance o resultado esperado.
3. UMA DAS PRINCIPAIS CARACTERÍSTICAS DE UM
PROJETO ÁGIL É O ESCOPO ABERTO, OU SEJA, DURANTE
A CONDUÇÃO DO PROJETO, NOVOS REQUISITOS PODEM
SER DESCOBERTOS E O CLIENTE TERÁ A LIBERDADE DE
PRIORIZAR OU DESPRIORIZAR REQUISITOS PARA QUE
ESTES FAÇAM PARTE DAS ENTREGAS DE CADA SPRINT
PLANEJADA. O GRANDE PROBLEMA DO ESCOPO ABERTO
É QUE NÃO EXISTE UMA VISÃO CLARA DO ORÇAMENTO
NECESSÁRIO NO INÍCIO DO PROJETO PARA A ENTREGA
DE TODOS OS REQUISITOS QUE O CLIENTE POSSA VIR A
DESEJAR DURANTE A CONDUÇÃO DE TODO O PROJETO. É
IMPORTANTE DESTACAR QUE NOS PROJETOS ÁGEIS NÃO
EXISTE UM FOCO EM PRODUZIR DOCUMENTAÇÃO, MAS,
POR OUTRO LADO, COMO PODE UMA ESTIMATIVA
REALIZADA EM APENAS DOIS DIAS TER SIDO TÃO
ASSERTIVA SEM NENHUMA OUPOUCA DOCUMENTAÇÃO
EXISTENTE? QUAIS SERIAM SUAS AÇÕES COMO
GERENTE DE PROJETOS PARA QUE FOSSE MINIMIZADO
QUALQUER TIPO DE RISCO DEVIDO À CRIAÇÃO DE UMA
FALSA EXPECTATIVA AO CLIENTE COM RELAÇÃO A PRAZO
E CUSTO TOTAL?
RESPOSTA
Um dos principais problemas em qualquer tipo de projeto é a criação de falsas expectativas com relação a
prazo e custo. Por outro lado, dificilmente uma empresa iniciará um projeto sem ter uma visão clara de
quanto será necessário investir e quando será a entrega do projeto. Por essa razão, é fundamental que todos
javascript:void(0)
os envolvidos estejam devidamente alinhados com relação a todos os processos e a metodologia que será
seguida, antes mesmo do início do projeto. O maior risco de um projeto é a execução do próprio projeto. Se
não houver uma concordância sobre os processos e a metodologia a ser seguida, é mais prudente que nem
se inicie um projeto. Não existe garantia nenhuma de prazo e custo em um levantamento superficial que foi
realizado em apenas dois dias, isso com certeza criou uma falsa expectativa na empresa SPE com relação a
prazo e custo e o gerente de projetos e toda a equipe enfrentaram muitos problemas durante toda a
execução do projeto. Se o projeto foi contratado no modelo de “escopo aberto”, então deveria ter ficado claro
para o cliente que não há garantia nenhuma com relação a prazo e custo total. O prazo e o orçamento
variarão com o andamento e as entregas do projeto, o cliente poderá ter total liberdade de solicitar o
encerramento do projeto se não houver mais orçamento disponível.
MANIFESTO ÁGIL
O Manifesto Ágil configura um marco no contexto do desenvolvimento de software e consequentemente
na gestão de projetos para esta indústria. O documento foi assinado em um encontro nos dias 12 e 13
de fevereiro de 2001 em Snowbird, Utah, EUA, pelos seguintes expoentes desse nicho: Kent Beck, Mike
Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Bob Martin, Stephen Mellor, Jeff
Sutherland, Ken Schwaber e Dave Thomas.
Os signatários já atuavam com alguns métodos como: XP (Extreme Programming), DSDM (Dynamic
System Development Model), ASD (Adaptive Software Development), FDD (Feature-Driven
Development), Crystal e Scrum.
Esses métodos compartilhavam conceitos que foram incorporados ao manifesto por meio de suas ideias
como valores e princípios.
A figura 1 apresenta o que ficou popularizada como “cebola ágil”. As camadas simbolizam a relevância
na transformação ágil em uma organização. As camadas internas são mais fáceis de mostrar, mas não
representam criação de cultura ágil. Os processos e ferramentas podem ser impostos por uma gestão
autoritária, por exemplo. Já as camadas como valores e princípios são fundamentais para a criação do
mindset, ou seja, da forma de pensar ágil.
Os valores e princípios do manifesto foram criados na ocasião basicamente para atender às dores
conhecidas no desenvolvimento de software, mas com a propagação dos métodos ágeis, o mercado foi
percebendo os benefícios da agilidade em diversas áreas, como: RH, jurídico, comercial, inovação, entre
outras.
Imagem: Shutterstock.com
 Figura 1- “Cebola” Ágil”.
Adaptada de Adventures With Agile pelo Autor.
Foto: SeventyFour / Shutterstock.com
VALORES
Segundo o Agile Manifesto (2001), estamos descobrindo maneiras melhores de desenvolver software,
fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a
valorizar:
Foto: Shutterstock.com
VALOR 1 - INDIVÍDUOS E INTERAÇÕES MAIS QUE
PROCESSOS E FERRAMENTAS
Com esse valor, o manifesto apresenta a preocupação em colocarmos mais foco nas pessoas e nas
relações entre elas, do que ficarmos apoiados em processos e ferramentas. A ideia é fornecermos
condições para que os times executem suas tarefas e não perdermos tempo em engessar o trabalho
com processos. Outro ponto é a supervalorização das ferramentas. Ferramentas, como o próprio nome
diz, devem servir de apoio.
Foto: Shutterstock.com
VALOR 2 - SOFTWARE EM FUNCIONAMENTO MAIS QUE
DOCUMENTAÇÃO ABRANGENTE
A má interpretação deste valor foi responsável pelo mito que projetos ágeis não possuem
documentação. Mas o que o valor quer dizer é que mais do que documentação abrangente devemos
priorizar produto na mão do cliente, mas isso não quer dizer que não se documenta em projetos ágeis.
Se a entrega esperada pelo cliente contempla documentação, esta deverá ser adicionada ao conjunto
de critérios de aceitação.
Foto: Shutterstock.com
VALOR 3 - COLABORAÇÃO COM O CLIENTE MAIS QUE
NEGOCIAÇÃO DE CONTRATOS
É óbvio que a relação entre empresas deve ser baseada em contratos, mas se não houver colaboração
com o cliente, com preocupação em entender suas dores e expectativas, e com ciclos curtos de
feedback para validação de que as entregas atendem às necessidades, o contrato não será suficiente
para segurar a relação.
Foto: Shutterstock.com
VALOR 4 - RESPONDER A MUDANÇAS MAIS QUE SEGUIR
UM PLANO
A má interpretação deste valor também foi responsável pelo mito de que a agilidade não possui
planejamento. Na verdade, o que este valor apresenta é que, como atuamos muitas vezes em contextos
complexos, com muitas incertezas, devemos, mais do que seguir um plano, experimentar, validar e
adaptar.
Imagem: PopTika / Shutterstock.com
PRINCÍPIOS
Os princípios são preceitos básicos para a condução de práticas de agilidade ou utilização de métodos
ágeis. Para que um método possa ser chamado de ágil, este não pode infringir nenhum dos doze
princípios abaixo:

1. NOSSA MAIOR PRIORIDADE É SATISFAZER O CLIENTE
ATRAVÉS DA ENTREGA CONTÍNUA E ADIANTADA DE
SOFTWARE COM VALOR AGREGADO
Com ciclos curtos de desenvolvimento, conseguimos ter inspeção e adaptação, que possibilitam validar
frequentemente se o que está sendo entregue atende à expectativa de valor pelo cliente.
2. MUDANÇAS NOS REQUISITOS SÃO BEM-VINDAS,
MESMO TARDIAMENTE NO DESENVOLVIMENTO.
PROCESSOS ÁGEIS TIRAM VANTAGEM DAS MUDANÇAS
VISANDO À VANTAGEM COMPETITIVA PARA O CLIENTE
A mudança faz parte do contexto de complexidade do mundo em que vivemos atualmente. Logo, se o
cliente deseja mudar, é porque ele precisa. Seja porque aquele requisito não atende mais à necessidade
ou ele aprendeu que o que foi solicitado pode ser melhorado para agregar mais valor ao produto.


3. ENTREGAR FREQUENTEMENTE SOFTWARE
FUNCIONANDO, DE POUCAS SEMANAS A POUCOS MESES,
COM PREFERÊNCIA À MENOR ESCALA DE TEMPO
Este princípio reforça a necessidade de software funcionando (produto) como medida de progresso,
ainda que com períodos curtos entre a solicitação e a entrega, para rapidamente colhermos feedback do
cliente, nos adaptarmos e melhorarmos o produto.
4. PESSOAS DE NEGÓCIO E DESENVOLVEDORES DEVEM
TRABALHAR DIARIAMENTE EM CONJUNTO POR TODO O
PROJETO
Durante o desenvolvimento de um produto em um projeto, quanto menor ruído de comunicação entre
quem define os requisitos e quem desenvolve os incrementos de produto, menor será o risco de não
aceitação da entrega. Assim, devemos promover constantemente a comunicação face a face, a fim de
reduzirmos a perda de entendimento entre a definição de requisitos e o desenvolvimento do produto.


5. CONSTRUA PROJETOS EM TORNO DE INDIVÍDUOS
MOTIVADOS. DÊ A ELES O AMBIENTE E O SUPORTE
NECESSÁRIO E CONFIE NELES PARA FAZER O TRABALHO
Este princípio demonstra a preocupação em criarmos um ambiente favorável ao trabalhador do
conhecimento. O líder precisa entender o propósito de cada colaborador, se suas atividades estão
alinhadas com esse propósito, se a pessoa que está desenvolvendo as atividades está motivada com o
que está fazendo, para propiciar o engajamento, dedicação, comprometimento dos membros do time no
desenvolvimento do produto.
6. O MÉTODO MAIS EFICIENTE E EFICAZ DE TRANSMITIR
INFORMAÇÕES PARA E ENTRE UMA EQUIPE DE
DESENVOLVIMENTO É ATRAVÉS DE CONVERSA FACE A
FACE
Reforçado por este princípio,o conceito de times ágeis pressupõe equipes pequenas, para facilitar a
comunicação. Só com equipes pequenas podemos ter a comunicação face a face. Quando precisamos
executar grandes projetos com agilidade, é necessário escalarmos, ou seja, utilizarmos técnicas para
que vários pequenos times trabalhem juntos em um mesmo produto.


7. SOFTWARE FUNCIONANDO É A MEDIDA PRIMÁRIA DE
PROGRESSO
Ao contrário do que é apresentado geralmente em relatórios de status de projetos com percentual de
evolução de atividades, este princípio preconiza que software funcionando ou produto na mão do cliente
é a melhor medida de progresso. Melhor que uma informação de percentual de completude de uma
atividade é a entrega para o cliente de parte do produto potencialmente utilizável.
8. OS PROCESSOS ÁGEIS PROMOVEM DESENVOLVIMENTO
SUSTENTÁVEL. OS PATROCINADORES,
DESENVOLVEDORES E USUÁRIOS DEVEM SER CAPAZES
DE MANTER UM RITMO CONSTANTE INDEFINIDAMENTE
Agilidade pressupõe qualidade. Qualidade no produto entregue, mas também qualidade de vida para as
pessoas que trabalham no produto. Processos ágeis não incentivam sobrecarga de trabalho, como
horas extras, por exemplo. Em processos ágeis, as pessoas devem manter um ritmo de trabalho
sustentável constante indefinidamente.


9. CONTÍNUA ATENÇÃO À EXCELÊNCIA TÉCNICA E BOM
DESIGN AUMENTAM A AGILIDADE
Quando não é dada a devida atenção à qualidade técnica no desenvolvimento do produto, ocorre o que
chamamos de dívidas técnicas. Em desenvolvimento de softwares, essas dívidas técnicas podem ser
código mal feito, sem testes necessários, entre outros fatores, que com o passar do tempo irão consumir
o prazo da equipe para corrigi-los, com isso a capacidade da equipe em entregar novas funcionalidades
é comprometida com dívidas técnicas.
10. SIMPLICIDADE É ESSENCIAL
Muitas vezes a resolução de um problema está em uma solução simples. Ao apresentar uma solução
simples, o time estará sendo Lean (enxuto), quer dizer: Entregando valor com menos recursos e menos
tempo. Soluções elaboradas podem requerer um custo agregado de testes elaborados e risco de
aumento de dívida técnica.


11. AS MELHORES ARQUITETURAS, REQUISITOS E
DESIGNS EMERGEM DE EQUIPES AUTO-ORGANIZÁVEIS
Em times ágeis, devemos buscar a auto-organização. Times auto-organizados recebem o objetivo da
entrega e se auto-organizam para definirem a melhor forma de construir o produto. Com isso, as
melhores arquiteturas emergem dessa união de perfis diferentes em prol do objetivo comum de construir
uma melhor arquitetura para suportar a entrega do produto.
12. EM INTERVALOS REGULARES, A EQUIPE REFLETE
SOBRE COMO SE TORNAR MAIS EFICAZ E ENTÃO REFINA
E AJUSTA SEU COMPORTAMENTO DE ACORDO
Este princípio preconiza que os times ágeis, por exemplo ao final de um ciclo de entrega, devem realizar
uma retrospectiva com o objetivo de entender o que deu certo, o que deu errado e como podem
melhorar para o próximo ciclo.

 ATENÇÃO
O manifesto ágil, com sua definição de valores e princípios, configurou um marco no contexto do
desenvolvimento de software e, consequentemente, na gestão de projetos para esta indústria.
Posteriormente, entendeu-se que em outras áreas, os métodos ágeis também poderiam ser utilizados
com sucesso, e atualmente temos agilidade em processos financeiros, de RH, comercial, marketing,
inovação entre outros.
Assista ao vídeo a seguir para saber mais sobre valores e princípios do Manifesto Ágil.
VERIFICANDO O APRENDIZADO
1. DE ACORDO COM O QUE VOCÊ ESTUDOU NESTE MÓDULO, SELECIONE A
SENTENÇA QUE NÃO REPRESENTA UM VALOR DO MANIFESTO ÁGIL:
A) Em detrimento de muita documentação, entregue software funcionando.
B) Priorize a relação com seu cliente ao invés de recorrer constantemente ao contrato.
C) Siga seu plano à risca e defina um processo que não acate mudanças.
D) O processo não é mais importante que as pessoas e suas relações.
2. ASSINALE O PRINCÍPIO DO MANIFESTO ÁGIL QUE NÃO ESTÁ DE ACORDO
COM A REALIZAÇÃO DE EXCESSIVAS HORAS EXTRAS.
A) Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software
com valor agregado.
B) Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo constante indefinidamente.
C) Simplicidade é essencial.
D) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.
GABARITO
1. De acordo com o que você estudou neste módulo, selecione a sentença que não representa
um valor do Manifesto Ágil:
A alternativa "C " está correta.
O quarto valor do Manifesto Ágil diz para respondermos às mudanças mais que seguirmos um plano. As
mudanças devem ser acatadas, porque os ciclos curtos permitem a adaptação para responder às
mudanças. Este valor não fala de não seguir um plano, mas, sim, de responder às mudanças ser mais
importante que seguir um plano.
2. Assinale o princípio do Manifesto Ágil que não está de acordo com a realização de excessivas
horas extras.
A alternativa "B " está correta.
O oitavo princípio do Manifesto Ágil diz que a equipe deve manter um ritmo sustentável
indefinitivamente, logo não devemos ter variações de carga de trabalho, como horas extras, para que a
equipe possa manter esse ritmo. O ritmo sustentável de um time ágil é determinado pelo respeito à sua
capacidade durante o tempo da construção do produto. Este ritmo deve evitar variações como sobre ou
subcarga de trabalho para que não tenhamos períodos de ociosidade, bem como não devemos permitir
sobrecarga para que não tenhamos problemas de saúde dos membros do time e também má qualidade
na entrega do produto.
MÓDULO 2
 Identificar as principais características do método Extreme Programming
Imagem: Profit_Image / Shutterstock.com
LIGANDO OS PONTOS
Você sabe o que é uma Programação em Par? Você, como o gerente responsável pela área de
desenvolvimento de uma empresa de TI, recebe a missão de desenvolver um software que será uma
inovação para o mercado financeiro e, para isso, resolve adotar a programação em par, que é uma das
práticas da metodologia Extreme Programming, com o objetivo de criar um ambiente de
desenvolvimento mais colaborativo. Para entendermos esse conceito na prática, vamos analisar o caso
da empresa HW Consulting.
A empresa HW Consulting é uma empresa privada que atua na área de Tecnologia da Informação. A HW
Consulting é estruturada basicamente em duas verticais de negócio, produção e comercialização de
hardware (servidores, computadores pessoais, impressoras e dispositivos bancários) e desenvolvimento
de sistemas voltados para instituições financeiras, principalmente bancos financeiros.
A HW Consulting nasceu da aquisição de uma empresa especializada na produção e comercialização de
dispositivos bancários (impressoras, leitoras de cartão, PIN pads e outros) em 1992. Em 2004, a HW
Consulting iniciou o desenvolvimento de uma plataforma bancária aberta conhecida como Open
Banking. O Open Banking era uma ideia totalmente inovadora em termos de negócio e das tecnologias
utilizadas. Cada banco possuía seu sistema financeiro próprio por meio da utilização de diferentes tipos
de protocolos e tecnologias da informação.
A principal ideia do Open Banking era criar um sistema baseado em um protocolo comum de
comunicação e de uma tecnologia inovadora e altamente escalável – ser escalável significa ser aberto à
implementação de futuras melhorias de acordo com a necessidade do mercado global. A tecnologia
selecionada foi a linguagem C# da plataforma de desenvolvimento Microsoft .NET. Essa linguagem de
programação é uma das tecnologias mais promissoras da Microsoft e tem evoluído de forma constante
ao longo dos anos.
Outro grande desafio do Open Banking era que todo o sistema deveria ser executado por meio da Web,
ou seja, todas as transações financeiras mais comuns (saque, depósito, extrato, abertura e
encerramento de conta, pagamentos,transferências e outros) deveriam ser executadas em qualquer
navegador de Internet, tais como o Internet Explorer do Windows e o Safari do Mac OS. Como havia a
necessidade de muita comunicação com hardware, boa parte das interfaces com o hardware havia sido
desenvolvida nas linguagens C e C++. Sendo assim, era um ambiente de desenvolvimento de alta
complexidade que necessitava estar sob um ambiente altamente colaborativo para que o projeto fosse
bem-sucedido.
APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS
CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?
1. O QUE VEM A SER O EXTREME PROGRAMMING (XP)?
A) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que somente
pode ser adotada por empresas experientes na área de TI.
B) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que deu
origem ao Scrum.
C) O Extreme Programming é um conjunto de processos que possibilita o desenvolvimento padrão de
softwares.
D) O Extreme Programming é um conjunto de boas práticas no desenvolvimento de softwares.
E) O Extreme Programming é uma metodologia focada no desenvolvimento de softwares que possui
valores e princípios, que são fundamentados por um conjunto de práticas.
2. NO QUE CONSISTE A PROGRAMAÇÃO EM PAR?
A) A Programação em Par consiste em dois programadores que trabalharão juntos para resolver o
mesmo problema. O desenvolvedor que assume o teclado e digita é chamado condutor, enquanto o
outro que acompanha é chamado de navegador, que fará um trabalho de estrategista.
B) A Programação em Par consiste em dois programadores que trabalharão de forma separada para
resolver o mesmo problema.
C) A Programação em Par consiste em dois programadores que trabalharão para resolver o mesmo
problema, mas em diferentes etapas. Um dos programadores será responsável pela codificação
enquanto o outro será responsável pela revisão.
D) A Programação em Par consiste em dois ou mais programadores que trabalharão juntos para
resolver o mesmo problema.
E) A Programação em Par consiste em dois programadores que trabalharão juntos para resolver
diferentes tipos de problemas. A troca de ideias será constante entre os programadores.
GABARITO
1. O que vem a ser o Extreme Programming (XP)?
A alternativa "E " está correta.
A metodologia de desenvolvimento de softwares Extreme Programming (XP) é leve e pode ser
facilmente adotada por diferentes níveis de equipes de desenvolvimento (iniciantes a experientes) e em
qualquer tamanho de equipe. O XP é considerado uma excelente metodologia de desenvolvimento de
softwares, que pode ser facilmente adaptável aos requisitos de negócio que podem mudar facilmente.
2. No que consiste a Programação em Par?
A alternativa "A " está correta.
A Programação em Par consiste em dois programadores que trabalharão para resolver o mesmo
problema e este será um grande benefício para a modelagem da solução, pois quando uma solução é
modelada por dois programadores, ela tende a ser mais eficiente do que quando modelada por uma só
pessoa. Geralmente, os programadores utilizam de conhecimentos e experiências que se acumularam
ao longo de suas carreiras, então, acaba ocorrendo um somatório dessas experiências, o que é muito
bom para o projeto.
3. NA SUA VISÃO COMO GERENTE DE DESENVOLVIMENTO
DA HW CONSULTING, A ADOÇÃO DA METODOLOGIA
EXTREME PROGRAMMING TROUXE EXCELENTES
RESULTADOS PARA A EMPRESA, PRINCIPALMENTE COM A
ADOÇÃO DA PROGRAMAÇÃO EM PAR – PAIR
PROGRAMMING. ACONTECE QUE ESTÁ OCORRENDO
MUITO RUÍDO NAS OUTRAS ÁREAS DA EMPRESA, DE QUE
OS RECURSOS HUMANOS ESTÃO SENDO UTILIZADOS DE
FORMA INEFICIENTE, SENDO QUE SEMPRE UM
DESENVOLVEDOR PROGRAMA, ENQUANTO O OUTRO FICA
PARADO CONVERSANDO. QUE EXEMPLO DE AÇÃO VOCÊ
TOMARIA PARA CONSCIENTIZAR O RESTANTE DA
EMPRESA DE QUE A PROGRAMAÇÃO EM PAR ESTÁ, DE
FATO, GERANDO BONS RESULTADOS PARA OS
PROJETOS?
RESPOSTA
javascript:void(0)
A técnica da Programação em Par pode parecer estranha para muitas pessoas, principalmente para aqueles
que desconhecem a metodologia Extreme Programming. Como gerente de desenvolvimento, uma das
primeiras ações necessárias para reduzir o ruído seria a elaboração de workshops internos apresentando os
benefícios da metodologia Extreme Programming para toda a empresa. Ruídos devem ser eliminados o mais
rápido possível, pois um dos maiores problemas que levam ao fracasso é a falta de comunicação e esses
ruídos podem impactar negativamente na tomada de decisão por parte das principais partes interessadas –
Stakeholders dos projetos. Mas, como um bom gerente de desenvolvimento, não bastaria somente um
workshop focado em conceitos. Seria muito importante o levantamento de dados reais (horas de esforço,
tamanho de equipe, prazos, custos e indicadores de qualidade) nos quais fossem apresentadas as
diferenças do antes e do depois da implementação da metodologia Extreme Programming. Com certeza,
uma justificativa baseada em indicadores reais tem um peso muito maior do que simplesmente a
apresentação de conceitos.
EXTREME PROGRAMMING
O Extreme Programmig (XP) é um método de desenvolvimento de software criado por três dos
signatários do Manifesto Ágil: Kent Beck, Ward Cunningham e Ron Jeffries. O XP, além de ser
inteiramente aderente aos valores e princípios do Manifesto Ágil, fato que o credencia como um método
ágil, também é fundamentado em seus próprios valores e práticas.
VALORES
Os valores denotam o grau de importância de um determinado tema e representam as melhores ações a
serem tomadas no contexto deste tema. De acordo com Wildt (2015), o XP define cinco valores para
que seus papéis e práticas atuem de acordo com sua essência ágil: A comunicação, o feedback, a
simplicidade, o respeito e a coragem.
Foto: Shutterstock.com
COMUNICAÇÃO
A comunicação figura como a principal causa em fracasso em projetos de software na maioria das
pesquisas do ramo. O contexto de desenvolvimento de software envolve muitas incertezas, logo
precisamos dar muita atenção à comunicação, ainda mais em ambientes de equipes remotas onde a
comunicação face a face ocorre por meio de recursos eletrônicos, podendo acarretar perda de
informação.
FEEDBACK
O feedback rápido e frequente é outra forma de minimizar riscos em ambiente de desenvolvimento de
software. Muitas vezes, o cliente só percebe o que realmente precisa ao receber as primeiras versões
do que pediu, e quanto mais cedo o time receber o feedback, mais cedo fará as adaptações
necessárias.
Foto: Black Salmon / Shutterstock.com
Foto: sutadimages / Shutterstock.com
SIMPLICIDADE
A simplicidade é um valor que ajuda o time a manter o foco no valor que realmente precisa entregar. O
foco é essencial para evitar desperdícios no processo de desenvolvimento de software.
RESPEITO
Este valor deve ser praticado por todos. Tanto os membros dos times quanto clientes e outras partes
interessadas. Criar um ambiente onde se pratica o respeito, sem necessidade de encontrar culpados e
focado em criar um ambiente agradável de trabalho certamente contribuirá para a formação de um time
de alta performance, mais motivado e com empatia, que pratica o respeito tanto com seus pares, quanto
com a qualidade do produto que está sendo desenvolvido, que se traduz em respeito com o cliente.
Foto: sutadimages / Shutterstock.com
Foto: fizkes / Shutterstock.com
CORAGEM
As práticas dos valores anteriores, principalmente o respeito, estimulam a formação de um ambiente
onde os membros do time tenham coragem para fazer o que é preciso, por exemplo, refatorar um código
(ver prática: refatoração). Os membros dos times precisam se sentir em um ambiente safe to fail, que
significa, em livre tradução, um ambiente seguro para falhar, para que possam ter coragem de fazer o
que é preciso, sem se sentirem inseguros e com medo de serem penalizados.
PRÁTICAS
No Extreme Programmig, membros do time e cliente interagem para definir, priorizar e entregar o
produto utilizando as práticas de desenvolvimento de software. SegundoTeles (2004), o time precisa ter
coragem e acreditar que a utilização dessas práticas e valores do XP fará o software evoluir com
segurança e agilidade.
Imagem: Jeffries, 2011.
 Figura 2 - Práticas Extreme Programming.
Veja um pouco mais sobre cada uma dessas práticas:
EQUIPE INTEIRA
Colaboração com partes interessadas, como cliente, deve ser uma prática constante da equipe com o
objetivo de promover a interação com o time para fornecer requisitos e prioridades para o time de
desenvolvimento.
Foto: George Rudy / Shutterstock.com
Segundo Massari (2014), o princípio de equipe inteira ou equipe unida parte da premissa de que a
equipe deve ser formada por generalistas e não por especialistas.
Foto: George Rudy / Shutterstock.com
JOGO DE PLANEJAMENTO
Oportunidade na qual cliente e time de desenvolvimento se reúnem para decidir quais entregas entrarão
na próxima release e iterações. Uma release pode ser uma versão de um software ou um módulo do
software.
No jogo do planejamento, o cliente e o time trabalham juntos, colaborativamente para planejarem a
entrega de uma release. Uma release poderá ter várias iterações. No jogo, o cliente definirá o escopo, a
prioridade e a expectativas de data de entrega. O time estima o trabalho apresentado em forma de
história de usuário e aponta dependências técnicas, caso existam. Os desenvolvedores puxam as
histórias e se comprometem com sua entrega.
 ATENÇÃO
Os incrementos de produto são definidos em um plano de release e as iterações são definidas em um
plano de iterações. Um incremento pode ser desenvolvido em uma ou mais iterações.
PEQUENAS ENTREGAS
Entregas pequenas e frequentes são essenciais para a obtenção de feedback.
 COMENTÁRIO
Com essa prática, o time valida se está indo no caminho correto ou precisa corrigir parte do produto para
atender à expectativa do cliente.
TESTES DE ACEITAÇÃO (CLIENTE)
Ao definir o requisito, o cliente define os critérios de aceitação para o requisito. A equipe deve
desenvolver o objeto do requisito à luz dos critérios de aceitação, e implementar testes automatizados
para validar se o que foi desenvolvido está de acordo com o que foi pedido pelo cliente.
Foto: George Rudy / Shutterstock.com
Foto: George Rudy / Shutterstock.com
PROPRIEDADE COLETIVA DO CÓDIGO
Os códigos desenvolvidos em times XP são compartilhados entre os membros da equipe evitando que
indivíduos sejam seus proprietários. Isso é muito importante para que a produtividade não caia quando,
por algum motivo, um membro esteja indisponível. Outro ponto importante é que a qualidade aumenta
quando mais de uma pessoa trabalha no código, em razão do compartilhamento do conhecimento.
PADRÃO DO CÓDIGO
Os times XP seguem um padrão de codificação para manter a produtividade coletiva.
 COMENTÁRIO
Assim, quando um membro for trabalhar em um código desenvolvido por outro membro, não haverá
problema de entendimento.
RITMO SUSTENTÁVEL
De acordo com o WHAT IS EXTREME PROGRAMMING, assim como abordamos no módulo anterior, os
times XP devem manter um ritmo de trabalho que possa perdurar por muito tempo, evitando grandes
variações de carga de trabalho, como, por exemplo, com a realização de horas extras.
Foto: George Rudy / Shutterstock.com
METÁFORAS
As metáforas são utilizadas para manter uma linguagem comum entre os membros do time XP.
É uma técnica para que todos saibam identificar rapidamente uma determinada rotina ou sistema.
Quando alguém se referir a determinado nome, não deixará dúvida sobre o que ele está mencionando.
Isso é mais fácil do que explicar sobre o que se está falando.
 COMENTÁRIO
Segundo Wildt (2015) usamos metáforas em nosso cotidiano para facilitar nosso entendimento, como o
carrinho de compras de uma loja virtual ou a área de trabalho de nosso computador com nossas pastas.
INTEGRAÇÃO CONTÍNUA
Os times XP integram seus códigos várias vezes ao dia.
 ATENÇÃO
Quanto mais tempo levar para integrar os códigos escritos, mais difícil será para ajustar erros. Por isso,
é muito importante integrar continuamente o código.
Foto: George Rudy / Shutterstock.com
TESTES UNITÁRIOS
Os testes unitários servem para fornecer feedback imediato ao desenvolvedor ou ao par de
desenvolvedores. Na execução do código principal, o código do teste também é executado, informando
se o código feito está com erro ou não.
REFATORAÇÃO
A melhoria contínua é uma preocupação dos métodos ágeis e no XP não é diferente.
A refatoração ou melhoria contínua é uma técnica para melhorar o código minimizando problemas como
duplicidade de código.
Para Massari (2014), o princípio da refatoração consiste em melhorar a qualidade do código existente,
tornando-o mais elegante e legível, porém sem alterar o comportamento da funcionalidade.
DESIGN SIMPLES
Alinhado ao valor simplicidade, o XP preconiza que o design do software comece simples e continue
assim, mesmo com o incremento de funcionalidades no sistema.
 COMENTÁRIO
As práticas como testes unitários, programação em par e refatoração ajudam a evoluir com o software e
manter seu design simples.
PROGRAMAÇÃO EM PAR
De acordo com Massari (2014), os códigos produzidos por times que adotam o XP são desenvolvidos
em par, mas em uma mesma máquina.
 ATENÇÃO
Está técnica propicia não só um melhor compartilhamento de código, mas também de conhecimentos, o
que propicia alcançar melhor qualidade, identificar riscos e formar equipes de alto desempenho.
Outra técnica muito utilizada no Extreme Programmig, que também aparece no Scrum, é a história de
usuário.
Seu formato simples requer uma conversação face a face para coletar detalhes do cliente pelo time de
desenvolvimento. Exemplos de histórias de usuários:
Eu, como médico, quero pesquisar prontuário do paciente pelo número do CPF.
Eu, como cliente, quero pesquisar restaurantes próximos à minha casa.
As práticas do Extreme Programmig de desenvolvimento de software foram tão consolidadas pelo
mercado que atualmente é comum serem utilizadas em conjunto com outros métodos ágeis, por
exemplo, o Scrum.
Foto: Lipik Stock Media/ Shutterstock.com
PAPÉIS DO XP
O Extreme Programming preconiza alguns papéis que objetivam equilibrar as responsabilidades
inerentes ao desenvolvimento de software. Conforme Wildt (2015), em alguns casos, um indivíduo pode
acumular papéis, desde que não haja conflito de interesses, por exemplo, um indivíduo que atua em um
papel de gerente, sendo pressionado para realizar uma determinada entrega, e este mesmo indivíduo
atuando como coach com necessidade de trabalhar com mais paciência e foco na evolução
comportamental do time.
DESENVOLVEDOR
O desenvolvedor, também conhecido como programador, é um papel com atribuições ligadas
diretamente à criação do software com qualidade. As atribuições do desenvolvedor vão desde a
estimativa das atividades até a entrega do produto. Em times ágeis multidisciplinares é comum termos
desenvolvedores com especialidades específicas como front-end ou back-end. Mas podemos ainda ter
indivíduos que possuem competência para atuar em todas essas áreas, como os chamados atualmente
de full stacks. Obviamente, este perfil é muito interessante para um time ágil, mas não é fácil montar
times com vários indivíduos assim, pelo fato de geralmente pedirem uma remuneração maior e serem
mais difíceis de ser encontrados no mercado para contratação, uma vez que são profissionais que
costumam possuir um nível mais elevado de conhecimentos.
CLIENTE
O cliente é o papel que mais conhece do negócio. No Scrum, existe um papel semelhante a este, que é
conhecido como Product Owner. O cliente do Extreme Programming é quem define os requisitos em
formato de histórias de usuário, bem como sua priorização para os desenvolvedores materializá-las em
produto. O papel do cliente é fundamental para fornecer o feedback rápido em relação ao produto.
Sabemos que mesmo com uma boa definição do requisito e frequente comunicação do cliente com a
equipe, ainda é possível que, ao utilizaro produto, a experiência possa não atender à expectativa do
cliente, por isso é importante que o cliente alimente o time de desenvolvimento com constantes
feedbacks sobre a sua percepção de utilização do produto.
COACH
O XP é intimamente orientado ao lado comportamental do time. Isso quer dizer que além da capacidade
técnica, o time precisa respeitar valores, aderir às práticas, ter disciplina com os ritos necessários do
método. Para ajudar o time a criar essa cultura, o XP conta com o papel do coach. O coach precisa
conhecer bem de desenvolvimento de sistemas e ser um técnico capaz de ajudar o time a assimilar os
valores e utilizar as práticas do XP. O coach é o líder servidor, ele facilita cerimônias, como jogo do
planejamento, reuniões diárias e retrospectivas e é o guardião dos valores do XP. Ele serve à equipe XP,
identifica necessidades de cada membro, como a realização de um treinamento para que um
desenvolvedor possa melhor realizar suas atividades. O coach também pode acumular o papel com um
desenvolvedor, por exemplo.
TESTADOR
O testador é um papel importante para garantir a qualidade do software. Dentre suas responsabilidades,
ele apoia o cliente a escrever testes de aceitação. O testador faz parte da equipe e pode apoiar a
automatização dos testes, bem como realizar testes funcionais para minimizar a probabilidade de
liberação de software com erros.
CLEANER
O cleaner é o indivíduo responsável por melhorar o código sempre apoiado nas práticas do XP. Ele deve
ter como característica a excelência técnica porque precisa enxugar o código sem obviamente perder
sua consistência. O cleaner deve encorajar o time a desenvolver códigos mais limpos e com qualidade
para minimizar problemas com dívida técnica. A dívida técnica ocorre quando o time não prima pela
qualidade do código e posterga ações de melhoria de qualidade. Com o tempo, os problemas vão se
acumulando e consumindo a capacidade do time de desenvolver novas funcionalidades, pelo fato de
ficarem ocupados corrigindo problemas causados por falta de atenção à qualidade no passado.
TRACKER
O tracker é responsável por coletar medições do time durante o projeto. Essas medições servem para
avaliar a evolução do time e suas entregas. Por exemplo, a medição da quantidade de histórias de
usuários entregues com sucesso. Quando um time começa a entender seu padrão de entregas por
iteração (ciclos de entregas), é possível utilizar essa métrica para prever entregas de produtos no futuro.
GERENTE
O gerente é um papel que auxilia o time XP com a comunicação com clientes e partes interessadas do
projeto. Ele é responsável pela elaboração e manutenção de relatórios sobre a evolução do projeto. Seu
papel não é o de chefe do time XP, mas, sim, o de líder servidor, sempre procurando avaliar as
necessidades do time para prestar suporte naquilo que for necessário para melhorar o seu desempenho
e motivação para a entrega de produtos de qualidade.
Antes de finalizar o módulo, assista ao vídeo abaixo e tenha mais clareza sobre o que é Extreme
Programmig e seus valores.
TEXTO
VERIFICANDO O APRENDIZADO
1. CARLOS É UM DESENVOLVEDOR EM UM TIME QUE UTILIZA O MÉTODO
EXTREME PROGRAMMING. ELE DESENVOLVEU UM CÓDIGO E ESTÁ MUITO
ORGULHOSO DO QUE FEZ, A PONTO DE NÃO QUERER MOSTRAR PARA
NINGUÉM SEU CÓDIGO COM RECEIO QUE COPIEM SUAS IDEIAS. QUAL DAS
PRÁTICAS LISTADAS ABAIXO FOI DESRESPEITADA NO CENÁRIO
APRESENTADO?
A) Metáforas
B) Design simples
C) Padrão de código
D) Propriedade coletiva do código
2. OS TIMES DE DESENVOLVIMENTO DE EMPRESA QUE UTILIZAM O MÉTODO
ÁGIL EXTREME PROGRAMMING REFEREM-SE AO SISTEMA QUE MAIS GERA
RECEITA PARA A EMPRESA COMO “MINA DE OURO” PARA QUE TODOS
SAIBAM SOBRE QUAL SISTEMA ESTÃO FALANDO. DADO O CONTEXTO ACIMA,
QUAL PRÁTICA DO EXTREME PROGRAMMING ESTÁ SENDO UTILIZADA?
A) Jogo do planejamento
B) Pequenas entregas
C) Metáforas
D) Ritmo sustentável
GABARITO
1. Carlos é um desenvolvedor em um time que utiliza o método Extreme Programming. Ele
desenvolveu um código e está muito orgulhoso do que fez, a ponto de não querer mostrar para
ninguém seu código com receio que copiem suas ideias. Qual das práticas listadas abaixo foi
desrespeitada no cenário apresentado?
A alternativa "D " está correta.
O código em equipes Extreme Programming deve ser desenvolvido em par para que não haja
propriedade de código. Este deve ser compartilhado para que o time tenha conhecimento que o risco de
só uma pessoa conhecer o código seja minimizado.
2. Os times de desenvolvimento de empresa que utilizam o método ágil Extreme Programming
referem-se ao sistema que mais gera receita para a empresa como “mina de ouro” para que
todos saibam sobre qual sistema estão falando. Dado o contexto acima, qual prática do Extreme
Programming está sendo utilizada?
A alternativa "C " está correta.
As metáforas são utilizadas pelo time para relacionar algo no ambiente de desenvolvimento de sistemas
a uma coisa fora deste ambiente. Por exemplo, a lixeira na área de trabalho, a própria área de trabalho,
o carrinho de compras em um site de buscas, a lupa como símbolo de buscas. As metáforas auxiliam na
criação de uma linguagem comum entre o time para referenciar objetos no sistema.
MÓDULO 3
 Reconhecer as principais características do framework Scrum
Foto: Panchenko Vladimir/ Shutterstock.com
LIGANDO OS PONTOS
Você conhece as práticas do Scrum? Imagine você sendo o líder técnico de uma fábrica de softwares e
tomando a decisão de utilizar as práticas do Scrum em uma empresa que até então possui toda sua
metodologia de desenvolvimento de sistemas baseada em modelos tradicionais como o CMMi (Modelo
de Capacidade e Maturidade Integrado – Capability Maturity Model Integration). Para entendermos esse
conceito na prática, vamos analisar o caso da empresa FSW RS Ltda.
A empresa FSW RS Ltda. é uma filial gaúcha de uma fábrica de softwares brasileira com presença
global. Criada em 2009, a empresa surgiu como vencedora de um edital de licitação para atender a
diversos tipos de projetos de toda a rede pública do estado do Rio Grande do Sul.
Todos os processos e a principal metodologia de desenvolvimento de sistemas da FSW RS Ltda. eram
baseados nas práticas do modelo CMMi (Modelo de Capacidade e Maturidade Integrado – Capability
Maturity Model Integration), no qual era certificada como nível 5. O modelo CMMi é extremamente formal
e muito mais aderente ao modelo cascata, também conhecido como modelo Waterfall, em que
geralmente os projetos são organizados em grandes etapas e uma etapa só inicia após a aprovação
formal de toda documentação ou código da etapa anterior. O modelo CMMi envolve um processo
extremamente burocrático em que praticamente tudo que se produz necessita de aprovação e revisão
formal.
Processos formais são muito eficientes para grandes projetos, principalmente projetos para órgãos
públicos onde existe a necessidade da formalização dos requisitos por diversos níveis de
departamentos. As áreas da FSW RS Ltda. eram organizadas pelos seguintes processos: Gestão,
Análise, Desenvolvimento e Testes. Cada área possuía um líder técnico e deveria seguir a metodologia
de sua etapa, que era baseada no modelo CMMi. O líder técnico da área de desenvolvimento tinha
muita experiência com a utilização do Scrum e teve uma ideia muito interessante, que era utilizar as
práticas do Scrum na etapa de desenvolvimento de sistemas, ou seja, utilizar práticas, como a
organização das entregas por Sprints, criar a figura do Scrum Master, utilizar o Planning Poker para
estimar o tamanho dos requisitos (histórias de usuário) etc. Essa ideia foi muito bem recebida pela alta
gestão da FSW RS Ltda. e aplicada na prática, mas era um grande desafio conciliar as práticas do
Scrum com as práticas da atual metodologia baseada no CMMi.
APÓS A LEITURA DO CASE, É HORA DE APLICAR SEUS
CONHECIMENTOS! VAMOS LIGAR ESSES PONTOS?
1. O QUE VEM A SER O SCRUM?
A) O Scrum é uma metodologia de desenvolvimento de sistemas.
B) O Scrumé um guia que reúne todos os processos necessários para que se desenvolva sistemas.
C) O Scrum é um framework ágil de desenvolvimento de produtos e serviços.
D) O Scrum é uma metodologia de desenvolvimento de sistemas baseada no modelo tradicional de
desenvolvimento.
E) O Scrum é uma Metodologia Ágil de desenvolvimento de sistemas que foi baseada no Extreme
Programming.
2. QUAIS SÃO OS TRÊS PILARES DO SCRUM?
A) Transparência, inspeção e adaptação.
B) Transparência, controle e adaptação.
C) Planejamento, controle e direção.
D) Planejamento, inspeção e adaptação.
E) Transparência, respeito e colaboração.
GABARITO
1. O que vem a ser o Scrum?
A alternativa "C " está correta.
O framework Scrum define uma estratégia flexível do desenvolvimento de produtos e serviços. Dada a
sua natureza flexível e de fácil implementação, o Scrum acaba por ser o framework ágil mais utilizado no
mundo inteiro. Um dos princípios-chave do Scrum é o reconhecimento de que os clientes podem, e vão,
mudar de ideia. Ou seja, mudar de ideia sobre o que eles querem, como eles querem e quando eles
querem. Em consequência, é de se esperar que desse modo os requisitos não possam ser gerenciados
da forma tradicional como prevista no modelo CMMi, por exemplo, em que esse tipo de modelo gerencia
os requisitos da maneira inicialmente planejada e aprovada pelo cliente.
2. Quais são os três pilares do Scrum?
A alternativa "A " está correta.
A transparência é um dos pilares-chave do Scrum e deve ser perseguida constantemente por todo time
Scrum. A inspeção será realizada por meio de cerimônias presentes no Scrum com o objetivo de
inspecionar o incremento do produto e do atingimento da meta da Sprint, garantindo que a Sprint seja
entregue conforme o esperado pelas partes interessadas no projeto. Projetos ágeis são utilizados em
projetos em que existe um nível muito alto de incerteza. Dessa forma, o pilar de adaptação permite que
o produto seja adaptado de modo rápido e de acordo com a expectativa das partes interessadas.
3. VOCÊ, COMO O LÍDER TÉCNICO QUE PROPÔS A
UTILIZAÇÃO DAS PRÁTICAS DO FRAMEWORK SCRUM NA
ETAPA DE DESENVOLVIMENTO DA FÁBRICA DE
SOFTWARES, PODERÁ TER UM GRANDE DESAFIO AO
CONCILIAR AS PRÁTICAS ÁGEIS DO SCRUM COM AS
PRÁTICAS DA METODOLOGIA ATUAL, QUE É BASEADA NO
MODELO CMMI. NA SUA VISÃO, QUAIS SERIAM OS
MAIORES DESAFIOS DESSE “MODELO HÍBRIDO”?
RESPOSTA
A atual metodologia da fábrica de softwares é baseada no modelo CMMi, que é um dos modelos mais
maduros e respeitados em nível global. Um dos prováveis requisitos que levou a empresa a ser a ganhadora
do processo de licitação foi o fato de a empresa ser certificada como nível 5. Geralmente, essas certificações
possuem validade, então, de tempos em tempos, a empresa deverá ser avaliada novamente para que essa
certificação seja mantida. Sendo assim, é extremamente importante que todos da empresa sigam as práticas
previstas nesse modelo. O framework Scrum, por sua vez, é baseado nas práticas ágeis e muito mais focado
em gerar resultado do que seguir processos extremamente burocráticos. Com a implantação do Scrum na
etapa de desenvolvimento, a equipe se sentirá mais motivada a colaborar. A natureza do Scrum já prevê um
ambiente colaborativo onde todos se sentem responsáveis por aquilo que está sendo produzido. Como líder
técnico, é extremamente importante garantir que o Scrum “rode” normalmente gerando os resultados
esperados pelas partes interessadas, mas, ao mesmo tempo, as saídas geradas pela etapa devem estar
100% aderentes ao que o modelo CMMi exige. Com certeza, é um grande desafio conciliar esses dois
modelos e fazer com que esse “modelo híbrido” atenda às expectativas de todas as partes interessadas e
javascript:void(0)
que esteja totalmente alinhado aos processos do modelo CMMi. Nesse “modelo híbrido”, é inevitável que o
esforço seja maior.
SCRUM
Segundo Sutherland (2016), Ken Schwaber e Jeff Sutherland, dois dos signatários do Manifesto Ágil
criaram o Scrum sob influência do artigo de nome The New New Product Development Game, de
Nonaka e Takeuchi. Neste artigo, eles apresentaram um estudo de equipes de algumas das empresas
mais produtivas e inovadoras do mundo: Honda, Fuji-Xerox, 3M, Hewlett-Packard, entre outras. O
desenvolvimento de software precisava de uma nova abordagem, pois o ciclo de vida em cascata já não
era eficiente para um cenário de complexidade.
 VOCÊ SABIA
O nome Scrum vem de uma forma de reinício de jogada no rugby, na qual os jogadores dos dois times
se juntam e se empurram com o objetivo de ganhar a posse de bola. Esta jogada onde o time trabalha
unido com um objetivo comum influenciou a atribuição do nome da jogada para o método ágil.
A primeira apresentação pública formal do Scrum ocorreu quando Ken Schwaber e Jeff Sutherland
fizeram uma palestra do Scrum na Conferência OOPSLA de 1995.
De acordo com o Scrum Guide (2017), O Scrum pode ser considerado um framework usado para
gerenciar o trabalho em produtos complexos. O Scrum é leve, simples de entender, mas difícil de aplicar.
Foto: fizkes/ Shutterstock.com
TEORIA DO SCRUM
O Scrum é baseado no empirismo para controle de processo, isso quer dizer que o conhecimento vem
da experiência. Ao invés de fazermos previsões de entregas sem grande função em ambientes
complexos, cuja principal característica é a incerteza, com o empirismo, nós fazemos, aprendemos e aí
sim temos a condição de projetar uma entrega futura, mas como norte, como um objetivo a ser buscado,
pois não esqueçamos que ainda estamos em contexto complexo com muitas incertezas.
 EXEMPLO
Por exemplo: Para que um time de desenvolvimento forneça uma estimativa para término de um
produto, ele precisará conhecer a velocidade média do time nas últimas iterações para poder projetar a
previsão.
PILARES
A implementação do controle de processo empírico é apoiada em três pilares
Imagem: Creative Stall / Shutterstock.com
TRANSPARÊNCIA
A transparência deve ser perseguida constantemente por todo o time Scrum. Por exemplo, não deve
haver dúvida sobre a situação da entrega do incremento de produto ao final de uma iteração (sprint).
Todos devem saber o que é um incremento pronto, isso é fornecido pela transparência. Por exemplo, se
o Product Owner (PO) reclamar ao final de uma sprint que o produto não está com a qualidade
esperada, provavelmente temos um problema de transparência sobre o que é uma entrega pronta. Se
houvesse transparência nesse time Scrum, o PO saberia qual era o acordo para entrega pronta. A
transparência garante que todos ao final de uma sprint saibam o que é um incremento pronto.
INSPEÇÃO
O Scrum, como veremos mais adiante, possui cerimônias que possibilitam a inspeção do incremento do
produto e do atingimento da meta da sprint. Por exemplo, em uma reunião diária, o time possui a
oportunidade de inspecionar se o trabalho que está sendo realizado está evoluindo no sentido de atingir
a meta, e caso não esteja, o time deverá adaptar seu plano para maximizar as chances de atingimento
do objetivo. Na reunião de revisão, o time possui outra oportunidade de inspecionar a entrega.
ADAPTAÇÃO
Como vimos nos módulos anteriores, os métodos ágeis são utilizados em ambientes complexos, com
muita incerteza. Nesses contextos, é necessário validar rapidamente se estamos no caminho certo e
corrigir o rumo. O Scrum não é diferente, o pilar adaptação possibilita a rápida adequação do que não
está de acordo. O framework Scrum preconiza iterações de até 30 dias para que possamos ter ciclos de
desenvolvimento curtos e consequentemente feedbacks curtos. A resposta rápida sobre o produto
propicia a adaptação do mesmo no sentido de se adequar à expectativa do cliente.
VALORES
Como vimos, no Extreme Programming os valores denotam o grau de importância de um determinado
tema e representam as melhores ações a serem tomadas no contexto deste tema. No Scrum não é
diferente, os valores precisam ser vividos e praticados por todos para que possamos criar um ambientede confiança e, consequentemente, fortalecer os pilares transparência, inspeção e adaptação.
CORAGEM
FOCO
COMPROMETIMENTO
RESPEITO
ABERTURA
CORAGEM
Os membros de um time Scrum precisam ter coragem para fazer a coisa certa, fazer o que é preciso.
Por exemplo: Informar que não estão confiantes em entregar a meta e apresentar os motivos ou ouvir
opiniões mesmo que sejam contrárias às suas.
FOCO
O time Scrum durante um ciclo de desenvolvimento mantém o foco nas entregas prioritárias ao negócio.
O time procura entregar o que é esperado com simplicidade e objetividade.
COMPROMETIMENTO
Como o Scrum é um método ágil, e como já vimos que métodos ágeis geralmente são utilizados para
problemas complexos, cuja principal característica é o contexto com muitas incertezas, o
comprometimento refere-se ao empenho, atitude e engajamento do time com os resultados, mas não
necessariamente com o atingimento dos resultados.
RESPEITO
Este valor refere-se não somente ao evidente respeito que devemos ter com qualquer pessoa com a
qual nos relacionamos, mas também respeito para com o cliente ao desenvolver software de qualidade.
ABERTURA
O time Scrum deve estar aberto a ser transparente constantemente durante a construção do produto; a
colaborar sem problemas em ser assertivo para dizer o que precisa ser dito. Abertura para ouvir críticas
construtivas que podem melhorar o comportamento profissional, bem como melhorar o processo ou o
produto.
TIME SCRUM
O time Scrum compõe um modelo desenhado para otimizar a flexibilidade, criatividade e produtividade.
Este modelo composto de papéis muito bem equilibrados com responsabilidades inerentes às atividades
de construção de produto em ambientes complexos.
Os times Scrum são auto-organizáveis e multifuncionais.
AUTO-ORGANIZÁVEIS
Auto-organizáveis no sentido de se organizarem para desenvolver o produto necessário, sem
precisar de chefe ou gerente para dizer como desenvolver as atividades
MULTIFUNCIONAIS
javascript:void(0)
javascript:void(0)
Multifuncionais no sentido que o time deve possuir os perfis necessários para o desenvolvimento
do produto de modo iterativo e incremental, maximizando o valor de suas entregas.
Imagem: NicoElNino/ Shutterstock.com
Muito embora o time Scrum não possua outros papéis além dos citados acima, o Scrum pode ser
utilizado em projetos com um gerente de projetos, por exemplo. O gerente de projetos pode trabalhar
com o Product Owner ou Scrum Master para apoiar no relacionamento com o restante da organização;
pode criar relatórios de evolução de projetos e pode trabalhar com o time Scrum para criar previsões
para entregas de projetos.
Os papéis de um time Scrum são: Product Owner, Scrum Master e Time de Desenvolvimento.
PRODUCT OWNER (DONO DO PRODUTO)
O Product Owner ou PO é o dono do produto. Ele define, transmite a visão do produto ao time de
desenvolvimento e é responsável por representar a visão do produto em um product backlog.
O PO é responsável por gerenciar o product backlog. Ele deve garantir que a necessidade mais
premente do negócio esteja refletida no topo da pilha de forma a garantir o retorno sobre o investimento
feito no produto. Imaginem que o patrocinador está financiando o produto e espera receber em entregas
parciais e frequentes o que mais representa valor naquele momento, por exemplo, uma entrega para
atender a uma promoção.
Imagem:Sakaidasan/ Shutterstock.com
 ATENÇÃO
O PO deve interagir sempre com stakeholders, como clientes ou departamento de marketing para
identificar novas features ou tendências que poderão influenciar o produto. Ele deve também identificar,
por exemplo, com o help desk as reclamações dos usuários para retroalimentar o backlog com essas
necessidades. Com essa dinâmica, o PO gerencia a entrada e saída dos itens no backlog.
O PO é responsável por definir os PBI (product backlog items) e esclarecer as dúvidas do time de
desenvolvimento durante a sprint planning meeting (reunião de planejamento) sobre os itens que
entrarão na próxima sprint (ciclo de desenvolvimento).
 RECOMENDAÇÃO
Ainda nesta reunião, o PO entra em acordo com o time de desenvolvimento sobre o objetivo da sprint.
Muito embora a sprint possa conter vários PBI, ela deve possuir um objetivo de entregar um incremento
de produto.
O PO é o único papel com autoridade para cancelar uma sprint. Ao detectar que o objetivo, meta da
sprint não faz mais sentido para o negócio, o PO pode cancelar a sprint.
SCRUM MASTER (LÍDER SCRUM)
O Scrum Master, SM, é quem mais conhece o Scrum dentre todos os papéis do Scrum.
Imagem: Sakaidasan/ Shutterstock.com
Ele é um líder servidor e deve apoiar todos no entendimento do Scrum, tanto o time Scrum quanto a
organização.
Assim como o PO está focado em criar um product backlog alinhado com as necessidades do cliente
para o time de desenvolvimento criar o produto certo, o SM é focado em apoiar o time Scrum a abraçar
os valores, princípios e práticas do Scrum, além de remover impedimentos e interagir com stakeholders
no sentido de apoiar o uso do Scrum dentro da organização. Isso tudo como líder servidor, sem fazer
uso de autoridade.
 ATENÇÃO
O SM atua para o PO e time de desenvolvimento líder servidor, coach, facilitador dos eventos Scrum,
removedor de impedimentos e agente de mudança. Para o PO, por exemplo, o SM pode apoiar nas
atividades de criação e refinamento e ordenação do product backlog, que proporcione o
desenvolvimento do produto certo; para o time de desenvolvimento, pode atuar fazendo que ele
descubra as melhores formas para resolver os problemas encontrados na utilização do Scrum.
DEV TEAM (TIME DE DESENVOLVIMENTO)
Um time de desenvolvimento Scrum deve ter entre 3 e 9 componentes.
Imagem: Sakaidasan/ Shutterstock.com
Os times precisam ser pequenos para não perderem a capacidade de comunicação e também a auto-
organização.
Fórmula de canais de comunicação:
N * ( N - 1 ) / 2
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Logo:
Para um time com 5 pessoas, temos: 5 * ( 5 - 1 ) / 2 canais de comunicação, mas se colocarmos uma
pessoa a mais no time, temos 6 * (6 - 1) / 2 = 15 canais de comunicação. Percebam neste exemplo
que, ao aumentarmos uma pessoa no time, aumentamos em 50% a quantidade de canais de
comunicação.
O time de desenvolvimento auto-organizado não precisa de um gerente para fazer microgestão de
atividades. Após a criação do forecast (previsão) da meta da sprint durante a sprint planning o time se
auto-organiza para a criação de um plano para desenvolvimento das entregas que compõem a meta da
sprint, sem precisar que um gerente diga como fazer.
O time de desenvolvimento pode incrementar o framework Scrum utilizando técnicas de
desenvolvimento de software como algumas abordadas no Módulo 2.
Imagem: Quick Creative / Shutetrstock.com
 Figura 3 - Framework scrum.
A figura 3 apresenta o ciclo do Scrum com os artefatos: Product Backlog, sprint backlog e incremento,
bem como os eventos sprint planning, daily, sprint review e sprint retrospective.
Foto: Pra Chid/ Shutterstock.com
EVENTOS
O Scrum preconiza eventos que possibilitam oportunidades de transparência e inspeção. Cada evento
possui seu propósito claro dentro do Scrum e também um tempo limite (time-boxed), para que não se
perca o foco em cada evento.
SPRINT PLANNING (REUNIÃO DE PLANEJAMENTO)
A reunião de planejamento da sprint é o primeiro evento dentro da sprint. Nele o time e o PO debatem
sobre a meta da sprint e os PBI, ou seja, os itens que farão parte do backlog da sprint. Esta reunião de
time-box dura no máximo oito horas para uma sprint de um mês de duração.
Imagem: MicroOne / Shutterstock.com
META OU OBJETIVO DA SPRINT
O conceito de meta ou objetivo da sprint é bastante relevante para entendermos o que deve ser entrega
na sprint. Quando o time Scrum não trabalha com esse conceito, ele atua como um time “tarefeiro” ou
seja, preocupa-se com entrega de histórias do sprint backlog (históriasque compõem o escopo da
sprint). Desta forma, o PO chega a um acordo com o time sobre quantas histórias eles puxam para a
sprint e, ao final, na reunião de revisão, é verificado quantas histórias foram entregues. Já um time
orientado à meta define com o PO a meta, o objetivo, ou seja, qual a entrega relevante para o negócio
será realizada ao término da sprint. Essa entrega obviamente é composta por histórias de usuário, mas
podemos ter dentro da sprint histórias que não fazem parte da meta. Assim, o time deve priorizar a
entrega da meta, o compromisso é com a meta. Esta é a diferença de um time orientado a meta e um
time orientado a tarefas.
É importante entender que o time possui uma capacidade de trabalho durante a sprint. O trabalho
puxado pelo time de desenvolvimento deverá ser factível de ser executado dentro do período da sprint.
Percebam que usei o verbo “puxar”. Em agilidade não se empurra trabalho. Isso significa que o time de
desenvolvimento avalia os itens com o PO, estima um a um e só puxa do backlog do produto para o
backlog da sprint a quantidade de itens que a capacidade de trabalho da equipe comporta realizar com a
qualidade acordada (definição de pronto) dentro da duração da sprint.
ESTIMATIVA
Não existe um padrão para estimativa, mas uma forma muito usada são os pontos por história. Os
pontos por história são uma forma de estimativa relativa na qual o time de desenvolvimento atribui
tamanho de cada história de usuário. Exemplo: Para um item simples o time pode atribuir tamanho 1,
para um maior pode atribuir tamanho 3. Uma técnica muito utilizada para isso é o planning poker, na
qual o time utiliza um baralho com uma numeração, geralmente com a série de Fibonacci e cada
membro, após entender o que é para ser feito na história, joga uma carta com uma numeração, sem que
os outros vejam para não influenciá-los. Caso haja discrepância na numeração jogada, os membros
argumentam sobre os motivos da estimativa de cada e jogam novamente até chegaram ao consenso,
com isso o tamanho da história de usuário é atribuído.
Como a duração da sprint é fixa e o time só puxa para o sprint backlog a quantidade de itens que
consegue entregar, o time de desenvolvimento começa a conhecer sua velocidade (velocity). A
velocidade é uma métrica que serve para estimativas de demandas futuras.
Uma vez que conhecemos a capacidade de trabalho do time de desenvolvimento em uma sprint,
podemos fazer previsões.
Segundo Kenneth (2017), é importante determinar a capacidade do time porque só conhecendo a
capacidade poderemos saber o que o time pode entregar.
Após definir os itens que entrarão no backlog da sprint, o time se auto-organiza para definir um plano
para atingimento da meta ao final da sprint.
SPRINT
A sprint é o evento que contém outros eventos, ou seja, os outros eventos ocorrem dentro de uma sprint.
A sprint deve ter no máximo um mês de duração e, ao definir esta duração, o ideal é que não seja
alterada durante a evolução do produto ou projeto. Este tempo máximo de um mês é para permitir ciclos
de feedbacks curtos, para validação da entrega, que possibilitem inspeção e adaptação.
 VOCÊ SABIA
Assim como não se deve alterar a duração sprint, da mesma forma, não se altera escopo que possa
comprometer a meta da sprint, também não se altera o padrão de qualidade acordado para as entregas.
A sprint só pode ser cancelada pelo PO se a meta (objetivo) da sprint se tornar obsoleta.
Durante a sprint, geralmente o time utiliza um quadro físico ou virtual para acompanhamento da
evolução do trabalho. Não existe regra para a confecção desses quadros, mas normalmente são criadas
as colunas: sprint backlog para colocar os post-its com as histórias de usuário contidas na sprint
backlog; Fazendo, para as histórias de usuários que estão sendo feitos e Feitas para as histórias de
usuário prontas. À medida que as histórias vão sendo desenvolvidas, os post-its são movidos nas
colunas, até todas migrarem para a coluna Feitas.
Imagem: Iconic Bestiary / Shutterstock.com
DAILY MEETING (REUNIÃO DIÁRIA)
É um evento de time-box de no máximo 15 minutos no qual o time de desenvolvimento aproveita a
oportunidade para inspecionar a evolução do trabalho em direção ao atingimento da meta da sprint.
Neste evento, cada membro do time de desenvolvimento responde:
O que eu fiz ontem que ajudou a atingir a meta da sprint?
O que eu farei hoje para ajudar a atingir a meta da sprint?
Existe impedimento que atrapalhe a mim ou o time de desenvolvimento para atingir a meta da sprint?
A reunião diária é um evento do time de desenvolvimento, logo não há necessidade de mais ninguém
participar além do time, à exceção se for convidado pelo time ou o Scrum Master perceber que o time
precisa para seguir os valores e pilares do Scrum. O time também pode pedir apoio ao PO para
participar e esclarecer algo da sprint backlog que, por ventura, não tenha ficado claro.
 ATENÇÃO
Obviamente, a meta da sprint é obtida por meio da conclusão das histórias de usuário contidas na sprint,
mas o time deve sempre se focar no atingimento da meta. Este é um ponto de atenção, pois pode
acontecer de o time se focar em atividades e descolar da meta. A priorização da execução das
atividades dentro da sprint deve ser orientada à meta.
SPRINT REVIEW (REVISÃO DA SPRINT)
É um evento de time-box de no máximo 4 horas para uma sprint de um mês.
Neste evento, o time de desenvolvimento apresenta para o PO e stakeholders o que foi feito durante a
sprint e o PO aprova ou não o incremento do produto que visa a atender a meta da sprint.
Este evento visa a inspecionar o produto e os participantes colaborarem sobre o que deverá ser
considerado para a próxima sprint.
 ATENÇÃO
O Scrum quando é implementado por um responsável sem experiência pode gerar várias disfunções
capazes de prejudicar muito o entendimento do framework. Não é difícil encontrarmos no mercado
sprints de testes, ou após a Reunião de Revisão da Sprint fazerem a “homologação”. Como disse, são
disfunções, porque ao final de uma sprint, deve ser entregue um incremento de produto potencialmente
utilizável, ou seja, os itens contidos da Definição de Pronto (ver definição de pronto) devem ser
executados. O padrão de qualidade definido deve ter sido atingido para o item ser aceito na reunião de
revisão.
SPRINT RETROSPECTIVE (RETROSPECTIVA DA
SPRINT)
É o último evento de uma sprint e possui um time-box de no máximo 3 horas para uma sprint de um
mês. Seu propósito é inspeção do próprio time. É comum nesse evento o time colaborar para identificar
coisas que deram certo, que deram errado e criar um plano de melhoria para as próximas sprints.
A retrospectiva da sprint é uma oportunidade para o time refletir sobre o processo, sobre o como foi a
sprint que se encerra com o evento desta reunião. O Scrum Master deve facilitar esta reunião de modo
que o time encontre um ambiente favorável para falar. Muitas vezes, os membros não falam dos
problemas para evitarem o conflito, mas o conflito respeitoso é saudável, ele traz foco ao problema e
fornece transparência (vejam o pilar transparência novamente) aos pontos de atenção. Detectada a
causa raiz, é possível traçar plano de ação para o time corrigir o problema e melhorar continuamente.
Imagem: Shutterstock.com
ARTEFATOS
Segundo o Scrum Guide (2017), os artefatos representam o trabalho ou o valor para o fornecimento de
transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são
especificamente projetados para maximizar a transparência das informações-chave de modo que todos
tenham o mesmo entendimento dos artefatos.
BACKLOG DO PRODUTO
Consiste em uma pilha de PBI (product backlog items) que pode conter histórias de usuários, itens
técnicos e correções, ordenados por valor, onde o que está no topo da pilha corresponde aos itens com
mais valor para o negócio.
O backlog do produto é um artefato em constante mudança. O cliente está cada vez mais exigentetanto
em qualidade quanto em redução de tempo para receber seus produtos. Por isso, o Product Owner (PO)
deve ficar atento às constantes mudanças de prioridades de negócio exigidas pelo mercado ou clientes
e fazer com que essas mudanças sejam refletidas no Product Backlog. Por isso, constantemente o PO
deve refinar o product backlog.
REFINAMENTO DO BACKLOG DO PRODUTO
O refinamento é um processo para deixar o backlog sempre com PBI preparados para serem
apresentados para a reunião de planejamento da sprint. Enquanto o time de desenvolvimento trabalha
na Sprint atual para desenvolver as entregas, o PO deve preparar os PBI candidatos para as próximas
sprints. Os PBI candidatos são os prioritários que representam mais valor para o negócio naquele
momento.
BACKLOG DA SPRINT
Consiste nos PBI que foram selecionados do product backlog na reunião de planejamento para compor
o trabalho a ser realizado na sprint.
INCREMENTO (INCREMENT)
É o produto do trabalho realizado na sprint. Este incremento deve estar pronto segundo o padrão de
qualidade estipulado na definição de pronto (DoD). O incremento é um produto potencialmente utilizável
após sua aceitação na reunião de revisão da sprint.
DEFINIÇÃO DE “PRONTO”
A definição de pronto (definition of done) fornece transparência para o time Scrum e partes interessadas
sobre o trabalho da sprint. É uma definição sobre o padrão de qualidade que a entrega possuirá. Na
estimativa das histórias, o time de desenvolvimento deve ter em mente o esforço que precisará
dispender para aplicar em cada entrega os critérios de qualidade definidos na definição de pronto. Na
review, todos sabem que os itens entregues devem atender à definição de pronto.
COMO RODAR O SCRUM
Pessoas com perfil de SM e PO, devem ser identificadas e, se necessário, capacitadas para
exercerem as responsabilidades de cada papel.
Os especialistas devem decidir os melhores componentes para a composição do time de
desenvolvimento.
O SM deve apoiar o PO na criação do product backlog que represente valor para o negócio.
O PO deve apresentar as histórias de usuário candidatas a entrarem na sprint, e na reunião de
planejamento do time, puxa as histórias de usuário para comporem a sprint backlog.
O PO e o time devem definir a meta da sprint.
O time desenvolve o incremento do produto durante a sprint e realiza as reuniões diárias para
inspecionar o andamento do desenvolvimento do incremento.
Ao final da sprint, na reunião de revisão, o time apresenta a entrega para o PO, que pode aceitar
ou rejeitar os itens.
O time Scrum realiza uma reunião de retrospectiva para identificar oportunidade de melhoria no
processo.
O ciclo se repete até a entrega de todo o backlog e, consequentemente, o produto.
Agora, aprenda um pouco mais sobre o Scrum assistindo ao vídeo abaixo:
TEXTO
VERIFICANDO O APRENDIZADO
1. EM UMA REUNIÃO DE REVISÃO DO PRODUTO, O DONO DO PRODUTO
INFORMA QUE A ENTREGA NÃO ESTÁ TOTALMENTE DIFERENTE DO QUE FOI
PEDIDO E AINDA DIZ QUE NÃO SABE DO QUE SE TRATA A ENTREGA.
DADO O CONTEXTO ACIMA, QUAL PILAR DO SCRUM FOI DESCONSIDERADO?
A) Transparência
B) Respeito
C) Inspeção
D) Adaptação
2. QUAL ITEM ABAIXO NÃO É UM PAPEL DO SCRUM?
A) Scrum Master
B) Product Owner
C) Gerente de projeto
D) Time de desenvolvimento
GABARITO
1. Em uma reunião de revisão do produto, o dono do produto informa que a entrega não está
totalmente diferente do que foi pedido e ainda diz que não sabe do que se trata a entrega.
Dado o contexto acima, qual pilar do Scrum foi desconsiderado?
A alternativa "A " está correta.
A transparência é um pilar que deve ser perseguido constantemente por todo o time Scrum. A
transparência faz com que não existam surpresas na revisão do produto. No cenário acima, se o dono
do produto tivesse participado da reunião de planejamento, respondido às perguntas do time, ajudado a
elucidar as dúvidas e ainda ficado disponível para o time durante a sprint, provavelmente não ocorreria
problema de falta de transparência sobre o que foi entregue.
2. Qual item abaixo não é um papel do Scrum?
A alternativa "C " está correta.
O time Scrum é composto dos seguintes papéis: Scrum Master, Product Owner e Time de
Desenvolvimento. Isso não quer dizer que em um projeto não possamos ter um gerente de projeto, mas
ele não é um papel preconizado no Scrum.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Durante nossa jornada, vimos um marco importante da criação do conceito da Agilidade, o Manifesto
Ágil. Assinado por 17 expoentes do ramo de desenvolvimento de software, os valores e princípios do
Manifesto apontam a necessidade de pensarmos primeiramente nas pessoas, tanto as que
desenvolvem produtos, quanto as que usam os produtos; a necessidade de colaborarmos com o cliente;
a necessidade de frequentemente validarmos se o que está sendo entregue está alinhado com as
expectativas do cliente, entre outras.
Na sequência, vimos o método ágil de desenvolvimento Extreme Programming (XP), que também possui
seus valores, mas inteiramente aderentes aos valores do Manifesto. Estudamos as práticas
preconizadas pelo XP que apoiam o desenvolvimento de software com qualidade. Por fim, vimos o
método ágil Scrum, seus valores, pilares, papéis, responsabilidades, eventos e artefatos.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
AGILE MANIFESTO. Agile Manifesto. Consultado em meio eletrônico em: 29 set. 2020.
JEFFRIES, R. What is extreme programming? In: Ronjeffries. Publicado em: 16 mar. 2011.
KENNETH, S. R. Scrum essencial: Um guia prático para o mais popular processo ágil. Traduzido por
Roberto Rezende. Rio de Janeiro: Alta Books, 2017.
MASSARI, V. Gerenciamento Ágil de Projetos. Rio de Janeiro: Brasport, 2014.
SCRUM GUIDES. Guia do Scrum. Publicado em: out. 2017.
SUTHERLAND, J. Scrum: A arte de fazer o dobro do trabalho na metade do tempo. São Paulo: LeYa,
2016.
TELES, V. M. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software
com agilidade e alta qualidade. Rio de Janeiro: Novatec, 2004.
WILDT, D. eXtreme Programming: Práticas para o dia a dia no desenvolvimento ágil de software. São
Paulo: Casa do Código, 2015.
EXPLORE+
Para saber mais sobre os assuntos tratados neste tema, pesquise na internet:
Scrum e XP direto das Trincheiras, Infoq.
Leia:
Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena
empresa de base tecnológica, Scielo.
Uma estratégia baseada em aquisição de conhecimento para o gerenciamento de riscos nos
requisitos em um desenvolvimento XP distribuído, Scielo.
Orientações para o processo de certificação SCM (Scrum Master Certified) da Scrum Alliance.
Orientações para o processo de certificação PSM (Professional Scrum Master) da Scrum.org.
Orientações para o processo de certificação EXIN Agile Scrum Foundation.
CONTEUDISTA
Wagner Rodrigues Ribeiro
 CURRÍCULO LATTES
javascript:void(0);