scrum:origens

Yóris Linhares

2

scrum:origens Yóris Linhares

Setembro de 2014

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

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

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

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

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

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

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

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

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

problemas, quando aplicado ao desenvolvimento de software aponta caminhos para lidar com a complexidade essencial do software.

Figura 1. Adaptado - Cynefin framework [3]

12

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

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

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

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

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

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

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

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

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

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

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

scrum:origens Yóris Linhares