Você está na página 1de 84

O Manifesto Ágil

e uma breve introdução ao Scrum

São Vicente, SP
2020
Sumário
Capítulo 1
A Certificação Professional Scrum Master
Certificações da Scrum.org
PSM – Professional Scrum MasterTM
PSM-I – Professional Scrum MasterTM Nível I
Capítulo 2
Métodos Tradicionais e Adaptativos
Principais ciclos utilizados para o desenvolvimento de um produto
Ciclos Preditivos
Ciclo de Desenvolvimento Iterativo e Incremental
Ciclo de Desenvolvimento Adaptativo
Capítulo 3
O Manifesto Ágil
História
Manifesto Ágil
Princípios
Capítulo 4
Introdução ao Framework Scrum
Breve História do Scrum
Definição do Scrum
Uso do Scrum
Capítulo 5
Teoria do Scrum
Capítulo 6
Introdução ao Framework Scrum
Time Scrum
Eventos do Scrum
Artefatos do Scrum
Capítulo 7
Introdução ao Backlog do Produto
Principais características de um Backlog do Produto
Priorize e construa apenas os itens do Backlog que agregam maior
valor para o negócio
Capítulo 8
Histórias de Usuário
Os 3 C’s — Cartão, Conversação e Confirmação
Características fundamentais de uma História de Usuário
Temas
Construindo Histórias de Usuário
Conclusão
Capítulo 9
O Planejamento no Scrum
Capítulo 10
Principais técnicas de estimativas empregadas no Scrum
Pontos por História
O Planning Poker
Dias (ou Horas) Ideais
Conclusão
Capítulo 11
Mitos do Scrum
A Reunião Diária deve ser realizada em pé
Durante a Reunião Diária, as três perguntas devem ser
respondidas
Os membros do Time de Desenvolvimento devem ser capazes de
executar qualquer tipo de trabalho
Os itens do Backlog do Produto devem ser descritos no formato
de histórias de usuário
É obrigatório utilizar o gráfico Burndown para acompanhar o
progresso da Sprint
A Sprint Zero (0)
Capítulo 12
Formação em Scrum – Preparatório para a Certificação PSM-I
Referências Bibliográficas
Capítulo 1
A Certificação Professional Scrum Master
Certificações da Scrum.org
​A Scrum.org foi fundada em 2009 por Ken Schwaber que, como todos
sabemos, é um dos criadores do Scrum. As certificações dessa instituição
são muito valorizadas no mundo inteiro. Ken Schwaber é o atual
presidente da Scrum.org, o que certamente contribui e muito para o grande
reconhecimento dessa empresa.
Apenas a título de curiosidade, até setembro de 2014, a Scrum.org
era a mantenedora do Guia Scrum.
A Scrum.org oferece treinamentos abrangentes, avaliações e
certificações a fim de aprimorar a entrega de software. Ela baseia-se nos
princípios do Scrum e do Manifesto Ágil.
A Scrum.org oferece as seguintes certificações:

PSM – Professional Scrum MasterTM


Destinam-se a certificar o conhecimento do
profissional em relação ao Scrum e à habilidade de
aplicar esses conhecimentos na prática.
Existem três níveis de certificações Professional
Scrum Master: Nível 1 (foundation), nível 2
(intermediário) e nível 3 (avançado).

PSPO – Professional Scrum Product OwnerTM


Destinam-se a atestar o conhecimento do
profissional em relação às atribuições do papel de
Dono de Produto e à sua habilidade de aplicar esses
conhecimentos, na prática.
Existem três níveis de certificações Professional
Product Owner: Nível 1 (foundation), nível 2
(intermediário) e nível 3 (avançado).

PSD – Professional Scrum DeveloperTM


A certificação profissional Scrum Developer
destina-se a validar o conhecimento dos profissionais
que trabalham como membros de um Time de
Desenvolvimento. Ela valida e certifica os seguintes
conhecimentos:
Práticas e técnicas que suportam a
construção de softwares complexos.
A capacidade do profissional em aplicar
esses conhecimentos.

SPS – Scaled Professional ScrumTM


A certificação Scaled Professional Scrum irá
validar e certificar o conhecimento do profissional em
relação a como escalar o Scrum, utilizar o framework
Nexus e a sua habilidade de aplicar esses
conhecimentos.
Apenas a título de informação, o Scrum escalado é
utilizado quando estamos desenvolvendo um produto
muito grande e complexo, envolvendo muitos
profissionais na construção do mesmo. Dessa forma, o
projeto irá contar com múltiplos times Scrum
trabalhando em um mesmo produto.

PSK – Professional Scrum With KanbanTM


A certificação Professional Scrum With Kanban
destina-se a qualquer pessoa que deseja validar os seus
conhecimentos sobre como os Times Scrum podem
utilizar o Scrum juntamente com o Kanban a fim de
suportar a criação e entrega de valor.

PAL - Professional Agile LeadershipTM


A certificação Professional Agile Leadership está
disponível para qualquer profissional que deseje
assegurar que é um líder e entende que a agilidade
agrega valor ao negócio; e também o motivo pelo qual
o entendimento dos líderes, patrocinadores e suporte às
práticas ágeis são essenciais para uma organização se
tornar mais ágil.
PSU - Professional Scrum with User Experience™
A certificação Professional Scrum with User
Experience tem por objetivo validar que o profissional
possui um nível fundamental de entendimento sobre
como integrar ao Scrum modernas práticas de UX,
com o intuito de propiciar um maior valor.

Dentre as certificações disponibilizadas pela Scrum.org, a mais


conhecida é a Professional Scrum Master nível 1 (PSM-I).
PSM – Professional Scrum MasterTM
​A partir dessa seção serão apresentados os três níveis da certificação
Professional Scrum Master. Atualmente, a PSM é a certificação mais
procurada pelos profissionais.
Professional Scrum Master nível I
Os profissionais que possuem a certificação PSM-I demonstram e
atestam que possuem os conhecimentos fundamentais do Framework
Scrum, conforme descrito no Guia Scrum. Além disso, eles também
entendem os conceitos necessários para aplicar o Scrum.
Os Profissionais com a Certificação PSM-I possuem uma
terminologia e abordagem consistentes para o Scrum.
Professional Scrum Master nível II
Os profissionais que possuem a certificação PSM-II demonstram
um nível avançado de maestria no Scrum.
Esses profissionais provam que possuem uma compreensão dos
princípios subjacentes do Scrum e que podem efetivamente aplicar o
Scrum em situações complexas do mundo real.
Professional Scrum Master nível III
Os profissionais que possuem a certificação PSM-III demonstram
um nível distinto de maestria no Scrum.
Esses profissionais atestam que possuem um profundo
entendimento da aplicação, das práticas e dos valores do Scrum em uma
variedade de situações complexas.
PSM-I – Professional Scrum MasterTM Nível I
A certificação Professional Scrum Master Nível 1, disponibilizada
pela Scrum.org, destina-se a qualquer pessoa que deseje validar seu nível
de conhecimento no framework Scrum e a sua aplicação. Conforme já foi
dito anteriormente, os indivíduos que a possuem demonstram e atestam
que conhecem os fundamentos do Scrum, conforme descrito no Guia
Scrum. Além disso, eles também entendem os conceitos necessários para
aplicar o Scrum. Contudo, caso o profissional deseje validar que possui
conhecimentos mais avançados e que sabe empregar o Scrum no mundo
real, deve partir para as certificações mais avançadas como a PSM-II.
A prova é composta por 80 questões, cujas respostas podem ser de
múltipla escolha, múltiplas respostas ou verdadeiro/falso.
​O tempo máximo disponibilizado ao candidato para concluir a
avaliação é de 60 minutos. Dessa forma, o candidato tem uma média de 45
segundos para responder a cada questão. Conforme pode-se perceber, é um
intervalo bem curto.
O candidato, para ser aprovado, deve alcançar 85% de
aproveitamento, ou seja, necessita acertar ao menos 68 questões. A
Scrum.org considera que o exame possui um nível de dificuldade
intermediário.
No momento, o exame PSM-I é disponibilizado somente no idioma
inglês. Caso tenha dificuldades com a língua inglesa, existe uma opção: O
exame pode ser realizado utilizando o navegador Google Chrome, que
possui um recurso de tradução.
​Perceba que não é tão fácil obter essa certificação. Entretanto, é por
esse motivo que as certificações da Scrum.org são cada vez mais
reconhecidas pelo mercado.
A taxa para prestar o exame é de US$ 150,00 e, em caso de reprovação,
não é concedida uma nova tentativa. O candidato reprovado, caso deseje
realizar novamente o teste, deverá pagar a mesma a taxa, sem a concessão
de desconto.
​Uma das grandes vantagens da certificação PSM-I é que o candidato,
ao ser aprovado, não necessita pagar taxas periódicas a fim de renová-la,
pois ele a possuirá por tempo indeterminado.
Como o exame é realizado de forma on-line, os únicos pré-
requisitos técnicos consistem em possuir um navegador e um computador
com conexão à Internet. A prova poderá ser prestada em qualquer horário
e local.
O candidato não é monitorado durante a realização da avaliação.
Dessa forma, embora exista uma brecha para que se realize consultas a
materiais durante o exame, isso é bastante improvável, pois, é
disponibilizado apenas 45 segundos para a seleção da resposta de cada
questão.
Sendo assim, é recomendável que o requerente estude e se prepare
bem para o exame, e que faça o mesmo sem consultas, uma vez que não
adianta possuir a certificação sem obter aprendizado. Além do mais, o
profissional que conquista a certificação sem se dedicar pode até conseguir
um bom emprego, porém certamente acabará não ficando muito tempo na
empresa, uma vez que não terá o conhecimento necessário para executar as
suas atividades.
Capítulo 2
Métodos Tradicionais e Adaptativos
O objetivo principal deste capítulo consiste em apresentar os
principais métodos utilizados no desenvolvimento de um produto, para que
seja possível compará-los com o ciclo de desenvolvimento adaptativo,
também conhecido como ágil.
Principais ciclos utilizados para o desenvolvimento de um produto
​Segundo o guia PMBOK, que é mantido pelo PMI, o ciclo de vida de
um projeto é composto por um encadeamento de fases, através das quais
um projeto percorre desde o seu início até à sua conclusão. O ciclo de vida
irá prover a estrutura básica para o gerenciamento de um projeto durante o
desenvolvimento de um produto. Além disso, essa estrutura pode ser
aplicada independentemente de qual seja o trabalho do projeto.
​A partir desse momento será apresentado um resumo dos seguintes
ciclos de desenvolvimento: preditivos, iterativos e incrementais e
adaptativos.
Ciclos Preditivos
​Quando ocorre a utilização de um método de desenvolvimento baseado
no ciclo preditivo, o escopo, o prazo e o custo são estabelecidos nas fases
iniciais do projeto. Comumente as fases são executadas em sequência e,
por esse motivo, as mudanças devem ser bem gerenciadas, uma vez que é
muito custoso e arriscado mudar nos estágios finais.
Sendo assim, os ciclos preditivos são empregados em projetos
cujos requisitos sejam totalmente compreendidos e onde mudanças não
sejam constantes. Soma-se a isso que o escopo, o tempo e os custos
requeridos para o projeto devem ser determinados o mais cedo possível.
No ciclo preditivo, o projeto avança através de fases sequenciais ou
consecutivas, onde cada uma delas possui trabalhos específicos e
diferentes das demais. Por exemplo, ao desenvolver um software,
inicialmente são coletados os requisitos e, em sequência, é realizado o
desenho do produto. Posteriormente, inicia-se a construção e, finalmente,
são executadas as fases de testes e implantação do produto.
Dessa forma, pode ser necessário realizar alterações na composição
dos membros do time durante o andamento do projeto, pois, as habilidades
necessárias para a realização do trabalho variam a cada fase. No exemplo
anterior, na fase de requisitos, será necessário que o time seja composto
por profissionais que irão identificar as funcionalidades do software a ser
desenvolvido. Já nas fases de desenho e implementação, o projeto carecerá
de arquitetos e desenvolvedores. Nas fases que se sucedem, profissionais
de outras especialidades serão requeridos.
O ciclo preditivo costuma ser a melhor opção:
Quando o produto a ser construído possui requisitos bem
compreendidos e estáveis.
Nas situações onde existe uma base significativa de práticas
na indústria.
Quando o valor entregue para o negócio ou partes
interessadas é obtido apenas ao desenvolver e entregar o produto
por completo.

O ciclo preditivo também é conhecido como waterfall, em cascata,


