Scrum - Origens Da complexidade dos sistemas ao Scrum

1. scrum:origens
Yóris Linhares

2. 2
scrum:origens
Yóris Linhares
Setembro de 2014

3. Scrum: origens
Os homens nunca estão satisfeitos até eles conhecerem o
“porquê” de uma coisa – Aristóteles
Por que software é complexo ? Por que abordar o
desenvolvimento de software na perspectiva da
complexidade ? Por que o Scrum ?
Muito se sabe como o Scrum funciona, muito se sabe o que
é o Scrum, entender o porquê do Scrum ser usado no
desenvolvimento de software, em que bases ele foi criado,
quais os fundamentos de onde ele emergiu e o porquê da
sua estrutura é valorizar o Scrum e melhor entender os
retornos crescentes advindos da sua aplicação.
3

4. Renúncia
Esta obra é fruto da interpretação do autor a respeito dos assuntos
aqui tratados. Não podendo se caracterizar como base definitiva e
única fonte de suporte aos conhecimentos desejados pelo leitor.
Sobre o Autor
Yóris Linhares desenvolveu software para as principais instituições
financeiras públicas e privadas do Brasil, ERP para as maiores
empresas brasileiras do setor de alimentação industrial e liderou
equipes de desenvolvimento durante os últimos 20 anos. Trabalha no
desenvolvimento de software para o Governo Federal do Brasil e
leciona disciplinas relacionadas a gestão de projetos, engenharia de
software e gestão do conhecimento e informação em cursos de pós-
graduação e MBA's, além de compartilhar o que sabe por meio de
palestras, treinamentos e mentorias. É mestre em Administração e
bacharel em Ciência da Computação.
Para mais informações:
br.linkedin.com/in/yorisls/
lattes.cnpq.br/9659321335984012
yoris.linhares@gmail.com
4

5. 5
Sumário
Iniciando ........................................................................................................................................................................ 06
Por que software é complexo ........................................................................................................................................ 07
Por que abordar o desenvolvimento de software na perspectiva da complexidade ? ................................................. 10
Por que o Scrum ? .......................................................................................................................................................... 18
Fechando... .....................................................................................................................................................................21
Referências Bibliográficas.............................................................................................................................................. 22

6. Iniciando...
A crença de que todas as coisas podem ser conhecidas (no
sentido newtoniano) persistiu por séculos. O crescimento
da tecnologia e o domínio de abordagens baseadas em
engenharia, decorrentes da necessidade de automação e
escalabilidade, reforçaram o desejo e a assunção desta
ordem. O desenvolvimento da ciência da administração, a
partir da visão Taylorista do controle do tempo e da
produção até a reegenharia dos processos de negócio,
estava enraizada na crença de que os sistemas são
ordenados, e seriam apenas uma questão de tempo e de
recursos antes que as relações entre causa e efeito
fossem descobertas [3].
O que todas essas abordagens e percepções não
aceitavam é que há situações em que a falta de ordem
não é uma questão de má investigação, recursos
inadequados ou falta de compreensão, mas é, a priori, o
caso - e não necessariamente uma coisa ruim. Uma nova
consciência para uma contrapartida sobre ordem
começou há mais de um século atrás e cresceu nas
últimas décadas. A nova ciência da complexidade, gerada
por estas descobertas, é interdisciplinar e toca campos
como a matemática, evolução, economia, meteorologia e
telecomunicações [3].
Em se tratando de desenvolvimento de software,
abordagens preditivas, que tentam controlar tudo a priori
em um ambiente complexo como o desenvolvimento de
software, tem apresentado desempenho aquém de suas
potencialidades, com projetos atrasados, acima do
orçamento e com resultados deficientes. Mesmo
reconhecendo que há certos softwares e ambientes de
desenvolvimento que se apresentam com baixa
complexidade e onde os ganhos de aplicação de uma
visão newtoniana-taylorista estão presentes, uma elevada
parte dos softwares e dos seus processos de
desenvolvimento se encontram em ambientes complexos.
Os conceitos da teoria da complexidade foram
introduzidos juntamente com uma distinção importante
entre processos empíricos e preditivos. Negócios
empresariais são percebidos como sistemas adaptativos
complexos e os softwares que funcionam neles se
tornaram igualmente complexos. Usar controle de
processos empíricos para prever o comportamento
caótico tem se mostrado a essência do Scrum [12].
6

