A Aplicação do Scrum na Módulo

Novembro de 2011
Versão 2.0
PREFÁCIO ...................................................................................................................................................... 4

1. INTRODUÇÃO ....................................................................................................................................... 5

2. APRESENTAÇÃO .................................................................................................................................. 6

3. VISÃO GERAL DO MODSCRUM ........................................................................................................ 7

3.1. Gestão do Produto.......................................................................................................................................... 7

3.1.1. Product Roadmap ......................................................................................................................................... 9
3.1.2. Gestão do Product Roadmap ........................................................................................................................ 9
3.1.3. Priorização dos Requisitos .......................................................................................................................... 12
3.1.4. O Product Backlog ...................................................................................................................................... 13
3.1.5. Priorização das Histórias de Usuário .......................................................................................................... 13

3.2. Ciclos de Desenvolvimento ........................................................................................................................... 13

3.3. Papéis ........................................................................................................................................................... 15

3.3.1. Product Manager ........................................................................................................................................ 15
3.3.2. Product Owner ........................................................................................................................................... 16
3.3.3. Times .......................................................................................................................................................... 16
3.3.4. Scrum Master ............................................................................................................................................. 17

3.4. Scrum of Scrums ........................................................................................................................................... 17

3.5. Sprint de Estabilização .................................................................................................................................. 19

3.6. Scrum Room ................................................................................................................................................. 19

4. REUNIÕES E CERIMÔNIAS .............................................................................................................. 21

4.1. Planning Poker – Story Points ....................................................................................................................... 21

4.1.1. Story Points ................................................................................................................................................. 22
4.1.2. Procedimento para o Planning Poker ......................................................................................................... 23

4.2. Sprint Planning 1 .......................................................................................................................................... 25

4.2.1. Selected Backlog ......................................................................................................................................... 26

4.3. Sprint Planning 2 .......................................................................................................................................... 27

4.3.1. Task Board .................................................................................................................................................. 27
4.3.2. Burndown e Burnup Charts ........................................................................................................................ 30

4.4. Daily Meetings .............................................................................................................................................. 32

4.5. Sprint Review ............................................................................................................................................... 34

4.5.1. Definição de Pronto (“Definition of Done”) ................................................................................................ 35

4.6. Release Review ............................................................................................................................................. 36

4.7. Sprint Retrospective ..................................................................................................................................... 37

modScrum 2
Novembro de 2011
5. DEVOPS – INTEGRAÇÃO ENTRE O DESENVOLVIMENTO E A OPERAÇÃO ....................... 39

ANEXOS ........................................................................................................................................................ 42

ANEXO I – MODELO DE DIVULGAÇÃO DO ROADMAP DO RELEASE ......................................... 43

ANEXO II – FICHA DE REQUISITO – EXEMPLO................................................................................. 45

ANEXO III – LISTA DE VERIFICAÇÃO PARA PLANEJAMENTO DAS HISTÓRIAS .................... 48

ANEXO IV – EXEMPLOS DE FEEDBACK E SUGESTÕES DAS REUNIÕES DE RETROSPECTIVA

DAS EQUIPES .............................................................................................................................................. 54

ANEXO V - SCORECARD DOS SPRINTS (BURN-UP RELEASE) ..................................................... 57

ANEXO VI – PRINCÍPIOS DO MANIFESTO ÁGIL ............................................................................... 59

ANEXO VII - HISTÓRICO - “POR ONDE COMEÇAMOS?” ................................................................. 60

REFERÊNCIAS ............................................................................................................................................. 60

AGRADECIMENTO..................................................................................................................................... 62

modScrum 3
Novembro de 2011
Prefácio

“Nós valorizamos processos e ferramentas mas,

valorizamos mais indivíduos e interações”

do Manifesto Ágil

No início de 2011, começamos uma nova fase de desenvolvimento na Módulo com uso do Scrum a
partir de equipes multidisciplinares. Esta nova abordagem baseada em métodos ágeis e flexíveis
trouxe ótimos resultados com maior qualidade, produtividade e transparência tanto para os
processos de desenvolvimento como para os resultados e funções na área.

Planejamos esse movimento com decisões e mudanças que estão registradas neste documento
chamado de modScrum, ou “A Aplicação do Scrum na Módulo”, atualizado conforme os
acontecimentos nesse período.

Obrigado a todos pela participação nos treinamentos, envio de sugestões e comentários para
criação e revisão deste documento de forma colaborativa e participativa.

O processo incorporou também ferramentas e técnicas kanban (com “k” minúsculo que em
japonês quer dizer “sinais visuais”), que utiliza, basicamente, os quadros, post-its, cortiças, e
assim, muitas informações coladas nas paredes e quadros. Também incorporamos técnicas do
método Kanban (com “k” maiúsculo), como a redução de WIP (work in progress), a reserva de
raias para suporte, execução imediata de tarefas emergenciais etc.

A prática reforça a cultura de qualidade e melhoria contínua (kaizen) em todas as áreas,

promovendo melhor comunicação entre as pessoas e adotando equipes mais autônomas e
autogerenciadas para pensar, planejar e aperfeiçoar seus próprios processos e interações.

Esperamos que este guia sirva como referência para apresentar como fazemos Scrum na Módulo e
que se torne um documento “vivo” continuamente melhorado a partir do feedback e melhorias
alcançadas no processo. Estamos também tornando este documento público para que possa
ajudar outras empresas a partir de nossas experiências e exemplos.

Boa leitura! E fique à vontade para enviar sugestões e comentários.

Alberto Bastos, Novembro 2011

abastos@modulo.com.br

modScrum 4
Novembro de 2011
 1. Introdução
Este guia tem o objetivo de descrever como o framework Scrum é implementado no dia a dia da
Módulo, detalhando as particularidades para as necessidades da empresa.

O Scrum é uma forma de manter o registro das decisões sobre o trabalho dos profissionais de
desenvolvimento do software Risk Manager, incluindo fluxos de informações, produção de
documentos, artefatos, papéis e responsabilidades. Assim, a governança sobre o processo é
reforçada por este documento, que se torna a referência básica para o uso do Scrum na empresa.

Para correto entendimento deste guia é preciso que o leitor conheça o Scrum e esteja
familiarizado com seus conceitos e terminologias.

Para saber mais sobre Scrum, você pode consultar algumas referências que são sugeridas ao final
deste guia.

O Scrum começou a ser utilizado na Módulo em 2009 no Projeto NG (Next Generation), porém,
apenas pelas equipes de desenvolvedores do software (programação). As demais equipes
funcionais atuavam com um processo em cascata.

Iniciamos uma segunda etapa de uso em janeiro de 2011, com a expansão do Scrum para as
demais áreas, formando equipes multidisciplinares compostos por analistas de sistema, designers
e equipe de testes.

Atualmente, nessa terceira fase, expandimos a utilização dos métodos ágeis para as outras
equipes que utilizam um modelo misto de Scrum e Kanban (Scrumban).

modScrum 5
Novembro de 2011
Conforme os ciclos de desenvolvimento, a vivência da metodologia traz modificações naturais na
forma como os processos são executados, visando sempre à melhoria contínua. Para isso, a
flexibilidade deste documento é um fator importante, permitindo a documentação das mudanças
e o aprimoramento do método implementado.

2. Apresentação
Este guia traz, em linguagem simples, a descrição das etapas do processo e os detalhes referentes
aos artefatos utilizados, os papéis e responsabilidades em cada fase.

O documento foi organizado de acordo com o fluxo de desenvolvimento, no qual, para cada etapa
(em ordem cronológica dentro de um ciclo), são descritas suas atividades, as cerimônias e a
participação de cada ator envolvido:

O modScrum utiliza os conceitos e nomenclaturas já difundidos pelo Scrum. Porém, foi modificado
para se ajustar às particularidades da Módulo, principalmente à necessidade de vários times
colaborarem para produzir, no final, um único produto. Importante é que o objetivo seja sempre
aperfeiçoar o processo “descobrindo maneiras melhores de desenvolver software”, como consta
no Manifesto para o Desenvolvimento Ágil de Software:

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

Software em funcionamento mais que documentação abrangente

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

Responder a mudanças mais que seguir um plano

Reforçando que, mesmo que os itens à direita tenham valor, priorizamos sempre os itens à
esquerda.

