Gestão Agil

Prévia do material em texto

Gestão de Times - 
Métodos Ageis 
Luiz Gustavo Rezende Motta
Gestão de Times 
Créditos Institucionais 
Presidente do Conselho de Administração: 
Janguiê Diniz 
Diretor-presidente: 
Jânio Diniz 
Diretoria Executiva de Ensino: 
Adriano Azevedo 
Diretoria Executiva de Serviços Corporativos: 
Joaldo Diniz 
Diretoria de Ensino a Distância: 
Enzo Moreira 
(C) 2018 by Telesapiens 
Todos os direitos reservados
O AUTOR 
Luiz Gustavo Rezende Motta 
Ola! Meu nome é Luiz Gustavo Rezende Motta. Sou 
formado em Ciência da Computação, com experiência técnico- 
profissional na área de Gestão de Projetos de mais de 10 anos. 
Passei por empresas com a Unimed, Benner e Postal Saúde. Sou 
apaixonado pelo que faço, e adoro transmitir minha experiência 
de vida aqueles que estão iniciando em suas profissões. Por isso 
fui convidada pela Editora Telesapiens a integrar seu elenco de 
autores independentes. Estou muito feliz em poder ajudar você 
nesta fase de muito estudo e trabalho. Conte comigo!
APRESENTAÇÃO 
Olá. Meu nome é Manuela César. Sou a responsável pelo 
projeto gráfico de seu material. Esses ícones irão aparecer em 
sua trilha de aprendizagem significam: 
OBJETIVO 
Breve descrição do 
objetivo: o 
Q 
Là 
CITAÇÃO 
Parte retirada de um 
texto; 
TESTANDO 
Foco em um objeto 
de estudo: 
IMPORTANTE 
As observações escritas 
têm que ser priorizadas; 
so DICA 
0: Destaque para 
estões e novas 
ormações; 
Ho 
+
 
4º
 U
0 
R 
(O) 2018 by Telesapiens 
Todos os direitos reservados 
OBSERVAÇÃO 
Breve descrição do 
objetivo: 
RESUMINDO 
Resumo | 
acumulativo das 
últimas abordagens; 
DEFINIÇÃO 
Apresentação de 
um novo conceito; 
ACESSE 
Links úteis 
para fixação da 
informação: 
SAIBA MAIS 
Informações 
adicionais sobre 
o conteúdo;
SUMÁRIO 
Conhecendo o universo dos métodos ágeis... 9 
O Manifesto Ágil possui a seguinte base... 9 
O desenvolvimento ágil é incremental... 1 
Desenvolvimento ágil necessita de práticas ágeis............... 12 
Equipes... eee er nas ereto nen r arena eanenreneno 13 
Entendendo a definição e o uso do Framework Scrum...... 15 
Defiiição dá SEU acesas eras scenes ncasaeussecaaracarcasam I5 
O Time Scrum...... eee 17 
O Product Owner ...... eee eieeeenereees 17 
O Time de Desenvolvimento . suas sas usra pes 18 
Tamanho do Time de Desenvolvimento............. 20 
O Serum Master ..... essi 20 
Backlog do Produto.........eseceressssenerorenecrcacerenscasisserecsseonaõoo 21 
EVENTOS SOU sussa SS a 23 
SOC assacasranass eee seen acena oca 24 
Revisão da Sprint... eee DD 
Retrospectiva da Sprint... renata 26 
Reinão DITA a DS sra a 27 
Compreendendo a teoria por trás do Framework Scrum..29 
Areas de conhecimento do gerenciamento de projetos aplicáve 
IS... iii ereneeeesaa neon ao anta aaa aea nasce na caneca near annn ce nanerannoo 29 
A dmalnea do SON SD Ea Ga 30 
O gerente de projcio DO APOIO asas cesasencaenosscacansascsaanadd 
Adaptabilidade............ errar 31 
Transparência... rare DD 
Fécdback CONTO. anus seas a 32 
Melhora Contas easasasans cream osasco massas nandd 
Entrega Continua de Valor.......... ie IA 
Eficiência... esteira D 
MENVAÇÃO: ES Ds co DO 
Ata VELADO essas asas canen susana nara
Atento IRD sue rancor eceaç 
Entender os valores do método Scrum...............cccceseeeese 39 
Papel e os princípios do Serum... 40 
PSDC os TE Ss cpm 40 
EASPEÇÃO .susssassassascsssaaesasm ne cusnsasar amensecaasaRa aan pnacaau asas 41 
Adaptação... resetar erereneeneeo 42 
Pontos para inspeção e adaptação em Scrum..................... 42 
Valores que sustentam os pilares do Serum..................... 43
 