7. Por que software é complexo ?
A complexidade em software possui características que
derivam dos quatro elementos seguintes [11].
A complexidade do domínio do problema
A capacidade necessária para o usuário resolver um
problema ou atingir um objetivo, conhecido como
requisitos de software, podem ser difícil de se expressar.
Ao adicionar todos os (muitas vezes implícitos) requisitos
não-funcionais, tais como usabilidade, desempenho,
custo, capacidade de sobrevivência e confiabilidade, tem-
se uma complexidade ainda maior para expressá-los.
Toda esta complexidade geralmente é percebida no
"déficit de comunicação" que existe entre os diversos
atores: clientes, usuários e desenvolvedores de um
software. Para tentar suplantar esta dificuldade entre os
atores, a forma comum é registrar os requisitos em uma
grande quantidade de texto formatado, acompanhado de
alguns desenhos, mas que podem ser de difícil
entendimento, visto que dependem do contexto e do
conhecimento e da interpretação dos atores envolvidos.
Uma complicação a mais é que os requisitos de software
geralmente mudam durante o desenvolvimento. Isto
acontece porque o tempo até a apresentação do requisito
traduzido em uma solução no software ser demasiado
longo, dando tempo para que o usuário ou cliente mude
de ideia sobre algo ou por um efeito resultante da
interação entre os atores, onde a simples apresentação
do software ao usuário pela equipe de desenvolvimento
faz com que o requisito mude, traduzido normalmente
pela frase "não era isto o que eu queria".
A dificuldade de gerir o processo de desenvolvimento
A tarefa fundamental da equipe de desenvolvimento de
software é criar uma solução simples para um problema
complexo. No entanto, para atender o volume de
requisitos às vezes a equipe de desenvolvimento é
obrigada a escrever uma grande quantidade de código
para um novo software ou a reutilização de muito código
ou software existente em novas formas. Com isto, se pode
chegar a milhares ou até milhões de linhas de código
combinadas e que interagem de outras milhares de
formas diferentes. O que gera enorme complexidade para
as pessoas que estão trabalhando nestes códigos.
Nenhuma pessoa possui cognição suficiente para
entender tal software completamente. Para enfrentar
este desafio utilizamos uma equipe com desenvolvedores
7

8. de software. Ter mais desenvolvedores significa uma
comunicação mais complexa e, portanto, uma
coordenação mais difícil além da necessidade contínua de
manter uma unidade e integridade do software que está
sendo criado.
A flexibilidade possível através de Software
Uma empresa de construção civil não forja vigas
personalizados para um novo edifício. Quando o edifício
está construído, há enorme restrição para mudar, quando
não inviável estruturalmente, alguma porta ou janela de
lugar mesmo que o cliente queira. No entanto, na
indústria de software, tais práticas são comuns. Software
é criado em camadas e estruturas extremamente flexíveis.
O desenvolvedor pode criar blocos de códigos básicos e
personalizados para um software. Mudanças em um
software, com quase nenhuma exceção, são viáveis.
Assim, software oferece a máxima flexibilidade. E como
resultado desta flexibilidade, o software é intensivamente
dependente do esforço e conhecimento das pessoas.
O problema do comportamento
Peças de um motor de um automóvel, que por si só são
unidades completas, para atingir o objetivo de gerar o
necessário para mover um automóvel precisam estar
conectadas e interdependentes. Blocos pequenos de
código de software são criados para atender a pequenas
necessidades e interagem entre si para alcançar
funcionalidades de negócio do cliente. Em software estes
pequenos blocos de código são feitos aos milhares e
permitem várias combinações que geram uma explosão
de comportamentos diferentes. Assim como mudar uma
peça do motor pode gerar um comportamento diferente
do automóvel, mudanças em pequenos blocos de
software podem gerar novos comportamentos, por vezes
inesperados e não desejados. Além disto, como colocar
um combustível diferente para o motor de um automóvel
pode mudar os resultados do mesmo, mudanças no
ambiente onde estão estes softwares e nos dados que
entram neles podem gerar resultados diferentes e por
vezes inesperados. Este é um motivo forte para se
executar uma grande bateria de testes em software.
8