modScrum 6
Novembro de 2011
O anexo VII apresenta os princípios do Manifesto Ágil.

3. Visão Geral do modScrum

3.1. Gestão do Produto

Atualmente, na Módulo, o processo de desenvolvimento do Risk Manager conta com a seguinte

estrutura de equipes:

A Gerência do Produto é responsável pela preparação e gestão do product roadmap e do product

backlog.

O Desenvolvimento é responsável pela construção do software, desde a divisão das histórias em

tarefas até o teste do sistema, quando ele está pronto para o deployment interno. Isso inclui
design, tradução, desenvolvimento e teste do código.

A equipe de Operação é responsável pela Documentação, Quality Assurance, entrega e instalação

do Risk Manager nos clientes.

O processo de desenvolvimento e entrega do software pode ser entendido como a interação entre
esferas de diferentes níveis. A partir da visão do negócio inicia-se a construção da estratégia do
produto, em que são definidos os objetivos e os planos para as próximas versões. Em um próximo
nível, foca-se na gestão de uma nova versão (release) que é desenvolvida através de ciclos de
desenvolvimento (sprints). Os sprints, por sua vez, são caracterizados por interações diárias entre
os times para alinhamento do trabalho executado. Por fim, para o suporte necessário ao
desenvolvimento e incremento do produto, são utilizadas tecnologias e práticas que garantam a
integridade do software desenvolvido. Assim, é possível que seja entregue, periodicamente, um
produto que esteja alinhado à estratégia do negócio e possua a qualidade esperada.

modScrum 7
Novembro de 2011
A gestão do produto é uma atividade bastante dinâmica no modScrum. Ela está sob a
responsabilidade do Product Manager e pode ser representada pela seguinte figura:

modScrum 8
Novembro de 2011
 3.1.1. Product Roadmap

O modScrum se inicia com a preparação e gestão do product roadmap que contém os requisitos
criados a partir de sugestões e demandas de mercado e que constituem as novas funcionalidades
esperadas para futuras versões do Risk Manager 7.

O product roadmap é proposto pelo Product Manager a partir de feedback e contatos com os
clientes e pessoal de negócios. O Product Manager avalia as sugestões e demandas recebidas
dessas e outras fontes (técnicos, consultores, clientes etc.) e, quando pertinente, as insere como
requisitos no product roadmap. Os requisitos constituem itens mínimos que merecem visibilidade
para o mercado e possuem um MMR – Minimum Marketable Release (um conjunto mínimo de
funcionalidades que, na visão do cliente, justificam seu investimento no produto). O Product
Manager sugere e planeja o conteúdo dos futuros releases a partir dos requisitos cadastrados.
Esse conteúdo é submetido, mensalmente, pelo Diretor Técnico, a aprovação da diretoria da
Módulo e publicado como o roadmap oficial do produto.

Assim, o product roadmap, composto de requisitos, é um compromisso assumido pela diretoria

técnica com o restante da empresa, alinhando as expectativas das demais diretorias quanto às
futuras atualizações e versões do Risk Manager 7.

O product roadmap possui um processo bastante dinâmico para a manutenção da priorização dos
seus requisitos, para que estes estejam sempre atualizados quanto às demandas mais urgentes do
negócio. Esse processo é de responsabilidade do Product Manager e descrito no item 3.1.2.

A partir do product roadmap e outras eventuais entradas como bugs e sugestões é gerado o
product backlog que contém as histórias de usuário priorizadas e que podem ser selecionadas
para ser desenvolvidas no sprint, compondo o selected backlog.

Exemplo de product roadmap (em parte):

ID Release Module Title Requestor Customer
797 (2011) R12 - 7.5 18 - Integration API to update customized attributes in Workflow - (View & Update Text type) Pessoa 1 CLIENTE 1
835 (2011) R12 - 7.5 20 - Mobile Improvements in Workflow for Ipad (Filter & Progress) I & Iphone Questonnaires Pessoa 1 ALL CLIENTS
843 (2011) R12 - 7.5 07 - Workflow Update fields & Attributes on workflow (USR update) Pessoa 2 ALL CLIENTS
849 (2011) R12 - 7.5 16 - Others [DEM] Knowledge Migration from version 5 to version 7 Pessoa 2 CLIENTE 2
851 (2011) R12 - 7.5 16 - Others [BUG] Workflow Migration adjustments from version 5 to version 7 Pessoa 2 CLIENTE 2
852 (2011) R12 - 7.5 16 - Others [DEM] CEF Collectors Pessoa 3 CLIENTE 3
853 (2011) R12 - 7.5 18 - Integration API Token Management & Other domain usage Pessoa 1 RISK MANAGER
854 (2011) R12 - 7.5 16 - Others [DEM] Projects Migration from version 5 to version 7 (Inventory) Pessoa 2 CLIENTE 2
855 (2011) R12 - 7.5 07 - Workflow Update fields & Attributes on workflow (Resp.Coord.Dates.Attrlist.AttrText) - II Pessoa 2 ALL CLIENTS

3.1.2. Gestão do Product Roadmap

A manutenção do product roadmap é feita pelo Product Manager em uma lógica de

versionamento a cada sprint. O roadmap é atualizado antes do início de cada sprint conforme as
funcionalidades forem incluídas no software e a lista de prioridades de requisitos for atualizada,
devido à dinamicidade do mercado e às exigências dos clientes.

modScrum 9
Novembro de 2011
Porém, a lista ordenada de requisitos sofre alterações dentro de um determinado limite. Isso
porque o product backlog precisa ser elaborado e atualizado com base nos requisitos que estão
mais próximos de serem desenvolvidos. Esses são detalhados em histórias e pré-pontuados pelo
Product Owner (com auxílio dos times, quando preciso) para que possam se tornar histórias
candidatas ao selected backlog dos próximos sprints.

A dinâmica de atualização do product roadmap pode ser descrita da seguinte forma:

Para cada release, são inseridos, no product roadmap, os requisitos prioritários em uma
quantidade correspondente à velocidade planejada para os times (To Do). Além desses, também é
selecionada uma quantidade adicional de 25% de requisitos, que exercem um papel de reserva
para serem incluídos no desenvolvimento, de acordo com possíveis mudanças de prioridade para
o negócio. Esse roadmap é, então, atualizado a cada sprint com novas demandas surgindo e outras
retiradas do escopo segundo novas priorizações. A quantidade de requisitos presente no roadmap
também é ajustada a cada sprint para manter sempre a mesma proporção de 25% extra além da
velocidade planejada para os times, descartando-se, assim, um conjunto de requisitos de menor
prioridade.

modScrum 10
Novembro de 2011
Quanto mais perto do início de um sprint, mais detalhados devem estar aqueles requisitos
prioritariamente candidatos a fazer parte do product backlog. A figura abaixo demonstra esta
dinâmica de forma mais detalhada, com um exemplo concreto do planejamento de um release:

A velocidade para o release foi determinada como 480 pontos, sendo 120 pontos para cada sprint.
Assim, os requisitos são divididos em faixas de acordo com o grau de certeza sobre o seu
desenvolvimento. A cada sprint são eleitos, dentre os mais prioritários, quais requisitos serão
desenvolvidos. Estes já devem estar detalhados no product backlog em nível de história de
usuário. Isso permite que a prioridade de execução esteja sempre atualizada em relação às últimas
tendências e estratégias de negócio.

O controle dos requisitos que estão no product roadmap e que já foram desenvolvidos é feito no
Scrum Room, através de controles fixados nas paredes e no quadro branco, conforme pode ser
visto na foto abaixo. Assim, todos podem ter acesso a esses controles.

modScrum 11
Novembro de 2011
 3.1.3. Priorização dos Requisitos

Para a priorização dos requistos do product roadmap é utilizada a metodologia FUI (Facilidade,
Urgência e Impacto):

Facilidade – previsão de esforço/prazo de dedicação necessário ao desenvolvimento do

requisito baseada na pontuação preliminar do requisito

Urgência – momento no qual é previsto que o requisito será desenvolvido

Impacto – relevância que o requisito tem na criação de valor para o produto

A tabela abaixo apresenta a pontuação para o grau de cada critério.

modScrum 12
Novembro de 2011
A priorização do requisito é dada, primeiramente, por sua urgência. Após, é utilizado o produto UI
(Urgência x Impacto) como segundo critério e, finalmente, o produto FUI (Facilidade x Urgência x
Impacto) como valor de desempate final.