8 ] ( Gestão de Times 
 
UNIDADE 
 
INTRODUÇÃO AOS MÉTODOS ÁGEIS E O 
SCRUM
 
Gestão de Times J (o 
 
INTRODUÇÃO 
Projetos ágeis fazem parte da cadeia de processos de uma 
empresa. Os Métodos Ágeis surgiram como alternativa para os 
problemas pontuais que apresentam durante a elaboração de um 
software usando os métodos de desenvolvimento orientado a 
planos. 
O Scrum é um framework para gerenciamento de 
projetos ágeis, e que apesar de muito utilizado na área de 
desenvolvimento de software, pode ser utilizado para o 
planejamento, gerenciamento e desenvolvimento de qualquer 
produto, principalmente por ser um framework iterativo 
(repetitivos) e incremental. 
A ideia principal aqui é controlar processos empíricos, 
mantendo o foco na entrega de valor, de um negócio, no menor 
tempo possível. Os projetos são divididos em ciclos repetitivos 
(iterativos) e curtos para que possam ser modificados e adaptados 
para corrigir os desvios (incrementais). Estes ciclos podem durar 
de duas a quatro semanas, e são chamados de Sprints. 
O framework Scrum é simples de entender. Para ajudar 
eu separei abaixo alguns tópicos que resumem o Scrum, sua 
teoria, sua história e seus componentes. Ao longo desta unidade 
letiva você vai mergulhar neste universo!
 
10 ] ( Gestão de Times 
 
OBJETIVOS 
Olá! Se bem-vindo a nossa Unidade 1, e o nosso objetivo 
é auxiliar você no desenvolvimento das seguintes competências 
profissionais até o término desta etapa de estudos: 
Conhecer o universo dos métodos ágeis. 
 
Entender a definição e os usos do Framework Scrum. N9
 
 
Compreender a teoria por trás do Framework Scrum. La
d 
 
Entender os valores do método Scrum. Pa
 
 
 
Gestão de Times ) E 
 
Conhecendo o universo dos métodos 
ágeis 
Metodologias ágeis existem há anos, desde a década 
de 80, mas algumas informações passaram por distorções, 
fato que dificultou, no início, a utilização das metodologias. 
Por conseguinte, desenvolvedores passaram a entender a 
metodologia ágil como algo que tudo pode, ou seja, podemos 
desenvolver sem documentação, sem padrão e sem cuidado. 
Isto não é verdade, as metodologias ágeis podem trazer sucesso 
ao projeto, e são utilizadas inclusive na indústria. Apesar 
das metodologias existirem, foi em 2001 que um grupo de 
renomados desenvolvedores assinaram o MANIFESTO PARA 
O DESENVOLVIMENTO ÁGIL DE SOFTWARE e o grupo foi 
batizado de aliança dos ágeis. 
O Manifesto Ágil possui a seguinte base: 
Figura 1 - imagem que faz alusão ao manifesto deil. 
 
 
 
 
 
 
INDIVÍDUOS E | DE PROCEDIMENTOS 
SUAS INTERAÇÕES E FERRAMENTAS 
FUNCIONAMENTO DE DOCUMENTAÇÃO 
DO SOFTWARE ABRANGENTE 
COLABORAÇÃO DE NEGOCIAÇÃO 
DOS CLIENTES DE CONTRATOS 
 
 
CAPACIDADE DE 
RESPOSTA AS 
MUDANÇAS 
DE UM PLANO PRÉ- 
ESTABELECIDO 
 
12 ] ( Gestão de Times 
 
= Os indivíduos e as interações são mais importantes do 
que os processos e as ferramentas; 
= O software funcionando é mais importante do que uma 
documentação completa; 
= A colaboração dos clientes acima de apenas negociações 
de contratos e; 
= Respostas à mudanças acima de seguir um plano. 
IMPORTANTE 
 
Isso não quer dizer que documentação não seja importante e que 
os processos € as ferramentas sejam inúteis significa que os itens à 
esquerda são mais valorizados, apenas isso. 
 
A engenharia de software ágil combina filosofia com um 
conjunto de princípios de desenvolvimento. A filosofia defende 
a satisfação do cliente e a entrega de incremental prévio; equipes 
de projetos pequenas e altamente motivadas; métodos informais: 
artefatos de engenharia de software minimos e, acima de tudo, 
simplicidade no desenvolvimento geral. 
Os princípios de desenvolvimento priorizam a entrega 
mais que a análise e projeto (embora essas atividades não sejam 
desencorajadas): também priorizam a comunicação ativa e 
contínua entre desenvolvedores e clientes. (Pressman, 2011) 
 
http://agilemanifesto.org (Acesso em 21/08/2018) 
 
 
Gestão de Times ) (13 
 
Um projeto envolve pessoas e mudanças, principalmente 
quando falamos de entregas constantes. Desta forma, as 
metodologias ágeis trabalham com equipes altamente motivadas 
e suporte à mudanças durante o processo de desenvolvimento. 
O desenvolvimento ágil é incremental 
Um plano completo com tudo que devemosfazer para 
depois iniciar o desenvolvimento. Você não deve desenvolver 
o produto sem antes fazer contato com o cliente, ao invés disso, 
desenvolver incrementalmente, ou seja, o produto é feito aos 
poucos e entregue constantemente, desta forma, toda mudança 
é bem-vinda, pois o projeto está em desenvolvimento e não foi 
concluído por completo. 
Os incrementos iniciais do sistema podem fornecer uma 
funcionalidade de alta prioridade, de forma que os clientes logo 
poderão obter valor do sistema durante seu desenvolvimento. Os 
clientes podem assim ver os requisitos na prática e especificar 
mudanças para serem incorporadas nos releases (liberações ou 
lançamentos) posteriores do sistema. 
O contato constante com o cliente também gera 
conhecimento, pois a equipe vai entendendo o negócio, para, ao 
desenvolver, fazê-lo com maior velocidade e precisão, e, em caso 
de erros, a equipe não terá perdido um ano de desenvolvimento, 
e sim terá perdido apenas o tempo de desenvolvimento do 
incremento, podendo corrigir rapidamente. 
 
“Incremental” relativo a incremento, ato ou efeito de desenvolver 
ou aumentar alguma coisa. Que visa aprimorar gradualmente, em 
etapas: mudança incremental, atualização incremental. 
 
 
14 ] ( Gestão de Times 
 
 
Falamos da importância de saber escolher o que será feito, ou seja, 
funcionalidades que tenham alta prioridade, desta forma o cliente já 
pode usufruir de recursos do sistema. O que antes demoraria meses, 
agora, em semanas, ele poderá ter acesso para verificar erros e 
especificar novas mudanças ou melhorias, não necessitando chegar 
ao final do desenvolvimento para ver os problemas. 
 
Desenvolvimento ágil necessita de práticas 
ágeis 
Podemos citar: 
= Utilização de TDD : é a técnica que permite fazer testes 
continuos, e não apenas na conclusão do sistema, melhorando 
assim a qualidade técnica do produto; 
Planejamento incremental: ao invés de planejar o 
software como um topo, podemos planejar de forma sistêmica, 
ou seja, definir o todo, mas planejar em etapas, realizando um 
planejamento por incremento. Os requisitos do incremento 
podem ser registrados em cartões que algumas metodologias 
denominam de “histórias do usuário”, aqui determinamos 
a prioridade que o cliente define e também o tempo que os 
desenvolvedores precisam para o desenvolvimento 
m Incrementos desenvolvidos em tempo reduzido: 
releases (liberações ou lançamentos) pequenos, entregando 
funcionalidades em meses ou semanas, ao invés de anos; 
= Utilização de refatoração: melhorando o código e 
tornando-o mais fácil de manter constantemente; 
= Integração continua: quando o incremento está pronto, 
ele é integrado ao sistema como um todo, ou seja, isto é feito 
diariamente.
 
Gestão de Times ) (15 
 
Figura 2 - imagem alusiva a desenvolvimento agil. 
 DESENVOLVIMENTO 
AGIL 
 
 
Os métodos ágeis são eficientes para alguns tipos de sistemas, 
como em desenvolvimento de produtos para venda em pequeno e 
médio porte, ou também, em desenvolvimento de sistemas que o 
cliente estará envolvido no processo de desenvolvimento, em que 
não haverá muitas regras que afetam o software. 
 
Equipes 
Os pontos acima são base para quase todas as 
metodologias ágeis, mas o principal ponto nestas metodologias, 
além dos citados acima, é a possibilidade de a equipe ser auto 
gerenciável, ou seja, não há necessidade de um gerente e sim um 
líder, que tem o papel de facilitador. A equipe e a comunicação 
entre os membros da equipe e o cliente é crucial para o sucesso 
das metodologias ágeis, e para isso, as equipes pequenas tornam- 
se fatores de sucesso.
 
16 ] ( Gestão de Times 
 
Figura 3 - imagem alusiva a equipe. Fonte: https:Mpixabay.com/ptr 
a%CI%ATWCI%oA30-colaborar-ra%6C3I%A7%C3%430-colegas-2277292/ 
 
 
 
 
As equipes pequenas reduzem problemas de conflitos, 
comunicação entre outros. Mike Cohn, um dos colaboradores 
da invenção da metodologia de desenvolvimento de software 
Scrum, afirma que equipes pequenas possuem menos ociosidade 
social, melhoram a interação construtiva, menor tempo na 
coordenação, ninguém fica para trás, pois todos apreendem 
em conjunto, há maior satisfação entre os membros do grupo 
e é menos provável que ocorra excesso de especialização, pois 
todos devem conhecer o projeto. 
Outro ponto que foi notado por 
Cohn é que o tamanho não indica 
realmente maior produtividade, 
pois equipes grandes não 
são necessariamente mais 
produtivas, pois há menos 
comunicação e maior número 
de conflitos. Ainda segundo 
Cohn, não é de se surpreender 
que equipes menores concluem 
os projetos com um esforço total 
menor, equipes maiores demandam 
Figura 4 - imagem alusiva
 
Gestão de Times ) (17 
 
mais esforços e custos. Equipes entre 5 a 8 integrantes têm maior 
chance de sucesso, pois é mais fácil a comunicação, mais fácil 
criar uma integração do que equipes com 20 a 30 integrantes. 
Equipes muito pequenas podem sofrer problemas de falta de 
pessoal. O Scrum e outras metodologias ágeis, indicam que 
equipes pequenas tem maior chance de concluir o projeto do 
que equipes grandes. Caso isso ocorra, nas equipes pequenas, o 
líder nota as deficiências, e pode atacá-las com maior facilidade 
utilizando capacitação, integração etc. 
PIN IMPORTANTE 
Como a equipe é pequena, a perda de um integrante pode prejudicar 
o grupo como um todo, para isso, não há grande especialização na 
equipe, ou seja, todos devem ser responsáveis pelo projeto e não 
por apenas uma tarefa, o que torna a equipe elástica, caso algum 
integrante saia do projeto. 
 
 
Entendendo a definição e o uso do Frame- 
work Scrum 
Definição do Scrum 
 
Figura 5 - imagem alusiva a equipe realizando SCRUM. Fonte: htips:/f 
pixabay. conv/pylocal-de-trabalho-equipe-1245776/
 
18 ] ( Gestão de Times 
 
Um framework dentro do qual pessoas podem tratar 
e resolver problemas complexos e adaptativos, enquanto 
produtiva e criativamente entregam produtos com o mais alto 
valor possível. Scrum é: 
= Leve; 
= Simples de entender; 
= Extremamente difícil de dominar; 
= Scrum é um framework estrutural que está sendo usado 
para gerenciar o desenvolvimento de produtos complexos desde 
o início de 1990. Ele não é um processo ou uma técnica para 
construir produtos; em vez disso, é um framework dentro do 
qual você pode empregar vários processos ou técnicas. O Scrum 
deixa claro a eficácia relativa à práticas de gerenciamento e 
desenvolvimento de produtos, de modo que você possa melhorá- 
las. 
O framework Scrum consiste nos times do Scrum 
associadas 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 seus sucesso. 
As regras do Scrum integram os eventos, papéis e 
artefatos, administrando as relações e interações entre eles. As 
suas regras serão descritas ao longo deste documento. 
IMPORTANTE 
 
Scrumnão émetodologia. 
 
 
Gestão de Times ) (19 
 
O Time Scrum 
O Time Scrum é 
composto pelo Product Owner, 
o Time de Desenvolvimento 
e o Serum Master. Times 
Scrum são auto-organizáveis e 
multifuncionais eles escolhem 
qual a melhor forma para 
completarem seu trabalho, 
em vez de serem dirigidos por 
outros de fora do Time. Times 
multifuncionais possuem todas 
as competências necessárias 
para completar o trabalho sem depender de outros que não fazem 
parte da equipe. O modelo de time no Scrum é projetado para 
aperfeiçoar a flexibilidade, criatividade e produtividade. 
Times Scrum entregam produtos de forma iterativa e 
incremental, maximizando as oportunidades de realimentação. 
Entregas incrementais, do produto “Pronto”, garantem que uma 
versão potencialmente funcional do produto do trabalho esteja 
sempre disponível. 
O Product Owner 
O Product Owner, ou dono do produto, é o responsável 
por maximizar o valor do produto e do trabalho do Time de 
Desenvolvimento. Como isso é feito pode variar amplamenteatravés das organizações, times Serum e indivíduos. 
O Product Owner é a única pessoa responsável por 
gerenciar o Backlog do Produto. O gerenciamento do Backlog 
do Produto inclui: 
Figura 6 - imagem alusiva 
= FExpressar claramente os itens do Backlog do Produto: 
= Ordenar os itens do Backlog do Produto para alcançar 
melhor as metas e missões; 
= Garantir o valor do trabalho realizado pelo Time de 
Desenvolvimento:
 
20 ] ( Gestão de Times 
 
m Garantir que o Backlog do Produto seja visível, 
transparente, claro para todos, e mostrar o que o time Scrum vai 
trabalhar a seguir; e, 
m Garantir que o Time de Desenvolvimento entenda os 
itens do Backlog do Produto no nível necessário. 
PIN ON RO 
O Product Owner pode fazer o trabalho acima, ou delegar para o 
Time de Desenvolvimento fazê-lo. No entanto, ele continua sendo 
o responsável pelos trabalhos. 
O Product Owner é uma pessoa e não um comité pode representar 
o desejo de um comitê no Backlog do Produto, mas aqueles que 
quiserem uma alteração nas prioridades dos itens de Backlog devem 
convencer o Product Owner. 
 
 
 
ACESSE 
 
http://www.scrum.org/ (Acesso em 22/08/2018) 
 
 
O Time de Desenvolvimento 
O Time de Desenvolvimento consiste de profissionais 
que realizam o trabalho de entregar uma versão usável que 
potencialmente incrementa o produto “Pronto” ao final de cada 
Sprint. Somente integrantes do Time de Desenvolvimento criam 
incrementos.
 
Gestão de Times ) (21 
 
Os Times de Desenvolvimento são estruturados e 
autorizados pela organização para organizar e gerenciar seu 
próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a 
eficácia do Time de Desenvolvimento como um todo. Os Times 
de Desenvolvimento têm as seguintes características: 
= Elessão auto-organizados. Ninguém (nem mesmo o Scrum 
Master) diz ao Time de Desenvolvimento como transformar 
o Backlog do Produto em incrementos de funcionalidades 
potencialmente utilizáveis; 
= Times de Desenvolvimento são multifuncionais, 
possuindo todas as habilidades necessárias, enquanto equipe, 
para criar o incremento do Produto. 
= O Scrum não reconhece títulos para os integrantes 
do Time de Desenvolvimento que não seja o desenvolvedor, 
independentemente do trabalho que está sendo realizado pela 
pessoa, não há exceções para esta regra. 
= Individualmente os imtegrantes do Time de 
Desenvolvimento podem ter habilidades especializadas e área 
de especialização, mas a responsabilidade pertence ao Time de 
Desenvolvimento como um todo; e. 
= Times de Desenvolvimento não contém sub-times 
dedicados a domínios específicos de conhecimento, tais como 
teste ou análise de negócios. 
 
http://www.scrum.org/ (Acesso em 22/08/2018) 
 
 
22 ] ( Gestão de Times 
 
Tamanho do Time de Desenvolvimento 
O tamanho 
ideal do time de 
desenvolvimento é 
pequeno o suficiente 
para se manter ágil e 
grande o suficiente para 
completar uma parcela 
significativa do trabalho 
dentro dos limites da 
Sprint. Figura 7 - Exemplo de equipe. Fonte: 
 
Menos de 
três integrantes no Time de Desenvolvimento diminuem a 
interação e resultam em um menor ganho de produtividade. 
Times de Desenvolvimento menores podem encontrar 
restrições de habilidades durante a Sprint, gerando um Time 
de Desenvolvimento incapaz de entregar um incremento 
potencialmente utilizável. Havendo mais de nove integrantes 
é exigida muita coordenação. Times de Desenvolvimento 
grandes geram muita complexidade para um processo empírico 
gerenciar. Os papéis de Product Owner e de Scrum Master 
não são incluídos nesta contagem, a menos que eles também 
executem o trabalho do Backlog da Sprint. 
O Scrum Master 
O Scrum Master é responsável por garantir que o Scrum 
seja entendido e aplicado. O Scrum Master faz isso para garantir 
que o Time Scrum adere à teoria, práticas e regras do Serum. O 
Scrum Master é um servo-lider para o Time Scrum. 
O Scrum Master ajuda aqueles que estão fora do Time 
Scrum a entender quais as suas interações com eles e, quais são 
úteis e quais não são. O Serum Master ajuda todos a mudarem 
estas interações para maximizar o valor criado pelo Time Scrum.
 
 
Gestão de Times ) (23 
 
ic SAIBA MAIS 
a 
 
O Serum Master serve o Product Owner de várias maneiras, 
incluindo: 
Encontrando técnicas para o gerenciamento efetivo do Backlog do 
Produto; 
Claramente comunicar a visão, objetivo e itens do Backlog do 
Produto para o Time de Desenvolvimento; 
Ensinar a Time Serum a criar itens de Backlog do Produto de forma 
clara e concisa: 
Compreender a longo prazo o planejamento do Produto no ambiente 
empírico; 
Compreender e praticar a agilidade; e, 
Facilitar os eventos Scrum conforme exigidos ou necessários. 
 
Backlog do Produto 
O Backlog do Produto é uma lista ordenada de tudo que 
deve ser necessário no produto, e é uma origem única dos requisitos 
para qualquer mudança a ser feita no produto. O Product Owner 
é responsável pelo Backlog do Produto, incluindo seu conteúdo, 
disponibilidade e ordenação. 
Um Backlog do Produto nunca está completo. Os 
primeiros desenvolvimentos apenas estabelecem os requisitos 
inicialmente conhecidos e melhor entendidos. Fle evolui tanto 
quanto o produto e o ambiente no qual ele será utilizado, evoluem 
é dinâmico; mudando constantemente para identificar o que o 
produto necessita para ser mais apropriado, competitivo e útil que 
existirá enquanto o produto também existir. 
O Backlog do Produto lista todas as características, funções, 
requisitos, melhorias e correções que formam as mudanças 
que devem ser feitas no produto nas futuras versões, seus itens 
possuem os atributos de descrição, ordem, estimativa e valor.
 
24 ] ( Gestão de Times 
 
Enquanto um produto é usado, ganha valor, e o mercado 
oferece retorno, o Backlog do Produto torna-se uma lista maior 
e mais completa. Requisitos nunca param de mudar, então ele é 
um artefato vivo, por isso mudanças nos requisitos de negócio, 
condições de mercado ou tecnologia podem causar mudanças 
nele. 
Múltiplos Times Scrum frequentemente trabalham 
juntos no mesmo produto. Um Backlog do Produto é usado para 
descrever o trabalho previsto para o produto, assim um atributo 
seu, que agrupe itens, pode ser então aplicado. 
O refinamento é a ação de adicionar detalhes, estimativas 
e ordem aos itens no Backlog do Produto. Este é um processo 
contínuo em que o Product Owner e o Time de Desenvolvimento 
colaboram nos detalhes dos itens do Backlog do Produto. Durante 
o seu refinamento os itens são analisados e revisados. O Time 
de Desenvolvimento decide como e quando o refinamento está 
“Pronto”. Este refinamento usualmente não consome mais de 10% 
da capacidade do Time de Desenvolvimento. Contudo, os itens do 
Backlog do Produto podem ser atualizados a qualquer momento 
pelo Product Owner ou a critério do dele. 
Os itens do Backlog do Produto de ordem mais alta (topo 
da lista) devem ser mais claros e mais detalhados que os itens de 
ordem mais baixa. Estimativas mais precisas são feitas baseadas 
em maior clareza e maior detalhamento; quanto menor a ordem 
na lista, menos detalhes. Os itens irão ocupar o desenvolvimento 
na próxima Sprint são mais refinados, de modo que todos os itens 
possam ser “Prontos” dentro do time-box da Sprint esses itens são 
considerados como “Preparados” para seleção no Planejamento da 
Sprint e geralmente adquirem este grau de transparência através 
das atividades de refinamento descritas acima. 
O Time de Desenvolvimento é responsável por todas as 
estimativas. O Product Owner deve influenciar o Time, ajudando 
no entendimento e nas decisões conflituosas de troca, mas as 
pessoas que irão realizar o trabalham fazem a estimativa final.
 
Gestão de Times ) (25 
 
 
Time-box na tradução literal significa "caixa de tempo". Ou seja, o 
tempo para fazer um trabalho é limitado, executando-o da melhor 
forma que puder, nessa janela de tempo. E uma técnicasimples, 
usada no desenvolvimento de software para rastrear o progresso e 
para ter o trabalho feito. 
 
são usados no Serum 
para criar uma rotina e 
minimizar a necessidade o 
de reuniões não definidas ' Ea 
anteriormente. Todos 
os eventos são eventos 
time-box, de tal modo, 
que todo evento tem uma 
duração máxima. Uma 
vez que a Sprint começa, qe Scrum 
Eventos Scrum a 
Eventos prescritos 
 
Figura 8 - Exemplo de planejamento 
sua duração é fixada e não pode ser reduzida ou aumentada. Os 
eventos restantes podem terminar sempre que o propósito do 
evento é alcançado, garantindo que uma quantidade adequada 
de tempo seja gasta sem permitir perdas no processo. 
Além da Sprint, que é um container para outros eventos, 
cada evento no Scrum é uma oportunidade de inspecionar 
e adaptar alguma coisa. Estes eventos são especificamente 
projetados para permitir uma transparência e inspeção criteriosa. 
A não inclusão de qualquer um dos eventos resultará na redução 
da transparência e da perda de oportunidade para inspecionar e 
adaptar.
 
26 ] ( Gestão de Times 
 
Sprint 
O coração do Scrum é a Sprint, um time-box de um mês 
ou menos, durante o qual um “Pronto”, versão incremental 
potencialmente utilizável do produto, é criado. Sprints tem durações 
coerentes em todo o esforço de desenvolvimento. Uma nova Sprint 
inicia imediatamente após a conclusão da Sprint antenor. 
 
As Sprints são compostas por uma reunião de planejamento da 
Sprint, reuniões diárias, o trabalho de desenvolvimento, uma 
revisão da Sprint e a retrospectiva da Sprint. 
 
Durante a Sprint: 
m Não são feitas mudanças que possam colocar em perigo 
o objetivo da Sprint; 
m As metas de qualidade não diminuem; e, 
E O escopo pode ser clarificado e renegociado entre o 
Product Owner e o Time de Desenvolvimento quanto mais for 
aprendido. 
Cada Sprint pode ser considerada um projeto com 
horizonte não maior que um mês. Como os projetos, as Sprints 
são utilizadas para realizar algo. Cada Sprint tem a definição do 
que é para ser construído, um plano projetado e flexível que irá 
guiar a construção, o trabalho e o resultado do produto. 
 
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar. 
Somente o Product Owner tem a autoridade para cancelar a Sprint, 
embora ele (ou ela) possa fazer isso sob influência das partes 
interessadas, do Time de Desenvolvimento ou do Scrum Master. 
 
 
Gestão de Times ) [27 
 
 
http://www.scrum.org/ (Acesso em 22/08/2018) 
 
Revisão da Sprint 
A Revisão da Sprint é executada no final para inspecionar 
o incremento e adaptar o Backlog do Produto, se necessário. 
Durante a reunião Time Scrum e as partes interessadas 
colaboram sobre o que foi feito na Sprint e as sobre próximas 
coisas que podem ser feitas para otimizar valor. Esta é uma 
reunião informal, não uma reunião de status, e a apresentação do 
incremento destina-se a motivar e obter comentários e promover 
a colaboração. 
Esta é uma reunião time-box de 4 horas de duração para 
uma Sprint de um mês. Para Sprints menores, este evento é 
usualmente menor. O Scrum Master garante que o evento ocorra 
e que os participantes entendam o seu objetivo. O Scrum Master 
ensina a todos a manter a reunião dentro dos limites do time-box. 
A Reunião de Revisão inclui os seguintes elementos: 
m Os participantes incluem o Time Scrum e os Stakeholders 
chaves convidados pelo Product Owner; 
 
Stakeholders: Em inglês stake significa interesse, participação, 
risco. Holder significa aquele que possui. De modo geral, descreve 
uma pessoa ou grupo que tem interesse em uma empresa, negócio 
ou indústria, podendo ou não ter feito um investimento neles. 
 
 
28 ] ( Gestão de Times 
 
O Product Owner esclarece quais itens do Backlog do 
Produto foram “Prontos”, e quais ainda não foram. 
E O Time de Desenvolvimento discute o que foi bem 
durante a Sprint, quais problemas ocorreram dentro da Sprint, e 
como estes problemas foram resolvidos; 
E O Time de Desenvolvimento demonstra o trabalho que 
está “Pronto” e responde as questões sobre o incremento; 
E O Product Owner discute o Backlog do Produto tal como 
está. Ele (ou ela) projeta as prováveis datas de conclusão baseado 
no progresso até a data (se necessário); 
= O gmupo todo colabora sobre o que fazer a seguir, e é assim 
que a Reunião de Revisão da Sprint fornece valiosas entradas para 
a Reunião de Planejamento da próxima Sprint; 
= Análise de como o mercado ou o uso potencial do produto 
pode ter mudado e o que é a coisa mais importante a se fazer a 
seguir; e, 
m Análise da linha do tempo, orçamento, potenciais 
capacidades, e mercado para a próxima versão esperada do produto. 
O, OBSERVAÇÃO 
 
O resultado da Reunião de Revisão da Sprint é um Backlog do 
Produto revisado que define o provável Backlog do Produto para a 
próxima Sprint. O Backlog do Produto pode também ser ajustado 
completamente para atender novas oportunidades. 
 
Retrospectiva da Sprint 
A Retrospectiva da Sprint é uma oportunidade para o Time 
Scrum inspecionar a si próprio e criar um plano para melhorias a 
serem aplicadas na próxima Sprint. 
A Retrospectiva da Sprint ocorre depois da Revisão da 
Sprint e antes da reunião de planejamento da próxima Sprint. Esta 
 
 
Gestão de Times ) (29 
 
é uma reunião time-box de três horas para uma Sprint de um mês. 
Para Sprint menores, este evento é usualmente menor. O Scrum 
Master garante que o evento ocorra e que os participantes entendam 
seu propósito. O Scrum Master ensina todos a mantê-lo dentro do 
time-box. O Scrum Master participa da reunião como um membro 
auxiliar do time devido a sua responsabilidade pelo processo Scrum. 
O propósito da Retrospectiva da Sprint é: 
E Inspecionar como a última Sprint foi em relação às pessoas, 
aos relacionamentos, aos processos e às ferramentas; 
E Identificar e ordenar os principais itens que foram bem e as 
potenciais melhorias; e, 
E Criar um plano para implementar melhorias no modo que o 
Time Scrum faz seu trabalho; 
AIN DEN 
 
Em qualquer ponto do tempo na Sprint, o total do trabalho 
remanescente dos itens do Backlog da Sprint pode ser somado. O Time 
de Desenvolvimento monitora o total do trabalho restante pelo menos 
a cada Reunião Diária. O Time de Desenvolvimento acompanha 
estes resumos diários e projeta a probabilidade de alcançar o objetivo 
da Sprint. Com o rastreamento do trabalho restante em toda a Sprint, 
o Time de Desenvolvimento pode gerenciar o seu progresso. 
 
Reunião Diária 
A Reunião Diária do Scrum é um evento time-boxed 
de 15 minutos, para que o Time de Desenvolvimento possa 
sincronizar as atividades e criar um plano para as próximas 24 
horas. Esta reunião é feita para inspecionar o trabalho desde a 
última Reunião Diária, e prever o trabalho que deverá ser feito 
antes da próxima Reunião Diária. 
A Reunião Diária é mantida no mesmo horário e local 
todo dia para reduzir a complexidade. Durante a reunião os 
membros do Time de Desenvolvimento esclarecem:
 
30 ] ( Gestão de Times 
 
O que eu fiz ontem que ajudou o Time de Desenvolvimento 
a atender a meta da Sprint? 
O que eu farei hoje para ajudar o Time de Desenvolvimento 
atender a meta da Sprint? 
Eu vejo algum obstáculo que impeça a mim ou o Time de 
Desenvolvimento no atendimento da meta da Sprint? 
O Time de Desenvolvimento usa a Reunião Diária para 
inspecionar o progresso em direção ao objetivo da Sprint e para 
inspecionar se o progresso tende para completar o trabalho do 
Backlog da Sprint. A Reunião Diária aumenta a probabilidade do 
Time de Desenvolvimento atingir o objetivo da Sprint. Todos os 
dias, o Time de Desenvolvimento deve entender como o mesmo 
pretende trabalhar em conjunto, como um time auto-organizado, 
para completar o objetivo da Sprint e criar um incremento 
esperado até o final da Sprint. O Time de Desenvolvimento ou 
membros da equipe frequentemente se encontram imediatamente 
após a Reunião Diária paradiscussões detalhadas, ou para 
adaptar, ou replanejar, o restante do trabalho da Sprint. 
O Scrum Master assegura que o Time de Desenvolvimento 
tenha areunião, mas o Time de Desenvolvimento é responsável por 
conduzir a Reunião Diária e ensina o Time de Desenvolvimento 
a manter a Reunião Diária dentro do time-box de 15 minutos. 
Ele reforça a regra de que somente os integrantes do Time de 
Desenvolvimento participem da Reunião Diária. 
 
Reuniões Diárias melhoram as comunicações, eliminam 
outras reuniões, identificam e removem impedimentos para o 
desenvolvimento, destacame promovemrápidas tomadas de decisão, 
e melhoram o nível de conhecimento do Time de Desenvolvimento. 
Esta é uma reunião chave para inspeção e adaptação. 
 
 
Gestão de Times J E 
 
Compreendendo a teoria por trás do 
Framework Scrum 
Areas de conhecimento do gerenciamento 
de projetos aplicáveis 
A possibilidade de mudança do gerenciamento de 
projetos tradicional para o gerenciamento de projetos ágil requer 
uma atenção especial em cinco áreas de conhecimento definidas: 
m Gerenciamento de Recursos Humanos; 
m Gerenciamento da Qualidade; 
E Gerenciamento da Integração; 
E Gerenciamento do Escopo; 
E Gerenciamento do Tempo. 
Tanto a abordagem ágil quanto a abordagem tradicional 
identificam as três restrições de um projeto como sendo: custo, 
tempo (agenda) e escopo. Para a abordagem tradicional, no 
entanto, o escopo do projeto deve ser fixado para que tempo 
e custo possam ser estimados. Já as abordagens ágeis se 
manifestam acreditando que o escopo estará em constante 
mudança, então tempo e custo devem ser fixados. Em abordagens 
ágeis a estratégia de comando-controle deve ser substituída por 
facilitação, colaboração e suporte. 
Uma abordagem segundo o PMBOK - Project 
Management Body of Knowledge e do PMI 2004 - Project 
Management Institute, nos leva a perceber que: a preocupação 
está na definição do escopo em um alto nível que permita o 
entendimento do trabalho, inclusive com a participação do 
cliente para a priorização das funcionalidades; o cronograma é 
orientado ao produto que será produzido em iterações (repetições) 
curtas que contribuem para uma redução dos conflitos pela 
cumplicidade no processo; as alterações são incorporadas dentro 
da iteração mais apropriada e de comum acordo com o cliente, 
podendo elevar o custo final; os padrões
 
32 ] ( Gestão de Times 
 
a serem seguidos devem ser estabelecidos no início 
do projeto e estarem concentrados na programação em pares; 
a monitoração e o controle dos riscos ocorrem durante todo o 
processo de desenvolvimento; a comunicação é colaborativa 
e direta entre todos os membros da equipe, o que exige certo 
grau de maturidade por parte da organização, do cliente e da 
equipe; todos os participantes do projeto executam suas tarefas, 
planejam e tomam decisões em conjunto, compartilhando suas 
experiências; o processo de aquisição deve ser evitado em 
função da volatilidade dos requisitos; a atuação colaborativa da 
equipe com o cliente favorece um major grau de informalidade 
e o conhecimento implícito é privilegiado; o papel do gerente de 
projetos é voltado para o papel de facilitador ou coordenador das 
atividades. 
Figura 9 - Exemplo de gerenciamento de tempo e 
 
integração. Fonte: htips:hpixaba comptireloC3%6B3gio-inteligente-apple-iecnologia-82 1559 
A dinâmica do Scrum 
Existem papéis e responsabilidades bem definidos, assim 
como diversas etapas que devem ser cumpridas que visam 
produzir de forma rápida ao mesmo tempo em que atende às 
necessidades do cliente. 
O dono do produto — ou Product Owner — representa
 
Gestão de Times ) (33 
 
os stakeholders e o negócio, os membros da equipe ou Team é 
formada por cerca de 7 pessoas. Equipes com poucos envolvidos 
e multidisciplinares são uma das características marcantes da 
metodologia. Para gerenciar o projeto surge a figura do Scrum 
Master que funciona como o gerente de projeto, dirigindo a 
equipe para que os objetivos e metas sejam atingidos. Ele garante 
que o processo está sendo seguido. Participando das reuniões 
diárias, revisão da Sprint, e planejamento. 
O gerente de projeto no apoio 
Um dos papéis mais polemizados quando o assunto é 
Scrum, é o tradicional gerente de projetos. Primeiro, porque este 
papel específico não aparece nas suas definições de papéis, e 
segundo, porque ele defende que o time deve ser autogerencial, 
o que resumidamente é interpretado como não havendo a 
necessidade de ter um gerente de projetos na equipe. 
Adaptabilidade 
O controle de processos empíricos e a entrega iterativa 
fazem com que os projetos sejam adaptáveis e abertos à 
incorporação de mudanças. 
Enquanto os métodos tradicionais de desenvolvimento, 
em especial o cascata, valorizam análise extensa e definições 
rígidas de requisitos, visando “segurança” (ou a falsa sensação 
dela), o Scrum abraça a imprevisibilidade que um projeto longo 
possui ao inserir mais resiliência neles. 
Transparência 
Na administração tradicional a Gestão à Vista não é 
algo novo e comprovadamente vantajoso para as organizações. 
Isso porque permite que todos vejam o que está acontecendo e 
consigam tomar atitudes em relação a isso. 
Scrum fala de adaptação, mas não há como se adaptar ao
 
34 ] ( Gestão de Times 
 
que não se consegue ver, e, por isso, que o primeiro pilar 
da metodologia é a transparência. 
Sem transparência não há: 
E Inspeção adequada 
m Adaptação 
E Engajamento 
m Confiança 
= Evolução do time 
m Sucesso no projeto 
Figura 12 - Exemplo 
de gráfico que denota 
transparência. 
E= Fonte: https:// 
-— pixabay.com/pt/computador- 
 
Feedback Contínuo 
O feedback continuo é fornecido através de processos 
denominados como a Reunião Diária e a Sprint Review. 
O Seum fornece 
diversos mecanismos de 
feedback, o que garante 
o segundo pilar do 
framework: inspeção, que 
leva à adaptação, em um 
ciclo virtuoso, que gera a 
melhoria contínua. 
Fonte: higps:/pixabayrcompilocal-de-trabalho- 
 
 
 
Gestão de Times J (35 
 
 
Feedback contínuo não é dar tapinhas nas costas na reunião de final 
de ano da empresa. Feedback contínuo tem a ver com transparência, 
pois o time precisa saber se suas ações estão gerando resultado. 
Você precisa saber se está no caminho certo. O seu colega precisa 
saber como pode lhe ajudar e você precisa saber se ele precisa de 
ajuda também. 
Melhoria Continua 
As entregas melhoram progressivamente, Sprint por 
Sprint, através do processo de refinamento do Backlog do 
Produto e do processo em si. 
Na metodologia de inovação em startups denominada 
Lean Startup, existe um ciclo chamado construir-medir-aprender 
(build-measure-learn no original) que trabalha da seguinte 
maneira: 
!. Você constrói um incremento de produto; 
2. Você mede o desempenho dele; 
>. Você aprende com os erros e refina-o; 
+. Volte ao passo 1. 
E assim o é também no Scrum. 
O framework é enxuto, apenas 19 páginas. Talvez não 
cubra nem sequer 10% da “ciência” da gestão de projetos. Mas os 
seus princípios fundamentais te ajudam a pensar de uma maneira 
diferente, com o mindset correto. Ele próprio te ensina que a 
inspeção vai te levar inerentemente ao aprendizado (adaptação) 
e com isso à melhoria contínua dos processos e produtos. 
Esqueça aquela ideia que alguns métodos pregam 
que você deve apenas confiar cegamente em um livro e seus 
problemas estarão resolvidos!
 
36 ] ( Gestão de Times 
 
 
Lean startup: Esse conceito, no universo da administração, envolve 
um trabalho de enxugar, identificação, eliminar desperdícios nos 
processos e está muito ligado ao ambiente de startups de tecnologia. 
Mindset: traduzindo ao pé da letra seria mente configurada, ou 
configuração da mente. O conceito significa o conjunto de atitudes 
mentais que influencia diretamente nos nossos comportamentos e 
pensamentos. 
 
Entrega Contínua de Valor 
Os processos iterativos permitem a entrega continuade 
valor tão frequente quanto o exigido pelo cliente. 
Tenha em mente que ninguém compra software. Ninguém. 
Só quem gosta de software é programador. Chente gosta 
de solução que entrega valor. Se o seu time demora demais e/ou 
não entrega valor, ele não vai ir muito longe. 
Achave aqui é entregar valor continuamente, em pequenas 
porções mas frequentes, deixando sempre o cliente satisfeito e 
com um “gostinho de quero mais”. A cada iteração do Scrum 
(sprint), um incremento de produto é entregue ao cliente, um 
que gera valor ao mesmo. É assim que tem que ser em todos os 
projetos. 
Você nunca terá como entregar tudo o que o cliente quer, 
no prazo que ele quer e dentro do orçamento dele. Isso não 
existe! 
Mas o processo de criar e priorizar um Backlog de 
Produto garante que as exigências de maior valor ao cliente 
sejam atendidas primeiramente e que o valor que ele tanto busca 
(não confunda valor com custo) seja entregue em partes, à cada 
iteração. 
Uma abordagem colaborativa com stakeholders (como 
a do Scrum) e a ênfase no valor de negócio, garantem uma
 
Gestão de Times ) (37 
 
estrutura orientada para o cliente. E não orientada ao software. 
OBSERVAÇÃO 
 
Seus clientes não querem seus softwares. Eles querem o valor 
gerado pelos mesmos. Eles querem ser “melhores” do que eram 
antes de comprar seu software. 
 
Eficiência 
O Time-boxing e a minimização de trabalho não-essencial 
conduzem a níveis mais altos de eficiência. 
As coisas mais excêntricas existentes no Scrum são em 
prol da eficiência e, por isso, que seguir o Scrum à risca é tão 
importante, principalmente em equipes imaturas do ponto de 
vista de agilidade. 
Pense nas time-boxes: restrições pétreas quanto à duração 
de eventos no ciclo de desenvolvimento. Sprints de x semanas. 
Reuniões de x horas. E por aí vai. Isso não é algo negociável. 
Esse tipo de restrição estimula os desenvolvedores do time a 
pensar no que é mais importante ser desenvolvido hoje rumo 
ao objetivo de amanhã. Não há tempo a perder com coisas que 
não gerem valor à meta da sprint. Estimula o Product Owner a 
manter o backlog priorizado com o que realmente deve entrar 
no produto na próxima sprint, deixando para um futuro incerto o 
que não é essencial à aplicação. 
Todos sabemos (ou deveríamos saber) que a falácia da 
próxima feature e a over-engineering são alguns dos piores 
maus que podem arruinar um projeto de software e até mesmo 
uma empresa. As restrições de tempo do Scrum (e as demais 
também) te ajudam a não cair nessas tentações, como essa outra, 
de reescrever todo o código da sua aplicação para que fique 
“melhor”, por exemplo.
 
38 ] ( Gestão de Times 
 
ia ; ço 
Di ai ; Ro E dai e E mg 
 
Figura 14 - Exemplo de eficiência. Fonte: htfps:/pixabay:- com ptimindmap- 
brainstorm-idaC3 A Sia-inovaaC3 ad 720C3%aA30-2123973/ 
 
Feature: é uma funcionalidade ou uma característica. E algo que 
tem uma função. 
Over-engineering: quando se constrói um código mais sofisticado 
do que ele precisa ser. 
 
Motivação 
Os processos de conduzir N | / 
8 
a reunião diária e de retrospectiva 
da Sprint conduzem a níveis 
mais altos de motivação entre os; À 
colaboradores. 
E necessário um ambiente 
de alta confiança para que o time se / N 
sinta motivado a seguir em frente 
apê a Figura 15 - Exemplo de 
em prol dos objetivos gerais da moiivação. Fonte: Flaticon. 
Sprint. 
Processos do Scrum como a Reunião Diária e a 
Retrospectiva da Sprint promovem a transparência (pilar 1, 
lembra?) e a colaboração, resultando em um ambiente de 
trabalho de alta confiança, e garantindo baixo atrito entre os
 
Gestão de Times ) (39 
 
colaboradores, além de uma alta motivação, uma vez que o time 
tem o suporte e aval necessários para que consiga avançar sem 
impedimentos. 
Quando os Times confiam sem si mesmos e seus líderes 
confiam no time, a motivação se torna algo inabalável, gerando 
a responsabilidade coletiva e o comprometimento, que é o que 
todo gerente quer da sua equipe e toda empresa quer ver nos seus 
funcionários. 
O processo de aprovar, estimar e comprometer-se às 
tarefas (ou histórias de usuário, casos de uso, etc.) permite que 
os membros do time se sintam responsáveis pelo projeto e por 
seu trabalho, resultando em uma qualidade muito maior. Não 
importa se você vai usar planning poker ou não, mas se não 
houver confiança no time para tomar essas decisões, não haverá 
motivação para executar as tarefas. Tudo começa na confiança! 
 
Planning poker: é uma técnica do Serum que permite ao time do 
projeto gerar estimativas rapidamente. 
 
Alta Velocidade 
Uma estrutura de colaboração permite que os times 
multifuncionais atinjam o seu pleno potencial e alta velocidade. 
Se o seu time vem vencendo nos demais quesitos como 
motivação, entrega continua de valor, transparência, adaptação, 
entre outros, você terá o que todo gerente de software almeja: 
alta velocidade! 
Não, agilidade não é entregar software, pura e 
simplesmente, mais rápido. É sobre entregar valor mais cedo. 
Mas quando você entrega valor mais cedo, a percepção que 
todos têm (interna e externamente) é que o time está avançando 
mais rápido.
 
40 ] ( Gestão de Times 
 
OBSERVACÃO 
 
O que vale mais, um professor sedentário correndo em linha reta 
por 100m ou o Usain Bolt correndo em zigue-zague para chegar no 
mesmo destino que está 100m à frente? É o mesmo para software! 
Se você não está trabalhando com um backlog priorizado, não 
esta entregando software com foco no cliente (ou seja, entregando 
valor pra ele), você está “andando em zigue-zague” rumo ao 
mesmo objetivo que poderia estar perseguindo em linha reta! 
A alta velocidade obtida com o Scrum não está na quantidade de 
linhas de código que seu time vai escrever por Sprint, mas, sim 
nas linhas certas que serão escolhidas para serem escritas. Aquelas 
que trarão os maiores resultados para o cliente em menos tempo. 
Isso é velocidade, de maneira inteligente! 
 
Ambiente Inovador 
Os processos de Retrospectiva da Sprint e de Review 
da Sprint criam um ambiente de introspecção, aprendizagem e 
adaptabilidade, que levam a um ambiente de trabalho inovador e 
criativo. 
Não custa repetir: transparência, inspeção e adaptação. Os 
três pilares do Scrum. 
Esse ciclo virtuoso é a chave para a inovação. A inspeção 
e adaptação frequentes do Scrum levam o seu produto sempre 
aonde ele deve estar, agora, neste momento. E não conforme foi 
planejado um ano atrás com a diretoria. 
Embora seja extremamente válido (e aconselhável) definir 
as estratégias a médio e longo prazo, é a execução em curto prazo 
(aliado aos pilares do Scrum) que vão garantir a existência do 
projeto para talvez chegar no destino desejado. Se ele ainda fizer 
sentido um ano depois de traçado. 
A chance de revisitar o processo e ajustá-lo a cada Sprint 
 
 
Gestão de Times ) (41 
 
é única e dá uma vantagem muito grande ao time frente às 
metodologias tradicionais: a vantagem de poder errar. Mas errar 
rápido e aprendendo com esse erro para acertar. 
Ninguém tem as respostas sobre como os softwares 
precisam ser desenvolvidos em todos os casos, nem o Scrum, 
mas a inspeção e adaptação às mudanças devem ser o ceme dos 
projetos. 
Entender os valores do método Scrum 
Como sabemos o Scrum é uma metodologia ágil para 
gestão e planejamento de projetos. Nele, os projetos são divididos 
em ciclos com atividades que devem ser executadas dentro de 
um cronograma. As metodologias ágeis de desenvolvimento 
de software são iterativas, ou seja, o trabalho é dividido em 
Iterações. As funcionalidades a serem implementadas no projeto 
são mantidas em uma lista, para criá-la ou definir as atividades 
prioritárias são feitas pequenas reuniões 
de planejamento. As reuniões também 
servem para disseminar conhecimento 
sobre o que foi feito no dia anterior, 
identificar impedimentos e priorizar o 
trabalho do dia que se inicia. 
Figura J6 - Exemplo de valoresdo método. Fonte: hitps:/pixabay.compt' 
186C3%A?mpada-idoC3%ASia-pera-vista- 
pensava-432246/ 
 
42 ] ( Gestão de Times 
 
Papel e os princípios do Scrum 
Mostrar a eficácia das suas práticas de desenvolvimento 
para que você possa melhorá-las, enquanto provê um framework 
dentro dos quais produtos complexos podem ser desenvolvidos. 
O Scrum é fundamentado nas teorias empíricas de controle 
de processo e tem como base para sua implementação três 
pilares: transparência, inspeção e adaptação. A metodologia 
emprega uma abordagem iterativa e incremental para otimizar a 
previsibilidade e controlar riscos. 
Transparência 
Os aspectos do processo que afetam o resultado devem 
ser visíveis aqueles que gerenciam-no. Esses aspectos não apenas 
devem ser transparentes, mas também o que está sendo visto, 
deve ser conhecido. O que isso quer dizer? Quando alguém que 
inspeciona um processo acredita que algo está pronto, isso deve 
ser equivalente à sua definição de pronto. 
A transparência se dá através da comunicação (verbal ou 
escrita) e ocorre em diversos momentos, por exemplo: 
= Quando o cliente (Product Owner) descreve as 
funcionalidades esperadas para o produto; 
= Quando o cliente informa as prioridades das entregas; 
“ Quando o Scrum Master apresenta o planejamento e o 
andamento das sprints; 
* Quando a equipe comunica diariamente o andamento do 
trabalho; 
«= Quando a equipe atualiza um kanban deixando claro o 
andamento do desenvolvimento do produto; 
= Quando a entrega parcial é realizada e o cliente tem a 
oportunidade de dar um feedback antes do final do projeto.
 
Gestão de Times ) E 
 
Inspeção 
Os diversos aspectos 
do processo devem ser 
inspecionados com uma 
frequência suficiente para 
que variações inaceitáveis 
 
no processo possam ser 
detectadas. A frequência 
da inspeção deve levar em 
consideração que qualquer 
processo é modificado pelo 
próprio ato da inspeção. O Figura 18 - Exemplo de inspeção. 
problema acontece quando onte: Flaticon 
a frequência de inspeção necessária excede a tolerância do 
processo à inspeção. Os outros fatores são a habilidade e a 
aplicação das pessoas em inspecionar os resultados do trabalho. 
A inspeção é um princípio tão forte que o Scrum 
considera que o processo de testes está dentro da própria Sprint. 
Isso nos remete aos conceitos de integração continua, test driven 
development e pair programming, que são formas de garantir a 
qualidade enquanto o produto está sendo produzido, ao invés de 
controlar a qualidade só no final. 
A inspeção se dá, por exemplo, através dos seguintes 
itens: 
« No conceito de ready (definition of ready); 
" No conceito de done (definition of done); 
* Na reunião de grooming: 
= Quando se estima os story points de uma história de 
usuário: 
“ Reunião de revisão (review meeting) com o cliente 
(product owner); 
“ Diariamente, quando alguém termina uma história e um 
membro do grupo faz a verificação do DoD; 
" Na verificação de bugs e sua respectiva correção.
 
44 ] ( Gestão de Times 
 
Adaptação 
O inspetor determinará, a partir da inspeção, que um ou 
mais aspectos do processo estão fora dos limites aceitáveis e que 
o produto resultante será inaceitável, ele deverá ajustar 
o processo ou o material 
que está sendo processado. 
Esse ajuste deve 
ser feito o mais rápido 
possível para minimizar 
desvios posteriores. 
A adaptação é a grande Figura 18 - Exemplo de 
vedete dos projetos Scrum, adapiação. Fonte: htips:/Avww;poutube.com/ 
pois ele pode começar com um pe 
conjunto de histórias e terminar relativamente diferente. O PO 
pode constituir, modificar e excluir estórias ao término de cada 
Sprint. 
 
 
 
A adaptação se dá, por exemplo, através dos seguintes 
itens: 
* No planejamento do projeto, quando o PO prioriza as 
histórias; 
“ No review de uma Sprint, quando o PO reprioriza as 
histórias (itens do backlog): 
= No conceito de meta da Sprint, quando o time tem a 
liberdade de realizar mais ou menos histórias do que estava 
planejado; 
= No conceito de velocidade — que difere de progresso, 
quando, após algumas Sprints se tem a velocidade real do time e 
se pode calcular o tempo necessário para terminar o projeto. 
Pontos para inspeção e adaptação em 
Scrum 
Daily Scrum: reunião utilizada para inspecionar o 
progresso em direção à Meta da Sprint e para realizar adaptações 
que otimizem o valor do próximo dia de trabalho.
 
Gestão de Times ) E 
 