9. Entretanto, testes exaustivos e completos a respeito de
todos os possíveis comportamentos em algo tão
complexo como software, podem estar fora da
capacidade intelectual dos desenvolvedores e de
qualquer modelo matemático de predição de
comportamento. Um caminho é trabalhar com níveis
aceitáveis de confiança em relação à exatidão desejada.
9

10. Por que abordar o desenvolvimento de software na
perspectiva da complexidade ?
O termo sistemas adaptativos complexos (SACs)
representa os sistemas que possuem elevado número de
elementos, com grande fluxo de interação e aprendizado.
Os sistemas adaptativos mudam com cada nova
informação que o ambiente capta através de um processo
de aprendizado[10] [2]. A interação entre os agentes
adaptativos promovem a auto-organização do sistema, o
que resulta em uma compreensão do mundo como um
fenômeno transdisciplinar. Os sistemas adaptativos
complexos são caracterizados pelas “interações entre
agentes individuais e desses com o ambiente, tal que
emergem padrões não determinados de comportamento
do sistema” [1].
São propriedades comuns aos SAC's [10]:
• Emergência: Ao invés de ser planejados ou
controlados os agentes do sistema interagem de
maneira aparentemente aleatória. De todos esses
padrões de interação emerge o comportamento dos
agentes dentro do sistema e o comportamento do
sistema em si.
• Co-evolução: Todos os sistemas existem dentro de seu
próprio ambiente e eles também fazem parte desse
ambiente. Portanto, quando o ambiente muda o
sistema também precisa mudar para garantir um
melhor ajuste. Mas porque eles fazem parte de seu
ambiente, quando mudam, mudam de ambiente, e
como ele muda eles precisam mudar novamente, e
assim por diante como um processo constante.
• Sub ideal: Um sistema complexo adaptativo não
precisa ser perfeito para que a prosperar no seu
ambiente. Ele só tem de ser ligeiramente melhor do
que seus concorrentes e toda a energia utilizada em
ser melhor do que isso é desperdício de energia.
• Variedades: Quanto maior a variedade dentro do
sistema, mais forte. A ambiguidade e o paradoxo
abundam em sistemas adaptativos complexos, que
utilizam as contradições para criar novas
possibilidades de co-evolução com o ambiente .
• Conectividade: As formas em que os agentes em um
sistema se conectam e se relacionam uns com os
outros é fundamental para a sobrevivência do
sistema, pois é a partir dessas conexões que os
padrões são formados e o conhecimento
compartilhado. As relações entre os agentes são
10