A partir da estimativa de pontos calculada para cada requisito e da projeção da velocidade dos
times, é definido o roadmap do release a ser divulgado, denominado "roadmap externo". O
modelo de divulgação pode ser visto no Anexo I – Modelo de Divulgação do Roadmap do Release.

3.1.4. O Product Backlog

O product backlog é composto de histórias de usuário. As histórias podem ter sua origem em um
requisito presente no roadmap, em um conjunto de bugs que devem ser resolvidos ou em
sugestões de melhorias rápidas (quick changes) que possuem um esforço baixo para
desenvolvimento.

O product backlog encontra-se hoje no SharePoint e sua manutenção e atualização são de

responsabilidade do Product Owner.

3.1.5. Priorização das Histórias de Usuário

As histórias herdam a priorização do requisito associado. Caso a história não tenha requisito
associado (originada de um bug ou de uma quick change), o método FUI também é utilizado para
essas histórias durante as reuniões semanais de priorização.

Quanto maior a prioridade de uma história de usuário, mais urgente é detalhar e pontuar esta
história. Histórias menos prioritárias no product backlog podem ser mantidas consolidadas e com
menos precisão (chamadas de “épicos”).

Conforme já mencionado, as histórias recebem uma pontuação preliminar dada pelo Product
Owner e sua pontuação definitiva é dada pelo time, através do planning poker que ocorre durante
o Sprint Planning 1.

3.2. Ciclos de Desenvolvimento

A partir da preparação do product backlog, dá-se início aos ciclos de desenvolvimento. Estes
podem ser representados pelo seguinte esquema:

modScrum 13
Novembro de 2011
O input principal desse processo é o product backlog atualizado e priorizado a cada sprint,
conforme já foi explicado nos itens anteriores. A preparação do product backlog envolve a
atualização e manutenção da lista de histórias de usuário, oriundas do detalhamento e da
priorização dos requisitos do product roadmap. Esse é um processo contínuo, que permeia todos
os ciclos.

Os ciclos de desenvolvimento são feitos em várias iterações (sprints) que se iniciam com o Sprint
Planning 1 (SP1), reunião entre o Product Owner (PO), o Scrum Master (SM) e o time para a
definição do objetivo do sprint e do selected backlog. O tempo estimado para o SP1 é de 2 horas.

Durante o SP1, são realizadas rodadas de planning poker, no qual os times pontuam as histórias
candidatas ao selected backlog para definição do esforço necessário ao seu desenvolvimento.

Essas histórias são derivadas de requisitos que já receberam uma pontuação preliminar dada pelo
PO (com consultas aos times, quando necessário). Essa pontuação tem a função de auxiliar a
seleção do conjunto de histórias candidatas ao selected backlog de acordo com a velocidade dos
times.

Durante o planning poker, o PO apresenta os critérios de aceitação, que ajudam o time a entender
a complexidade de desenvolvimento da história em questão. Esses critérios podem ser tanto
técnicos como de negócio.

Após o entendimento e pontuação das histórias, os times negociam com o PO o selected backlog
com base na velocidade estimada do time para o respectivo sprint. Essa velocidade depende de
fatores como dias úteis no sprint, pessoas de férias ou alocadas em outras atividades, percentual
do esforço reservado para suporte ou correção de bugs, déficit técnico etc.

modScrum 14
Novembro de 2011
Logo após o SP1, de posse do selected backlog acordado com o PO, os times se reúnem para o
Sprint Planning 2 (SP2) para o entendimento detalhado das histórias e a determinação,
planejamento e divisão das tarefas. O tempo estimado para o SP2 é de 2 horas.

Após o SP2, é dado início ao sprint para o desenvolvimento do software respectivo ao selected
backlog.

Ao término do sprint, é feita uma reunião denominada Sprint Review onde todos os times
participam juntos, formalizando o encerramento do sprint. Nessa reunião também participam
outras equipes como a de Documentação, Quality Assurance, Infraestrutura, Suporte e outros
convidados, para que tomem conhecimento do trabalho realizado, tirem eventuais dúvidas e
colaborem com sugestões. O tempo estimado para o Sprint Review é de 3 horas.

Por último, o time e o Scrum Master realizam uma reunião denominada Sprint Retrospective para
avaliar o andamento e ocorrências do sprint, trazendo ideias e sugestões, para a melhoria
contínua. O tempo estimado para o Sprint Retrospective é de 1 hora.

Em seguida, um novo ciclo se inicia a partir de um novo Sprint Planning 1 para execução do
próximo sprint.

Normalmente todas estas cerimônias acontecem no mesmo dia, em quartas-feiras alternadas,

início e término dos sprints (Sprint Review, Sprint Retrospective, SP1 e SP2).

Quando necessário, os times são requisitados para reuniões de pontuação das histórias usando o
planning poker.

3.3. Papéis

3.3.1. Product Manager

O Product Manager tem o papel de fazer a ponte entre a visão do negócio e o desenvolvimento,
garantindo que o que está sendo desenvolvido no Risk Manager esteja alinhado às necessidades
dos clientes e às tendências de mercado, dentro de uma ordem de prioridade adequada. O
Product Manager possui as seguintes tarefas:

⋅ Consultar o stakeholders do negócio e receber sugestões e demandas dos clientes para

manter a visão do produto atualizada e adequar as prioridades do product roadmap;
⋅ Gerenciar o product roadmap, através da sua atualização contínua, para que este esteja
sempre disponível para a elaboração do product backlog;
⋅ Manter os stakeholders do negócio atualizados quanto ao que foi, está e será desenvolvido
no Risk Manager, trazendo suas opiniões para a equipe técnica;
⋅ Interagir com os Product Owners para a construção e atualização do product backlog.

modScrum 15
Novembro de 2011
 3.3.2. Product Owner

Na Módulo, esse papel possui as seguintes tarefas:

⋅ Converter os requisitos em histórias de usuário e funcionalidades do software;

⋅ Fazer a ligação entre o desenvolvimento e as necessidades dos clientes;
⋅ Gerenciar o product backlog mantendo-o priorizado.

A Módulo possui três Product Owners que se dividem entre os sete times e são os responsáveis
pela gestão do product backlog e um Product Manager que é o responsável pela gestão do
product roadmap.

3.3.3. Times

O time é responsável pelo desenvolvimento das funcionalidades no produto. É formado por

equipes multidisciplinares e composto de:

⋅ Desenvolvedores – responsáveis pelo desenvolvimento/programação do código do

produto;
⋅ Designers – responsáveis pela interface gráfica e usabilidade;
⋅ Testes – responsáveis pelo teste do código desenvolvido;
⋅ Equipe de Quality Assurance – responsáveis pelos testes de aceitação. Participam apenas
como ouvintes nos times e trabalham na confecção de casos de teste que serão utilizados
após a entrega das funcionalidades pelos times, durante a fase de testes final.

modScrum 16
Novembro de 2011
Em cada ciclo, o time é responsável pela execução de um conjunto de histórias de usuário
escolhidas durante o Sprint Planning 1. Essas histórias são desenvolvidas por todos os profissionais
que compõem o time, sendo entregues prontas para o seu uso no software.

Alguns times possuem um foco de atuação, desenvolvendo as histórias relacionadas a um módulo

ou função específica do produto.

3.3.4. Scrum Master

Na Módulo, o Scrum Master faz parte do time e deve assegurar o bom andamento das atividades
e o cumprimento das regras estabelecidas. É o principal responsável por remover impedimentos
que possam impactar a execução do trabalho e, além disso, é quem interage diretamente com o
Product Owner e participa das reuniões diárias do Scrum of Scrums. Alguns times estabelecem a
prática de rodízio de Scrum Master, para que diferentes membros do time possam exercer esse
papel.

Na ausência do Scrum Master, por exemplo, em caso de férias ou viagem, a equipe deve definir
um substituto para as reuniões diárias (Daily Meeting e Scrum of Scrums) bem como para as
outras cerimônias e atribuições.

3.4. Scrum of Scrums