clássico ou tradicional. Ele foi originado em 1970, após à publicação de
um artigo de Winston W. Royce. Contudo, é importante frisar que Royce
não tinha a intenção de criar o modelo em cascata. O seu artigo apenas
apresentou um conceito inicial para o desenvolvimento de grandes
programas de computador, que ele mesmo considerava uma abordagem
arriscada e convidativa ao fracasso.
Em nenhum momento a sua obra citou o termo em cascata. Além
disso, Royce buscava explorar uma maneira de utilizar o modelo através
de uma abordagem iterativa. Todavia, somente o seu modelo inicial se
destacou e suas críticas em relação ao mesmo foram totalmente ignoradas.
O método em cascata consiste em um modelo sequencial, que
costuma conter as seguintes fases: requisitos, desenho, implementação
(construção), testes e implantação. Cada fase inicia-se após à conclusão da
anterior.
Em contrapartida, o modelo inicial de Royce descrevia as seguintes
fases: requisitos do sistema, requisitos de software, análise, desenho do
programa, codificação, testes e operação.
Muitos dizem que uma das maiores vantagens em utilizar esse
modelo consiste que ele é composto por fases bem definidas e possui foco
no planejamento. Além disso, uma das maiores desvantagens é que o
cliente irá visualizar o produto desenvolvido apenas próximo à conclusão
do projeto, normalmente durante a fase de testes.
Caso fosse identificada uma falha de requisito durante a fase de
testes, o projeto estaria em um estágio avançado, onde o custo para a
realização da correção será alto. Além disso, o prazo de entrega poderá se
estender. Esteja ciente que localizar problemas durante as fases iniciais é
menos custoso e de mais fácil resolução em relação a encontrá-los nos
estágios finais.
Portanto, o modelo em cascata não é recomendado para o
desenvolvimento de produtos complexos, onde os requisitos não são
completamente compreendidos no início do projeto e em situações em que
são exigidas mudanças constantes como, por exemplo, na construção de
um software.
Ao contrário disso, o modelo poderá ser uma excelente opção para
projetos onde os requisitos são bem definidos e não exigem constantes
mudanças como, por exemplo, na construção civil.
Exemplo de Ciclo Preditivo – Em Cascata

​ A famosa imagem acima visa demonstrar graficamente o


funcionamento do modelo em cascata. Pode-se perceber que, conforme o
tempo avança, as fases são executadas em sequência.
Vamos pressupor que se esteja trabalhando em um projeto de
desenvolvimento de software, cuja estimativa para término seja de 12
meses. Como as fases são executadas sequencialmente, o cliente poderá
visualizar alguma parte funcional do software somente a partir da segunda
metade da fase de implementação ou durante os testes, por volta do oitavo
mês da execução do projeto.
Agora imagine se o cliente identificar algum erro, requisito
incorreto, ou a necessidade de aplicar uma mudança durante alguma das
fases finais. Certamente os custos para a adequação serão elevados e o
prazo acordado não será cumprido. É por esse motivo que não se
recomenda a utilização do ciclo em cascata para o desenvolvimento de
software.
Ciclo de Desenvolvimento Iterativo e Incremental
O ciclo de desenvolvimento iterativo e incremental foi concebido
para tentar solucionar os problemas existentes no modelo em cascata. Ao
utilizar esse modelo, o produto é desenvolvido em partes, através de ciclos
que se repetem. Em cada ciclo ocorre a execução de algumas fases e, ao
seu final, é entregue um novo incremento do produto.
O produto vai evoluindo ao final de cada iteração. É importante
destacar que os ciclos podem possuir curta ou longa duração.
Principais características do ciclo iterativo e incremental:

O projeto avança através de fases (também conhecidas como


iterações) que se repetem. A cada nova iteração, maior será a
compreensão da equipe do projeto em relação ao produto.
Ao final de cada iteração, é entregue uma nova
funcionalidade ou a melhoria de uma existente. Por isso dizemos
que o desenvolvimento é incremental. Por exemplo, ao
desenvolver um software de comércio eletrônico, podemos
segregar o desenvolvimento do sistema em algumas iterações: ao
longo da primeira iteração será desenvolvido os módulos de
cadastramento de clientes, produtos e fornecedores. Durante a
segunda iteração, será acrescido ao software os módulos de
pagamento, recebimento e de emissão de nota fiscal. O projeto
segue dessa maneira até à finalização do desenvolvimento de
todo o software.
Sendo assim, podemos dizer que o produto é separado em
partes pequenas e, durante a construção de cada uma dessas
etapas, ocorre a execução do ciclo preditivo. Ou seja, em cada
fase é realizada a coleta e análise de requisitos, desenho do
produto, desenvolvimento, testes e implantação. Ao final da
iteração, o produto é incrementado.

Da mesma maneira que o ciclo preditivo, as mudanças no escopo


do projeto devem ser gerenciadas cuidadosamente.
Os principais padrões que utilizam o desenvolvimento iterativo e
incremental são o RUP (Rational Unified Process), da IBM e os métodos
ágeis. Contudo, é relevante destacar que os métodos ágeis possuem
iterações muito curtas e são orientados a mudanças. O ciclo adaptativo será
apresentado mais à frente.
RUP (Rational Unified Process)
Com a intenção de demonstrar a utilização do ciclo de
desenvolvimento iterativo e incremental, será apresentada uma introdução
da metodologia RUP (Rational Unified Process). Ela foi desenvolvida pela
Rational, que também foi a criadora do padrão UML (Unified Modeling
Language). Em 2003, a IBM adquiriu a Rational e passou a ser a
proprietária da metodologia RUP.
O RUP é um processo de Engenharia de Software, que utiliza a
abordagem de Orientação a Objetos. É documentado e projetado utilizando
a metodologia UML. Conforme foi dito anteriormente, essa metodologia
baseia-se no ciclo de Desenvolvimento Iterativo e Incremental.
O RUP é considerado pesado e sua utilização é recomendada para
projetos longos ou quando houver a necessidade de se trabalhar com
grandes equipes de desenvolvimento. Caso exista o desejo de se utilizar o
RUP em pequenos projetos, é possível customizá-lo a fim de que ele se
torne mais enxuto.
É importante destacar que a metodologia RUP prevê a elaboração
de uma grande quantidade de artefatos (diagramas e documentos) durante
o desenvolvimento de um produto, o que certamente aumenta os custos e o
tempo de execução do projeto.
Cada disciplina possui um conjunto de artefatos a serem
construídos. Exemplos de artefatos a serem produzidos:

Diagramas.
Casos de Uso;
Arquitetura;
Classe;
Sequencia;

Documentos.
Especificações de Caso de Uso;
Visão;
Solicitações dos Envolvidos;
Regras de Negócio;
Casos de Testes;
Glossário;
Especificações Suplementares;
Dentre outros.

Além disso, o RUP define diversos papéis a serem atribuídos a


membros da equipe do projeto. É possível que seja atribuído mais de um
papel a cada profissional do time. Exemplos de papéis definidos por essa
metodologia:

Gerente de Projetos;
Analista de Requisitos;
Analista de Testes;
Testador;
Arquiteto;
Desenvolvedor;
Gerente de Implantação;
Gerente de Configuração;
Entre outros.

O RUP também disponibiliza métodos para realizar o controle e


gerenciamento de mudanças durante o andamento do projeto de
desenvolvimento de um determinado produto.
Ao utilizar o RUP para desenvolver um produto, existe uma
dimensão de tempo, composta por fases que indicam o estágio em que o
produto se encontra. Essas fases podem possuir uma ou mais iterações.
Como resultado de cada fase ou iteração são produzidos artefatos.
As fases do RUP são:

Iniciação
Durante essa fase ocorre a definição do escopo do
projeto.
Elaboração
Utilizada a fim de se realizar uma validação da
arquitetura a ser utilizada para o desenvolvimento do
produto. Além disso, durante essa etapa pode ocorrer o
desenvolvimento de algum requisito selecionado para
a iteração, a fim de validar com os clientes se o
produto em construção está de acordo com o que ele
prevê.
Construção
Momento em que ocorre o desenvolvimento do
produto propriamente dito.
Transição
Essa é a última fase do projeto. É o momento onde
será realizada a implantação do produto no ambiente
de Produção.

É importante destacar que, a cada fase (ou iteração), são executadas


disciplinas a fim de se realizar o trabalho de desenvolvimento do projeto.
As disciplinas do RUP são:

Modelagem de Negócio;
Requisitos;
Análise e Design;
Implementação;
Teste;
Implantação;
Gerenciamento de Configuração e Mudança;
Gerenciamento do Projeto;
Ambiente.

​ imagem apresenta graficamente o funcionamento da Metodologia


A
RUP. Na parte de cima, na horizontal, são apresentadas as fases do RUP
ao longo do andamento do projeto. Adicionalmente, perceba que, para
cada fase, pode ser executada uma ou mais iterações.
Além do mais, pode-se constatar que, para cada iteração do projeto,
são executadas todas as disciplinas previstas para o RUP. Por exemplo, na
primeira iteração da fase de elaboração, são executadas as disciplinas de
modelagem de negócios, requisitos, análise e design, implementação, teste,
implantação, gerenciamento de configuração e mudança, gerenciamento de
projeto e ambiente. Ao final de cada iteração e de cada fase são produzidos
artefatos ou incrementos do produto em desenvolvimento.
Com base no que foi explicado até o momento, repare como o RUP
é uma metodologia bem complexa e destinada a grandes projetos. No
entanto, nada nos impede de customizá-lo. Por exemplo, em um projeto
menor, podemos optar por não realizar as atividades da disciplina de
modelagem de negócios.
Ciclo de Desenvolvimento Adaptativo
Para finalizar, será apresentado o ciclo de desenvolvimento
adaptativo, também conhecido como ágil. Os ciclos adaptativos baseiam-
se no manifesto ágil, que será explicado adiante.
O ciclo adaptativo é ideal para o desenvolvimento de produtos
complexos, que exigem altos níveis de mudança, onde não é possível
definir antecipadamente todos os requisitos e o escopo do projeto. É
relevante frisar que os ciclos adaptativos são muito utilizados no
desenvolvimento de softwares.
Ao empregar ciclo adaptativo, as partes interessadas estão
continuamente envolvidas, provendo feedbacks e auxiliando na definição
dos requisitos do produto.
O desenvolvimento é realizado através da abordagem iterativa e
incremental, com a diferença de que, nos ciclos adaptativos, as iterações
possuem curta duração (que pode variar de uma semana a um mês).
Quando uma iteração finaliza, ocorre a entrega de um novo
incremento, que consiste em uma nova versão funcional do produto,
contendo novas funcionalidades ou melhorias em relação à anterior.
Principais características de um ciclo adaptativo:

Realização de entregas rápidas e constantes.


Desenvolvimento orientado a mudanças.
Como as entregas são realizadas em curtos períodos, ocorre
uma redução nos riscos do projeto.
Foco no cliente e na qualidade.
Ao utilizar desenvolvimento adaptativo, o time deve elaborar
apenas documentos que sejam estritamente necessários para o
projeto e que serão utilizados posteriormente.
As comunicações devem ser constantes e, preferencialmente,
cara a cara.
São baseados nos valores e princípios do manifesto ágil.

Exemplo de Ciclo Adaptativo


​ onforme pode-se perceber na imagem, a cada iteração, ocorre o
C
desenvolvimento de uma parte do produto. Ao final da iteração, que
costuma durar de uma semana a um mês, deve ser entregue uma nova
versão do produto, que consiste na entrega anterior, acrescida de novas
funcionalidades ou melhorias. Esses incrementos devem ser funcionais
para que, caso faça sentido para o cliente, possam ser implantados e
utilizados.
​É importante destacar que, durante as primeiras iterações, ocorre o
desenvolvimento das funcionalidades mais importantes e que agregam um
maior valor para o negócio.
Capítulo 3
O Manifesto Ágil
História

​ m fevereiro de 2001, dezessete pessoas compareceram a uma reunião


E
agendada por Robert Cecil Martin, com o intuito de discutir, dentre outras
atividades, sobre boas práticas adotadas para o desenvolvimento de seus
trabalhos. O encontro ocorreu nas montanhas, em um resort de ski, no
estado de Utah, nos Estados Unidos.

​ urante a reunião, todos chegaram a um consenso sobre aspectos


D
importantes referente ao desenvolvimento de software e decidiram
escrever um documento, que foi intitulado manifesto do desenvolvimento
de software ágil. Ele continha as crenças e os valores dos participantes do
encontro sobre o desenvolvimento ágil de software.

​ osteriormente, nos meses que se sucederam, os participantes


P
continuaram trabalhando conjuntamente com o intuito de elaborar os
princípios das metodologias ágeis.

Segue os nomes dos participantes que compareceram ao evento:

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.
Robert Cecil Martin.
Steve Mellor.
Ken Schwaber.
Jeff Sutherland.
Dave Thomas.

Vale ressaltar que Ken Schwaber e Jeff Sutherland, os criadores do


Scrum, estiveram presentes. Outro participante que se destaca é Kent
Beck, conhecido por ser o criador da metodologia Extreme Programming
(XP) e dos conceitos de Desenvolvimento Orientado a Testes (TDD).

Manifesto Ágil

Estamos descobrindo maneiras melhores de desenvolver


software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através
deste trabalho, passamos a valorizar:

1. Indivíduos e interações mais que processos e ferramentas.


2. Software em funcionamento mais que documentação
abrangente.
3. Colaboração com o cliente mais que negociação de
contratos.
4. Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos


mais os itens à esquerda.

Indivíduos e interações mais que processos e ferramentas

O Manifesto Ágil, através desse valor, busca defender que, mais


importante que utilizar processos e ferramentas, consiste em focar nos
indivíduos e nas interações que ocorrem entre eles.

Os membros de um time, sempre que possível, devem interagir


entre si presencialmente. Dessa maneira, propicia-se a consolidação do
trabalho em equipe e constroem-se relações de confiança. Como
consequência, os indivíduos passam a colaborar uns com os outros.

Contudo, isso não significa que as ferramentas e os processos não


devam ser utilizados. Ao contrário, elas são muito importantes para a
execução de um projeto. Entretanto, aconselha-se que sejam simples, com
o intuito de desburocratizar o trabalho e de não gerar desperdício de tempo
e recursos.