11. geralmente mais importantes do que os próprios
agentes.
• Regras Simples: Sistemas adaptativos complexos não
são complicados. Os padrões emergentes podem ter
uma variedade rica, mas como um caleidoscópio, as
regras que regem a função do sistema são bastante
simples.
• Iteração: Pequenas mudanças nas condições iniciais
do sistema podem ter efeitos significativos após
terem passado através do ciclo emergência-feedback
algumas vezes.
• Auto-organização: não há hierarquia de comando e
controle em um sistema complexo adaptativo. Não há
nenhum planejamento ou gestão, mas há uma
constante re-organização para encontrar o melhor
ajuste com o ambiente.
• Beira do caos: Um sistema em equilíbrio não tem a
dinâmica interna que lhe permita responder ao seu
ambiente e lentamente (ou rapidamente) morrer. Um
sistema no caos deixa de funcionar como um sistema.
O estado mais produtivo é estar à beira do caos, onde
há variedade máxima e criatividade, levando a novas
possibilidades.
• Sistemas aninhados: A maioria dos sistemas são
aninhados dentro de outros sistemas e sistemas de
muitos sistemas de sistemas menores.
Ao abordar a organização do desenvolvimento de
software como um sistema adaptativo complexo,
percebe-se que estes agentes são os indivíduos (pessoas)
que atuam neste trabalho. Mas não apenas um conjunto
de indivíduos que trabalham sozinhos, mas também
interagindo - colaborando e competindo, em diferentes
níveis. Estes elementos organizacionais por meio de suas
interações organizam o sistema. Eles não só interagem
uns com os outros, mas eles dependem uns dos outros,
por exemplo através da distribuição de funções e tarefas
para os indivíduos. Assim, enquanto os indivíduos são os
elementos básicos (agentes) que constituem as
organizações, é deles e de suas interações o que é
essencial para o desempenho organizacional.
Percebe-se necessária uma abordagem que permita lidar
com as propriedades dos SAC's para se conduzir o
desenvolvimento de software em direção a retornos
satisfatórios. Neste sentido, o framework Cynefin [3],
composto por 5 domínios (Simples, Complicado,
Complexo, Caótico e Desordenado) – figura 1, que
corrobora na tomada de decisão para uma ampla gama de
11

12. problemas, quando aplicado ao desenvolvimento de
software aponta caminhos para lidar com a complexidade
essencial do software.
Figura 1. Adaptado - Cynefin framework [3]
12

13. Entendendo o software como algo complexo e
observando seu desenvolvimento se comportando como
um SAC, pode-se analisá-lo como um problema que
repousa no domínio Complexo do Cynefin. Neste domínio,
há uma falta de ordem, onde o relacionamento entre
causa e efeito pode ser percebido apenas em
retrospectiva e os resultados são imprevisíveis. Para
navegar por este domínio é preciso criar um clima
tolerante às falhas [3]. Não é possível resolver problemas
complexos utilizando-se das melhores ou boas práticas
impostas previamente, mas sim permitir que elas
emerjam durante os trabalhos. Enquanto se conduz
experimentos é necessário eliminar as partes que falham
e melhorar as partes bem sucedidas. Portanto, para este
domínio, a abordagem é: experimentar, sentir/entender
as falhas e/ou sucessos e responder/decidir o que fazer
(melhorar sucessos ou eliminar falhas) [3].
Esta abordagem é observada em processos empíricos. O
empirismo defende que as teorias devem ser baseadas
em observações do mundo, em vez da intuição ou fé.
Defende a investigação empírica e o raciocínio dedutivo.
Todo o processo do conhecer, do saber e do agir é
aprendido pela experiência, pela tentativa e erro. Grande
parte da nossa sociedade é baseada em processos que
funcionam somente porque o seu grau de imprecisão é
aceitável. Entretanto, o que acontece quando se está
construindo algo que requer um grau de precisão maior
do que a média obtida anteriormente? O que acontece se
qualquer processo que inventado para a construção de
carros é muito impreciso, e é necessário aumentar o nível
de precisão? Nesses casos, temos que orientar o processo
passo a passo, garantindo que o processo converge para
um grau aceitável de precisão. Nos casos em que a
convergência não ocorre, temos que fazer adaptações
para que o processo volte para a faixa de níveis de
precisão aceitável. Estabelecendo um processo que
repetidamente irá produzir uma saída de qualidade
aceitável é chamado de controle de processo definido.
Quando o controle do processo definido não pode ser
alcançado por causa da complexidade das atividades
intermediárias, algo chamado controle de processos
empíricos tem de ser empregado [4].
Há uma complexidade essencial em software [11] e seu
desenvolvimento pode ser abordado como um SAC. Ao
perceber o problema da complexidade em software e em
seu desenvolvimento sob o domínio complexo, conforme
o framework Cynefin [3], percebe-se que é necessária uma
abordagem empírica que lide com a gestão e o
desenvolvimento.
13