“ Reuniões de Revisão da Sprint e de Planejamento da 
Sprint: utilizadas para inspecionar o progresso em direção à 
Meta da Release e para fazer as adaptações que otimizem o valor 
da próxima Sprint. 
" Retrospectiva da Sprint: utilizada para revisar a Sprint 
passada e definir que adaptações tornarão a próxima Sprint mais 
produtiva, recompensadora e gratificante. 
Valores que 
sustentam os pilares 
do Scrum 
Comprometimento: 
cada pessoa deve estar 
comprometida com os objetivos 
do time e com a meta do Sprint. 
Foco: o time mantém 
o foce constante na meta da 
Sprint e nos objetivos do time. Figura 19 - Exemplo de valores, 
 
Coragem: trabalha com coragem para fazer a coisa certa e 
encara os problemas dificeis, dentro dos limites do framework. 
Respeito: os membros do time respeitam uns aos outros 
como pessoas capazes e independentes. 
= Abertura: o Time Scrum e Stakeholders concordam em 
estarem abertos a respeito do trabalho a ser feito e dos desafios 
com amsua execução. 
Scrum não descreve o que fazer em cada situação. Ele é 
usado para trabalhos complexos nos quais é impossível predizer 
tudo o que irá ocorrer. Ele é mais que isso: representa um 
conjunto de valores, princípios e práticas que fornecem a base 
para que a sua organização adicione suas práticas particulares de 
planejamento e que sejam relevantes para a sua realidade, com 
uma versão de Scrum exclusivamente sua.
 