Para exemplificar: durante o expediente, um membro da equipe


necessita sanar uma dúvida com um colega que se encontra no mesmo
andar. Em vez de enviar um e-mail, utilizar o telefone ou a ferramenta de
mensagens instantâneas, por que não ir até à mesa do colega para
conversar? Certamente, agindo dessa forma, a dúvida será esclarecida mais
rapidamente e irá ocorrer um fortalecimento no relacionamento entre esses
colaboradores.

Software em funcionamento mais que documentação abrangente

Decerto, para o cliente, é primordial que o software a ser


desenvolvido:

Cumpra os requisitos acordados.


Possua alto grau de qualidade.
Esteja livre de erros.
Seja intuitivo e de simples utilização.
Dentre outras características importantes.

Ao contrário do que muitos imaginam, quando se constrói um


sistema utilizando desenvolvimento ágil, é necessário elaborar
documentos. Entretanto, deve-se valorizar mais software em
funcionamento em relação à documentação abrangente. Ou seja, é preciso
produzir apenas documentos imprescindíveis, que serão utilizados após o
desenvolvimento do produto.

Exemplos de documentos a serem elaborados: manual de


utilização, regras de negócio e arquitetura do sistema.

Imagine que você comprou um automóvel moderno, com muitas


funcionalidades, e que não veio um manual de utilização. Se estivesse com
dificuldade para utilizar alguma dessas funcionalidades, como procederia?
Seria difícil, não?

Com software é a mesma coisa: ele nem sempre será utilizado e


mantido pelas mesmas pessoas que o construíram. Por esse motivo, é
necessário produzir uma documentação mínima.

Colaboração com o cliente mais que negociação de contratos

​ olaborar com o cliente significa que os times de desenvolvimento


C
devem trazê-lo para perto da equipe, compartilhando:

Como os processos são implementados.


Como o trabalho é executado.
Como ocorre o acompanhamento do andamento do projeto.
A quantidade de trabalho que a equipe pode executar.
Como as mudanças são gerenciadas.
Quais são os impactos causados por mudanças solicitadas
pelo cliente.
Os riscos identificados ao longo do projeto.
Dentre outras informações relevantes.

​ s equipes devem manter o cliente por perto e colaborar com ele,


A
assegurando a transparência em relação ao que transcorre no
desenvolvimento do produto. Como consequência, os clientes,
independentemente de serem internos ou externos, entenderão o que se
passa e certamente irão colaborar com o projeto.

​ relevante frisar que isso não significa que é necessário atender a


É
todos os desejos dos clientes, mas sim que devemos ser transparentes e
prestativos.

Vamos supor que a equipe está utilizando o framework Scrum e


que na reunião de planejamento da sprint, o Dono do Produto está tentando
influenciar o time durante a elaboração das estimativas. Conforme será
apresentado adiante, ninguém pode persuadi-los nessa atividade. Portanto,
o Scrum Master deve intervir e orientar que a estimativa é desenvolvida
pelo time e que somente eles podem opinar sobre a duração das atividades.

Quando estamos trabalhando com clientes externos, sempre existirá


um contrato informando as reponsabilidades de ambas as partes
(comprador e fornecedor). Logo, é comum a existência de cláusulas
informando como serão solucionados conflitos e quais punições serão
aplicadas no descumprimento de um item. Além disso, existem cláusulas
sobre disputas judiciais.

Todavia, devemos sempre buscar a colaboração entre as partes e


solucionar os problemas de forma amigável. Negociação no sentido de
impor clausulas punitivas ou ações judiciais deve ser a última alternativa a
ser aplicada. Essa recomendação não é sugerida apenas pelas metodologias
ágeis. O PMBOK®, no capítulo em que trata de aquisições, informa que,
em caso de divergências, deve-se procurar chegar a um acordo de forma
amigável. A disputa judicial deve ocorrer apenas em último caso, pois, isso
irá comprometer novos trabalhos futuros entre as partes.

Responder a mudanças mais que seguir um plano


O manifesto ágil esclarece que deve-se estar constantemente aberto
a mudanças, uma vez que as mesmas são inevitáveis em qualquer projeto.
Contudo, isso não significa que devemos simplesmente aceitá-las e
implementá-las.

Inicialmente, quando o cliente solicita uma mudança, é necessário


analisá-la para identificar os riscos e impactos aos quais o produto estará
sujeito, pois, ela pode ser rápida e simples ou, alternativamente, irá
proporcionar novos desafios para o desenvolvimento do produto.

Após à análise, é imprescindível expor o resultado do estudo aos


envolvidos, com o intuito de que decidam, de forma colaborativa, se a
mudança será implementada. Na hipótese de se optar pelo prosseguimento
da mudança, é realizado um planejamento e identificado o melhor
momento para a sua implementação. Caso ela seja urgente, de baixo
impacto e não afete o objetivo da iteração, poderá ser executada
imediatamente ou planejada para uma iteração futura.

Sempre que for preciso alterar o prazo, custo ou escopo de um


projeto resguardado por um contrato de prestação de serviços, antes de
aplicar a mudança, será imperativo renegociá-lo com o cliente.

Princípios

​ pós à apresentação dos valores que compõe o manifesto ágil, inicia-


A
se o momento de discorrer sobre os doze princípios que abarcam os pilares
das metodologias ágeis.

1. Nossa maior prioridade é satisfazer o cliente, através da


entrega adiantada e contínua de software de valor.

Quando se desenvolve um produto utilizando os métodos ágeis,


deve-se satisfazer os clientes, em curtos períodos, através de entregas
contínuas. Consequentemente, será entregue valor para o cliente que,
ao perceber constantemente a evolução de seu produto, ficará
satisfeito com o serviço prestado.

2. Aceitar mudanças de requisitos, mesmo no fim do


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

Ao praticar a agilidade é necessário estar acessível para acolher


mudanças, independentemente de se estar no início ou próximo ao
encerramento do projeto, pois, atualmente, mudar é inevitável.

É relevante frisar que alterações nos requisitos no início do


projeto são mais fáceis e rápidas de se implementar. Conforme o
projeto avança, as alterações ficam mais difíceis, demoradas e será
necessário despender maiores volumes de recursos financeiros.

Contudo, estar aberto a mudanças não significa que é preciso


implementar, imediatamente, todas as alterações solicitadas. Ao
receber um pedido de mudança, é indispensável analisá-lo, com o
intuito de identificar os riscos e impactos que serão causados.
Posteriormente, o resultado da análise é exposto para o cliente e
demais partes interessadas. Caso todos concordem, inicia-se o
planejamento para a implementação da mudança.

Além disso, quando existe um contrato de prestação de


serviços, deve-se averiguar se exigir-se-á uma alteração contratual,
devido à modificação no escopo, prazo ou custo em relação ao que foi
planejado originalmente.

Alternativamente, pode ser oferecida uma troca: verifica-se


com o cliente a possibilidade de remover do contrato alguma
funcionalidade prevista, cujo esforço seja semelhante ao da mudança
solicitada.

Portanto, é propiciado ao cliente a opção de remover do projeto


uma funcionalidade com baixa prioridade para acrescentar outra que
será mais importante e útil.

Isso é colaborar com o cliente!

3. Entregar software funcionando com frequência, na escala de


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

Um dos grandes pilares do desenvolvimento ágil consiste em


realizar entregas frequentes de versões funcionais do produto em
construção. Apesar de o princípio dizer que a entrega deva ocorrer na
escala de semanas a meses, quanto menor for o tempo, melhor.

Um dos motivos para entregar novas versões do software


funcionando com frequência consiste em prover valor para o cliente.
Conforme ele percebe que o seu produto está em constante evolução,
ficará satisfeito e irá colaborar cada vez mais com a equipe.
Adicionalmente, será propiciada a oportunidade de inspecionar e
testar o funcionamento do produto, identificando rapidamente erros a
serem corrigidos (que podem ser de requisitos ou de implementação).
Além do mais, quanto antes os mesmos forem identificados, melhor,
pois, dessa forma, menor será o esforço e o custo necessário para
corrigi-los.

Aliás, a cada entrega estaremos inspecionando os processos e


ferramentas utilizados, com o intuito de identificar pontos de
melhorias.

4. Pessoas relacionadas à negócios e desenvolvedores devem


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

Com o intuito de agilizar o desenvolvimento de um produto, é


imprescindível que tanto as pessoas relacionadas a negócio, quanto os
desenvolvedores trabalhem em conjunto e diariamente, durante todo o
projeto.

Por exemplo, suponha que, durante o andamento de uma


iteração, um membro do time de desenvolvimento tenha uma dúvida
de negócio sobre uma história a ser implementada. Como negócio e
desenvolvimento trabalham em conjunto, basta o desenvolvedor
procurar o Dono do Produto, esclarecer a sua dúvida e prosseguir com
o trabalho.

Caso contrário, se não houvesse colaboração e alguém de


negócio disponível, o desenvolvedor ficaria impedido de prosseguir
com seu trabalho, o que poderia acabar impedindo o time de cumprir
todas as metas acordadas no período.

Além disso, como estamos falando de metodologia ágil, é


importante frisar que as especificações de negócio não são elaboradas
apenas uma vez, no início do projeto, como é comum ocorrer ao
utilizar métodos tradicionais. Durante a iteração corrente, um membro
do time de negócio estará detalhando o que será construído na
próxima.

5. Construir projetos ao redor de indivíduos motivados. Dando a


eles o ambiente e suporte necessário, e confiar que farão seu
trabalho.

É importante que as equipes de desenvolvimento e de produtos


trabalhem em um ambiente motivador, tendo liberdade para auto
organizarem as suas atividades.

Além disso, é vital prover ao time todo o suporte necessário


para a realização de seu trabalho. Certamente os indivíduos
produzirão muito mais ao perceberem que os gestores confiam que
eles executarão as suas atividades com maestria e onde todo o suporte
lhes é prestado sempre que necessário.

De forma oposta, quando as equipes trabalham em um


ambiente controlador, burocrático e sem suporte, os indivíduos
ficarão desmotivados, produzirão somente o essencial e,
consequentemente, não se comprometem com o projeto.

6. O Método mais eficiente e eficaz de transmitir informações


para, e por dentro de um time de desenvolvimento, é através de
uma conversa cara a cara.

Atualmente as empresas dispõem de várias ferramentas que


permitem aos seus colaboradores se comunicarem local ou
remotamente. Dentre as várias tecnologias existentes, podemos citar o
e-mail, o telefone, as redes sociais e as web conferências.

Contudo, o método mais eficaz de transmitir informações entre


o time continua sendo através de uma boa conversa cara a cara. Isso
ocorre, pois, enquanto nos comunicamos, transmitimos sinais não-
verbais (gestos, postura, expressões faciais) e paralinguais (tom,
volume e velocidade da voz). Esses sinais não podem ser
completamente percebidos em uma iteração remota.

Ao se reunir em uma conferência telefônica, por exemplo, não


é possível avaliar as comunicações não verbal e paralingual dos
indivíduos e, em diversas situações, é difícil identificar
completamente a mensagem que o outro interlocutor deseja
transmitir.

Adicionalmente, quando as pessoas interagem entre si através


de conversas presenciais, elas constroem uma relação de confiança,
que fortalece o trabalho em equipe e, como resultado, passam a
colaborarem mais umas com as outras.

Portanto, sempre que possível, ao trabalhar em equipe, opte por


manter todos os seus membros em um mesmo local de trabalho e,
além disso, incentive que a comunicação seja realizada através de
uma boa conversa cara a cara.

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

Ao utilizar o desenvolvimento ágil, não se mede o progresso do


projeto calculando e informando a porcentagem concluída de uma
atividade, sem entregar nada para o cliente. O progresso é constatado
no final de cada iteração, através da entrega de valor para o cliente,
que irá perceber imediatamente o resultado do trabalho através da
utilização do produto.

Geralmente, em uma iteração, existem três situações a serem


atribuídas a uma atividade: pendente (ou a fazer), em andamento ou
finalizada. Independentemente de a tarefa estar 5% ou 95%
concluída, dizemos que a mesma está em andamento. A tarefa
somente será considerada finalizada quando estiver totalmente
concluída, sem pendências de desenvolvimento. Ao utilizar os
métodos ágeis, não existe o “praticamente pronto”.

Por esse motivo é importante que, ao decompor as atividades


durante o planejamento de uma iteração, seja possível quebrá-las em
partes menores, com duração máxima de um dia, pois, isso proverá
uma maior visibilidade de que o trabalho está evoluindo.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes
de manter indefinidamente, passos constantes.

Ao desenvolver um produto utilizando técnicas ágeis, é


necessário realizar entregas contínuas, em intervalos de tempo
predefinidos e curtos. Portanto, é valoroso manter um ritmo de
trabalho constante.

Para que seja possível manter a frequência, a equipe deve


definir e seguir alguns procedimentos que os auxiliarão durante a
execução do trabalho. Ao final de cada iteração, estes processos
podem ser revisados e melhorados. Os patrocinadores e clientes
devem apoiar o time para que seja promovido um ambiente
sustentável.

Equipes ágeis devem desenvolver produtos rapidamente e em


ritmo constante. Todavia, isso não significa que os patrocinadores e
usuários devam solicitar ao time para produzir mais do que é capaz.

Vamos supor que, em um determinado projeto, com o intuito