14. O artigo “The new new product development game” [5] de
1986 apresentava alguns conceitos, consolidados de
estudos realizados em diversas empresas, e que apontava
uma nova abordagem de gestão e desenvolvimento para
ambientes complexos:
1. Instabilidade embutida: A alta administração ou a
primeira linha de gestão, inicia o processo de
desenvolvimento estabelecendo a principal meta ou a
direção geral estratégica. Raramente mostra um conceito
definido ou plano específico de trabalho, mas oferece ao
grupo de projeto ampla medida de liberdade e também
estabelece metas extremamente desafiantes.
2. Grupo de projeto auto organizado: O grupo projetista
opera, a princípio, como uma empresa que acaba de ser
aberta – com seus erros e acertos, e desenvolve uma
pauta independente. Em um certo ponto o grupo começa
a criar o seu próprio conceito. O grupo desenvolve a sua
capacidade de auto-organização quando apresenta três
condições:
• Autonomia: Responsável em providenciar orientação,
capital e apoio moral para iniciar o processo, a direção
da empresa raramente interfere e o grupo fica livre
para desenvolver o seu projeto.
• Auto Superação: O grupo se vê absorvido em um
limite sem fim para o projeto. Começam com a
diretriz dada pela empresa, e a partir daí estabelecem
as suas próprias metas e, durante o desenrolar do
projeto continuam a elevar o nível das mesmas.
• Troca de idéias: Um grupo formado por membros
especializados em diferentes funções, por meio de
padrões de processados e comportamento, conduz o
desenvolvimento de um novo produto.
3. Desenvolvimento de fases sobrepostas: A característica
de auto organização do grupo produz dinâmica e ritmo
únicos. Apesar de poder haver várias equipes trabalhando
no mesmo produto, cada qual com seu ritmo
diferenciado, elas eles tiveram que trabalhar o tempo de
forma sincronizada dentro do seu próprio ritmo para
conseguirem terminar o projeto. Sob movimento de
seqüência e revezamento, o projeto segue, passo a passo
as diferentes fases, mudando para a seguinte fase
somente depois que todas as expectativas da fase
anterior estejam totalmente satisfeitas.
4. Multi Aprendizagem: Como todos os membros do
projeto ficam sempre em contato com as fontes de
informação, eles reagem rapidamente às mudanças do
mercado. Membros do grupo se empenham em um
processo continuo de tentativas e erros, para diminuírem
14

15. o numero de alternativas a serem consideradas. Eles
também adquirem amplo conhecimento e diversas
qualificações, o que ajuda o grupo a criar um time versátil
e capaz de resolver os problemas rapidamente.
5. Controle Sutil: Apesar do grupo de projeto trabalhar
por conta própria, ele não é descontrolado. O
gerenciamento estabelece checkpoints para prevenir
instabilidade, ambigüidade e tensão de se tornarem um
caos. Ao mesmo tempo, o gerenciamento evita o tipo de
controle rígido que prejudica a criatividade e a
espontaneidade.
6. Transferência de aprendizagem organizacional: A
transferência de aprendizagem para subseqüentes
projetos de desenvolvimento ou para outras partes
dentro da organização acontece regularmente.
Sustentado por estes conceitos, é proposta então uma
abordagem em forma de rugby (jogo britânico tipo o
futebol americano), onde o processo de desenvolvimento
do produto surge a partir de constante interação entre as
pessoas, onde um grupo de pessoas extremamente
disciplinado trabalha junto do início ao fim. Em vez de se
mover de forma pré-definida, com fases altamente
estruturadas, o processo inicia-se com a interação do
grupo e este avança por cada fase mesmo antes da fase
anterior se finalizar. A equipe então se engaja em uma
experimentação iterativa [3]. Esta característica é vista no
desenvolvimento de software por meio do modelo de
desenvolvimento iterativo e incremental.
O desenvolvimento iterativo e incremental tem suas
raízes há longo tempo. Desde o trabalho de Walter
Shewhart nos anos 1930, ciclos de PDSA (Plan, Do, Study,
Act) que depois ficou mais conhecimento pelo Ciclo de
Deming - PDCA (Plan, Do, Check, Act). Se consolidou nos
projetos de desenvolvimento de sistemas da IBM para as
forças armadas americanas nos anos 1970 e 1980. E se
tornou amplamente conhecido a partir dos anos 1990. O
desenvolvimento iterativo é uma abordagem para a
construção de software (ou qualquer coisa), em que o
ciclo de vida total é composto de várias iterações em
sequência. Cada iteração é um mini-projeto independente
composto por atividades como análise de requisitos,
design, programação e teste. A meta para o final de uma
iteração é uma entrega, um sistema parcialmente
completo estável, integrado e testado [4]. Apesar de uma
iteração pode, em teoria, ser apenas para ajuste,
normalmente o sistema parcial cresce incrementalmente
com novos recursos, iteração por iteração; em outras
palavras, o desenvolvimento é progressivo. Assim, temos
15