modScrum 17
Novembro de 2011
Como os times trabalham na melhoria de um único produto, é necessário um mecanismo de
alinhamento de informações entre as equipes e também para que o Gerente de Desenvolvimento
possa ter insumos para garantir que o processo transcorre de forma harmônica. Além disso, os
times precisam trocar experiências e saber como estão as atividades dos demais, para sintonia e
que qualquer zona de sombra possa ser identificada a tempo de não causar maiores impactos no
resultado final.

Para isso, existe o Scrum of Scrums, uma reunião realizada diariamente com o Scrum Master de
cada time com o objetivo de passar informações relevantes sobre o andamento dos trabalhos de
cada time e com a presença do Gerente de Desenvolvimento que exerce o papel de Scrum Master
of Scrum Masters (SM of SM). Essa reunião segue o mesmo ritual dos daily meetings, com
duração de 15 minutos. Também participa o pessoal de QA, Product Owners e Documentação.

Essa é uma reunião para endereçar os problemas relacionados ao alinhamento entre os times,
discutir sobre integração, sintonia e padronização do trabalho. Outros representantes e
participantes poderão ser convidados para essa reunião conforme as questões discutidas.

Ao final de cada sprint o time Scrum of Scrums realiza uma reunião de retrospectiva para
compartilhar as experiências e sugerir melhorias para o processo como um todo. Essa reunião
possui formato parecido com a Sprint Retrospective dos times.

Com o objetivo de integrar todos os assuntos da diretoria técnica, é realizada uma reunião diária
entre o Diretor Técnico, o Product Manager, o Gerente do Desenvolvimento e o Gerente de
Operações, com 15 minutos de duração (Daily Meeting) – o “Scrum of Scrum of Scrums”.

modScrum 18
Novembro de 2011
Periodicamente outras equipes virtuais, compostas de membros de diferentes times, se reúnem
para tratar de temas específicos como design, QA (bugs), DevOps etc.

3.5. Sprint de Estabilização

Os sprints têm duração de duas semanas no modScrum, com liberações de builds internos,
porém, por decisão de negócio, as novas versões do Risk Manager são entregues aos clientes e ao
mercado apenas a cada 3 meses (com uma média de 6 sprints por versão). Além disso, as equipes
de Documentação e QA trabalham com um sprint de defasagem dos times do modScrum. Ou seja,
as funcionalidades entregues em um sprint são homologadas e documentadas no sprint seguinte
pelas equipes de QA e de Documentação. Assim, o último sprint é chamado de “sprint de
estabilização”, no qual todos os times estão focados na homologação e estabilização do sistema,
junto à equipe de QA, e no reparo de bugs inaceitáveis para a release.

3.6. Scrum Room

Para a consolidação do scrum e para fixação de quadros com a visão integrada de

acompanhamento dos ciclos, foi estruturada uma sala de reunião com diversos recursos visuais e
um espaço para os times poderem interagir e as informações mais importantes ficarem
visualmente expostas com o andamento das atividades gerais.

Essa sala serve como um ponto de integração e para transparência e alinhamento de informações
entre os times, Scrum Masters (Scrum of Scrums) e também as diversas outras áreas da empresa.

modScrum 19
Novembro de 2011
 Foto: Sala ScrumRoom em Novembro 2011

Nas paredes da sala está o quadro de acompanhamento do product roadmap, o burnup release,
um quadro para dúvidas e outros recursos de acompanhamento das atividades dos times e da
equipe como um todo. Também são dispostos na sala os principais indicadores de desempenho
dos times.

modScrum 20
Novembro de 2011
 Fotos: Sala ScrumRoom em Novembro 2011

4. Reuniões e Cerimônias
4.1. Planning Poker – Story Points

Para a estimativa do esforço para desenvolvimento de cada história do product backlog é

realizado o chamado planning poker. Essa dinâmica acontece entre o Product Owner, o Scrum
Master e o time sempre que uma nova história ou um conjunto de novas histórias do product
backlog necessita ter sua pontuação refinada (uma vez que as histórias recebem pontuações
preliminares dadas pelo PO do time).

modScrum 21
Novembro de 2011
Essa dinâmica deve ocorrer durante o Sprint Planning 1 e o tempo não é delimitado, porém, a
equipe deve se manter focada na eficiência da pontuação de cada história.

4.1.1. Story Points

É a medida de esforço de desenvolvimento de cada história. São valores relativos que, ao executar
a pontuação pela primeira vez, atribuem à história mais simples do product backlog o menor valor
(dois) da série de Fibonacci (adaptada) e às outras, suas pontuações por comparação.

Para efeito de referência, a história considerada mais simples (de valor 2) foi “Incluir novas
colunas no grid”. Na equipe modSIC a história mais simples (2) foi “Disponibilizar a licença de uso
de forma explícita”.

O modelo mental para a atribuição dos pontos é o seguinte:

Os critérios para a pontuação devem ser: o esforço intelectual, o esforço técnico e a incerteza
quanto ao esforço e ao entendimento da história. Quanto menor o entendimento sobre a história,
maior a incerteza e o esforço estimado, o que aumenta a pontuação da história. Além disso, para o
Risk Manager 7, existe uma lista de verificação – “Complementando suas Histórias” – que inclui

modScrum 22
Novembro de 2011
diversos pontos que devem ser levados em consideração durante a estimativa de esforço da
história. Essa lista de verificação se encontra no final do documento, no Anexo III.

As pontuações são dadas de acordo com a experiência dos profissionais que estiverem na reunião.
O histórico de pontuações a partir do método de planning poker dará o ritmo e uma maior
segurança para as futuras pontuações, assim como a velocidade do time.

A velocidade do time é dada pela sua capacidade de execução de uma certa quantidade de pontos
de histórias no tempo disponível para o sprint.

4.1.2. Procedimento para o Planning Poker

Durante a reunião de pontuação das histórias, os times devem proceder da seguinte forma para
cada história:

1. Verificar se a história está bem compreendida e esclarecer eventuais dúvidas quanto ao

que pode influenciar na complexidade de sua implementação;
2. Cada membro escolhe, em seu baralho, a pontuação que julga pertinente para a história
em questão, levando em conta o modelo comparativo entre histórias exposto acima;
3. Todos mostram suas cartas ao mesmo tempo;

modScrum 23
Novembro de 2011
 4. Os membros que tiverem dado o maior e o menor valor fazem uma breve defesa do
motivo;
5. Os passos 2, 3 e 4 são repetidos até as cartas ou o grupo convergirem a um valor final.

O baralho padrão para o planning poker é como este do exemplo:

Obs.: caso alguma história seja considerada ainda mais simples do que a(s) história(s) com
pontuação 2, as cartas 0, ½ e 1 podem ser utilizadas.

Com a evolução do modScrum, os times mudaram o seu parâmetro de comparação de pontos. O

aumento de eficiência do time faz com que pontuações menores sejam dadas para tarefas de
mesma complexidade devido ao aumento da eficiência e aprendizado do time. Portanto, para
mensurar a evolução de produtividade dos times, é preciso contextualizar o indicador “pontos
entregues”. Para isto, é preciso utilizar outros parâmetros, como, por exemplo, o valor agregado
ao software por sprint.

modScrum 24
Novembro de 2011
 4.2. Sprint Planning 1

No começo de cada sprint é realizada uma cerimônia entre o Product Owner, o Scrum Master e o
time: o Sprint Planning 1. O Product Owner fala sobre seus objetivos e expectativas para aquele
sprint, que deve ser definido em uma frase curta chamada “sprint goal”, e faz uma breve descrição

modScrum 25
Novembro de 2011
dos requisitos mais importantes presentes no product backlog. O Gerente de Desenvolvimento
também participa quando possível das reuniões de SP1.

4.2.1. Selected Backlog

Após a apresentação inicial do Product Owner, o time e o Scrum Master discutem sobre quais
histórias serão desenvolvidas no sprint em questão e as pontuam, conforme já mencionado. O
time deve escolher história por história até completar o número do story points correspondente à
velocidade do time. Essa escolha deve levar em conta também o número de dias do sprint
(normalmente 10 dias úteis ou 14 dias corridos). Este conjunto de histórias forma o selected
backlog referente àquele sprint.

Outro fator que pode afetar a velocidade do time é a necessidade de reservar uma porcentagem
da capacidade do time para outras atividades como, por exemplo, correção de bugs, suportes,
déficits técnicos etc.

É possível que a prioridade ou os pontos de uma história sejam alterados durante o Sprint
Planning 1. Nesse caso, o product backlog deve ser atualizado.