de entregar um produto mais rapidamente, é demandado ao time para
realizar horas extras e trabalhar aos finais de semana. Ou seja, está
sendo exigido que o time produza em um ritmo maior em relação a
sua capacidade. Ao contrário do que se imagina, essa atitude não será
benéfica para o projeto. O time acabará se desmotivando e os seus
membros trabalharão cansados. Consequentemente, produzirão
menos e o produto será de baixa qualidade.

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


a agilidade.

Ao desenvolver um produto, é importante prestar continuamente


atenção à excelência técnica e bom design. O produto deve possuir
qualidade e ser bem projetado, pois, dessa maneira, será propiciada a
agilidade.

A qualidade é muito importante no desenvolvimento de um


produto e nunca deve ser deixada de lado.
Vale destacar que excelência técnica não significa que deve-se
desenvolver produtos utilizando as últimas ferramentas e tecnologias
disponíveis, mas sim que o produto construído satisfaça os clientes.

Ao desenvolver um software utilizando uma arquitetura bem


projetada, aplicando as boas práticas de programação e executando
testes, ele possuirá qualidade. Assim sendo, em iterações futuras, será
mais rápido implementar mudanças, pois, o software foi bem
projetado.

10. Simplicidade: a arte de maximizar a quantidade de trabalho


que não precisou ser feito.

Ao utilizar o desenvolvimento ágil, o produto deve ser construído


na base da simplicidade.

Isso significa que:

O produto deve possuir apenas o que foi solicitado pelo


cliente. Nada mais, nada menos. O próprio guia PMBOK®
corrobora essa orientação. É inútil despender tempo construindo
funcionalidades que não serão utilizadas.

É preciso elaborar apenas documentos estritamente


necessários. Se o documento não tiver utilidade após o
encerramento do projeto, não deve ser escrito.

O produto precisa ser construído através de uma solução


simples, pois, dessa forma, é muito mais fácil e ágil aplicar
mudanças. Produtos elaborados com soluções complexas são
difíceis de manter.

11. As melhores arquiteturas, requisitos e designs emergem de


times auto-organizáveis.
Os membros de um time auto-organizável devem gerenciar as
suas atividades. A cada iteração, a equipe possui liberdade para se
organizar e decidir a melhor forma de executar o trabalho necessário
rumo ao atingimento das metas acordadas.

À medida que o time conquista a liberdade, existe uma


contrapartida: ele passa a ser responsável pelos resultados obtidos.
Como consequência, cada membro da equipe deve prover o seu
melhor, a fim de que o produto desenvolvido tenha qualidade e seja
bem construído.

Adicionalmente, o time, quando aprende a se auto-organizar,


passa a ser mais independente. Os indivíduos deixarão de aguardar
ordens de seus superiores e serão mais proativos. Como resultado,
produzirão muito mais.

12. Em intervalos regulares, o time reflete em como ficar mais


efetivo e então se ajustam e otimizam seu comportamento de
acordo.

No desenvolvimento ágil, o time deve refletir, em intervalos de


tempo regulares, sobre o que está indo bem e o que precisa ser
melhorado em seu trabalho. Geralmente a reflexão ocorre ao final de
cada iteração.

Após o time identificar os pontos a serem melhorados, eles


elaboram um plano de melhorias e as implementam a partir da
próxima iteração.

Dessa forma, ao aplicar a melhoria contínua, o time se torna


cada vez mais efetivo e ágil. A equipe está constantemente
inspecionando e adaptando o seu trabalho.
Capítulo 4
Introdução ao Framework Scrum
Neste capítulo será realizada uma introdução sobre o Framework
Scrum, conforme orientações do Guia Scrum 2017.

O Guia Scrum contém a definição e as regras do Scrum e foi


escrito por Ken Schwaber e Jeff Sutherland.

Breve História do Scrum

​ m 1986, Hirotaka Takeuchi e Ikujiro Nonaka, dois professores


E
universitários japoneses, publicaram um artigo intitulado “The New
Product Development Game” (O novo jogo para desenvolvimento de
produtos). O artigo foi publicado na “Harvard Business Review”.

Os professores citam que, na época, devido a um ritmo cada vez


mais acelerado e competitivo no mundo do desenvolvimento de novos
produtos, velocidade e flexibilidade era essencial. As empresas
perceberam que a velha abordagem utilizada para o desenvolvimento de
produtos, conhecida como em cascata ou sequencial, não dariam conta do
trabalho.

​ s professores Takeuchi e Nonaka analisaram algumas empresas


O
japonesas e americanas que utilizavam uma nova abordagem para o
desenvolvimento de produtos. As empresas analisadas foram: Fuji-Xerox,
Canon, Honda, NEC, Epson, Brother, 3M, Xerox e HP (Hewlett-Packard).
Essa nova abordagem de desenvolvimento permitia às empresas
desenvolver seus produtos com maior rapidez e flexibilidade. Os processos
eram sobrepostos, com equipes multifuncionais. Além disso, as equipes
possuíam autonomia e autoridade para tomar as suas próprias decisões.

Takeuchi e Nonaka compararam esse novo método de trabalho em


equipe com a formação Scrum, do Rugby. Segundo os autores, “a bola é
passada pelo time conforme ele avança, em unidade, pelo campo”. A
formação Scrum é utilizada durante o reinício do jogo, após à ocorrência
de uma penalidade.

Em 1993, Jeff Sutherland, até então vice-presidente de tecnologia


de uma empresa chamada Easel, fora incumbido para desenvolver, em um
prazo de seis meses, uma nova linha de produtos para um dos maiores
clientes da empresa. Jeff sabia que seria impossível construir os produtos
naquele tempo, utilizando a metodologia em cascata.
Portanto, ele e sua equipe leram centenas de livros e artigos,
procurando informações sobre métodos de organização e desenvolvimento
de produtos. Até que um de seus desenvolvedores lhe apresentou o artigo
dos professores Takeuchi e Nonaka.

Como Jeff Sutherland e seu time não tinham nada a perder,


resolveram experimentar a técnica informada no artigo. Funcionou. Eles
conseguiram desenvolver toda a linha de produtos, cumprindo o prazo
acordado, utilizando um orçamento abaixo do previsto e, adicionalmente, o
produto possuía menos erros em relação às entregas anteriores. Nesse
momento, ocorreu o nascimento do Scrum.

De 1993 em diante, Jeff Sutherland passou a se concentrar no


desenvolvimento do Scrum.

Em 1995 Ken Schwaber escreveu o artigo “Scrum Development


Process”, formalizando o Scrum pela primeira vez. Nesse mesmo ano, Ken
Schwaber e Jeff Sutherland apresentaram o artigo em uma conferência de
pesquisa, ocorrida em Austin, no Estado americano do Texas, chamada
OOPSLA (Object-Oriented Programming, Systems, Languages &
Applications), da Association for Computing Machinery.
No ano de 2010, Ken Schwaber e Jeff Sutherland publicaram a
primeira versão do Guia Scrum, que consiste em um documento que
contém a definição e as regras do Framework Scrum. O guia sofreu
atualizações e revisões nos anos de 2011, 2013, 2016 e a mais recente em
2017.
Atualmente Ken Schwaber é presidente fundador da Scrum.org,
uma organização focada em prover treinamentos, avaliações e
certificações em Scrum. Jeff Sutherland é CEO, principal consultor e
instrutor da Scrum Inc., uma organização cujo negócio basilar consiste em
prover treinamentos, consultoria e aconselhamento a empresas e
indivíduos.
Você pode baixar o guia Scrum gratuitamente no seguinte
endereço: http://www.scrumguides.org. O guia está disponível em inglês,
português e em 30 idiomas adicionais.
Definição do Scrum
​O Scrum é um framework dentro do qual as pessoas podem tratar e
resolver problemas complexos e adaptativos.
É importante reforçar que o Scrum é um Framework estrutural, e
não uma técnica, um processo ou uma metodologia.
O PMI define metodologia como sendo um sistema de práticas,
técnicas, procedimentos e regras utilizados pelas pessoas que trabalham
em uma disciplina. Ou seja, a metodologia é um modelo prescritivo, que
diz o que fazer e como proceder para realizar determinada atividade.
Ao contrário disso, um framework estrutural apresenta um caminho
a seguir. Todavia, ele não menciona como proceder. Dentro do framework
Scrum tem-se a liberdade para empregar as técnicas e os processos
desejados.
O Scrum é utilizado para desenvolver, entregar e manter produtos
complexos.
​Um produto complexo contém muitas regras e fluxos de negócios,
onde existem várias indefinições e riscos. Adicionalmente, durante o seu
desenvolvimento, são envolvidos diversos profissionais. Produtos com alta
complexidade costumam ser adaptativos, ou seja, podem sofrer constantes
mudanças durante o ciclo de desenvolvimento, uma vez que não é possível
prever com exatidão tudo o que deve ser feito ou pode vir a ocorrer.
O Scrum é um framework leve, uma vez que seu conteúdo é
enxuto. As suas regras, cerimônias, papéis e eventos são de simples
entendimento. Entretanto, é difícil dominar e aplicar o Scrum corretamente
e em sua totalidade, uma vez que deve ocorrer uma mudança na cultura da
organização. Além disso, os profissionais envolvidos precisarão aprender
um novo método de trabalho. Vale destacar que é difícil implementar
mudanças, pois, usualmente, os seres humanos são avessos às mesmas.
​O Scrum expõe a eficácia relativa de suas práticas de gerenciamento e
técnicas de trabalho, de modo que seja possível melhorar continuamente o
produto, o time e o ambiente profissional.
​O guia cita que o Scrum consiste em times que se associam a papéis,
eventos, artefatos e regras. É importante frisar que cada um dos
componentes que se encontram dentro do framework Scrum servem a um
fim específico e é essencial para o uso e sucesso do Scrum.
Uso do Scrum
A partir da versão 2017 do guia Scrum foi adicionada uma nova seção
chamada “Uso do Scrum”. Nessa seção, Jeff e Ken buscaram clarificar
sobre a utilização do Scrum.
Desde sua criação, o framework Scrum tem sido utilizado
extensivamente para:

Pesquisar e Identificar mercados viáveis, tecnologias e


funcionalidades de produtos;
Desenvolver produtos e melhorias;
Liberar produtos e melhorias frequentes, chegando a várias
vezes por dia;
Desenvolver e sustentar a Nuvem (online, segura, sob
demanda) e outros ambientes operacionais para uso de produtos;
Sustentar e renovar produtos.

O Scrum surgiu inicialmente para realizar o gerenciamento e


desenvolvimento de produtos de software, porém, atualmente, ele é
utilizado para:

Desenvolver software.
Desenvolver hardware.
Desenvolver software embarcado.
Desenvolver redes de funções interativas.
Desenvolver veículos autônomos.
Desenvolver produtos autônomos.
Projetos em escolas.
Projetos do Governo.
Projetos de Marketing.
Gerenciar a operação da organização.

Devemos nos lembrar que o Scrum é útil para o desenvolvimento


de produtos complexos e adaptativos, que estão em constante mudança.
Dessa forma, em algumas ocasiões, não é recomendável a
utilização do Scrum. A construção civil, por exemplo, é uma dessas
situações. Ao construir um prédio residencial, certamente será necessário
efetuar o planejamento completo do projeto antes do início da construção.
Caso contrário, como proceder ao identificar uma mudança no
projeto, em uma iteração futura, quando já estiver sendo construído o
terceiro ou quarto andar do edifício? Seria necessário demolir tudo e
iniciar novamente? Essa não parece ser uma opção prudente. Nesse caso, é
recomendável utilizar uma abordagem tradicional.
Ao contrário disso, o Scrum passaria a ser uma excelente opção
durante o desenvolvimento de um novo carro a ser lançado. O time do
projeto pode planejar as etapas de desenvolvimento do automóvel em
sprints e realizar entregas em curtos períodos.
Jeff Sutherland, em seu livro Scrum: a arte de fazer o dobro do
trabalho na metade no tempo cita o exemplo de uma empresa chamada
Wikispeed, que utiliza o Scrum para elaborar seus automóveis, que são
construídos de forma artesanal. Segundo Jeff, eles constroem um carro em
três semanas, ao preço de US$ 25.000,00. O carro faz mais de 40
quilômetros por litro e recebeu nota máxima no crash test.
Existem inclusive organizações que utilizam o Scrum para
gerenciar as suas operações.
Devido à versão 2017 do Guia Scrum ser destinada ao
gerenciamento do trabalho de produtos complexos, quando você ler os
termos “desenvolver” e “desenvolvimento”, considere que eles se referem
às atividades a serem executadas, independentemente de ser um software
ou outro produto qualquer.
Por exemplo, em um projeto de marketing: quando o guia se refere
a “time de desenvolvimento”, ele não está mencionando uma equipe de
desenvolvedores de software, e sim os profissionais da área de marketing
que estão concebendo um novo produto ou serviço.
Capítulo 5
Teoria do Scrum
​ Scrum é fundamentado nas teorias empíricas de controle de
O
processo, ou empirismo.
​O empirismo consiste em uma teoria segundo a qual todo o
conhecimento provém unicamente de nossa experiência. Dessa forma,
tomamos decisões baseando-nos em nossas percepções e vivências
passadas. Adicionalmente, pode-se obter novas ideias a partir de
observações e experimentos.
​A fim de aperfeiçoar a previsibilidade e o controle de riscos, o Scrum
emprega a abordagem iterativa e incremental, que ocorre quando estamos
desenvolvendo o produto através de iterações (repetições). Quando se
chega ao final de cada repetição, entregamos ao cliente uma nova parte (ou
funcionalidade) do produto. Dessa forma, a cada ciclo o produto será
incrementado.
A vantagem dessa abordagem consiste em que, ao final de cada
ciclo, o cliente pode validar o que foi desenvolvido até o momento. Caso
seja identificado um problema ou a necessidade de uma mudança, pode-se
realizar a implementação mais rapidamente e a um menor custo, mitigando
os riscos.
Se o produto fosse desenvolvido através da abordagem em cascata,
ele estaria disponível para validação apenas ao final do projeto e, em caso
de problemas, seria mais caro e custoso corrigi-los.
​O controle de processo empírico é apoiado por três pilares, que são:

Transparência
Inspeção
Adaptação

Transparência
​O guia Scrum (2017) define transparência da seguinte forma:
“Aspectos significativos do processo devem estar visíveis aos responsáveis
pelos resultados. A transparência requer que estes aspectos tenham uma
definição padrão comum para que os observadores compartilharem um
mesmo entendimento comum do que está sendo visto.”
Ao utilizar o Scrum, fica evidente que é vital manter a
transparência em relação a tudo que ocorre no projeto, tanto para membros
do time quanto para pessoas externas. Consequentemente, não é permitido
omitir informações acerca dos trabalhos executados.
Como manter a transparência? Assegurando que os aspectos mais
significativos dos processos utilizados para o desenvolvimento do produto
sejam conhecidos e entendidos por todos, a fim de que possuam uma
compreensão comum do que ocorre no projeto.

Exemplos sobre transparência:

Todos os participantes devem entender o processo que está


sendo utilizado para o desenvolvimento do produto.
Tanto o time que executa o trabalho, quanto os indivíduos
que irão inspecionar o incremento do produto devem
compartilhar uma mesma definição de pronto, ou seja, todos
compreendem quando é possível assegurar que a atividade foi
finalizada.
Comunicar diariamente o andamento dos trabalhos e se há
impedimentos.
Manter o quadro de tarefas atualizado para que todos os
interessados visualizem o andamento da Sprint.
O Dono do Produto descreve as funcionalidades esperadas e
deixa claro a priorização das entregas.

Inspeção
Definição de inspeção, segundo o guia Scrum:
“Os usuários Scrum devem, frequentemente, inspecionar os
artefatos Scrum e o progresso em direção ao objetivo da Sprint para
detectar variações indesejadas. Esta inspeção não deve ser tão frequente
que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas
quando realizadas de forma diligente por inspetores especializados no
trabalho a se verificar.”
Conforme o guia Scrum, o time deve inspecionar:

O incremento em desenvolvimento, com o intuito de


constatar que o produto seja entregue sem problemas, com
qualidade, atendendo aos requisitos, etc.
O backlog do produto e da Sprint, a fim de assegurar que os
requisitos estão corretos e que os prioritários possuam um nível
adequado de detalhamento.
Todo o processo utilizado para o desenvolvimento do
produto, com a intenção de identificar problemas que ocorrem na
equipe e possíveis melhorias.

Vale ressaltar que nem sempre é possível solucionar imediatamente


todos os problemas. Contudo, é importante que a equipe tenha ciência dos
mesmos, com a intenção de solucioná-los futuramente.
Seguem dois itens importantes a serem considerados:

As inspeções devem ocorrer com frequência, porém não


podem ser tão constantes a ponto de atrapalhar o andamento dos
trabalhos, ou seja, não pode prejudicar o desenvolvimento do
produto.
A inspeção pode gerar mais benefícios caso a mesma seja
efetuada por inspetores especializados.

Adaptação
Definição do guia Scrum para Adaptação:
“Se um inspetor determina que um ou mais aspectos de um
processo desviou para fora dos limites aceitáveis, e que o resultado do
produto será inaceitável, o processo ou o material sendo produzido deve
ser ajustado. O ajuste deve ser realizado o mais breve possível para
minimizar mais desvios.”
Em concordância com o que já foi exposto, a inspeção visa
identificar problemas e melhorias a serem aplicadas nos processos
empregados pelo time durante o desenvolvimento do produto.
Caso seja comprovado um desvio no processo para fora dos limites
aceitáveis, o time deve ajustá-lo o mais rapidamente possível, com intuito
de evitar a ocorrência de novos deslizes.
Além disso, quando o desvio do processo venha a impactar o
produto em desenvolvimento, o mesmo também deve ser ajustado antes de
ser entregue ao cliente.
O Framework Scrum prescreve quatro eventos formais onde
devemos inspecionar e adaptar. São eles:

Planejamento da Sprint.
Reunião diária.
Revisão da Sprint.
Retrospectiva da Sprint.

Valores do Scrum
​O guia apresenta 5 valores que devem ser incorporados e vividos pelos
membros do Time Scrum. São eles:

Comprometimento — Os membros do time Scrum se


comprometem em alcançar os objetivos definidos.
Coragem — O Time Scrum necessita de coragem para fazer
a coisa certa e trabalhar em problemas difíceis.
Foco — Todos devem focar no trabalho da Sprint e nos
objetivos do Time Scrum.
Abertura — O Time Scrum e seus stakeholders concordam
em estarem abertos ao trabalho e aos desafios a serem superados.
Respeito — Os membros do Time Scrum respeitam uns aos
outros para serem pessoas capazes e independentes.

Quando os cinco valores acima são incorporados e vividos pelo Time


Scrum, os pilares de Transparência, Inspeção e Adaptação tornam-se vivos
e constroem a confiança para todos.
Capítulo 6
Introdução ao Framework Scrum
Time Scrum
O Time Scrum é composto pelos seguintes papéis:

O Time de Desenvolvimento, que é composto pelos


profissionais que transformam os itens do backlog em
incrementos do produto. O ideal é que o Time de
Desenvolvimento seja composto por no mínimo 3 e no máximo
9 integrantes.
O Dono do Produto é o profissional que possui
conhecimentos em negócio. Sua principal atribuição é
maximizar o valor do produto e o trabalho do Time de
Desenvolvimento.
O Scrum Master é o profissional responsável por promover
e suportar o Scrum, conforme está definido no guia Scrum.
Podemos considerá-lo como sendo o “técnico” do Time Scrum.

Os Times Scrum são:

Auto-Organizáveis: Estão aptos a decidirem pela melhor


maneira de completarem o seu trabalho, em vez de serem
dirigidos por outros que estão fora do time.
Multifuncionais: Possuem todas as competências
necessárias para completar o seu trabalho sem dependerem de
outras pessoas que não fazem parte da equipe.

Os Times Scrum são responsáveis por entregar produtos de forma


iterativa e incremental, com o intuito de maximizar as oportunidades de
feedback. Isso significa que o desenvolvimento do produto ocorre em
curtos períodos.
É importante ressaltar que, ao final de cada iteração, deve-se possuir
um incremento do produto potencialmente pronto para entrega.
No Scrum, cada uma dessas iterações é chamada de Sprint.

Eventos do Scrum
O Scrum utiliza eventos prescritos com o intuito de:

Criar uma regularidade — Como a Sprint possui duração fixa


e os demais eventos são time-boxed, é criada uma regularidade e
o time adquire prática em relação ao framework. Assim que uma
Sprint finaliza, inicia-se a próxima, e assim sucessivamente, até
o encerramento do projeto. Vale ressaltar que, em cada iteração,
deve-se executar todos os eventos exigidos pelo Scrum.
Minimizar a necessidade de agendar reuniões que não sejam
definidas pelo framework, uma vez que o Scrum prevê um
número mínimo de encontros, que são necessários para assegurar
ao time que irão executar as atividades de planejamento,
adaptação e inspeção.

Todos os eventos do Scrum são Time-Boxed, ou seja, eles possuem


uma duração máxima para conclusão. Por exemplo, o time-box da reunião
diária é de 15 minutos, ou seja, o seu tempo não pode exceder os 15
minutos.

O Scrum prescreve cinco eventos:

Sprint — É o container de todos os outros eventos Scrum. É


dentro dela que ocorre o esforço para o desenvolvimento do
produto. A Sprint é um evento time-boxed com no máximo 30
dias de duração.
Planejamento da Sprint — É o primeiro evento que ocorre
em uma Sprint, onde o Time Scrum planeja o que será
construído na iteração e como realizarão a entrega do
incremento. Este evento possui o time-box de no máximo oito
horas para uma Sprint de um mês de duração. Em Sprints
menores, este evento é usualmente menor.
Reunião Diária (Daily Scrum) — Esse evento, que possui o
time-box de 15 minutos, é realizado diariamente pelo Time de
Desenvolvimento, com o objetivo principal de planejar o
trabalho a ser executado nas próximas 24 horas.
Revisão da Sprint — Ocorre ao final da Sprint, com o
objetivo de apresentar, ao Dono do Produto e demais
convidados, o incremento do produto desenvolvido e obter
feedback. Este é um evento time-boxed com 4 horas de duração
para uma Sprint mensal. Em Sprints menores, o evento
usualmente é menor.
Retrospectiva da Sprint — Ocorre após à revisão da Sprint.
É o momento onde o Time Scrum irá discutir as lições
aprendidas durante a iteração e criará um plano de melhorias.
Esse evento possui 3 horas de duração para uma Sprint de um
mês. Em Sprints menores, é comum que a duração do evento
seja menor.
Fonte: Scrum.org.
Artefatos do Scrum
Para finalizar essa pequena introdução, serão apresentados os artefatos
do Scrum, que representam o trabalho a ser executado. Além disso, eles
fornecem transparência em relação ao que está sendo produzido ou
entregue e oferecem oportunidades para a realização de inspeção e
adaptação.
São considerados artefatos do Scrum:

Backlog do Produto — Consiste em uma lista ordenada que


contém tudo o que é conhecido ser necessário no produto. É a
única fonte de requisitos para qualquer mudança a ser aplicada.
O Dono do Produto é o responsável pelo Backlog do Produto,
incluindo todo o seu conteúdo, disponibilidade e ordenação.
Backlog da Sprint — Contém os itens do Backlog do
Produto que foram selecionados para a Sprint. Adicionalmente,
ele contém um plano a ser utilizado para entregar o incremento
do produto e atingir os objetivos da Sprint. O Backlog da Sprint
é gerenciado e mantido pelo Time de Desenvolvimento.
Incremento — É a soma de todos os itens do Backlog do
Produto que foram finalizados na Sprint atual com os demais que
foram completados em iterações anteriores.

Muitas decisões em relação ao andamento do projeto são baseadas em


análises dos artefatos do Scrum e, por esse motivo, é importante que eles
sejam completamente transparentes. Se não houver a transparência, as
decisões poderão ser falhas. Adicionalmente, pode ocorrer a diminuição
dos valores e o aumento dos riscos do projeto.
Com o intuito de manter a transparência, deve-se elaborar a Definição
de “Pronto”, que consiste em um entendimento comum sobre o significado
de quando um trabalho pode ser considerado completo.
Capítulo 7
Introdução ao Backlog do Produto
Conforme consta no Guia Scrum, o Backlog do Produto consiste
em uma lista ordenada que contém as características, funções, requisitos,
melhorias e correções que serão transformadas em incrementos durante as
iterações. Ou seja, representa o produto final que deverá ser entregue após
à conclusão do projeto. O Backlog do Produto deve ser a única fonte de
requisitos para qualquer alteração a ser aplicada no produto.
O Dono do Produto é o responsável pelo Backlog do Produto, o
que inclui gerenciar e ordenar o seu conteúdo, além de mantê-lo disponível
a todos os interessados.
O Backlog do Produto muda constantemente, com o intuito de
identificar todas as características do produto que são necessárias para
torná-lo mais apropriado, competitivo e útil. Enquanto um produto existir,
seu Backlog de Produto também existirá.
Principais características de um Backlog do Produto
Roman Pichler e Mike Cohn (autores e especialistas em Scrum)
criaram o acrônimo DEEP, com o intuito de descrever quais são as
principais características que tornam um Backlog do Produto valoroso. O
acrônimo significa:
Detalhado apropriadamente (D)
Conforme consta no Guia Scrum, os itens do topo do Backlog do
Produto devem possuir um maior detalhamento em relação aos itens de
ordem mais baixa. Isso ocorre porque os itens posicionados na faixa
superior do Backlog estão prestes a serem desenvolvidos em uma Sprint e,
consequentemente, os mesmos necessitam possuir um nível de detalhe que
permita ao Time de Desenvolvimento construí-los.
Já os itens menos prioritários possuem um nível de detalhamento menor,
uma vez que os mesmos serão construídos a médio ou longo prazo e,
durante esse período, eles podem sofrerem alterações, ficarem obsoletos
ou serem repriorizados.
Emergente (E)
O Backlog do Produto é dinâmico e, por esse motivo, nunca estará
completo. Ele evolui conforme o produto e o ambiente no qual ele será
utilizado progride. Durante o desenvolvimento de um produto, novos
requisitos são identificados, problemas podem aparecer, ou requisitos
atualmente existentes tornam-se obsoletos, devido a mudanças no negócio,
nas condições de mercado ou tecnologia.
Estimado (E)
Os itens do Backlog do Produto precisam ser estimados. Isso
ocorre, pois, as estimativas irão auxiliar o Dono do Produto a:
Priorizar o Backlog do Produto.
Realizar o Planejamento das Releases.
Monitorar o progresso rumo ao atingimento dos objetivos.