46 ) ( Gestão de Times 
 
OBSERVAÇÃO 
 
No livro “Serum — A arte de fazer o dobro do trabalho na metade 
no tempo”, em que Jeff Sutherland autor e idealizador do Scrum, 
exemplifica que se exige prática e atenção para se chegar a um novo 
estado no qual as coisas apenas fluem para que o resto aconteça. 
 
 
Gestão de Times ) [47 
 
REFERÊNCIAS 
COHN, Mike, Gilleanes T.A. Uma Introdução ao Scrum. 2012 
FIGUEIREDO, A.M. Gerenciamento de Projetos Ágeis. Golden 
Cross,2007. 
KERZNER, H. Project Management: A system approach to 
planning 
scheduling and controlling. John Wiley & Sons, 2002. 
LEITAO, Rogério S. Escritório de Projetos: Definindo uma 
estratégia 
para projetos de TI, 2006. 
LESSA, L. O Papel do PMO nas Estruturas Organizacionais. Belo 
Horizonte: PMI Chapter MG, 2006. Disponível em: 
&lt:http:/Ayww.pmimg.org.br/Geral'visualizador Conteudo. 
aspx?cod a 
reaconteudo=423 &gt:. Acesso em: 14 fev. 2015.
 
 
ACIMA 
 
 
INDIVÍDUOS E — 
SUAS INTERAÇÕES 
DE PROCEDIMENTOS 
E FERRAMENTAS 
 
 
FUNCIONAMENTO 
DO SOFTWARE 
DE DOCUMENTAÇÃO 
ABRANGENTE 
 
 
COLABORAÇÃO 
DOS CLIENTES 
DE NEGOCIAÇÃO 
DE CONTRATOS 
 
 
 CAPACIDADE DE RESPOSTA AS MUDANÇAS DE UM PLANO PRÉ- ESTABELECIDO 
 
 
INTRODUÇÃO AOS MÉTODOS 
ÁGEIS E O SCRUM 
Este conteúdo visa fornecer o conceito sobre 
Metodologia Ágil e Framework Scrum, 
facilitando o entendimento e a aplicação de 
princípios e da estrutura do desenvolvimento 
ágil. 
 
INTRODUÇÃO AOS MÉTODOS 
ÁGEIS E O SCRUM 
A metodologia AG! E, ou ágil 
em português, se consolidou 
nos últimos anos como uma 
alternativa para atender às 
demandas de clientes e 
projetos de forma dinâmica, 
flexível e com grande 
aumento de produtividade. 
 
 
 Custo das Mud
a
n
ç
a
s
 
 
— Metodologias Ágeis 
— — Metodologias Clássicas 
INTRODUÇÃO AOS MÉTODOS 
ÁGEIS E O SCRUM 
“Ágil” se refere a um Ç 
conjunto de “métodos e ear 
práticas baseadas nos valores 
e princípio expressos, o que 
inclui coisas 
como colaboração, auto- 
organização, e equipes 
interdisciplinaresOBJETIVOS: 
1 - Conhecer o universo dos métodos ágeis. 
2- Entender a definição e os usos do Framework 
Sold Ucar 
3 - Compreender a teoria por trás do Framework 
Sold Ucar 
4 - Entender os valores do método Scrum. 
 
1. FUNDAMENTOS DA 
METODOLOGIA AGILE 
A metodologia Agile, nos moldes 
como é conhecida atualmente, foi 
concebida no início de 2001. Um 
grupo de 17 conceituados 
desenvolvedores de software se 
reuniu para aprimorar conceitos e 
metodologias ágeis existentes e 
formular o “Manifesto para o 
Desenvolvimento Ágil de Software”. 
Assinado pelos 17 desenvolvedores, 
ele reúne 4 valores e 12 princípios. 
1.1 O MANIFESTO ÁGIL E SUAS 
BASES: 
Indivíduos e interação entre eles mais que 
processos e ferramentas; 
Software em funcionamento mais que 
documentação abrangente; 
Colaboração com o cliente mais que 
negociação de contratos; 
Responder a mudanças mais que seguir um 
plano. 
1.2.2. PRINCÍPIOS 
Software funcionando é a medida primária de progresso. 
Os processos ágeis promovem desenvolvimento sustentável. 
Os patrocinadores, desenvolvedores e usuários devem ser 
capazes de manter um ritmo constante indefinidamente. 
Contínua atenção a excelência técnica e bom design aumenta 
a agilidade. 
Simplicidade: a arte de maximizar a quantidade de trabalho 
não realizado é essencial. 
As melhores arquiteturas, requisitos e designs emergem de 
times auto-organizáveis. 
Em intervalos regulares, a equipe reflete sobre como se tornar 
mais eficaz e então refina e ajusta seu comportamento de 
acordo. 
1.2.2. PRINCÍPIOS 
Nossa maior prioridade é satisfazer o cliente através da entrega contínua 
e adiantada de software com valor agregado. 
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. 
Processos ágeis se adéguam a mudanças, para que o cliente possa tirar 
vantagens competitivas. 
Entregar frequentemente software funcionando, de poucas semanas a 
poucos meses, com preferência à menor escala de tempo. 
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto por todo o projeto. 
Construir projetos em torno de indivíduos motivados. Dando a eles o 
ambiente e o suporte necessário, e confiando neles para fazer o 
trabalho. 
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. 
1.3. ADOÇÃO ÁGIL: RESISTÊNCIA A 
MUDANÇAS 
As mudanças que uma adoção ágil traz, 
impactam na forma em que os membros da 
equipe desempenham seus trabalhos, indo 
contra ao que foi aprendido com treinamentos 
anteriores. 
 
1.4. TRADICIONAL VS ÁGIL 
A principal diferença entre um modelo um 
Tradicional e um Ágil é o tipo de controle 
nos processos de cada um. 
D Ns o GAR US RS 
EU a(o TG 
AO RR Ria Ee 
OR OS (a 
1.4.1. A VISÃO DOS MODELOS 
TRADICIONAL E ÁGIL 
Vejamos a seguinte situação, sua empresa, um banco 
da cidade, vai implementar um aplicativo móvel 
para que os clientes possam visualizar seus 
extratos. Há rumores de que o seu principal 
concorrente, um outro banco da cidade, vai lançar 
seu próprio aplicativo móvel também. 
TEMPO É UMA QUESTÃO ESSENCIAL. 
1.4.1. A VISÃO DOS MODELOS 
TRADICIONAL E ÁGIL 
TRADICIONAL: Escreveria o termo de abertura do 
projeto, definindo o aplicativo móvel, 
enviaria para aprovação, definiria O 
cronograma precisamente, enviaria 
para aprovação de novo, criaria a equipe do 
projeto, para ai sim, iniciar o desenvolvimento. 
NESTE ESBOÇO TRADICIONAL JÁ IRIA UNS 30 DIAS! 
1.4.1. A VISÃO DOS MODELOS 
TRADICIONAL E ÁGIL 
ÁGIL: Seria parecido, porém, bem mais simples e 
objetivo! Seria definido a visão do produto para o 
aplicativo móvel, montaria uma equipe, e 
iniciaria o desenvolvimento. 
Neste esboço ágil, A SOBRECARGA É MUITO 
MENOR, economizando tempo desde a idéia até 
a execução. 
1.4.2. EXEMPLO 
DESENVOLVIMENTO DO PROJETO 
TRADICIONAL VS ÁGIL 
Da (OS O o RS ; 
AO INVES DE COMPLETAR UMA COISA POR VEZ, 
EQUIPES SGRUM FAZEM UM POUCO DE CASA COISA TODO O TEMPO, 
2. FRAMEWORK SCRUM 
SCRUM é um framework para organizar e gerenciar 
trabalhos complexos, tal como projetos de 
desenvolvimento de software. 
oO 
BACKLOG 
EN 
EDIT ART 
LUTO 
SPRINT 
2.1. PRODUCT OWNER 
O PRODUCT OWNER é o responsável pelo 
produto, tendo como meta maximizar o valor do 
produto e do trabalho da Equipe de 
Desenvolvimento. Como isso será alcançado 
dependerá de cada organização, Equipe Scrum e 
dos indivíduos que compõem a Equipe Scrum. 
 
2.2. SCRUM MASTER 
O SCRUMMASTER é responsável por ajudar a todos os 
envolvidos a entender e abraçar os valores, princípios e 
práticas do Scrum, age como um Coach, executando a 
liderança do processo e ajudando a equipe Scrum a 
desenvolver sua própria abordagem do Scrum. 
COACH = | | ESTUDO 
CONTRA 
| 
| 
[Ng aan (e o 
LÍDER 
SERVIDOR REMOVEDOR 
DE 
IMPEDIMENTOS 
AUTORIDADE 
NO PROCESSO 
AGENTE DE 
RUUL AS 
2.3. EQUIPE DE 
DESENVOLVIMENTO 
É a responsável pelo 
desenvolvimento do 
produto. À Equipe de 
Desenvolvimento que 
cabe a 
responsabilidade de 
estimar o esforço para 
implementação das 
histórias descritas no 
product backlog. 
2.4. PRODUCT BACKLOG 
O PRODUCT BACKLOG é uma lista contendo 
todas as funcionalidades desejadas para um 
produto. O conteúdo desta lista é definido 
pelo Product Owner. O Product Backlog não 
precisa estar completo no início de um projeto. 
Pode-se começar com tudo aquilo que é mais 
óbvio em um primeiro momento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
2.4.1. EXEMPLO PRODUCT 
BACKLOG 
PRODUCT BACKLOG (exemplo) 
ID | Nome Imp Est | Como demonstrar | Notas 
I Depósito 30 5 Logar-se. abrir a Precisa de uma 
página de depósito, diagrama 
depositar R$ 10,00, UML de 
 
 
 
ww para a página do sequência. Não 
meu saldo e é necessário se 
 
verificar que este preocupar com 
aumentou em R$ criptografia 
10,00. por enquanto. 
2 Verificar o) 8 Logar-se, clicar em Usar 
seu próprio “transações”. Fazer paginação para 
histórico de um depósito. Voltar | evitar 
transações para transações, consultas 
verificar se o novo muito grandes 
depósito é listado. ao banco de 
dados. Projetar 
de forma 
similar à 
página de 
visualização de 
usuários. 
2.5. TIME SCRUM 
No Scrum é definido o papel do Time de 
Desenvolvimento, que é simplesmente a junção de 
todas as pessoas de um projeto em uma equipe 
multidisciplinar, e que são responsáveis pela 
concepção, construção e testes do produto. 
PRODUCT OWNER RR O ROD = 
DESENVOLVIMENTO 
2.6. SPRINTS 
O trabalho realizado em iterações ou ciclos de até um 
mês de calendário são chamados de Sprints. Cada 
sprint deve criar algo de valor tangível para o cliente ou 
usuário. Sprints são timeboxed (duração fixa) para que 
tenham sempre um início e fim data fixa, e, 
geralmente, todos eles devem estar com a mesma 
duração. 
SNI! SN SINE IR 
O a ESnERe ana Eta 
o 
DURAÇÃO MÁXIMA DE 
ER [ao 
2.6.1. SPRINT PLANNING MEETING 
É uma reunião na qual estão presentes 
o Product Owner, o Scrum Master e todo 
o Scrum Team, bem como qualquer pessoa 
interessada que esteja representando a gerência 
ou o cliente. 
Sprint Planning Meeting 
Backlog Sprint Planning Sprin rs 
Meeting 
“B 
o» Eh, Se 
2.6.2. SPRINT BACKLOG 
O Sprint Backlog é uma lista de tarefas que o Scrum Team se 
compromete a fazer em um Sprint. Os itens do Sprint Backlog 
são extraídos do Product Backlog, pela equipe, com base nas 
prioridades definidas pelo Product Owner e a percepção da 
equipe sobre o tempo que será necessário para completar as 
várias funcionalidades. 
Sprint Backlog 
Forecast ToDe InProgress Done 
E +] 
F 
dotar puro 
5 =] 
 
 
 
 
2.6.3. SPRINT REVIEW MEETING 
Ao final de cada Sprint é 
feito um Sprint Review 
Meeting. Durante esta 
reunião, o Scrum Team 
mostra o quefoi 
alcançado durante o 
Sprint. Tipicamente, isso 
tem o formato de um 
demo das novas 
funcionalidades. 
2.6.4. SPRINT RETROSPECTIVE 
OBS ANINII 
RETROSPECTIVE ocorre 
ao final de um Sprint e 
serve para identificar o 
que funcionou bem, o 
que pode ser melhorado 
e que ações serão 
tomadas para melhorar. 
2.6.5. EXEMPLO PLANEJAMENTO 
did 
RR AR 
Hip 
INTERFACE 
QUERO QUE OS USUÁRIOS 
DRA TR OSS RETA Ta 
Si RE 
ITINERÁRIOS ONLINE 
CODIFICAR A 
CLASSE VOO 
ATUALIZAR TESTES 
dad HS 
2.7. DAILY SCRUM 
A cada dia do Sprint a equipe faz uma reunião diária, 
chamada . Ela tem como objetivo 
disseminar conhecimento sobre o que foi feito no dia 
anterior, identificar impedimentos e priorizar o trabalho 
a ser realizado no dia que se inicia. 
 
2.7.1. EXEMPLO DE DAILY SCRUM 
PARÂMETROS 
— Diário 
— 15 minutos 
TODOS EM PÉ 
NÃO É PARA SOLUÇÃO DE PROBLEMAS 
— Todo mundo é convidado 
— Apenas os membros da equipe, ScrumMaster, Dono do 
Produto podem falar 
AJUDA A EVITAR REUNIÕES ADICIONAIS DESNECESSÁRIAS 
3. TEORIA DO SCRUM 
O desenvolvimento de projetos com o 
FRAMEWORK SCRUM envolve diversos 
recursos, entre ele temos recursos tecnológicos 
e humanos, sendo este último, um dos fatores 
de sucesso e insucesso de projetos. 
 
3.1. PROJETOS SCRUM 
Em projetos Scrum a equipe 
tem a responsabilidade, ou 
seja, 
 
3.1.1. EQUIPES DOS PROJETOS 
SCRUM 
O Scrum atua de forma 
AUTO-ORGANIZADO, 
eliminando papeis, 
dando as pessoas, uma 
visão que vá além de 
suas especialidades e 
E 
ajuda a equipe de todas E 
as maneiras possíveis. 
Alem disso, equipes 
Scrum são pequenas. 
3.1.2. GERENTE FUNCIONAL OU 
DE PROJETOS 
A equipe é auto-organizada, 
ou seja, OS processos são 
definidos pela própria 
equipe, sendo um dos 
princípios do Manifesto Ágil. 
Alem disso, o manifesto 
ágeis prioriza pessoas e 
interações, mais do que 
processos e ferramentas 
F | E 
IM