16. ao final de uma sequência de iterações um incremento
maior que o anterior, resultante de um desenvolvimento
iterativo e incremental – figura 2 [4].
Figura 2. Desenvolvimento iterativo e incremental [4]
16

17. São vantagens de adotar uma abordagem incremental,
atributo central para a agilidade. Primeiro, a entrega
acelerada dos serviços ao cliente: desta forma os
incrementos iniciais do software podem fornecer uma
funcionalidade de alta prioridade, de forma que os
clientes logo poderão obter valor do software durante seu
desenvolvimento. Os clientes podem ver seus requisitos
na prática e especificar mudanças para serem
incorporadas nas entregas posteriores. Segundo,
engajamento do usuário com o software: os usuários do
software precisam estar envolvidos no processo de
desenvolvimento incremental porque devem dar
feedback à equipe de desenvolvimento sobre os
incrementos entregues. Este envolvimento não significa
somente que o software terá mais chances de atender aos
requisitos, mas também que os usuários finais que estão
comprometidos com o software querem vê-lo
funcionando. Ao produzir incrementos de forma contínua
e por meio de pequenos ciclos de trabalho, a equipe tem
a chance de experimentar conceitos, descobrir melhores
soluções, descartar soluções que não funcionaram e se
empenhar em fortalecer soluções que funcionam [9].
A complexidade essencial ao software não se dissipa. O
desenvolvimento de software emerge em um ambiente
onde a complexidade do produto e dos processos
consequentes a sua elaboração solicitam uma abordagem
que lide com as questões presentes e não as evite.
Abordando o desenvolvimento de software na
perspectiva da complexidade, onde as pessoas envolvidas
interagem para colaborar, buscar a organização e
descobrir todas as potencialidades do ambiente,
percebeu-se que com processos empíricos embutidos em
um modelo iterativo e incremental de experimentação,
aprendizado e resposta, tornou-se possível navegar por
toda a complexidade sem que haja rigidez ou caos
demasiado, tornando o desenvolvimento apto a abraçar
as mudanças que sucedem.
17