Contudo, esteja ciente que as estimativas dos itens prioritários


serão mais precisas em detrimento aos demais, pois eles possuem um
maior nível de detalhamento.
Priorizado (P)
Os itens do Backlog do Produto devem ser priorizados e ordenados
corretamente. Os requisitos mais importantes para o negócio e que
agregam maior valor ficam posicionados no topo, enquanto os de menor
importância ficarão no final do backlog.
O Dono do Produto, ao priorizar os itens do backlog, pode
considerar:

O valor do retorno do investimento realizado.


As necessidades dos clientes.
As dependências existentes entre os itens de backlog.
Os riscos para o projeto.
Qualquer outro motivo que o Dono do Produto julgue
importante.

Priorize e construa apenas os itens do Backlog que agregam maior


valor para o negócio
O princípio de Pareto (também conhecido como regra do 80/20)
nos diz que, dentre muitos eventos, por volta de 80% dos efeitos originam-
se de apenas 20% das causas.
Essa mesma regra pode ser aplicada ao desenvolvimento de um
produto: normalmente, 80% do valor gerado provem de apenas 20% de
suas funcionalidades. Dessa forma, de modo a evitar desperdício de tempo
e de recursos, o Dono do Produto deve priorizar para o desenvolvimento
os 20% dos itens de backlog que irão agregar maior valor para o negócio.
Existem várias técnicas que auxiliam o Dono do Produto a priorizar
o backlog e, dentre elas, podemos citar a análise MoSCoW, que é de
propriedade do framework Dynamic Systems Developent Method
(DSDM).
Ao utilizar essa técnica, o Dono do Produto deve representar os
itens de backlog como sendo:

Must Have — Os itens de backlog com essa classificação


são imprescindíveis para o produto em desenvolvimento. Sendo
assim, caso uma dessas funcionalidades não faça parte do
produto, ele perderá o seu propósito. Esses itens devem ser
desenvolvidos durante as primeiras Sprints do projeto.
Should Have — As funcionalidades que recebem essa
categorização são importantes para o cliente, porém, não são
vitais para o negócio.
Could Have — São os itens de backlog que os stakeholders
gostariam que fizessem parte do produto, mas que não são
importantes para o negócio.
Won’t Have — Finalizando, os itens que recebem essa
classificação não agregam nenhum valor para o negócio no
momento atual e não devem ser desenvolvidos.

É importante dizer que, conforme o projeto vai sendo executado e


os requisitos vão sendo melhor compreendidos, um item do Backlog do
Produto pode mudar de classificação. Por exemplo, um item que não fazia
sentido e estava classificado como Won’t Have, eventualmente pode ter
sido reclassificado como Should Have devido a uma mudança no mercado.
Para finalizar, é relevante frisar que o Dono do Produto possui uma
enorme responsabilidade ao gerenciar e priorizar corretamente o backlog,
pois, caso contrário, o produto desenvolvido pode não atender às
necessidades dos Stackholders e, portanto, não irá agregar valor para o
negócio.
Capítulo 8
Histórias de Usuário
A história de usuário é a técnica mais utilizada para descrever
requisitos ao se trabalhar com métodos ágeis. Ela é composta por uma
breve descrição sobre determinada funcionalidade, que irá atender à
necessidade de um indivíduo, que pode ser um cliente, usuário do sistema,
stakeholder, etc.
Os 3 C’s — Cartão, Conversação e Confirmação
Jeffries (2001) ensina que as histórias são compostas por três aspectos
críticos, também conhecidos como 3 C’s.
Cartão
A história de usuário é descrita em um cartão, e consiste em um
pequeno texto que identifica o requisito a ser desenvolvido. É importante
destacar que a história de usuário não contém todos os detalhes de um
requisito, e visa apenas lembrar ao time que é necessário discutir sobre o
assunto.
Conversação
O Dono do Produto irá apresentar os detalhes de uma história de
usuário para o Time de Desenvolvimento através de uma conversa, onde
todos podem expor as suas opiniões e sentimentos.
Tenha em mente que podem ocorrer várias conversas referentes a uma
história de usuário, pois, conforme os requisitos forem melhor
compreendidos, eles serão mais detalhados.
Por exemplo, uma mesma história pode ser discutida nos seguintes
momentos:

Durante sua criação.


No refinamento dos requisitos.
No planejamento da Sprint.
Ao longo do andamento de uma Sprint.

Jeffries deixa claro que, caso necessário, as conversas podem ser


complementadas com um documento. Vamos supor que a história tenha
uma regra de negócio com um cálculo complexo. Nessa situação, é
pertinente escrever um documento descrevendo as regras e fórmulas para a
realização desse cálculo.
Confirmação
Para finalizar, são definidos alguns critérios que permitem a
confirmação de uma história de usuário. Esses critérios são conhecidos
como testes de aceitação, e costumam ser descritos na parte de trás do
cartão. O desenvolvimento de uma história de usuário somente será
considerado finalizado quando todos os testes de aceitação tiverem sido
executados com sucesso.
Características fundamentais de uma História de Usuário
Quando estamos desenvolvendo uma história de usuário, a fim de
que a mesma tenha qualidade, ela deve possuir as seguintes características,
que são representadas pelo acrônimo INVEST:
Independente
Sempre que possível, as histórias de usuário devem ser
independentes umas das outras, de modo que o Dono do Produto possa
ordená-las, planejá-las e implementá-las segundo o valor que cada uma
delas agrega para o negócio.
Negociável
Conforme foi relatado anteriormente, a história de usuário não
contém muitos detalhes. Sendo assim, ela deve ser descrita em um nível
que permita ao Time Scrum e Stakeholders realizarem conversas, com o
intuito de entenderem o que deve ser construído.
Uma história não é um contrato a ser seguido, e sim um lembrete
para que ocorra uma conversação entre os envolvidos.
Valorosa
Para evitar desperdício de tempo e recurso, o Dono do Produto
deve priorizar os itens de backlog que irão agregar valor para o negócio.
Os demais ficam para depois ou, caso se tornem desnecessários, devem ser
descartados.
Estimável
É muito importante que seja possível ao Time de Desenvolvimento
avaliar o esforço de uma história de usuário, mesmo que a estimativa seja
de baixa precisão, pois ela possibilita ao Dono do Produto:

Priorizar o backlog do Produto.


Estimar custos.
Planejar entregas.
Dentre outras atividades.

Quando o Time de Desenvolvimento não consegue estimar uma


história, isso pode indicar que:

O seu tamanho é muito grande.


As informações são insuficientes.
O seu conteúdo é ambíguo.
O time não domina a tecnologia utilizada.

“Small” (Pequena)
As Histórias de Usuário devem ser pequenas, ou seja, necessitam
possuir um tamanho máximo que as permitam serem desenvolvidas dentro
de uma única Sprint.
Testável
É muito importante que as Histórias de Usuário possam ser
testadas, para que seja possível assegurar que o produto obtido ao final do
desenvolvimento esteja de acordo com o que foi definido, sem a existência
de erros.
Temas
As histórias de usuário podem ser agrupadas por temas
relacionados. Por exemplo, ao construir um novo site de comércio
eletrônico, as histórias poderiam ser agrupadas nos seguintes temas:
produtos, clientes, fornecedores, pagamento, recebimento, vendas,
relatórios, entre outros.
Construindo Histórias de Usuário
As histórias de usuário costumam ser descritas em um pequeno cartão,
e seu formato mais comum é:

Vamos supor que estamos desenvolvendo um site de comércio


eletrônico, e o Dono do Produto irá descrever as formas de pagamento
disponíveis para o cliente. Sendo assim, a história de usuário poderia ser:
Em sua opinião, essa história atende a todos os critérios do acrônimo
INVEST?
O Time de Desenvolvimento, ao analisar a história, ficará com muitas
dúvidas, tais como:

Quais formas de pagamento serão disponibilizadas? Boleto,


Cartão, Depósito, Dinheiro?
Se for Cartão, seria Débito, Crédito ou ambos?
Se for Débito, de quais bancos iremos aceitar?
Se for Crédito, quais bandeiras?
Podemos aceitar compras parceladas?
Entre outras dúvidas.

Conforme pode-se atestar, a história está descrita em um nível macro


de detalhamento e, por esse motivo, a chamamos de Épico.
Vale ressaltar que é difícil estimar e compreender um épico, pois ele
ainda não está detalhado o suficiente para ser desenvolvido. Dessa forma,
quando estiver chegando o momento de priorizá-lo para uma Sprint, o
Dono do Produto deve refiná-lo, quebrando-o em histórias menores e mais
detalhadas, conforme pode-se verificar na imagem abaixo.
O épico foi decomposto em seis histórias menores, que atendem a
praticamente todos os critérios do INVEST: São independentes,
negociáveis, valorosas, estimáveis e pequenas.
Entretanto, podemos considerá-las testáveis? Quais testes serão
realizados pelo Dono do Produto a fim de considerar essas histórias
prontas?
Como pode-se perceber, ainda não é possível identificar quais critérios
de aceite serão considerados pelo Dono do Produto de modo a assegurar
que, ao final da iteração, a história foi desenvolvida com sucesso.
Usualmente, o critério de aceite é descrito no verso do cartão,
conforme exemplo abaixo.

Assim que ocorre a definição do critério de aceite, o Time de


Desenvolvimento sabe o que deve construir e como o Dono do Produto irá
validar se a história foi finalizada com sucesso, ou não.

Vale destacar que o critério de aceite complementa o detalhamento dos


requisitos. Além disso, é comum que o Time de Desenvolvimento
automatize a execução dos testes que validarão esses critérios.
Para finalizar, tenha em mente que é permitido ao Dono do Produto
adicionar à história referência a um ou mais documentos, com o intuito de
aprimorar o entendimento de um requisito importante.
Por exemplo, na história “Pagamento - Cartão de Crédito - Bandeira
A”, o Dono do Produto pode referenciar um documento que conterá as
regras utilizadas para validar o número do cartão e identificar a sua
bandeira.
Conclusão
A História de Usuário é uma excelente técnica para descrever os
requisitos de um produto, porém, a sua utilização nem sempre é
recomendável.
Por exemplo, quando um item de backlog descrever um defeito, não
faz sentido escrevê-lo utilizando o formato de história de usuário. Nessa
situação é preferível que o item informe uma breve descrição do defeito.
Capítulo 9
O Planejamento no Scrum
Dentre as justificativas citadas por profissionais que não são adeptos ao
Scrum, podemos destacar que, segundo eles, não existe planejamento ao
utilizar este framework. Dessa forma, o produto vai sendo desenvolvido
sem o conhecimento de onde se pretende chegar. Entretanto, a afirmação é
falsa. Muitos chegam a essa conclusão porque o Guia Scrum fornece
apenas algumas diretrizes e regras, mas não orienta sobre como
implementá-las.
O guia Scrum informa que as principais responsabilidades do Dono do
Produto consistem em gerenciar o backlog do produto, maximizar o valor
resultante do trabalho do Time de Desenvolvimento e informar o que deve
ser feito a seguir.
Ou seja, o Dono do Produto planeja o trabalho a ser executado, afinal,
nenhuma empresa irá investir recursos sem possuir ao menos uma ideia
sobre o que será desenvolvido, quanto será gasto e quando o produto estará
disponível.
Contudo, grande parte dos profissionais não sabe como é realizado
esse planejamento, pois é comum que eles se preparem apenas para as
certificações mais básicas, focadas no papel do Scrum Master. Existem
também aqueles que apenas leem o Guia Scrum e, dessa forma, conhecem
apenas o essencial sobre o framework. Usualmente o profissional costuma
se aprimorar em relação a planejamento no Scrum quando se prepara para
obter uma certificação voltada ao papel do Dono do Produto como, por
exemplo, a Professional Scrum Product Owner Nível I (PSPO-I).
Ao utilizar o planejamento ágil, todos devem estar cientes que o plano
é uma previsão e, consequentemente, pode sofrer alterações.
O planejamento inicia-se definindo a visão, que irá conter informações
que atestam a imprescindibilidade do produto a ser construído.
Usualmente, a visão do produto informa:

O seu público-alvo.
As necessidades que devem ser atendidas.
O valor que o produto irá propiciar à empresa ou aos
clientes.

Uma vez definida a visão, todo o Time Scrum deve levá-la em


consideração durante a construção do produto.
Posteriormente, pode ser elaborado o Roadmap do Produto, que
consiste em um roteiro que irá orientar sobre o que deverá ser
desenvolvido ao longo do tempo, onde será identificado(a):
A estratégia a ser seguida para o desenvolvimento do
produto.
Como proceder a fim de entregar valor antecipadamente.
Uma previsão do que será entregue em cada versão.

Para exemplificar: O produto XYZ será desenvolvido no período de