Nos primeiros sprints, essa estimativa foi feita de acordo com a experiência e “feeling” individual,
porém, com a realização de uma série de sprints, cada time tem um histórico de esforço planejado
x realizado para se basear e se aperfeiçoar nas estimativas futuras. Esse histórico atualiza a
velocidade do time.

A qualidade externa do produto (a qualidade percebida pelo cliente) pode ser negociada com o
Product Owner, ou seja, algumas coisas podem deixar de ser feitas num sprint para serem
melhoradas em outro. Porém, a qualidade interna (a qualidade técnica do produto, seu código,
sua arquitetura etc.) deve ser preservada.

Também devem ser considerados quais os critérios de aceitação que serão verificados para que a
história seja considerada entregue. O Anexo III possui também uma lista de verificação de
considerações que devem ser levadas em conta no planejamento.

O tempo destinado a esta cerimônia é de 2 horas, no máximo, e deve ser respeitado. Todo o
esforço e concentração devem ser dedicados ao seu cumprimento.

modScrum 26
Novembro de 2011
 4.3. Sprint Planning 2

Com o selected backlog definido, o Scrum Master e o time se reúnem para o Sprint Planning 2. A
presença do Product Owner é requisitada caso existam possíveis dúvidas de entendimento e sobre
critérios de aceitação.

Nessa reunião, cada história é discutida e quebrada em tarefas para seu desenvolvimento. Todas
as etapas necessárias para que a tarefa seja considerada “Done” devem ser incluídas. As tarefas
normalmente são decompostas para que sejam concluídas em menos de um dia e são escritas em
um post-it e coladas na coluna “To Do” do task board. O post-it tem a seguinte configuração:

O tempo destinado a esta cerimônia é de 2 horas, no máximo, e deve ser respeitado. Todo o
esforço e concentração devem ser dedicados ao seu cumprimento.

4.3.1. Task Board

modScrum 27
Novembro de 2011
O task board é um quadro de acompanhamento do desenvolvimento das tarefas do time para
cada sprint. Esse quadro possui uma tabela e as colunas representam as fases do desenvolvimento
(To Do, Doing, Testing, Done). A primeira coluna representa as histórias do sprint, e os post-its
representam as tarefas que irão “caminhar” entre as colunas. Quando todas as tarefas de uma
mesma história estiverem completas, a história move-se para “Done”.

Cada equipe tem a liberdade para adaptar o quadro e organizar suas colunas para acompanhar o
processo de desenvolvimento.

modScrum 28
Novembro de 2011
modScrum 29
Novembro de 2011
 4.3.2. Burndown e Burnup Charts

No task board também é representado o burndown ou burnup chart que apresenta a estimativa
do esforço que resta (burndown) ou já concluído (burnup) comparado com o esforço previsto no
sprint. Esse gráfico representa a contagem de pontos concluídos ao longo do sprint versus a
evolução linear teórica e é atualizado diariamente no Daily Meeting a cada tarefa concluída
(“Done”). A utilização do burnup ou burndown depende da opção do time.

As equipes possuem liberdade de estruturar seus quadros e personalizá-los.

modScrum 30
Novembro de 2011
modScrum 31
Novembro de 2011
 4.4. Daily Meetings

Diariamente, o time e o Scrum Master devem se reunir de pé (Daily Meeting) em uma reunião de
15 minutos para discutir sobre o andamento das tarefas daquele dia. Cada integrante do time
deve responder a três perguntas básicas:

Essas informações servirão para a atualização do burndown chart (marcação de novos pontos no
gráfico) e do task board (atualização do posicionamento dos posts-its).

Os impedimentos levantados devem ser encaminhados pelo Scrum Master.

O tempo de 15 minutos da reunião deve ser respeitado. Para isso, é importante que o time
mantenha o foco nos objetivos e tenha noção de limite nas suas falas. Questões técnicas não
devem ser o foco das discussões.

modScrum 32
Novembro de 2011
Uma das equipes possui um membro que trabalha remotamente e tem como prática o uso de
ferramentas de comunicação como Skype e GoToMeeting para que participe também, mesmo que
a distância, das reuniões diárias dos times. Durante o início e fim de sprint (Sprint Review,
Retrospective, SP1 e SP2) a presença física é obrigatória.

modScrum 33
Novembro de 2011
 4.5. Sprint Review

Ao final do sprint, ocorre a reunião denominada Sprint Review, da qual participam juntos todos os
times, os Scrum Masters, os Product Owners. Conforme já mencionado, dessa reunião também
participam outras equipes como a de Documentação, Quality Assurance, Infraestrutura, Suporte e
outros convidados para que tomem conhecimento do trabalho realizado, tirem eventuais dúvidas
e colaborem com sugestões.

Essa reunião tem o objetivo de revisar o que foi feito durante o sprint, para que o Product Owner
possa atestar o status de “Done” às histórias desenvolvidas. Para isso, é importante que uma
versão navegável do software esteja disponível para que as funcionalidades possam ser
apresentadas e verificadas durante a reunião.

O Product Owner coloca suas observações quanto à qualidade esperada e a qualidade final
entregue, e comentários com o objetivo de estimular a melhoria contínua do time. Além disso, é
feita uma revisão do andamento do sprint e do projeto como um todo.

O tempo destinado para esta reunião é de 3 horas. É importante que todos tenham consciência
sobre o objetivo da reunião para que o foco seja mantido.

modScrum 34
Novembro de 2011
 4.5.1. Definição de Pronto (“Definition of Done”)

A definição de pronto prevê o software funcionando e com as interfaces traduzidas para

português, inglês e espanhol. Inclui também outros critérios de aceitação e requisitos não
funcionais que possam ser considerados para as histórias. Por exemplo, compatibilidade com
Firefox, tempo de resposta, desempenho etc.

Os tradutores não estão incluídos nos times e devem ser acionados durante o sprint sob demanda
quando necessário. O manual e a aceitação dada pela equipe de QA serão feitos após o
encerramento dos sprints de desenvolvimento, antes da entrega do release.

modScrum 35
Novembro de 2011
 4.6. Release Review

Assim como ocorre o Sprint Review, ao final de cada sprint, é realizada uma reunião denominada
Release Review para a formalização de entrega de uma nova versão (release) do Risk Manager.
Essa reunião ocorre com a presença dos representantes da equipe técnica: Diretor Técnico,
Gerente de Desenvolvimento, Product Owners, Product Manager e Gerente de Operações que
discutem o que foi entregue no novo release e falam sobre a visão estratégica do produto e do
próximo release.

modScrum 36
Novembro de 2011
 4.7. Sprint Retrospective

Essa reunião de retrospectiva é considerada a mais importante do sprint. Dela, participam o Scrum
Master o seu time e é um momento de privacidade (a participação do Product Owner só deve
ocorrer caso todo o time concorde), no qual o time discute sobre quais os pontos positivos e
negativos do sprint finalizado. Os impedimentos e situações desafiadoras são colocados para
possíveis soluções e sugestões de melhoria. Os pontos positivos também são destacados para que
continuem sendo aplicados a outros sprints.

modScrum 37
Novembro de 2011
Procedimento para a Retrospectiva:

1. Repassar o sprint cronologicamente.

2. Discutir sobre o que ocorreu de bom e o que pode ser melhorado para o futuro. Para esse
procedimento as equipes podem utilizar suas próprias metodologias ou técnicas. Por
exemplo:
a. Learning Matrix
i. www – what went well?
ii. wdnsw – what did not so well?
iii. wwl – what we learned?
iv. whu – what helped us?
b. “Começa – Para – Continua”

O Anexo VI possui um resumo com exemplos de feedback e sugestões coletados durantes

as reuniões de retrospectiva dos times.

3. Organizar um impediment backlog

a. Determinar o responsável por cada item (normalmente o Scrum Master).
b. Listar os compromissos (regras, políticas) assumidos pela equipe.

Após o fechamento desta reunião, o sprint é considerado oficialmente finalizado. Assim, outro
ciclo se inicia, seguindo a mesma lógica descrita anteriormente.

modScrum 38
Novembro de 2011
Por fim, as cerimônias são executadas todas as quartas-feiras (exceto feriados). Na parte da
manhã, todos se reúnem para o Review e na parte da tarde cada time realiza suas reuniões Sprint
Planning 1, Retrospectiva e Sprint Planning 2, nessa ordem.