18. Por que o Scrum ?
Dentro da metáfora proposta no artigo “The new new
product development game” [5], uma atividade que ocorre
durante o jogo de rugby, quando um grupo de jogadores
se forma ao redor da bola e os companheiros de equipe
trabalham juntos para mover a boa pelo campo, dar-se o
nome de Scrum [6]. No inicio dos anos 90 Ken Schwaber
usava, em sua empresa, uma nova abordagem para o
desenvolvimento ao mesmo tempo em que Jeff
Sutherland usava uma abordagem similar na Easel
Corporation. Em 1995, Jeff Sutherland apresentou o
termo Scrum a Ken Schwaber e trabalharam juntos para
apresentar o Scrum como um processo de
desenvolvimento em seu artigo no Object-Oriented
Programming, Systems, Languages & Applications '95
(OOPSLA '95) em Austin - Texas, nos Estados Unidos [12].
Formalizaram assim o framework Scrum. Criou-se um
arcabouço que embutia uma abordagem empírica,
iterativa e incremental, visando a experimentação e
aprendizados contínuos - adaptativa - necessários para
lidar com a gestão e promover o desenvolvimento de
produtos imersos em complexidade [8].
Os princípios Scrum são consistentes com o manifesto
ágil publicado em 2001 [6]:
• Pequenas equipes de trabalho são organizadas de
modo a “maximizar a comunicação, minimizar o
compartilhamento de conhecimento tácito informal.
• Precisa ser adaptável tanto a modificações técnicas
quanto de negócios “para garantir que o melhor
produto seja produzido”.
• Produz freqüentes incrementos de software “que
podem ser inspecionados, ajustados, testados,
documentados e expandidos”.
• O trabalho de desenvolvimento e o pessoal que o
realiza é dividido “em partições claras, de baixo
acoplamento, ou em pacotes”.
• Testes e documentação constantes são realizados à
medida que o produto é construído.
• Fornece a “habilidade de declarar o produto ‘pronto’
sempre que necessário”.
18

19. Os princípios Scrum são usados para guiar as atividades
de desenvolvimento dentro de um processo que
incorpora as seguintes atividades de arcabouço:
requisitos, análise, projeto, evolução e entrega. Estas
atividades ocorrem dentro de uma iteração, denominada
sprint pelo Scrum, que é adaptado ao problema em mãos
e é definido e modificado pela equipe Scrum. Três pilares
sustentam qualquer implementação de controle de
processos empíricos, como Scrum [8]:
• A transparência garante que aspectos do processo
que afetam o resultado estão visíveis para aqueles
que gerenciam os resultados. Esses aspectos não
apenas devem ser transparentes, mas também o que
está sendo visto deve ser conhecido. Isto é, quando
alguém que inspeciona um processo acredita que algo
está pronto, isso deve ser equivalente à definição de
pronto utilizada.
• Os diversos aspectos do processo devem ser
inspecionados com uma frequência suficiente para
que variações inaceitáveis no processo possam ser
detectadas. A frequência da inspeção deve levar em
consideração que qualquer processo é modificado
pelo próprio ato da inspeção. O problema acontece
quando a frequência de inspeção necessária excede a
tolerância do processo à inspeção. Os outros fatores
são a habilidade e a aplicação das pessoas em
inspecionar os resultados do trabalho.
• Se identificado, a partir da inspeção, que um ou mais
aspectos do processo estão fora dos limites aceitáveis
e que o produto resultante será inaceitável, o
processo ou o material sendo processado deverá ser
ajustado. Esse ajuste deve ser feito o mais rápido
possível para minimizar desvios posteriores.
Figura 3. Fluxo Scrum [8]
19

20. O Scrum é constituído de eventos como reunião de
planejamento, reunião diária, revisão da sprint e
retrospectiva da sprint. Consistentes com uma abordagem
empírica, cada evento no Scrum é especificamente
projetado para permitir uma transparência e inspeção
criteriosa além de uma constante adaptação dos
elementos que o preenchem. Todos os eventos Scrum
têm um período de tempo definido previamente - todo
evento tem uma duração máxima, o que faz com que se
deva adequar uma parte do escopo ou trabalho a ser feito
ao tempo disponível e este tempo é menor que o previsto
para fazer todo o escopo ou trabalho. Complementar a
isto, durante várias sprints, versões incrementais
potencialmente utilizáveis do produto são criadas. Desta
forma, há um desenvolvimento iterativo do trabalho e
entregas incrementais do produto [8].
Sendo um framework dentro do qual pode-se empregar
diversos processos e técnicas, é possível acomodar a
auto-organização, controle-sutil, mutiaprendizado,
emergência de padrões e práticas, pequenas mudanças e
evolução. Assim, o papel do Scrum é fazer transparecer a
eficácia relativa das práticas de desenvolvimento para que
se possa melhorá-las, enquanto provê um ambiente
dentro do qual produtos complexos podem ser
desenvolvidos.
20

21. Fechando...
“Ao entender o porquê se está fazendo algo, mais que
como fazê-lo, mais valor se ganha disto” – Dude's Law.
Os padrões de processo Scrum permitem a uma equipe
de desenvolvimento trabalhar de modo bem-sucedido em
um mundo em que a eliminação da incerteza é impossível
[6].
O Scrum aplica processos empíricos para que equipes
auto-organizadas e com liberdade possam desenvolver
produtos de forma iterativa e incremental, navegando em
meio a um ambiente complexo, gerando aprendizagem
constante para vencer os desafios que se apresentam.
O importante é entender os princípios e razões por trás
do simples mecanismo e dos elementos do framework.
Tendo sempre em mente que este entendimento é uma
ajuda para apoiar as equipes e empresas a inspecionar e
adaptar sua forma de trabalho e organização rumo a
excelência.
21

22. Referências Bibliográficas
[1] BORGATTI NETO, Ricardo. Perspectivas da
complexidade aplicadas à gestão de empresas. São
Paulo( SP), 2008. Tese (Doutorado) - Universidade de São
Paulo, São Paulo( SP), 2008.
[2] HOLLAND, John. Sistemas complexos adaptativos e
algoritmos genéticos. In: NUSSENZVEIG, H. Moysés (Org.).
Complexidade & Caos. Rio de Janeiro: UFRJ / COPEA,
1999.
[3] KURTZ, Cynthia F. SNOWDEN, David J. The New
Dynamics of Strategy: Sense-Making in a complex-
complicated world. IBM Systems Journal. Fall 2003.
[4] LARMAN, Craig. Agile and Iterative Development: A
Manager's Guide. Addison Wesley. August 11, 2003
[5] TAKEUCHI, Hirotaka. NONAKA, Ikujiro. The New New
Product Development Game. Harvard Business Review
(January–February 1986).
[6] PRESSMAN, Roger S. Engenharia de Software. 6ª
Edição, Porto Alegre. McGraw Hill, 2010. 860 p.
[7] SCHWABER, Ken. Agile Project Management with
Scrum, Microsoft Press, 2004.
[8] SCHWABER, Ken. SUTHERLAND, Jeff. The Scrum Guide.
The Definitive Guide to Scrum: The Rules of the Game.
July 2013. Access: https://www.scrum.org/Scrum-Guide
[9] SOMMERVILLE, Ian. Engenharia de Software. 8ª
Edição. São Paulo: Addison Wesley, 2007. 592 p.
[10] WALDROP, M. Mitcheel. Complexity. New York:
Touchstone Book, 1992.
[11] YOUNG, Bobbi J. BOOCH, Grady. CONALLEN, Jim.
ENGEL, Michael W. HOUSTON, Kelli A. MAKSIMCHUK,
Robert A. Software Complexity: How Do We Bring Order
to Chaos? Nov 30, 2007.
http://www.informit.com/articles/article.aspx?p=726130
[12] SUTHERLAND, Jeff. The Scrum Papers: Nut, Bolts, and
Origins of an Agile Framework Scrum. Inc. Version 1.1 – 2
Apr 2012. http://jeffsutherland.com/ScrumPapers.pdf.
22

23. 23
Para mais informações:
br.linkedin.com/in/yorisls/
lattes.cnpq.br/9659321335984012
yoris.linhares@gmail.com
Design e projeto gráfico:
Rodrigo Queiroz
Especialista em Artes Visuais, Cultura e Criação (Senac).
Desenhista Industrial formado pela Universidade do Estado
de Minas Gerais (UEMG). Atua no mercado como professor
designer e consultor principalmente nas áreas de design
editorial, sinalética, design social e design corporativo.
rodrigo.queiroz.costa@gmail.com

24. scrum:origens
Yóris Linhares