um ano, com a estratégia de liberação de uma nova versão a cada três
meses. As entregas irão ocorrer na última semana dos meses de março,
junho, setembro e dezembro. Ademais, o Roadmap do Produto XYZ pode
conter uma previsão macro do que será entregue em cada versão e
comumente é apresentado em um formato visual.
O Dono do Produto inicia a elaboração do backlog do produto,
baseando-se na visão definida.
Após à concepção dos itens de backlog conhecidos até o momento,
deve-se estimá-los previamente. Lembre-se: os itens do topo do backlog
do produto, que são prioritários, possuem mais detalhamento em relação
aos inferiores. Consequentemente, as suas estimativas são mais precisas.
A seguir, inicia-se o planejamento das releases, que é o momento de
idealizar os itens de backlog a serem entregues em cada versão.
Prosseguindo com o exemplo, o Time Scrum definiu que o projeto
XYZ será composto por iterações de 30 dias. Adicionalmente,
estabeleceram que cada release durará 3 meses, ou seja, será composta por
3 Sprints.
Posteriormente, o Dono do Produto prevê o que será entregue em cada
Sprint e, consequentemente, as funcionalidades a serem disponibilizadas
em cada liberação (release). Essa previsão é possível, pois, o Time de
Desenvolvimento elaborou uma estimativa macro de todos os itens de
backlog. Adicionalmente, o Dono do Produto baseia-se na velocidade do
Time de Desenvolvimento para avaliar a quantidade de itens a serem
construídos em cada Sprint.

Agora que possuímos a visão do produto, definimos o roadmap e


planejamos as liberações (releases), será que finalizamos o planejamento?
A resposta é não.
Em seguida, a cada iteração, é realizado o planejamento da Sprint, que
é o momento onde o Time Scrum se reúne para planejar o que irá
desenvolver na Sprint. Nesse instante, os itens do topo do Backlog do
Produto estarão mais detalhados e, consequentemente, a previsão do que
será entregue ao final da iteração será mais assertiva.
Além disso, ao desenvolver um produto complexo em um ambiente
empírico, tenha em mente que existem grandes chances de que ocorram
modificações nos itens de backlog previstos para as iterações. Sendo
assim, durante o planejamento de cada Sprint, o Dono do Produto deve
revisar o plano da release.
Para finalizar, ao longo da Sprint, os membros do Time de
Desenvolvimento se reúnem diariamente, em um evento conhecido como
Reunião Diária, que é o momento de planejar o que será realizado nas
próximas 24 horas e inspecionar o progresso em direção ao objetivo da
Sprint.
Todos esses níveis de planejamento são conhecidos como Planning
Onion, uma vez que, ao observar a imagem abaixo, você perceberá que o
processo se assemelha às camadas de uma cebola.

Conforme pode-se constatar, ao contrário do que muitos dizem,


quando se utiliza o Scrum, é realizado muito planejamento.
Capítulo 10
Principais técnicas de estimativas
empregadas no Scrum
O Guia Scrum diz que os itens do Backlog do Produto possuem os
atributos de descrição, ordem, estimativas e valor. Além disso, apenas os
membros do Time de Desenvolvimento são responsáveis por realizar as
estimativas. Sendo assim, qual técnica de estimativa deve ser utilizada ao
se implementar o Scrum?
Ao ler o Guia Scrum é possível perceber que, em nenhum momento, é
citada a obrigatoriedade da utilização de uma técnica específica para a
realização de estimativas. Dessa forma, é permitido ao Time de
Desenvolvimento definir como irá estimar os itens do Backlog do Produto.
Entretanto, as técnicas mais utilizadas são pontos por história e horas
ideais.
Contudo, antes de prosseguir, vale ressaltar que, ao utilizar o Scrum,
desenvolve-se um produto complexo, em um ambiente empírico, com
muitas incertezas. Portanto, as estimativas consistem em uma
probabilidade de concluir o trabalho em um determinado período.
Consequentemente, o Time de Desenvolvimento, ao estimar um item, não
se compromete em entregar o trabalho pronto ao final do período, pois,
muitos fatores (internos e externos) podem influenciar o tempo de
desenvolvimento do produto.
Além disso, pode ser solicitado ao Time de Desenvolvimento para
estimar um mesmo item do Backlog do Produto em diferentes momentos.
Quando o item está no final do Backlog do Produto, possuirá menos
detalhes e, consequentemente, sua estimativa estará em um nível macro.
Posteriormente, quando o Dono do Produto já tiver preparado o item para
ser desenvolvido na próxima Sprint, o seu nível de detalhamento será
maior e, consequentemente, a sua estimativa será mais precisa.
Por esse motivo, caso a empresa opte pela adoção do Scrum, é
importante que todos os Stakeholders estejam cientes que as estimativas
devem ser consideradas apenas uma previsão, e não um compromisso de
entrega.
A partir desse momento será realizada uma breve explanação sobre as
principais técnicas de estimativa utilizadas em projetos que adotam o
Scrum.
Pontos por História.
A História de Usuário é a técnica mais utilizada para descrever
requisitos quando adotamos o Scrum. Consequentemente, a estimativa
dessas histórias costuma ser realizada através de uma técnica relativa,
conhecida como Pontos por História (Story Points).
As técnicas relativas comparam o tamanho entre dois ou mais itens, ao
invés de estimar o esforço total necessário para realizar uma determinada
atividade. Por exemplo, quando solicitamos um copo de refrigerante em
uma lanchonete, podemos optar por um copo pequeno, médio ou grande.
Ao comprar uma camisa, pode-se escolhê-la pelo seu tamanho relativo: P,
M, G, GG ou XGG.
Da mesma maneira, estimamos uma história de usuário através da
técnica de pontos, onde se compara o tamanho de duas ou mais histórias,
considerando: a medida relativa de esforço, a sua complexidade e o risco
envolvido no desenvolvimento.
Ao estimar utilizando esta técnica, as histórias de usuário recebem uma
determinada quantidade de pontos, baseando-se em seu tamanho relativo.
Usualmente, é utilizada a seguinte estrutura de pontos para identificar o
tamanho de uma história: 0, 1, 2, 3, 5, 8, 13, 20, 40 ou 100. Como
podemos perceber, é uma sequência de Fibonacci, com algumas
modificações.
Sugestão para interpretação desses números:

O 0 (zero) indica que, para finalizar o desenvolvimento de


um item, será preciso aplicar um esforço tão pequeno que,
consequentemente, não é necessário informar um tamanho para a
história.
Os números 1, 2 e 3 indicam que a história é pequena e
demanda pouco esforço.
As histórias com tamanho 5, 8 e 13 são médias e demandam
um esforço intermediário.
Uma história de tamanho 20, 40 ou 100 é muito grande e,
dependendo da velocidade do Time de Desenvolvimento, não
pode ser desenvolvida em uma Sprint. Consequentemente, é
conhecida como épico. Nessa situação, o Dono do Produto deve
quebrá-lo em histórias menores, que serão melhor detalhadas
antes de sua construção.

Segue um exemplo prático de modo a facilitar o entendimento sobre


pontos por história:
Estimativa
Item do Backlog
(Story Points)
Como um Gerente do Produto, quero que seja
possível realizar o cadastramento dos Clientes, para que 2
possa vender os nossos produtos a eles.
Como um Gerente de Compras, quero que seja
possível cadastrar todos os nossos fornecedores, para que
possa negociar a compra dos produtos a serem vendidos 2
ao cliente.

Como um Gerente de Compras, quero que seja


possível controlar o estoque dos produtos, para que possa
2
saber quando devo adquirir novos produtos dos
fornecedores.
Como um Cliente, quero acessar o website com o
intuito de pesquisar os produtos disponíveis e seus 5
preços, para que eu possa escolher quais irei comprar.
Como um Cliente, quero que seja possível adicionar
os produtos por mim selecionados ao carrinho de 13
compras, para que eu possa comprá-los.
Como um Cliente, quero que seja possível pagar os
produtos através de Boleto, Cartão de Crédito ou Débito, 100
para que eu possa escolher a forma de pagamento.
Ao analisar a última história, é possível perceber que ela possui um
tamanho muito grande e trata-se de um épico que deve ser quebrado em
histórias menores.
Agora que já apresentamos como funciona a estimativa em pontos por
história, será explanado como o Time de Desenvolvimento atribui o
tamanho relativo de uma história de usuário, através de um jogo conhecido
como Planning Poker.
O Planning Poker
O Planning Poker consiste em uma técnica gamificada, baseada em
consenso, utilizada para a realização de estimativas relativas. O jogo foi
criado por James Grenning, em 2002. Entretanto, foi popularizado apenas
em 2006, por Mike Cohn, através do livro Agile Estimating and Planning.
O Planning Poker é a técnica mais utilizada para estimar os itens do
Backlog do Produto quando se adota o Framework Scrum.
Antes de iniciar o jogo, cada membro do Time de Desenvolvimento
deve possuir um conjunto de cartas, que é composto pelos números
equivalentes aos pontos por história a serem atribuídos aos itens do
Backlog do Produto. Adicionalmente, o baralho usualmente possui as
cartas de interrogação, xícara de café e infinito.
A carta de interrogação é utilizada quando um membro da equipe
necessita de esclarecimentos antes de estimar um item, ou na situação em
que ele não se sentir seguro para atribuir um valor à história.
O símbolo do infinito exprime que a história possui um tamanho tão
grande, que não é possível atribuir um valor. Para finalizar, o cartão com a
xícara de café é utilizado com o intuito de requisitar um intervalo para
reflexão.
O Planning Poker é utilizado para realizar estimativas relativas, ou
seja, é baseada em comparações e consenso. Consequentemente, o
primeiro passo consiste em selecionar uma história base para comparação.
Caso seja a primeira Sprint, o Dono do Produto e o Time de
Desenvolvimento podem avaliar as histórias priorizadas para a Sprint. Em
comum acordo, escolhem uma pequena e atribuem a ela o valor de 2 ou 3
pontos. A partir da segunda iteração, é aconselhável que o Time de
Desenvolvimento selecione a história de referência que foi utilizada na
Sprint anterior.
A seguir, inicia-se o jogo. O Dono do Produto apresenta uma
explicação sobre o primeiro item de backlog a ser estimado, e os membros
do Time de Desenvolvimento ouvem com atenção o que está sendo dito.
Assim que o Dono do Produto concluir a explicação, o Time de
Desenvolvimento discute sobre o item e esclarece as suas dúvidas.
Após o entendimento da história, inicia-se a votação. Cada membro do
Time de Desenvolvimento reflete individualmente sobre o que foi
apresentado pelo Dono do Produto e seleciona a carta com a quantidade de
pontos que acha adequada para aquele item. É importante citar que a carta
ainda não deve ser apresentada aos demais, de modo a não influenciar os
demais membros da equipe.
O esforço relativo é obtido comparando o item a ser estimado com a
história de referência. Por exemplo, caso o desenvolvedor entenda que a
história possui o dobro de complexidade em relação ao item de referência
(2 pontos), então ele pode optar por atribuir 5 pontos à história estimada.

Após todos os desenvolvedores escolherem as suas cartas, eles devem


apresentá-las simultaneamente. Caso todos selecionem o mesmo número
de pontos por história, o time terá chegado a um consenso e aquela será a
estimativa para o item.
Caso o time não chegue a um acordo, então eles realizam uma nova
discussão para entender as divergências e buscarem um entendimento. É
comum que os profissionais que forneceram a menor e a maior estimativa
comecem apresentando as suas justificativas.
Posteriormente, os membros da equipe realizam uma nova votação. O
processo se repete até que o Time de Desenvolvimento chegue a um
consenso. Entretanto, alguns times optam por realizar no máximo três
votações e, caso não cheguem a uma concordância, aplicam uma regra
para estimar o item. Por exemplo, caso não se chegue em um acordo após
3 tentativas, deve-se selecionar o valor da maior estimativa realizada.
Assim que finalizar a estimativa da história, o Dono do Produto
apresenta o próximo item priorizado e o jogo se repete até o time constatar
que chegou à sua capacidade máxima para a Sprint.
Normalmente a capacidade do time é definida baseando-se na
velocidade do Time de Desenvolvimento. Por exemplo, quando o time
possui uma velocidade de 40 pontos por Sprint, os seus membros devem
parar de estimar quando a soma de todos os itens estimados até o momento
chegar a esse valor.
Conforme consta no Guia Scrum, o Time de Desenvolvimento costuma
estimar os itens de backlog em dois momentos: na reunião de
Planejamento da Sprint e durante o refinamento do Backlog do Produto
(Grooming).
A partir deste momento será demonstrado na prática o funcionamento
do Planning Poker. Vamos pressupor que o time atribuiu o tamanho de 2
pontos à história de referência.
O Dono do Produto apresentou a próxima história a ser estimada e
todos esclareceram as suas dúvidas. Posteriormente, cada membro do time
avaliou o tamanho da história, comparando-a com a de referência e, ao
final, realizaram a votação. Segue resultado obtido:

Como pode-se perceber, o time não chegou a um consenso.


Consequentemente, iniciou-se a discussão para entender as divergências
identificadas. Os desenvolvedores 2 e 4 foram os primeiros a justificarem
as suas estimativas. Após o término da discussão, ocorreu a segunda
rodada de votação, onde o resultado foi:
Dessa vez o Time de Desenvolvimento chegou a um consenso e a
estimativa atribuída ao item do Backlog do Produto foi de 5 pontos por
história.
Dias (ou Horas) Ideais
Dias (ou Horas) Ideais consiste em uma técnica de estimativa absoluta,
onde é atribuída uma unidade de tempo a uma atividade, sem a realização
de comparações.
Mike Cohn (2006) diz que, quando se optar pela utilização dessa
técnica, deve-se assumir as seguintes premissas:

O item do Backlog do Produto sendo estimado deve ser o


único trabalho que o Desenvolvedor irá realizar.
Quando o trabalho for iniciado, todos os recursos necessários
para a sua execução precisam estar em posse do desenvolvedor.
Não existirão interrupções durante a realização do trabalho.