A lógica de realização das cerimônias demonstra como o Scrum pode ser realizado em larga escala,
quando vários times desenvolvem um mesmo produto.

Conforme já descrito, na Módulo existe um Product Manager e, relacionados a ele, três Product
Owners que são responsáveis por dois ou três times. Assim, cada PO conduz uma Sprint Planning 1
com seus times e, após, cada time conduz sua própria Sprint Planning 2. Para a cerimônia de
entrega, o Sprint Review, todos os times se reúnem em uma só reunião e, após esta, cada time
conduz a sua reunião de Retrospectiva.

5. DevOps – Integração entre o Desenvolvimento e a Operação

Para que os benefícios de aumento de produtividade e qualidade trazidos pelo Scrum sejam
efetivos, é preciso que as outras equipes de Operação (Documentação, Quality Assurance,
Suporte, Infraestrutura e Gestão de Conhecimento) estejam integradas e trabalhando no mesmo
ritmo e em parceria com a equipe de Desenvolvimento.

Muitas empresas enfrentam dificuldades nessa integração, isso porque, historicamente, existe
uma barreira entre a área de Desenvolvimento e Operações. Enquanto o Desenvolvimento deseja
ter um ambiente propício a mudanças, Operações tem preferência por um ambiente estável e
confiável. As duas áreas acreditam, dentro de suas perspectivas, estarem fazendo o melhor para o
negócio. Porém, acabam entrando em conflito. Além disso, tecnologicamente, cada área possui
um conjunto diferente de ferramentas para executar suas atividades, o que gera mais
inconsistência.

Esse assunto, que trata da sincronia do ritmo de entrega do Desenvolvimento e Operações, tem
sido o foco da filosofia DevOps, que reúne uma série de processos, métodos e sistemas de
comunicação, colaboração e integração entre Desenvolvimento, Operações e Quality Assurance.

modScrum 39
Novembro de 2011
Esse novo conceito estende as diversas práticas ágeis e sugestões de integração tecnológica para
diminuir a barreira entre Desenvolvimento e Operações, maximizando os ganhos da agilidade.

Assim, o alinhamento entre as diversas áreas em torno de um objetivo global focado na melhoria
do negócio traz maiores benefícios do que o pensamento isolado de otimização pontual.

A Módulo já vem adotando práticas relacionadas ao DevOps, para aumentar a integração entre
Operações, QA e Desenvolvimento. Dentre as práticas adotadas, podemos citar:

⋅ Criação de times de Infraestrutura, Documentação, QA, Suporte e Gestão de

Conhecimento que também utilizam método e ferramentas ágeis;
⋅ Esses times de Operação trabalham sincronizados com mesmo time box dos sprints dos
times de Desenvolvimento;
⋅ Participação de integrantes das equipes de Operações nas cerimônias dos times de
Desenvolvimento, para que possam antecipar tarefas, se atualizarem com o que está
sendo feito e opinarem sobre como integrar o trabalho dessas equipes;
⋅ Questões tecnológicas ligadas à entrega contínua dos builds e automação de testes
facilitam a integração periódica;
⋅ Reunião diária entre o Product Manager, Gerente de Desenvolvimento, Gerente de
Operações e Diretor de Operações para alinhar todo o trabalho da equipe técnica.

modScrum 40
Novembro de 2011
 Equipe de QA Equipe de Documentação

Equipe de Suporte e Infraestrutura Equipe de Gestão de Conhecimento

modScrum 41
Novembro de 2011
 ANEXOS

modScrum 42
Novembro de 2011
Anexo I – Modelo de Divulgação do Roadmap do Release

modScrum 43
Novembro de 2011
modScrum 44
Novembro de 2011
Anexo II – Ficha de Requisito – Exemplo
Esse artefato é opcional para o registro de algumas informações que caracterizam mais
detalhadamente os requisitos, sendo elas:

Descrição do Problema: explicação sobre a questão que motivou o pedido de inclusão do

requisito no software;

Solução Sugerida: sugestão da modificação no software para que o problema descrito no
item acima possa ser solucionado;

Histórias de Usuário Sugeridas: sugestão de histórias de usuário necessárias para o
desenvolvimento do requisito;

Anexos (opcionais): esquemas com detalhes para a implementação do requisito no
software ou qualquer outra informação que auxilie a compreensão do requisito.

Esse artefato é utilizado como insumo para que as histórias de usuário contidas nele sejam
colocadas no product backlog. A construção e manutenção deste documento são de
responsabilidade do Product Owner. Como dito anteriormente, este é um artefato opcional,
porém, a criação e passagem de histórias de usuário de cada requisito para o product backlog são
obrigatórias, mesmo que este documento não exista, as histórias relacionadas a cada requisito
devem ser criadas.

modScrum 45
Novembro de 2011
384 – CREATE QUERIES AND DASHBOARD GRAPHICS FOR FUI PRIORITY (4-4-5): 80
THREAT SOURCE POINTS (*): 04

DESCRIPTION
Create new risk query and graphic in dashboard for Threat source.

PROBLEM DESCRIPTION
Como não existe a solução de ERM ainda na versão 7, e alguns clientes querem cadastrar seus Riscos
e relacionar estes "Riscos" com outros elementos de consolidação, há uma necessidade de consolidar
alguns indicadores para o objeto de Fonte de Ameaça (que no caso estará sendo usado como elemento
consolidador).

SUGGESTED SOLUTION
Criar mais um objeto de consolidação de riscos (Fonte de Ameaças) em uma consulta de forma que seja
possível visualizar os resultados dos indicadores de Risco, consolidados por este elemento, análogo ao
que já é feito para Ameaças. Deve-se criar uma nova dimensão nos gráficos do Dahboard (Fontes de
Ameaça) para refletir também as consolidações (o usuário deve escolher Fonte de Ameaças como
dimensão, os indicadores a serem consolidados Risk Index, Control Index, Security Index, Gap Index
e PSR, e os mesmos filtros que já são usados para o Objeto Ameaças).
A consolidação será feita de forma análoga ao que é feito para o objeto Ameaças. Ou seja, deverão ser
considerados todos os controles relacionados à fonte da ameaça. Exemplificando, se um controle estiver
relacionado a duas ameaças relacionadas à uma mesma fonte de ameaça, será contado duas vezes.

USER STORIES
1. Eu como usuário do módulo de riscos, quero gerar uma consulta de Riscos por Fontes de Ameaça.
2. Eu como usuário do módulo de Dahboard, quero gerar um gráfico de consolidação de indicadores
de risco pela dimensão Fontes de Ameaça.

* Métrica de esforço = Quantidades de Recursos/Semana

modScrum 46
Novembro de 2011
modScrum 47
Novembro de 2011
Anexo III – Lista de verificação para planejamento das histórias
Para avaliar o esforço e planejar o desenvolvimento de cada história, as equipes devem refletir
criticamente sobre os seguintes pontos:

1. Quais as necessidades de controle de acesso?

O controle de acesso do Risk Manager é flexível e pode, em alguns casos, ter granularidade para
controlar acesso a funções bem específicas, como “Publicar uma Pesquisa”. Essa flexibilidade é
necessária para que o sistema possa atender ao maior número de casos de uso possível.

Se a história requer controle de acesso:

- Verifique se o que existe implementado atende às necessidades da história.
- Se for necessário ampliar o modelo, quais os novos perfis, papéis e seus respectivos
privilégios?
- Se o perfil ou papel já existe, preciso alterar ou criar um novo privilégio?
- Será necessário criar uma mensagem para acesso negado?

2. A história gera notificação no Meu Espaço?

O Meu Espaço é um módulo que pode “prestar serviço” para diversos outros módulos do Risk
Manager. Um dos benefícios desse módulo é apresentar notificações de diversos tipos para os
usuários imediatamente após a autenticação. Por exemplo:
- Alocação do usuário em papéis (“Você foi alocado como responsável pelo knowledge base
"Controle Unix").
- Notificações sobre eventos relevantes (A entrevista "Pesquisa de compliance SP" do
projeto PRJC10001 foi cancelada.).

Se a história requer notificações no Meu Espaço:

- Qual o texto da mensagem que deve ser gerada (e variáveis?)
- Para quem a mensagem deve ser enviada?