Sendo assim, para que um item estimado em 2 dias ideais seja


efetivamente construído nesse prazo, o desenvolvedor precisa iniciar o
trabalho possuindo todos os recursos necessários, e deverá trabalhar
efetivamente 8 horas por dia, sem interrupções.
Entretanto, na prática, a quantidade de tempo ideal difere do tempo
efetivamente decorrido ao realizar uma atividade, pois, em um dia de
trabalho, um profissional não consegue trabalhar 8 horas. Certamente ele
consumirá parte de seu dia indo a reuniões, tomando café, lendo e-mails,
solucionando problemas, provendo suporte, entre outras atividades.
Dessa forma, considere que o profissional irá trabalhar efetivamente
por volta de 5 a 6 horas por dia. Consequentemente, todos os Stakeholders
devem ter a ciência que uma tarefa estimada em 2 dias ideais
provavelmente levará o dobro do tempo para ser finalizada.
Conclusão
Quando implementamos o Scrum em uma equipe ou até mesmo em
toda a empresa, pode-se utilizar o método de estimativa que melhor se
adequar à sua realidade, pois, em nenhum momento, é citada a
obrigatoriedade da aplicação de uma técnica específica.
Capítulo 11
Mitos do Scrum
Nesse capítulo serão apresentados alguns mitos, referentes ao Scrum,
que eventualmente são disseminados através de redes sociais, treinamentos
ou livros. Você os conhece?
A Reunião Diária deve ser realizada em pé
Embora muitos treinamentos e artigos sobre o Scrum informem que a
Reunião Diária deve ser realizada em pé, tenha em mente que essa é
apenas uma boa prática que pode ser adotada (ou não) pelo Time de
Desenvolvimento e, dessa forma, é opcional.
A maioria dos Times de Desenvolvimento realizam a reunião em pé,
pois, é desconfortável e ninguém gosta de permanecer muito tempo nessa
posição. Portanto, isso ajuda a manter a reunião curta, direta e objetiva.
Logo, caso você visualize algum Time de Desenvolvimento realizando
a reunião em uma sala, com seus membros sentados, saiba que eles não
estão ferindo uma regra do Scrum.
Durante a Reunião Diária, as três perguntas devem ser
respondidas
Durante a Reunião Diária, as três perguntas devem ser respondidas.
Muitos livros e treinamentos, principalmente os mais antigos, dizem
que, na Reunião Diária, os membros do Time de Desenvolvimento são
obrigados a responderem às seguintes perguntas:

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
atingir a meta da Sprint?
Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atingimento da meta da Sprint?

Entretanto, a partir da versão 2017 do Guia Scrum, tornou-se possível


ao Time de Desenvolvimento estruturar e conduzir a reunião de diferentes
formas, desde que se foque no progresso em direção à meta da Sprint.
Dessa maneira, as 3 perguntas acima passam a ser opcionais, e não mais
obrigatórias.
Os membros do Time de Desenvolvimento devem ser capazes de
executar qualquer tipo de trabalho
O guia Scrum diz que o time de desenvolvimento é multifuncional, ou
seja, deve possuir todas as habilidades necessárias para desenvolver os
incrementos do produto e, portanto, não pode depender de outras equipes
ou pessoas externas.
Muitos confundem multifuncionalidade com multidisciplinaridade, ou
seja, acham que os profissionais do time de desenvolvimento precisam
serem capazes de executar todas as atividades necessárias para
desenvolver o produto. Ou seja, é o famoso conceito de que “todo mundo
deve fazer tudo”.
Contudo, essa definição é equivocada, pois, o guia Scrum não diz que
os membros da equipe devem ser multidisciplinares, mas sim que o time
de desenvolvimento deve ser multifuncional. Isso quer dizer que o time
deve possuir todas as habilidades necessárias para construir um incremento
do produto. Consegue perceber a diferença?
Em um projeto, cujo produto final seja um software, o time pode ser
composto por indivíduos que tenham conhecimentos específicos em
desenvolvimento, arquitetura, bancos de dados, UX, testes, etc. É difícil a
um profissional conhecer várias disciplinas e ser especialista em todas
elas. Apesar disso, é fato que o Scrum propicia aos membros do time a
oportunidade para se aprimorarem e aprenderem novas habilidades, uma
vez que eles devem se ajudar para completar o trabalho e gerar o
incremento do produto.
Durante o andamento de uma Sprint, caso todas as atividades de banco
de dados tenham sido concluídas, o profissional responsável por essa
atividade pode auxiliar a executar os testes. Como o analista de Banco de
Dados não é experiente nessa atividade, ele provavelmente irá testar as
funcionalidades de menor complexidade, deixando as demais para o
profissional especialista em testes.
Os itens do Backlog do Produto devem ser descritos no formato de
histórias de usuário
Certamente você já ouviu que os itens do Backlog do Produto devem
ser descritos utilizando o formato de histórias de usuário. Entretanto, é
importante esclarecer que o guia Scrum, em nenhum momento, irá dizer
como devemos descrever os itens do backlog do Produto.
Consequentemente, é permitido que o backlog seja descrito e detalhado
utilizando histórias de usuário, protótipos, casos de uso, especificações
técnicas ou qualquer outro documento que a organização desejar.
No entanto, ao utilizar o Scrum, o mais comum é que os itens do
Backlog do Produto sejam descritos utilizando histórias de usuário.
É obrigatório utilizar o gráfico Burndown para acompanhar o
progresso da Sprint
Embora sejam muito úteis, os gráficos Burndown, Burnup e Diagrama
de Fluxo cumulativo são apenas boas práticas sugeridas pelo Guia Scrum.
Dessa forma, seu uso é opcional. Caso você não os conheça, segue um
breve resumo sobre cada um deles:
Gráfico Burndown
É utilizado com o intuito de demonstrar o progresso e
desempenho da equipe, comparando o que foi planejado
com o que já foi entregue.
O gráfico Burndown apresenta o quanto ainda falta
para ser realizado durante a execução do projeto ou da
Sprint. Dessa forma, ele é apresentado em forma
decrescente.
Gráfico Burnup.
É semelhante ao gráfico Burndown. A diferença é
que esse gráfico apresenta o que já foi realizado até o
presente momento.
Diagrama de Fluxo Cumulativo.
É utilizado para demonstrar o progresso e o
desempenho do projeto. Esse diagrama irá apresentar
uma visão clara de como está a distribuição do trabalho
entre as etapas do Projeto.

A Sprint Zero (0)


Alguns times, antes de iniciar a primeira Sprint do projeto, optam por
executar uma iteração conhecida como Sprint 0. Ela usualmente destina-se
a:

Preparação do Backlog do Produto.


Preparação do ambiente de trabalho como, por exemplo,
realizar a aquisição e instalação de equipamentos e softwares.
Além disso, pode ser necessário adquirir materiais e outros
suprimentos a serem utilizados durante o andamento do projeto.
Definir o tamanho das Sprints e elaborar a Definição de
Pronto.
Eventualmente, durante a Sprint Zero, pode ocorrer a
formação do Time de Desenvolvimento.
Enfim, ela pode ser destinada à realização de quaisquer
atividades que sejam necessárias para a preparação inicial do
projeto.

Conforme podemos perceber, a Sprint 0 não resulta em nenhum


incremento do produto funcional e potencialmente pronto para entrega ao
Cliente.
É importante frisar que o Guia Scrum deixa claro que, ao final de uma
Sprint, um Incremento do Produto deve estar “Pronto” e em condições de
ser utilizado. Ou seja, como a Sprint 0 não gera incremento, não podemos
considerá-la como sendo oficialmente válida.
Capítulo 12
Formação em Scrum – Preparatório para a
Certificação PSM-I
O curso Formação em Scrum tem como objetivo principal prepará-
lo(a) para a obtenção da Certificação Professional Scrum Master Nível I da
Scrum. org.
Importante. O treinamento foi desenvolvido com o intuito de
prepará-lo(a) para a obtenção dessa certificação e, consequentemente, não
possui conteúdo duplicado e desnecessário. Matricule-se agora mesmo!
Durante o treinamento, irei apresentar-lhe todo o conteúdo
necessário para a realização da prova, e alguns tópicos adicionais. Segue
resumo do conteúdo programático:

Principais Certificações em Scrum.


O Manifesto Ágil (valores e princípios).
Principais métodos utilizados durante o desenvolvimento de
um produto.
O Framework Scrum.
Orientação para a realização do exame.
Simulado.

O treinamento é composto por mais de 6 horas de vídeo-aulas,


além de muitas questões de fixação e de revisão.
Segue link para a aquisição do treinamento: Formação em Scrum –
Preparatório para a Certificação PSM-I.
Venha aprender conosco!!!
Referências Bibliográficas
BECK, Kent et.al. History: The Agile Manifesto, agilemanifesto.org,
2001. Disponível em: https://agilemanifesto.org/history.html/. Acesso em:
08 jul. 2020, 11:30.

BECK, Kent et.al. Manifesto para Desenvolvimento Ágil de Software,


agilemanifesto.org, 2001. Disponível em:
https://agilemanifesto.org/iso/ptbr/manifesto.html/. Acesso em: 08 jul.
2020, 11:30.

BECK, Kent et.al. Princípios por trás do Manifesto Ágil,


agilemanifesto.org, 2001. Disponível em:
https://agilemanifesto.org/iso/ptbr/principles.html/. Acesso em: 08 jul.
2020, 11:30.

COHN, Mike. User Stories Applied (Addison-Wesley Signature


Series). Nova Jersey: Editora Pearson Education, 2006. E-book acessado
do Kindle.

DEVMEDIA. RUP - Rational Unified Process, DEVMEDIA, 2007.


Disponível em: https://www.devmedia.com.br/rup-rational-unified-
process/4574/. Acesso em: 08 jul. 2020, 13:30.

HIGHSMITH, Jim. History: The Agile Manifesto, agilemanifesto.org,


2001. Disponível em: https://agilemanifesto.org/history.html/. Acesso em:
08 jul. 2020, 11:30.

ITM. Ciclos de vida preditivo ou clássico, iterativo e incremental,


adaptativo ou ágil, ITM Platform, 2015. Disponível em:
http://www.itmplatform.com/br/blog/ciclos-de-vida-preditivo-ou-classico-
iterativo-e-incremental-adaptativo-ou-agil/. Acesso em: 08 jul. 2020,
11:30.

JEFFRIES, Ron. Essential XP: Card, Conversation, Confirmation.


RonJeffries.com, 2001. Disponível em:
https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/.
Acesso em: 08 jul. 2020, 09:30.

MARTINEZ, Marina. RUP, InfoEscola. Disponível em:


https://www.infoescola.com/engenharia-de-software/rup/. Acesso em: 08
jul. 2020, 13:00.
MEDEIROS, Higor. Introdução ao Modelo Cascata, DEVMEDIA,
2013. Disponível em: https://www.devmedia.com.br/introducao-ao-
modelo-cascata/29843/. Acesso em: 08 jul. 2020, 12:30.

RAMOS, Almir et al. Modelo cascata apresentação, Modelo Cascata


Blog. Disponível em: http://modelocascata.blogspot.com.br/. Acesso em:
08 jul. 2020, 12:30.

RAMOS, Robson. Uma comparação entre os modelos ágil e cascata de


desenvolvimento de software, Brainstorm de TI, 2010. Disponível em:
https://brainstormdeti.wordpress.com/2010/05/25/uma-comparacao-
entremodelo-agil-e-cascata/. Acesso em: 08 jul. 2020, 12:30.

ROYCE, W.W. (1970). Managing the Development of Large Software


Systems. Proceedings of IEEE WESCON, 26, 328-388.

RUBIN, Kenneth S. Scrum Essencial: Um guia prático para o mais


popular processo ágil. Rio de Janeiro: Alta Books, 2017. Edição do
Kindle.

SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. Um guia


definitivo para o Scrum: As regras do Jogo, 2017. Disponível em:
<http://www.scrumguides.org>. Acesso em: 18 fev. 2019.

SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho


na metade do tempo. Rio de Janeiro: Leya Brasil, 2014. Edição do
Kindle.

TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The New New Product


Development Game. Harvard Business Review 64, no. 1 (January–
February 1986). Disponível em: https://hbr.org/1986/01/the-new-new-
product-development-game. Acesso em: 08 jul. 2020, 16:30.

UFPE. RUP para pequenas equipes, Centro de Informática - UFPE,


2003. Disponível em: https://compbionets.cin.ufpe.br/~processos/rup-
pe/process/ovu_proc.htm/. Acesso em: 08 jul. 2020, 14:30.

WAKE, William C. 2003. INVEST in Good Stories, and SMART


Tasks, XP123, 2003. Disponível em: https://xp123.com/articles/invest-in-
good-stories-and-smart-tasks/. Acesso em: 08 jul. 2020, 09:30.
WILDT, Daniel; MOURA, Dionatan; LACERDA, Guilherme; HELM,
Rafael. eXtreme Programming – Práticas para o dia a dia no
desenvolvimento ágil de software. São Paulo: Casa do Código, 2018.

WIKIPÉDIA. Modelo em Cascata, Wikipédia, 2005. Disponível em:


https://pt.wikipedia.org/wiki/Modelo_em_cascata/. Acesso em: 08 jul.
2020, 12:30.

Você também pode gostar