3. A história envia mensagens por e-mail?

Algumas funcionalidades enviam e-mail para informar as pessoas sobre a situação de alguns
processos, por exemplo, entrevistase revisões de entrevistas.

Cada mensagem possui um modelo editável e aceita variáveis da aplicação. Esses modelos podem
ser customizados no módulo Administração.

4. A história precisa de registros de auditoria?

A auditoria do módulo Administração também pode “prestar serviços” para outros módulos do
sistema. Há mensagens de caráter geral, como “Tentativa de entrada no sistema mal sucedida
pelo usuário Administrator.”, mas também é possível usar o recurso de auditoria para registrar
eventos relevantes de outros módulos do sistema.

Se a história requer registros de auditoria:

- Qual é a mensagem que deve ser gravada?
- Qual é o módulo de origem?

modScrum 48
Novembro de 2011
 - Existe necessidade de incluir mais alguma informação nos registros já existentes (por
exemplo, recentemente foi adicionado o endereço IP do servidor associado)?

5. A história permite customização da apresentação?

Através das customizações de apresentação no módulo Administração, o administrador pode
configurar (como padrão para todos os usuários do sistema) o idioma da interface, a quantidade
de itens por página nas listas e decidir se quer exibir ou ocultar gráficos por padrão.

6. A história permite customização de preferências dos usuários?

Através das customizações de preferências no Meu Espaço, o usuário pode configurar o idioma da
interface, a quantidade de itens por página nas listagens e decidir se quer exibir ou ocultar gráficos
por padrão.

De um modo geral, as preferências do usuário também são as customizações da apresentação.

7. A história requer atributos customizados?

Através das customizações de atributos customizados no módulo Administração, é possível criar
diversos tipos de metadados (novas propriedades) para ativos e perímetros, como anexos, campos
data/hora, e-mail, links, campos de listas de opções genéricas, campos tipo número, parágrafo,
texto e lista de tópicos.

A história requer algum novo tipo de atributo customizado?

8. A história requer restrição aos integrantes que podem exercer um papel?

Através da configuração de integrantes permitidos para papéis no controle de acesso no módulo
Administração, é possível definir que um determinado papel do sistema deve aceitar somente
certas pessoas ou grupos de pessoas. Por padrão, apenas alguns papéis aceitam estas
configurações.

Caso a história introduza novos papéis (ver questão 1), existe necessidade de criar uma lista de
integrantes autorizados para ele?

9. A história permite integrações com outros sistemas?

Através da configuração de tarefas de integração no módulo Administração, é possível integrar o
Risk Manager com outros sistemas ou serviços.

A história tem necessidade de integrações que possam utilizar esse modelo?

Caso afirmativo, quais são os atributos desta (tarefa de) integração? Qual é o propósito da
integração? Onde os dados serão exibidos? Etc.

10. A história requer novos tipos de eventos no Workflow ?

O Workflow é um módulo que pode ser utilizado isoladamente (eventos padrão), mas também
“presta serviço” para os módulos de Risco e de Compliance (através dos eventos de tratamento).

A história pode criar eventos que utilizem os serviços do Workflow?

modScrum 49
Novembro de 2011
Em caso afirmativo, os eventos existentes são adequados, ou a história requer a criação de algum
novo tipo de evento? Quais são os atributos? Etc.

11. A história requer indicadores para o Dashboard?

O Dashboard é um módulo que também “presta serviço” para os módulos de Risco, Compliance e
Workflow, permitindo a visualização gráfica de indicadores gerados por esses módulos em
dashboards criados pelos próprios usuários.

A história pode se beneficiar dos serviços do Dashboard?

Em caso afirmativo, há necessidade de criação de algum novo tipo de gráfico? Quais são os
indicadores e dimensões?

De onde virão os dados (organização, projetos ou outras fontes)?

Quais filtros serão aplicáveis?

12. A história pode gerar consultas para a Organização, Riscos, Compliance?

Já existe a funcionalidade de gerar consultas para a organização, para projetos de risco e projetos
de compliance. Essas consultas podem ser criadas pelos usuários autorizados através de
assistentes para diversos objetos, na forma de tabela e mapa (para certos objetos).

Se a história requer criação de novas consultas ou alteração em alguma das consultas existentes:
- Quais são os objetos da consulta?
- Quais são os requisitos para definição do escopo?
- Quais são os requisitos para definição dos filtros?
- Quais são os requisitos para seleção de colunas?
- Quais são os requisitos para exibição dos resultados? Haverá representação em mapas?
(ver item 16 da lista de verificação)

13. A história requer gráficos?

Há muitas partes do Risk Manager onde são exibidos gráficos (fora do contexto do dashboard). Um
caso comum é a exibição de gráficos acima de listas.

Se a história requer a exibição de um gráfico:

- Qual é o tipo de gráfico (pizza, histograma, etc)?
- Se as fatias, barras ou outras indicações vão exibir números absolutos ou percentagens
(%)?
- Como o gráfico é calculado?
- Quais são as cores, legendas, rótulos e títulos, quando aplicável?
- Qual deve ser o comportamento quando não existirem dados para a geração do gráfico?
- Qual a escala cromática que ele pode utilizar? (Administração > Customizações > Escalas)

14. A história possui listagens?

Há muitas partes do Risk Manager onde são exibidas listagens (grids).

Se a história requer a exibição de uma listagem:

modScrum 50
Novembro de 2011
 - Quais colunas devem ser exibidas?
- Quais colunas são ocultas?
- Qual é a ordem padrão das colunas?
- Haverá recursos de agrupamento?
- Haverá recurso de filtros avançados?
- Haverá paginação?
- Haverá exportação da listagem para PDF, XLS ou outros formatos?

15. A história requer formulários para cadastramento ou edição de dados?

Há muitas partes do Risk Manager onde são exibidos formulários para os usuários cadastrarem ou
editarem dados.

Se a história requer a exibição de um formulário:

- Quais campos são opcionais e quais são obrigatórios?
- Quais são as condições para validação dos dados (tamanho mínimo, tamanho máximo,
máscaras (formatos válidos))?
- Quais os rótulos dos campos e apoio para preenchimento (help de campo)?
- Quais os botões do formulário e suas ações dos botões?
- Existe necessidade de help de campo? (apoio para o preenchimento?)

16. A história requer help de página?

Há muitas partes do Risk Manager onde são exibidos helps de página para ajudar o usuário.

Se a história requer a exibição de help de página:

- Colocar a marcação com o ícone apropriado nos locais adequados;
- Solicitar para a equipe de Documentação a geração do texto adequado.

17. A história requer mapas?

Há muitas partes do Risk Manager onde são exibidos dados em formato de mapas (Google Maps).

Se a história requer a exibição de mapas:

- Quais entidades requerem coordenadas georreferenciais?
- Como o mapa será representado (inicialização)?
- Qual o conteúdo do detalhe do mapa (balão com detalhes)?

18. A história permite importação e/ou exportação de dados de planilhas?

Há muitas partes do Risk Manager onde se pode importar e exportar dados para planilhas Excel, e
há diferentes padrões para isso.

Se a história requer a importação e/ou exportação de dados para planilhas:

- Se algum dos padrões já existentes para esta funcionalidade pode ser utilizado;
- Limitações de tamanho dos arquivos importados;
- Limitação de formatos dos arquivos;
- Se haverá validação ANTES da importação;
- Quais devem ser os testes e as respectivas mensagens de validação da importação.

modScrum 51
Novembro de 2011
19. A história requer ícones?
No Risk Manager existem ícones em vários locais, nas páginas iniciais, nos diálogos com o usuário
e nos botões. O ícone que a história necessita já existe?

20. A história requer novo item no menu?

Um item no menu pode representar uma página inicial ou uma página secundária. Essas duas
páginas requerem ícones, textos e links para o novo item?

21. A história requer um assistente?

Funcionalidades que são complexas de serem realizadas podem ter o apoio de assistentes, por
exemplo, criar um gráfico para o Dashboard.

22. A história requer diálogos com o usuário ou mensagens?

O Risk Manager utiliza diálogos com o usuário para confirmar operações, alertar sobre problemas
no processo ou para informar parâmetros durante uma funcionalidade.

Mensagens com o usuário são utilizadas para dar o retorno de operações de sucesso e erro?

23. A história afeta informações em relatórios, planilhas ou aplicativos (Report Editor, iPhone
app) (termos que mudam em uma área não necessariamente mudam em outra)?

24. A história requer um filtro?

Filtros de um modo geral são funcionalidades complexas de serem realizadas. O Risk Manager
possui diálogos que chamamos de Power Search que permitem aplicar filtros para localizar
elementos do sistema.

25. A história requer criar novos termos ou palavras reservadas no glossário?

Existe uma lista de termos e conceitos no Risk Manager que fazem parte de um glossário de
palavras reservadas e respectiva terminologia e tradução.

- A história deve criar novos termos para o sistema?

- Os termos possuem seus conceitos definidos e descritos?
- As traduções dos termos está disponível?

modScrum 52
Novembro de 2011
26. A história requer criar novas entidades ou objetos para o modelo conceitual?
Existe um diagrama que consolida os principais conceitos e entidades do sistema e como eles se
relacionam entre si. A história prevê a criação de novas entidades ou objetos que complementam
esse modelo conceitual?

27. A história requer compatibilidade com diferentes sistemas, como, por exemplo, Firefox ou
outros navegadores?

28. A história possui requisitos de performance?

29. A história requer ordenação ou definição de valores default para campos ou dados?

30. A história requer quebra de linhas em textos multilinhas?

31. A história requer compatibilidade com a versão anterior do sistema? Nesse caso, precisa
atualizar o sistema de migração?

32. A história requer performance aceitável com bases grandes?

33. A história funciona com tema cinza?

34. A história requer uso concorrente?

35. A história funciona com usuário limitado?

modScrum 53
Novembro de 2011
Anexo IV – Exemplos de Feedback e Sugestões das Reuniões de
Retrospectiva das Equipes

Sprint 22

modScrum 54
Novembro de 2011
modScrum 55
Novembro de 2011
Sprint 29

Sprint 30

modScrum 56
Novembro de 2011
Anexo V - Scorecard dos Sprints (Burn-up Release)

modScrum 57
Novembro de 2011
 Indicadores na Sala do Diretor Técnico

modScrum 58
Novembro de 2011
Anexo VI – Princípios do Manifesto Ágil
Nós seguimos os seguintes princípios:

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

contínua de software de valor.

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.

3. Entregar software funcionando com frequência, na escala de semanas até meses,

com preferência aos períodos mais curtos.

4. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto

e diariamente, durante todo o curso do projeto.

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.

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 pessoal.

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

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

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

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

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-

organizáveis.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e otimizam seu comportamento de acordo.

modScrum 59
Novembro de 2011
Anexo VII - Histórico - “Por onde começamos?”
Para a migração para os times multidisciplinares, houve um período de estruturação na equipe
técnica da Módulo. Foi contratado um treinamento para o alinhamento do conhecimento sobre o
método Scrum, com três turmas de 20 profissionais cada. Durante os meses de novembro e
dezembro de 2010, diversas decisões foram tomadas quanto à lógica de funcionamento do Scrum
na Módulo.

⋅ Adoção do Scrum – salvo pequenas modificações, optou-se por adotar o Scrum na íntegra,
como colocado na sua teoria, para que as adaptações venham com a experiência prática.
Aproveitou-se também a experiência do uso de Scrum que vinha sendo utilizado pela
equipe de desenvolvimento desde 2009.

⋅ Composição dos Times – os times foram compostos por analistas, pesquisadores,

programadores, equipe de teste e designers. A equipe de documentação não foi incluída e
trabalha com um ciclo defasado. Os profissionais de QA participam como ouvintes,
obtendo insumos para a confecção de casos de testes.

⋅ Execução dos testes de QA (Quality Assurance) – os testes de homologação realizados

pela equipe de QA são executados durante os sprints e antes da liberação de cada Release.

⋅ Envolvimento da equipe – para a implementação de equipes multidisciplinares, todos, ao

mesmo tempo, migraram para o novo método.

⋅ Backlog de bugs – como existia um grande backlog de bugs no início do processo, os 15

primeiros dias de janeiro de 2010 foram reservados para que as equipes focassem na
resolução desses bugs. Após essa lista bastante reduzida, os bugs restantes foram
pontuados como se fossem histórias de usuário e endereçados pelo Product Owner para
serem corrigidos durante os sprints. Novos bugs introduzidos pelo time durante o
desenvolvimento são resolvidos imediatamente, sem necessidade de passar pelo backlog
de bugs. As equipes também são incentivadas a corrigir imediatamente outros bugs
encontrados nos sprints. Nesse caso, a equipe de QA é informada para a gestão atual que
inclui outros bugs encontrados por usuários ou durante os testes de homologação
realizados pela equipe de QA.

Referências
Para um conhecimento mais específico do framework Scrum e metodologias ágeis, algumas
referências podem ser consultadas:

modScrum 60
Novembro de 2011
 • Sites
⋅ http://agilemanifesto.org/
⋅ http://www.controlchaos.com
⋅ http://visaoagil.wordpress.com
⋅ http://martinfowler.com
⋅ www.implementingScrum.com
⋅ http://www.infoq.com
⋅ www.Scrumalliance.org
⋅ http://www.sprint-it.com/
⋅ http://Scrum4you.wordpress.com
⋅ http://amagno.blogspot.com
⋅ http://www.improveit.com.br
⋅ http://www.teamware.com.br/
⋅ http://mountaingoatsoftware.com/Scrum
⋅ www.tecgraf.puc-rio.br/nrtoledo
⋅ http://www.bridgeconsulting.com.br/conhecimento-em-ti/publicacoes-bridge/item/59-
desafios_beneficios_scrum.html

• Livros
⋅ “Agile Software Development with Scrum”, Ken Schwaber e Mike Beedle
⋅ “Agile Project Management with Scrum”, Ken Schwaber
⋅ “Enterprise Scrum”, Ken Schwaber
⋅ “Scrum and XP from the treches” (versão brasileira gratuita em:
www.infoq.com.br/minibooks/Scrum-xp-direct-from-the-treches)
⋅ “Agile Project Management” (disponível na web)
⋅ “The New Methodology”, Martin Fowler (disponível na web)
⋅ Jeff-Sutherland-7-Ways-To-Fail-With-Scrum.pdf

• Videos On-line
⋅ Jeff Sutherland (2007) – http://www.infoq.com/interviews/jeff-sutherland-Scrum-rules
⋅ Jeff Sutherland (2006) – http://www.infoq.com/presentations/The-Roots-of-Scrum
⋅ Google Tech Talks – http://www.youtube.com/watch?v=9y10Jvruc_Q
⋅ Google Tech Talks – http://www.youtube.com/watch?v=Ht2xclJrAXo
⋅ Ken Schwaber - http://www.youtube.com/watch?v=lyNpeTn8fpo#
⋅ Ken Schwaber - http://www.infoq.com/presentations/agile-quality-canary-coalmine
⋅ Mike Cohn - http://www.youtube.com/watch?v=FkWglejhJZM
⋅ Mike Cohn - http://www.youtube.com/watch?v=fb9Rzyi8b90
⋅ Mike Cohn - http://www.infoq.com/presentations/prioritizing-your-Product-Backlog-mike-
cohn
⋅ David Anderson (futuro dos métodos ágeis, Lean/Kanban, CMMI) -
http://www.infoq.com/presentations/Agile-Directions-David-Anderson

modScrum 61
Novembro de 2011
 ⋅ Agile Testing (Google Tech Talks) -
http://www.youtube.com/watch?v=bqrOniECCSg&feature=related
⋅ Scott Ambler - http://www.infoq.com/news/2007/05/ambler-role-of-testing
⋅ Scott Ambler - http://www.infoq.com/presentations/Agile-in-Practice-Scott-Ambler
⋅ Métodos Ágeis em Larga Escala - http://www.infoq.com/presentations/5-Success-Factors-
Michael-Mah
⋅ Modelagem Ágil na TDC 2008 - http://visaoagil.wordpress.com/author/vmteles
⋅ Tese de Mestrado na USP – http://agileandart.blogspot.com/2009/05/máster-thesis-
defense-video.html

Agradecimento
Este documento foi construído em parceria com a empresa Bridge Consulting®.

www.bridgeconsulting.com.br

modScrum 62
Novembro de 2011