Scrum, lean e os desperdícios do desenvolvimento de software: um estudo exploratório

(1)

INSTITUTO DE CIˆ

ENCIA E TECNOLOGIA

MESTRADO EM ENGENHARIA DE PRODUC

¸ ˜

AO E SISTEMAS

COMPUTACIONAIS

FELIPE DOS SANTOS ANDRADE

SCRUM, LEAN E OS DESPERD´ICIOS DO DESENVOLVIMENTO DE

SOFTWARE: UM ESTUDO EXPLORAT ´

ORIO

RIO DAS OSTRAS, RJ

2016

(2)

SCRUM, LEAN E OS DESPERD´

ICIOS DO

DESENVOLVIMENTO DE SOFTWARE: UM ESTUDO

EXPLORAT ´

ORIO

Disserta¸cão apresentada ao Instituto de Ciência e Tecnologia da Universidade Federal Fluminense, como requisito parcial à obten¸cão do t´ıtulo de Mes-tre em Engenharia de Produ¸cão e Sistemas Com-putacionais.

Campo de Confluˆencia: Engenharia de Sistemas de Informa¸c˜ao.

Orientador:

Prof.a _Dr.a _{Adriana Pereira de Medeiros}

Co-orientador:

Prof. Dr. Carlos Bazilio Martins

Rio das Ostras, RJ

2016

(3)

SCRUM, LEAN E OS DESPERD´

ICIOS DO

DESENVOLVIMENTO DE SOFTWARE: UM ESTUDO

EXPLORAT ´

ORIO

Disserta¸cão apresentada ao Instituto de Ciência e Tecnologia da Universidade Federal Fluminense, como requisito parcial à obten¸cão do t´ıtulo de Mes-tre em Engenharia de Produ¸cão e Sistemas Com-putacionais.

Campo de Confluˆencia: Engenharia de Sistemas de Informa¸c˜ao.

Aprovada em 16 de fevereiro de 2016.

BANCA EXAMINADORA

Prof.a _Dr.a _{Adriana Pereira de Medeiros - UFF} Orientador

Prof. Dr. Carlos Bazilio Martins -Co-orientador

Prof. Dr. Edwin Benito Mitacc Meza- UFF

Prof. Dr. Andr´e Duarte Bueno- UENF

Rio das Ostras, RJ

2016

(4)

Catalogação na fonte. UFF / SDC / Biblioteca de Rio das Ostras.

A553 Andrade, Felipe dos Santos

2016 Scrum, Lean e os desperdícios do desenvolvimento de software um estudo exploratório. / Felipe dos Santos Andrade ; Adriana Pereira de Medeiros, orientadora , Carlos Bazílio Martins, co-orientador. Rio das Ostras : s. n., 2016.

110 f.

Dissertação (mestrado) – Universidade Federal Fluminense, I Instituto de Ciência e Tecnologia. Campus de Rio das Ostras.

1. Desenvolvimento de software. 2. Desperdício. 3. Produçã_o

enxuta. 4. Controle de qualidade. 5. Produçã_{o intelectual. I. Título.}

II. Medeiros, Adriana Pereira de (orientadora). III. Martins, Carlos Bazílio (co-orientador). IV. Universidade Federal Fluminense. Instituto de Ciência e Tecnologia. Campus de Rio das Ostras.

(5)

Agrade¸co aos meus orientadores, Prof.a _Dr.a_{Adriana Pereira de Medeiros e Prof. Dr.} Car-los Bazilio Martins, que conduziram e possibilitaram a realiza¸c˜ao deste trabalho, mesmo com todas as adversidades encontradas no caminho. Sem a sua ajuda e confian¸ca, este trabalho n˜ao seria poss´ıvel.

`

A minha fam´ılia, amigos e colegas de trabalho, por me proverem motiva¸c˜ao durante todo este per´ıodo.

`

A minha parceira Raquel Borba Nascimento, por ter me apoiado e tornado este trabalho poss´ıvel durante este momento de transi¸c˜ao.

(6)

O Scrum é um dos métodos de desenvolvimento ágil mais utilizados no mercado. O fra-mework foi inspirado nas melhores práticas da indústria japonesa, com destaque para o Lean. A abordagem Lean, originada na manufatura automobil´ıstica, tem sido expandida para diversos outros campos, tendo trazido melhorias em rela¸cão a eficácia dos proces-sos e qualidade dos produtos desenvolvidos. Diversas companhias e estudos presentes na literatura indicam a utiliza¸cão do Scrum como meio de aprimorar processos de desenvol-vimento de softwares, tornando-os enxutos. Entretanto, raros estudos retratam de que forma o Scrum implementa o mais primordial princ´ıpio Lean: A identifica¸cão e elimina¸cão de desperd´ıcios. Neste contexto, o presente trabalho apresenta um estudo exploratório que tem como objetivo analisar as poss´ıveis rela¸cões dentre as práticas Scrum e os diferen-tes tipos de desperd´ıcios definidos pelo Lean e adaptados ao desenvolvimento de software. Foi utilizada uma metodologia mista quali-quantitativa, constitu´ıda de um estudo de caso em uma companhia multinacional de desenvolvimento de softwares, que tem sua base na cidade de Auckland e da realiza¸cão de uma survey difundida amplamente aos profissio-nais que atuam com desenvolvimento de software Scrum na Nova Zelândia. Os resultados demonstram que o Scrum trata, direta ou indiretamente, de diversos tipos de desperd´ıcios do desenvolvimento de software. Todavia, verificou-se que a ado¸cão parcial do framework, fato comum na indústria de desenvolvimento, pode possuir efeitos contrários, gerando diversos tipos de desperd´ıcios no processo. Apesar da amostra alcan¸cada ser limitada, impedindo que os resultados sejam generalizados, a pesquisa provê informa¸cões que são de valor para companhias que adotam, ou que pensam em adotar o Scrum.

(7)

Scrum is one of the most popular agile development processes. The framework was inspi-red by the best practices from the Japanese industry, specially by lean thinking. Lean ap-proach was originated in the automotive manufacturing and has been expanded to several other fields, being well-known for bringing significant improvements related to processes efficiency and product quality. Several companies and studies over the literature indicate the use of Scrum as a way of improving software development processes in a Lean manner. However, few studies depict or analise how Scrum implements the most fundamental Lean principle: Visualize and eliminate wastes. Therefore, this study presents an exploratory approach that aims to analyze the possible relationships among the Scrum practices and the different types of waste defined by Lean and adapted to the software development. A mixed-method approach was taken through a qualitative-quantitative methodology that consists of a case study on a software development multinational company located in Auckland and through a survey implemented and widely disseminated to professionals acting with Scrum software development in New Zealand. The results show that Scrum can treat, directly or indirectly, all types of wastes in software development. However, it was found that the partial adoption of the framework, which is common in the software development industry, may have an opposite effect, becoming a source of different types of waste in the process. Despite the limited sample achieved, preventing the results to be generalized, the study provides various information that can be valuable and useful for companies adopting Scrum.

(8)

Lista de Ilustra¸c˜oes . . . p. xii

Lista de Tabelas . . . p. 1

1 Introdu¸c˜ao . . . p. 1

2 Metodologia . . . p. 4 2.1 Objetivo e Questões de Pesquisa . . . p. 5 2.2 Fases da Pesquisa . . . p. 5 2.3 Estudo de Caso . . . p. 8 2.3.1 Procedimento para Coleta dos Dados . . . p. 8 2.3.1.1 Observa¸cão e Coleta de Documentos . . . p. 8 2.3.1.2 Entrevistas . . . p. 9 2.3.2 Tratamento e Análise dos Dados . . . p. 12 2.4 Survey . . . p. 14 2.4.1 Desenvolvimento do Questionário . . . p. 14 2.4.1.1 Valida¸cão do Questionário . . . p. 15 2.4.2 Procedimento para Coleta dos Dados . . . p. 16 2.4.3 Análise e Apresenta¸cão dos Dados . . . p. 17

3 Revis˜ao Conceitual . . . p. 18 3.1 Lean . . . p. 18 3.1.1 Desperd´ıcios Lean . . . p. 20 3.1.1.1 Desbalanceamento (Mura) . . . p. 21 3.1.1.2 Sobrecarga (Muri ) . . . p. 21 3.1.1.3 Desperd´ıcio (Muda) . . . p. 22 3.1.2 Lean em Outras Ind´ustrias . . . p. 24 3.2 Desenvolvimento de Software Lean . . . p. 24 3.2.1 Princ´ıpios Lean no Desenvolvimento de Software . . . p. 25 3.2.2 Desperd´ıcios do Desenvolvimento de Software . . . p. 25 3.2.2.1 Defeitos . . . p. 26

(9)

3.2.2.4 Atrasos . . . p. 28 3.2.2.5 Trabalho Parcialmente Completo . . . p. 28 3.2.2.6 Transferência de Conhecimento (Handoff ) . . . p. 28 3.2.2.7 Extra Processamento . . . p. 29 3.2.2.8 Desbalanceamento (Mura) e Sobrecarga (Muri ) . . . p. 29 3.3 Scrum . . . p. 29 3.3.1 Origem . . . p. 30 3.3.2 Caracter´ısticas Principais . . . p. 30 3.3.3 Papeis . . . p. 31 3.3.4 Eventos . . . p. 32 3.3.4.1 Sprint . . . p. 32 3.3.4.2 Reunião de Planejamento da Sprint . . . p. 33 3.3.4.3 Reunião Diária . . . p. 33 3.3.4.4 Reunião de Revisão da Sprint . . . p. 34 3.3.4.5 Reunião de Retrospectiva da Sprint . . . p. 34 3.3.5 Artefatos . . . p. 34 3.3.6 Elementos Adicionais . . . p. 35 3.3.7 Manufatura Ágil . . . p. 36

4 Revisão Bibliográfica . . . p. 37 4.1 Trabalhos com Fatores Favoráveis à Ado¸cão de Lean no Desenvolvimento Ágil p. 37 4.2 Trabalhos com Fatores Desfavoráveis à Ado¸cão de Lean no Desenvolvimento

´

Agil . . . p. 39 4.3 Scrum e os Desperd´ıcios do Desenvolvimento de Software . . . p. 40 4.4 Resultados da Revisão Bibliográfica . . . p. 41 4.4.1 Sprint . . . p. 41 4.4.2 Times Pequenos e Multifuncionais . . . p. 41 4.4.3 Planejamento da Sprint . . . p. 41 4.4.4 Reunião Diária . . . p. 42 4.4.5 Defini¸cão de Pronto . . . p. 42 4.4.6 Refinamento do Backlog . . . p. 42 4.4.7 Revisão da Sprint . . . p. 42 4.4.8 Retrospectiva da Sprint . . . p. 43

(10)

5.1.1 O processo de Desenvolvimento . . . p. 44 5.1.1.1 Pré-desenvolvimento . . . p. 45 5.1.1.2 Desenvolvimento . . . p. 45 5.2 Resultados . . . p. 46 5.2.1 Desbalanceamento (Mura) . . . p. 46 5.2.2 Sobrecarga (Muri ) . . . p. 48 5.2.3 Desperd´ıcio (Muda) . . . p. 49 5.2.3.1 Defeitos . . . p. 49 5.2.3.2 Funcionalidades Extra . . . p. 50 5.2.3.3 Mudan¸ca de Contexto . . . p. 51 5.2.3.4 Atrasos . . . p. 52 5.2.3.5 Trabalho Parcialmente Completo . . . p. 53 5.2.3.6 Transferência de Conhecimento (Handoff ) . . . p. 53 5.2.3.7 Extra Processamento . . . p. 54 6 Survey . . . p. 56 6.1 Participantes . . . p. 56 6.2 Desbalanceamento (Mura) . . . p. 58 6.3 Sobrecarga (Muri ) . . . p. 60 6.4 Desperd´ıcio (Muda) . . . p. 64 6.4.1 Defeitos . . . p. 66 6.4.2 Mudan¸ca de Contexto . . . p. 69 6.4.3 Funcionalidades Extra . . . p. 71 6.4.4 Trabalho Parcialmente Completo . . . p. 72 6.4.5 Atrasos . . . p. 73 6.4.6 Transferência de Conhecimento (Handoff ) . . . p. 74 6.4.7 Extra Processamento . . . p. 76

7 Resultados Gerais e Discuss˜ao . . . p. 79

8 Conclus˜ao e Sugest˜oes para Trabalhos Futuros . . . p. 83

Referˆencias . . . p. 85

(11)

Figura 1 Metodologia Adotada . . . 7

Figura 2 Estrutura da Codifica¸c˜ao no software QSR NVIVO . . . 13

Figura 3 Princ´ıpios Lean. Fonte: Adaptado de (WOMACK; JONES, 2010)) . . . 20

Figura 4 Muda, Mura, Muri. Fonte: Adaptado de (MARCHWINSKI; SHOOK, 2003) 21 Figura 5 Mapeamento dos desperd´ıcios da manufatura ao desenvolvimento de soft-ware. Fonte: Adaptado de Poppendieck e Poppendieck (2003) . . . 26

Figura 6 Processo Scrum. Fonte: Adaptado de (SUTHERLAND; SCHWABER, 2007) 31 Figura 7 Experiˆencia dos respondentes com o framework Scrum . . . 57

Figura 8 Tipo de desenvolvimento no qual os respondentes atuam . . . 57

Figura 9 Presen¸ca de t´ıtulos nos times de desenvolvimento . . . 58

Figura 10 Designa¸c˜ao principal dos participantes . . . 58

Figura 11 Desbalanceamento (Mura) no per´ıodo inicial das itera¸c˜oes . . . 59

Figura 12 Pr´aticas Scrum x Mura . . . 60

Figura 13 Muri (sobrecarga) no final das itera¸c˜oes . . . 61

Figura 14 Frequˆencia na qual o time sacrifica aspectos de qualidade para finalizar os itens da sprint. . . 62

(12)

Figura 16 Pr´aticas Scrum x (Muri ) . . . 64

Figura 17 Eficiência da reunião de retrospectiva na elimina¸cão de desperd´ıcios no processo. . . 65

Figura 18 N´ıvel de engajamento dos participantes nas reuni˜oes Scrum . . . 66

Figura 19 Frequência de verifica¸cão da defini¸cão de pronto nos itens implementados 67 Figura 20 Frequência na qual defeitos não urgentes e débitos técnicos são prioriza-dos . . . 68

Figura 21 Pr´aticas Scrum x Defeitos . . . 69

Figura 22 Frequência na qual a sprint é interrompida por trabalho não planejado 70 Figura 23 Práticas Scrum x Mudan¸ca de Contexto . . . 71

Figura 24 Pr´aticas Scrum x Funcionalidades Extra . . . 72

Figura 25 Pr´aticas Scrum x Trabalho Parcialmente Completo . . . 73

Figura 26 Pr´aticas Scrum x Atrasos . . . 74

Figura 27 Pr´aticas Scrum x Transferˆencias de Conhecimento . . . 75

Figura 28 Frequência de reaprendizado causado por itens refinados, porém não im-plementados . . . 76

Figura 29 Eventos do scrum s˜ao suficientes para realizar o desenvolvimento das solu¸c˜oes. . . 77

(13)

(14)

Tabela 2 Entrevistados . . . 10

Tabela 3 Sete desperd´ıcios da manufatura . . . 23

(15)

1 Introdu¸

c˜

ao

Na tentativa de aprimorar a qualidade e eficiência dos processos de desenvolvimento de software, o Lean tem ganhado crescente destaque nos últimos anos, principalmente no contexto de desenvolvimento ágil de software.

O Lean teve origem no setor automobil´ıstico nos anos 80 e expandiu-se para diversas outras indústrias como log´ıstica, militar e de constru¸cões, tendo proporcionado melho-rias em companhias de diversos campos (POPPENDIECK, 2011). O termo Lean ganhou notoriedade na literatura após um estudo realizado pelo Instituto de Tecnologia de Mas-sachusetts (MIT) sobre a indústria automotiva, onde o Lean foi identificado como um dos principais responsáveis pelos altos ´ındices de produtividade da indústria japonesa. O estudo culminou no best-seller “The machine that changed the world: The story of Lean production” (WOMACK; JONES; ROOS, 1990), que causou grande impacto na literatura (POPPENDIECK, 2011).

O Lean tem como foco principal eliminar os desperd´ıcios do sistema de produ¸cão, ou seja, todas as atividades ou processos que não contribuam para a gera¸cão de valor ao cliente (PETERSEN, 2010). De acordo com Poppendieck (2011) o Lean é uma abordagem sistemática para identificar e eliminar desperd´ıcios por meio de um processo de melhoria cont´ınua, de forma que o fluxo de produ¸cão seja iniciado a partir da solicita¸cão do cliente (produ¸cão puxada), em constante busca pela perfei¸cão.

A indústria de software tem sido caracterizada pelo alto ´ındice de insucesso na execu¸cão de seus projetos (The Standish Group, 2011). As metodologias ágeis de desenvolvimento de software foram originadas nos anos 90, perante ao descontentamento com o cenário de desenvolvimento de softwares. O movimento foi oficializado através do manifesto ágil, um documento elaborado no ano de 2000 por alguns dos mais influentes profissionais e autores do desenvolvimento de software da época (FOWLER; HIGHSMITH, 2001). Estes realizavam cr´ıticas aos modelos de desenvolvimento existentes, como o modelo em cascata, devido a questões como o seu alto n´ıvel de documenta¸cão e distanciamento do cliente durante

(16)

algumas etapas da implementa¸cão dos sistemas. De acordo com Sutherland e Schwaber (2007), os processos ágeis de desenvolvimento foram influenciados por melhores práticas da indústria japonesa, principalmente por princ´ıpios do Lean.

Conforme o relatório “9th State of Agile Development Survey Results” (VERSION ONE, 2011), o Scrum é o método de desenvolvimento ágil mais popular no mercado de desen-volvimento de softwares. O Scrum é um conjunto de princ´ıpios e práticas idealizadas por Jeff Sutherland e Ken Schwaber (SCHWABER; SUTHERLAND, 2013). De acordo com seus criadores, o Scrum auxilia times a entregarem produtos em curtos ciclos, promovendo a melhoria cont´ınua e a rápida adapta¸cão a mudan¸cas (SCHWABER, 1997). O Scrum é base-ado em um estudo publicbase-ado por Takeuchi e Nonaka em 1986 (TAKEUCHI; NONAKA, 1986), onde indica-se que times pequenos e multifuncionais têm historicamente produzido me-lhores resultados em projetos de desenvolvimento de produtos complexos. O Framework se concentra no gerenciamento de atividades diárias de gerenciamento de projeto e tem como foco a prioriza¸cão de tarefas de acordo com as necessidades do negócio, de forma a entregar valor para o cliente o mais breve poss´ıvel. De acordo com Sutherland e Schwaber (2007), o Scrum pode ser visto como uma abordagem enxuta para o desenvolvimento de software.

O Lean e o desenvolvimento de software ágil possuem valores semelhantes. A principal semelhan¸ca entre as abordagens é o objetivo de maximizar o valor gerado ao cliente ao en-tregar produtos de forma mais rápida e economicamente eficiente. Todavia, ao contrário do ágil, o Lean possui um forte foco em remover desperd´ıcios do processo. De acordo com

¯

Ono (1988), o primeiro passo para adotar o Lean é identificar e eliminar desperd´ıcios no processo atual. Esta medida poderá trazer melhorias na produtividade e mais importante, causar mudan¸cas fundamentais no processo. A elimina¸cão de desperd´ıcios tornará o pro-cesso transparente, tornando poss´ıvel realizar altera¸cões expl´ıcitas a ele e, em seguida, inspecionar e adaptar conforme necessário.

O desperd´ıcio é definido como qualquer coisa que não agregue valor ao cliente. Em ja-ponês, o desperd´ıcio pode ser definido como Mura, Muri e Muda. Mura diz respeito à desbalanceamentos ou varia¸cão (na qualidade do processo, custo, entrega), Muri diz res-peito à sobrecarga de máquinas ou pessoas e Muda é qualquer atividade que não agrega valor ao cliente (WOMACK; JONES, 1996). Os tipos de desperd´ıcios originalmente identifi-cados na manufatura, foram mapeados ao desenvolvimento de software por Poppendieck e Poppendieck (2003).

(17)

CON-BOY; CAWLEY, 2012) e (SWAMINATHAN; JAIN, 2012) buscam analisar a rela¸cão entre as abordagens Lean e Ágil. Entretanto, poucos estudos tem como foco analisar as práticas do método Scrum e sua habilidade de remover desperd´ıcios do desenvolvimento de soft-ware. Estudos como (JAKOBSEN; POPPENDIECK, 2011) relatam a aplica¸cão do Lean como forma de aprimorar processos Scrum. Barton (2009) sugere que o Scrum implementa um processo para eliminar desperd´ıcios e suavizar o fluxo através do sistema e prevenir a sobrecarga das equipes ao implementar um modelo semelhante a produ¸cão puxada do Lean. Todavia, não foram identificados estudos emp´ıricos que indiquem de que forma as práticas do framework Scrum influenciam na identifica¸cão e elimina¸cão de desperd´ıcios no processo.

Portanto, neste contexto, o presente estudo tem como objetivo analisar como os des-perd´ıcios identificados pelo Lean se apresentam em um ambiente de desenvolvimento Scrum, buscando identificar poss´ıveis rela¸cões entre o framework e os desperd´ıcios do de-senvolvimento de software. A análise destas rela¸cões é de interesse para organiza¸cões que adotam o Scrum como metodologia de desenvolvimento, pois esclarece de que forma as práticas Scrum são utilizadas para eliminar desperd´ıcios, assim como identifica eventuais desperd´ıcios provocados ou associados ao uso do framework.

Além disso, a companhia a ser analisada no estudo de caso realizado nesta pesquisa tem apresentado problemas em rela¸cão ao seu processo de desenvolvimento de software após a ado¸cão da metodologia Scrum, motivando a realiza¸cão de uma análise entre as práticas implementadas e os poss´ıveis desperd´ıcios causados no processo. A motiva¸cão deste estudo se deu também devido ao Lean ser um tópico de interesse comum dentre as grandes áreas (Engenharia de Produ¸cão e Sistemas Computacionais) do mestrado realizado.

A pesquisa se delimita ao campo de desenvolvimento de software, onde busca-se analisar as rela¸cões dentre o Lean e o Scrum em um estudo exploratório realizado com profissionais da indústria de desenvolvimento de software neozelandesa. A localiza¸cão do estudo foi escolhida devido a facilidade de acesso por parte do pesquisador.

Desta forma, a pesquisa pretende abordar quest˜oes como:

• O Scrum pode identificar e eliminar desperd´ıcios no desenvolvimento de software?

• Quais pr´aticas do Scrum podem auxiliar na elimina¸c˜ao de quais desperd´ıcios?

• O Scrum pode propiciar a ocorrˆencia de algum tipo de desperd´ıcio no desenvolvi-mento de software?

(18)

2 Metodologia

O estudo baseia-se em metodologia mista, envolvendo métodos qualitativos e quantitati-vos. De acordo com Guest, Namey e Mitchell (2012), os métodos qualitativos auxiliam a compreender o significado narrativo e descritivo de um fenômeno particular para um certo grupo de pessoas. Em outras palavras, ajudam a desenvolver uma visão mais ampla baseada na informa¸cão recebida de participantes individuais. Já os métodos quantitati-vos tem como objetivo explicar fenômenos através da coleta e análise de dados numéricos. (CRESWELL, 1999).

A combina¸cão destas duas abordagens de pesquisa, conhecida como método de pesquisa misto (“mixed method ”), é bem conhecida e estabilizada na academia (JOHNSON; CH-RISTENSEN, 2008). A utiliza¸cão do método misto é potencialmente capaz de prover um melhor entendimento do problema, ao prover uma combina¸cão das vantagens das duas metodologias. Também permite que pesquisadores olhem para o problema de múltiplos pontos de vista, de forma a aprimorar a acurácia de seus julgamentos. (JICK, 1979).

No presente estudo, a abordagem qualitativa é utilizada para analisar como se dá, na lite-ratura e na prática, a rela¸cão entre o Scrum e os desperd´ıcios do Lean no desenvolvimento de software. A abordagem quantitativa é então realizada com base nos resultados obti-dos na analise qualitativa e tem como objetivo verificar as hipóteses obtidas nas etapas anteriores.

A presente pesquisa é de natureza exploratória. De acordo com Gil (2010), este tipo de pesquisa tem como objetivo proporcionar familiariza¸cão ao tópico pesquisado, para torn´ a-lo mais explicito ou para que sejam constru´ıdas hipóteses. As etapas iniciais do presente estudo fornecem hipóteses e insumos para as fases seguintes de forma a refinar ou validar os resultados obtidos.

(19)

2.1 Objetivo e Quest˜

oes de Pesquisa

O principal objetivo deste estudo é avaliar a rela¸cão entre o método Scrum e os des-perd´ıcios do Lean no desenvolvimento de software. Tal objetivo envolve:

• Identificar na literatura os desperd´ıcios definidos pelo Lean e suas adapta¸c˜oes ao desenvolvimento de software.

• Identificar na literatura a rela¸c˜ao entre o Scrum e o Lean.

• Capturar a rela¸c˜ao entre o Scrum e os desperd´ıcios do desenvolvimento de software em um ambiente real de desenvolvimento de softwares.

• Obter a percep¸cão geral do praticante na utiliza¸cão do método Scrum em rela¸cão a sua efetividade na elimina¸cão de desperd´ıcios no desenvolvimento de software.

Para alcan¸car os objetivos propostos, as seguintes quest˜oes de pesquisa foram formuladas:

• QP1 - Quais s˜ao os desperd´ıcios do Lean e suas adapta¸c˜oes ao desenvolvimento de software na literatura?

• QP2 - Qual a rela¸c˜ao entre o Scrum e o Lean de acordo com a literatura?

• QP3 - Como se dá na prática a rela¸cão entre Scrum e os desperd´ıcios do desenvol-vimento de software? i.e. Quais práticas do Scrum estão relacionadas a quais tipos de desperd´ıcios?

2.2 Fases da Pesquisa

Este estudo ´e realizado atrav´es de quatro principais fases:

1. Revis˜ao da Literatura

2. Estudo de Caso

3. Pesquisa Survey

4. Refinamento dos Resultados

Na primeira fase do estudo, livros e artigos são examinados na tentativa de identificar rela¸cões entre o Scrum e os desperd´ıcios do Lean no desenvolvimento de software. Nesta fase buscou-se responder as questões de pesquisa QP1 e QP2.

(20)

A revisão da literatura provê a fundamenta¸cão teórica para realiza¸cão da segunda fase da pesquisa. Na segunda fase, busca-se responder parcialmente a questão QP3 ao se conduzir um estudo de caso em uma das grandes companhias de desenvolvimento de software da Nova Zelândia, utilizando-se de ferramentas de coleta de dados como a observa¸cão e a realiza¸cão de entrevistas semi-estruturadas com os gerentes e l´ıderes de desenvolvimento de software na companhia. Uma análise dos dados obtidos é então realizada a fim de obter resultados que sirvam de base para o questionário utilizado no próximo passo da pesquisa.

Na terceira fase, uma pesquisa survey é disponibilizada aos profissionais que atuam na indústria de software, com o objetivo de validar os resultados obtidos nas etapas ante-riores em rela¸cão ao Scrum e sua intera¸cão com os desperd´ıcios do desenvolvimento de software. A Survey será disponibilizada através da internet, direcionada diretamente à comunidade desenvolvimento ágil neozelandesa, através de divulga¸cão em empresas de desenvolvimento e também em plataformas como Meetup e LinkedIn, utilizadas por uma relevante quantidade de profissionais que atuam com os temas envolvidos.

Finalmente, na quarta etapa, os resultados da revisão da literatura, estudo de caso e survey são refinados para identificar respostas a pergunta QP3. Os estágios da pesquisa e os passos executados são ilustrados na Figura 1:

(21)

(22)

2.3 Estudo de Caso

Houveram reuniões para explicar a forma como o estudo de caso seria realizado na compa-nhia e após obter a aprova¸cão do gerente de desenvolvimento (CTO), iniciou-se o processo de coleta de dados nas equipes.

2.3.1 Procedimento para Coleta dos Dados

O trabalho de campo teve dura¸cão aproximada de 45 dias, sendo realizado da segunda semana de outubro de 2015 ao final do mês de novembro de 2015. A coleta dos dados foi realizada em três principais etapas:

• Observa¸c˜ao do processo.

• Coleta de documentos.

• Entrevista individual com l´ıderes do processo na companhia (Gerente de desenvol-vimento, gerentes de setor, gerente de processo e scrum masters).

2.3.1.1 Observa¸c˜ao e Coleta de Documentos

A coleta de dados foi iniciada com a observa¸cão. A observa¸cão foi selecionada como uma das técnicas de coleta de dados neste estudo, devido à possibilidade de se captar uma variedade de situa¸cões às quais não se teria acesso somente por meio de perguntas realizadas aos colaboradores.

Desta forma, houve a participa¸cão do pesquisador como observador em eventos Scrum em nove equipes durante três itera¸cões. Durante o per´ıodo de observa¸cão buscou-se coletar dados relacionados aos desperd´ıcios do desenvolvimento de software com base no referen-cial teórico deste estudo, levanto em conta fatores como, fluxo e carga de trabalho das equipes e problemas ou dificuldades relacionados ao processo destacadas por membros durante as reuniões.

Durante este per´ıodo, buscou-se também coletar documentos ou artefatos relacionados ao processo de desenvolvimento. Desta forma, foram coletados, entre outros, dados sobre o backlog de produtos das equipes, notas de reuniões de retrospectiva e documentos de análise do processo elaborados por uma empresa de consultoria contratada anteriormente.

Os dados foram agrupados e inseridos na ferramenta QSR NVivo (QSR, 2016) para an´alise posterior, conforme destacado nas se¸c˜oes seguintes.

(23)

O software QSR NVivo é uma ferramenta para análise de dados qualitativos criado pela companhia QSR. De acordo com Welsh (2002), ferramentas deste tipo auxiliam o pesqui-sador a identificar uma acurada e transparente imagem dos dados, enquanto que também proveem mecanismos que tornam o processo de análise dos dados mais confiável.

2.3.1.2 Entrevistas

Na tentativa de compreender quais tipos de desperd´ıcios se apresentam na companhia e quais as suas rela¸cões com o framework Scrum, foram conduzidas entrevistas semiestru-turadas com dura¸cão de 20 a 40 minutos. As entrevistas foram realizadas com 12 l´ıderes de processo na companhia, incluindo Scrum Masters, l´ıderes de equipe e gerentes de de-senvolvimento. Uma caracteriza¸cão mais detalhada de cada participante está descrita na tabela 2:

(24)

Participante Cargo Experiˆencia com desenvolvimento de

softwares (anos)

Experiência com métodos ágeis (anos) 1 Gerente de Desenvolvimento (CTO) 15 2 2 Gerente de Setor 9 2 3 Gerente de Processo 12 2 4 L´ıder de Equipe/Desenvolvedor 7 3 5 Scrum Master/Analista de negócios 7 2 6 Scrum Master/Desenvolvedor 6 2 7 Scrum Master/Desenvolvedor 7 2 8 Scrum Master/Desenvolvedor 5 2 9 Scrum Master/Desenvolvedor 4 1 10 Scrum Master/Testador 6 2 11 Scrum Master/Testador 7 3 12 Scrum Master/Testador 10 2 Tabela 2: Entrevistados

Durante as entrevistas, cada um dos desperd´ıcios foi apresentado ao entrevistado através de exemplos e descri¸cões presentes na literatura 3.2.2. Após a apresenta¸cão e exempli-fica¸cão do conceito, perguntas sobre os tipos de desperd´ıcios apresentados foram realiza-das.

Neste estudo optou-se pela entrevista semiestruturada, na qual o entrevistado tem a pos-sibilidade de discorrer sobre suas experiências, a partir do foco principal proposto pelo pesquisador e ao mesmo tempo permite respostas livres e espontâneas do informante ( DRE-VER, 1995). As questões elaboradas para a entrevista levaram em conta o embasamento teórico e as informa¸cões que o pesquisador recolheu previamente através da observa¸cão do processo. Desta forma, as entrevistas foram guiadas inicialmente através das seguintes

(25)

perguntas:

1. Você verifica a ocorrência de sobrecarga (Muri), causada por fatores como altas car-gas de trabalho, na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

2. Você verifica a ocorrência de varia¸cões ou desbalanceamentos no fluxo de trabalho na companhia (Mura)? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

3. Defeito diz respeito a partes ou unidades que apresentam problemas ou não atendem a especifica¸cão do cliente. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

4. Funcionalidades extra se referem a funcionalidades ou estruturas de código que não são exatamente necessárias no momento, mas são adicionadas ao sistema como forma de antecipar futuras necessidades. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de problema? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

5. A mudan¸ca de contexto está relacionada principalmente a interrup¸cões e ao traba-lho em diversas tarefas simultaneamente. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

6. O desperd´ıcio relacionado a atrasos está principalmente relacionado a espera ociosa causadas por atrasos ou desbalanceamentos no fluxo de trabalho das equipes. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

7. O trabalho realizado parcialmente diz respeito a unidades de trabalho iniciadas, porém não completamente finalizado, gerando desperd´ıcios. Exemplos deste tipo de desperd´ıcio são: Documenta¸cão não codificada, código não testado, código não

(26)

sincronizado etc. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

8. O desperd´ıcio relacionado a Handoffs ou transferência de conhecimento, está rela-cionado a perda de conhecimento e ao reaprendizado causado pela transferência de tarefas ou de conhecimento através de artefatos. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxi-liado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

9. O extra processamento diz respeito a etapas do processo que poderiam ser eliminadas para que o fluxo de produ¸cão seja otimizado, como documenta¸cão ou reuniões não necessárias. Você verifica a ocorrência deste tipo de desperd´ıcio na companhia? Existe algum elemento do Scrum que tem auxiliado a evitar este tipo de desperd´ıcio? Existe algo relacionado ao Scrum que pode estar de alguma forma favorecendo a ocorrência deste tipo de desperd´ıcio?

10. Existe algum evento ou artefato do Scrum que vocˆe consideraria como desnecess´ario, ou extra processamento?

2.3.2 Tratamento e An´

alise dos Dados

A análise dos dados foi baseada na análise temática, que de acordo com Fereday e Muir-Cochrane (2008) consiste em uma busca por temas que apresentem importância para descrever um fenômeno. Este processo envolve a leitura cuidadosa dos dados na tentativa de reconhecer padrões, onde temas emergentes se tornam as categorias de análise.

O método de análise escolhido para esta etapa foi a abordagem dedutiva baseada em modelos de códigos pré definidos, definida por Crabtree e Miller (1999). Esta aborda-gem prevê a cria¸cão prévia de um modelo de códigos que visa organizar o texto para interpreta¸cões posteriores. O modelo tem o intuito de organizar fragmentos do texto que possuam similaridades, auxiliando na análise posterior do material colhido. (CRABTREE; MILLER, 1999).

Nesta abordagem, o pesquisador define um template antes de iniciar a análise profunda dos dados. O modelo de códigos pode ser criado através de uma leitura preliminar dos dados, ou através de pressupostos externos como questões de pesquisa ou arcabou¸cos

(27)

teóricos, permitindo, desta forma integrar pressupostos originários de fontes externas aos dados ao processo de análise temática dedutiva. (FEREDAY; MUIR-COCHRANE, 2008).

Assim como em (FEREDAY; MUIR-COCHRANE, 2008), neste estudo o modelo de códigos foi desenvolvido a priori, baseando-se nas questões de pesquisa e no arcabou¸co teórico. Portanto, o modelo de códigos utilizado neste estudo foi criado com base na revisão da literatura realizada, resultando nos desperd´ıcios definidos pelo Lean aplicáveis ao desen-volvimento de softwares (Sobrecarga (Muri )), Desbalanceamento (Mura), Defeitos, Fun-cionalidades Extra, Mudan¸ca de Contexto, Atrasos, Trabalho Parcialmente Completo, Transferência de Conhecimento, Extra Processamento).

Os dados coletados (transcri¸cões das entrevistas, observa¸cões e documentos do processo) foram inseridas no software de gerenciamento de dados qualitativos QSR NVivo (QSR, 2016), onde o processo de codifica¸cão dos dados foi realizado. O processo de codifica¸cão envolve reconhecer uma ocorrência importante nos dados e destacá-lo através de um código (nome, termo, etc) que o descreva. Este processo ocorre anteriormente ao processo de interpreta¸cão (FEREDAY; MUIR-COCHRANE, 2008). De acordo com Boyatzis (1998), codi-ficar a informa¸cão envolve organizar os dados de forma a identificar padrões na informa¸cão que no m´ınimo descrevam e organizem as observa¸cões e no máximo interpretem aspectos do fenômeno.

Portanto, utilizando a análise dedutiva baseada em modelo de códigos (CRABTREE; MIL-LER, 1999), os códigos foram aplicados aos dados com o objetivo de agrupar unidades de textos significativas, identificando pontos chave no processo e fatores destacados pelos participantes em resposta às perguntas das entrevistas. A Figura 2 ilustra a estrutura dos códigos no software QSR NVivo (QSR, 2016).

(28)

A fase final envolveu uma análise minuciosa do resultado da codifica¸cão, na tentativa de identificar poss´ıveis falhas nas etapas anteriores, o que se assemelha a fase de confirma¸cão definida por Crabtree e Miller (1999). Após esta etapa foi realizada uma análise inter-pretativa, que envolve a descoberta de temas e padrões nos dados através da análise e conexão das unidades destacadas. Os resultados são descritos nas se¸cões posteriores.

2.4 Survey

Após analisar os resultados da revisão literária e do estudo de caso, uma pesquisa survey foi conduzida na tentativa de verificar e validar a forma na qual o Scrum tem sido utilizado na identifica¸cão e elimina¸cão de desperd´ıcios na indústria de softwares neozelandesa, visando responder a questão de pesquisa QP3 do presente estudo.

De acordo com Freitas et al. (2000), a pesquisa survey é utilizada para a obten¸cão de dados ou informa¸cões sobre as caracter´ısticas ou opiniões de um determinado grupo de pessoas, utilizando um questionário como instrumento de pesquisa. A pesquisa survey possibilita que dados sejam obtidos diretamente do grupo de interesse de forma a descrever, comparar ou explicar conhecimentos e comportamentos.

Considerando todos os benef´ıcios, o método survey foi selecionado como a melhor al-ternativa para obter a informa¸cão necessária em um curto espa¸co de tempo e através de uma popula¸cão significativa. Desta forma, o método foi aplicado ao se desenvolver um questionário e disponibilizá-lo a profissionais que atuam em diversas organiza¸cões de desenvolvimento de software da Nova Zelândia.

2.4.1 Desenvolvimento do Question´

ario

Conforme previsto na metodologia, capitulo 2, o question´ario foi desenvolvido com base nos resultados obtidos nas etapas anteriores do presente estudo. Desta forma, buscou-se obter dados qualitativos a respeito das rela¸c˜oes identificadas entre o Scrum e os des-perd´ıcios do desenvolvimento de software.

Optou-se pela utiliza¸cão da escala Likert com cinco pontos na elabora¸cão do questionário. A escala Likert é um instrumento psicométrico proposto por Likert (1932) e utilizado primariamente para se obter o n´ıvel de concordância dos participantes a respeito de uma afirma¸cão ou conjunto de informa¸cões.

(29)

Desta forma, ao realizar a survey os participantes deveriam indicar o n´ıvel de concordância em rela¸cão às afirma¸cões em uma escala constitu´ıda por 5 pontos, sendo eles:

1. Discordo totalmente

2. Discordo

3. Indiferente (Indeciso)

4. Concordo

5. Concordo Totalmente

Em casos onde buscava-se verificar a frequência de ocorrência de um determinado fator, a escala foi utilizada com os mesmos valores, porém com diferentes descri¸cões:

1. Nunca

2. Raramente

3. Algumas vezes

4. Frequentemente

5. Sempre

As afirma¸cões presentes na pesquisa estão principalmente relacionadas à forma na qual os participantes utilizam as práticas do framework Scrum como ferramenta para identificar e eliminar desperd´ıcios em seus processos. Foram levados em conta também poss´ıveis impactos negativos do framework em rela¸cão aos desperd´ıcios, conforme identificados na etapa do estudo de caso.

2.4.1.1 Valida¸c˜ao do Question´ario

A valida¸cão do questionário é um importante passo na realiza¸cão de uma survey, de acordo com Kitchenham e Pfleeger (2002a), se os participantes não puderem responder ou compreender a pesquisa, as respostas e análises podem ser comprometidas. No presente estudo, a valida¸cão do questionário envolveu três principais etapas:

Na etapa inicial, uma versão do questionário foi elaborada com 32 questões. Nesta versão, cada se¸cão correspondia a uma prática do Scrum e as afirma¸cões contidas na se¸cão se referiam a forma na qual tal prática impactava nos desperd´ıcios do desenvolvimento de software no processo do respondente. Após disponibilizar este questionário a alguns dos participantes do estudo de caso, estes reportaram problemas em rela¸cão à extensão do

(30)

questionário e ao tempo requerido para preenchimento do mesmo. Além disso, a forma na qual o questionário havia sido estruturado restringia a identifica¸cão de rela¸cões não descobertas nas etapas anteriores.

Portanto, a partir do feedback obtido, uma nova versão do questionário foi elaborada, constitu´ıdo por 21 questões. Nesta versão, as se¸cões foram estruturadas a partir dos des-perd´ıcios do desenvolvimento de software, onde os participantes puderam indicar, através da escala Likert, o grau de concordância em rela¸cão aos impacto positivo de cada prática Scrum no desperd´ıcio indicado. O questionário contou também com afirma¸cões relacio-nadas aos impactos negativos do Scrum identificados nas se¸cões anteriores do estudo.

Esta versão foi disponibilizada novamente aos participantes da pesquisa que avaliaram o questionário anteriormente e, após adicionar questões relacionadas aos dados do partici-pante e realizar pequenos ajustes sugeridos, o questionário pôde em fim ser publicado. O questionário final, em inglês, está anexado a este documento (Apêndice A).

2.4.2 Procedimento para Coleta dos Dados

De acordo com Kitchenham e Pfleeger (2002b), uma amostra válida é um subconjunto representativo da popula¸cão alvo. Portanto, torna-se importante avaliar se os responden-tes são relevantes para pesquisa. No presente estudo optou-se por utilizar uma amostra não probabil´ıstica por conveniência, na medida em que uma popula¸cão espec´ıfica, não aleatória, foi buscada. Em amostras não probabil´ısticas por conveniência, os dados são obtidos através de participantes que se disponibilizarem a realizar a pesquisa. De acordo com Freitas et al. (2000), este tipo de amostra não permite a generaliza¸cão dos resulta-dos, mas pode descrever dados intr´ınsecos da amostra analisada, sendo adequado quando existem restri¸cões de tempo e or¸camento, como no caso da presente pesquisa.

Portanto, buscou-se alcan¸car profissionais que tenham atuado diretamente com o fra-mework Scrum na indústria neozelandesa de desenvolvimento de softwares. Após analisar recursos e identificar formas de contactar tais profissionais, a pesquisa foi disponibilizada de forma eletrônica e publicada em diferentes meios:

Empresas: Al´em da empresa na qual o estudo de caso foi realizado, a pesquisa foi enca-minhada diretamente para duas diferentes companhias da cidade de Auckland.

Redes sociais: A pesquisa foi publicada em grupos de desenvolvimento lean e ágil da Nova Zelândia nas redes sociais Meetup e LinkedIn. Além dos grupos gerais da Nova Zelândia, foram alcan¸cados também grupos regionais, especificamente para as

(31)

cidades de Dunedin, Christchurch, Auckland e Wellington.

Grupos de e-mails: Foram identificados três grupos de e-mails locais constitu´ıdos por profissionais de desenvolvimento de software que atuam com o desenvolvimento ágil na região.

2.4.3 An´

alise e Apresenta¸

c˜

ao dos Dados

A escala Likert, utilizada no presente estudo, é uma escala ordinal na qual as observa¸cões são alocadas em categorias ordenadas. Isto significa que as categorias possuem um valor ordenado, mas os intervalos entre as categorias não pode ser considerado igual. ( JAMIE-SON, 2004).

Diversos estudos como (JAMIESON, 2004), (JAKOBSSON, 2004) e (BERTRAM, 2007),

indi-cam a estat´ıstica descritiva, utilizando-se de medianas, porcentagens e modas, como a fer-ramenta mais apropriada para interpretar dados oriundos deste tipo de escala. Jamieson (2004), defende que elementos como a média e o desvio padrão, mesmo que amplamente utilizados em estudos deste tipo, são inapropriados para dados ordinais, onde os números geralmente representam afirma¸cões verbais.

Portanto, a análise estat´ıstica descritiva foi selecionada para apresentar os dados e descre-ver as observa¸cões na amostra numericamente e graficamente. Para elementos da escala Likert, a mediana (med ) foi utilizada como medida de tendência central e a amplitude interquartil (aiq) foi utilizada como medida de dispersão. De acordo com Jakobsson (2004), altos valores de amplitude interquartil sugerem que as opiniões estão polarizadas, enquanto que valores menores podem indicar consenso.

Devido a limita¸cões de tempo, não foi poss´ıvel realizar testes estat´ısticos não-paramétricos aprofundados. Em trabalhos futuros testes não-paramétricos, como o teste de Friedman, poderão ser utilizados na tentativa de identificar as diferen¸cas gerais das práticas Scrum em rela¸cão a sua efetividade de eliminar desperd´ıcios.

(32)

3 Revis˜

ao Conceitual

Este cap´ıtulo descreve os fundamentos teóricos da pesquisa e tem como objetivo contribuir na elucida¸cão dos conceitos relacionados à problemática apresentada.

3.1 Lean

O Lean é originário do Sistema Toyota de Produ¸cão, uma filosofia de elimina¸cão de des-perd´ıcios desenvolvida e implementada pela companhia Toyota na manufatura automo-bil´ıstica japonesa a partir da década de 1940. Esta abordagem revolucionária auxiliou a companhia a produzir automóveis em cerca da metade das horas de trabalho que as demais companhias americanas e europeias, apresentando n´ıveis superiores de qualidade e satisfa¸cão do cliente. (POPPENDIECK; CUSUMANO et al., 2012).

Em um momento anterior a Ford dominava a indústria automobil´ıstica com carros de baixo custo, oferecendo porém, baixa variedade. Neste per´ıodo a Ford havia desenvolvido o conceito de produ¸cão em massa e linhas de montagem (KRAFCIK, 1988). Este sistema era considerado como a maneira mais barata e veloz de produzir carros. Todavia, o modelo requeria o armazenamento de uma grande quantidade de pe¸cas brutas para a fabrica¸cão dos automóveis. Apesar dos benef´ıcios do sistema, surgiram repercussões sobre fatores como o custo do maquinário utilizado e a baixa flexibilidade do modelo (WOMACK; JONES; ROOS, 1990).

No final dos anos 40 a Toyota, até então uma pequena produtora de automóveis, verificou que alguns fatores da produ¸cão em massa, como a grande quantidade de carros produzidos e a baixa variedade de modelos, eram incompat´ıveis ao pequeno mercado Japonês. Taiichi Ohno, que é também conhecido como o pai do Sistema Toyota de Produ¸cão (STP), realizou experimentos e concebeu um novo modo de pensar sobre a manufatura e desenvolvimento de produtos. A ideia central do seu trabalho era eliminar os desperd´ıcios do processo de produ¸cão (_ONO¯ _{, 1988).}

(33)

¯

Ono conseguiu alterar a mentalidade dentro da Toyota ao defender o pensamento de que qualquer coisa que não gere valor ao cliente consiste em desperd´ıcio. Os colaboradores da Toyota aceitaram e compreenderam este princ´ıpio fundamental e aplicaram o conceito de forma a eliminar desperd´ıcios do seu sistema. Este ato possibilitou a Toyota a rever-ter o fluxo de informa¸cão e ter um melhor controle sobre as opera¸cões de produ¸cão. O paradigma se modificou em dire¸cão a um sistema de produ¸cão puxada que buscava uti-lizar a quantidade exata de materiais e componentes necessários para a montagem final, através de um fluxo de produ¸cão continuo. Este modelo é contrário ao sistema empurrado, utilizado pela produ¸cão em massa e que armazena materiais com base em um plano de produ¸cão pré-determinado (WOMACK; JONES; ROOS, 1990).

O Lean é uma abordagem e filosofia que tem como foco a melhoria cont´ınua através da cont´ınua redu¸cão ou elimina¸cão de desperd´ıcios. O Lean é classificado como uma abordagem bottom-up e orientada a pessoas baseada na capacita¸cão de empregados que realizam de fato as tarefas, de forma que estes possam realizar aprimoramentos cr´ıticos em seus próprios dom´ınios (MORGAN, 2005). Aprimorar o fluxo e eliminar desperd´ıcios são os maiores direcionadores para se tornar uma organiza¸cão Lean (_ONO¯ _{, 1988).}

Lean pode ser visto como uma abordagem de administra¸c˜ao hol´ıstica de pessoas, produtos e processos, guiada por cinco princ´ıpios fundamentais (WOMACK; JONES, 1996):

Valor: Identificar e compreender valores mensur´aveis no ponto de vista do cliente. Em termos gerais, valor pode ser qualquer coisa que os consumidores s˜ao propensos a pagar.

Fluxo de Valor: Identificar cada passo do processo em detalhe. Mapear a cadeia de processo auxilia a identificar as ineficiências no processo, áreas de desperd´ıcio e atividades que não geram valor.

Fluxo Continuo: Alinhar os passos de cria¸cão de valor de uma maneira que possibilite o produto fluir suavemente durante o seu ciclo de vida. Sequenciar os passos que proveem o fluxo mais eficiente para atender as demandas dos clientes é um esfor¸co continuo, mas que pode gerar benef´ıcios em rela¸cão aos tempos de concep¸cão de produtos, de processamento de pedidos e de estoques.

Produ¸c˜ao Puxada: Implica que as equipes tenham a capacidade de iniciar e concluir as tarefas quando requerido para o pr´oximo passo do processo. Em outras pala-vras, permite que os clientes puxem o fluxo de valor, reduzindo n´ıveis de estoque e aprimorando o valor do produto.

(34)

Perfei¸cão: Buscar a perfei¸cão significa estabelecer às equipes da organiza¸cão que todos são responsáveis por compreender o fluxo de valor, identificando e eliminando des-perd´ıcios no processo. Esta busca pela perfei¸cão é a essência do Lean, onde o valor perfeito é criado sem desperd´ıcios.

Os princ´ıpios s˜ao ilustrados na Figura 3.

Figura 3: Princ´ıpios Lean. Fonte: Adaptado de (WOMACK; JONES, 2010))

3.1.1 Desperd´ıcios Lean

O Lean tem como foco eliminar desperd´ıcios para reduzir os custos e aprimorar a qualidade dos processos da organiza¸c˜ao. ¯Ono (1988) identificou trˆes principais fontes de desperd´ıcios no processo de manufatura: Desbalanceamento (Mura), Sobrecarga (Muri ) e Desperd´ıcio (Muda).

De acordo com Womack (2006), tais desperd´ıcios s˜ao relacionados. Mura e Muri podem ser a causa raiz de Muda nas organiza¸c˜oes, na medida em que o desbalanceamento no fluxo causa sobrecargas, que por sua vez acarreta em problemas como defeitos e atrasos, podendo causar outros tipos de desperd´ıcios. A Figura 4 exemplifica como ocorrem os diferentes tipos de desperd´ıcio.

(35)

Figura 4: Muda, Mura, Muri. Fonte: Adaptado de (MARCHWINSKI; SHOOK, 2003)

3.1.1.1 Desbalanceamento (Mura )

Mura se refere a desn´ıveis ou irregularidades prejudiciais ao processo de produ¸cão ( MAR-CHWINSKI; SHOOK, 2003). Este tipo de desperd´ıcio pode se apresentar de diversas formas, como na varia¸cão da dura¸cão de ciclos, varia¸cão do tamanho de lotes de processamento, varia¸cão do tamanho de equipes, entre outros. Este é um dos elementos combatidos pelo sistema de manufatura just-in-time que são baseados em manter baixos n´ıveis de estoques. O propósito principal do just-in-time é diminuir os custos fixos necessários para manter estoques de qualquer item associado a cadeia de manufatura. Por exemplo, quando um produto é requerido, este é entregue, após a entrega este produto é consumido. Portanto, é um ciclo que depende da regularidade nos instrumentos aplicados e dos resultados pro-duzidos. Como resultado, isto pode amenizar a ocorrência de desperd´ıcios em tarefas futuras no processo de produ¸cão (FUJIMOTO, 1999).

3.1.1.2 Sobrecarga (Muri )

A sobrecarga, conhecida como Muri em Japonês, é relativa a carga de trabalho demasiada na qual indiv´ıduos ou máquinas que atuam na cria¸cão do produto estão submetidos. Este desperd´ıcio ocorre quando equipamentos ou colaboradores operam em um ritmo maior, mais longo ou mais dificultoso do que o suportado (MARCHWINSKI; SHOOK, 2003). Muri como forma de desperd´ıcio é reduzida através da regularidade de procedimentos e ado¸cão de um ritmo de trabalho sustentável. Este desperd´ıcio pode ser também minimizado

(36)

através da identifica¸cão de instrumentos e tecnologias que possam tornar trabalhos re-petitivos mais simples e menos onerosos em indiv´ıduos que precisam realizar tarefas na linha de manufatura (FUJIMOTO, 1999). A elimina¸cão de sobrecargas no processo pode ter um impacto geral positivo na disposi¸cão dos trabalhadores, impactando na redu¸cão das outras formas de desperd´ıcio, como Muda e Mura. (WOMACK, 2006).

3.1.1.3 Desperd´ıcio (Muda )

O termo Muda em Japonês diz respeito a qualquer atividade ou etapas de processo que não adicionam valor ao produto. Muda é o conceito implementado pelo sistema de produ¸cão Toyota que reconhece desperd´ıcios gerados por pessoas ou atividades que ocorrem como resultado de incompetência ou má organiza¸cão das atividades do processo.

De acordo com ¯Ono (1988), existe um n´ıvel m´ınimo de recursos para o funcionamento do processo. Quando este limite é superado, desperd´ıcios estão sendo introduzidos no processo. Muda diz respeito a qualquer atividade que não contribua diretamente para gera¸cão de valor na perspectiva do cliente. De acordo Womack e Jones (2010) Muda pode ser classificado em dois principais tipos:

1. Tipo 1: Também conhecidos como desperd´ıcios necessários, este tipo de Muda diz respeito a atividades que não geram valor ao cliente diretamente, mas são necessárias para o correto funcionamento do sistema. Exemplo: Cria¸cão de documenta¸cão para atendimento à normas governamentais.

2. Tipo 2: Este tipo diz respeito `a atividades que n˜ao criam valor diretamente e podem ser imediatamente eliminadas.

¯

Ono (1988), identificou 7 principais tipos de Muda no ponto de vista da manufatura Lean. Estes tipos de desperd´ıcios s˜ao descritos na Tabela 3.

(37)

Superprodu¸c˜ao: Produzir em excesso, em uma quantidade superior a necessidade do cliente. Este tipo de desperd´ıcio pode ser considerado com o mais cr´ıtico e que requer maior aten¸c˜ao, pois pode estar relacionado diretamente aos demais tipos de desperd´ıcios.

Defeitos: Talvez o mais evidente dos desperd´ıcios, o defeito diz respeito a partes ou unidades que não atendem a espe-cifica¸cão do cliente. Os defeitos estão relacionados aos padrões de qualidade estabelecidos pela companhia.

Espera: Referente aos tempos inativos de operadores,

in-forma¸cões ou produtos. A espera pode ser decorrente de bloqueios no fluxo do processo que ocasionam inter-valos onde nenhuma opera¸cão é executada.

Transporte: Movimenta¸c˜ao excessiva de pessoas, informa¸c˜oes ou produtos que resultam em desperd´ıcios de tempo, es-for¸co e custo.

Processamento Inadequado: Utilizar o conjunto inadequado de ferramentas, proce-dimentos ou processos, onde geralmente, uma aborda-gem mais simples pode apresentar melhores resultados.

Estoque: Estoque excessivo de matéria-prima, material em pro-cesso ou produtos acabados. O estoque representa um capital aplicado que ainda não gera lucro para o pro-dutor ou consumidor e pode omitir problemas no fluxo de produ¸cão.

Movimenta¸cão Desnecessária: A movimenta¸cão desnecessária se refere a movi-menta¸cão excessiva de operários ou máquinas para execu¸cão de opera¸cões no processo. Além de afetar o tempo para realiza¸cão das opera¸cões, a movimenta¸cão desnecessária pode causar fadiga e danos a longo prazo.

(38)

3.1.2 Lean em Outras Ind´

ustrias

Embora tenha sido originado na manufatura, o Lean provou ser aplicável em diversas indústrias, expandindo-se para diversos outros campos, especialmente a partir dos anos 1980. A abordagem foi aplicada em áreas como log´ıstica, militar, de saúde, entre outras (HIBBS; JEWETT; SULLIVAN, 2009). Os benef´ıcios t´ıpicos da ado¸cão dos princ´ıpios Lean, independentemente do tipo de indústria podem estar relacionados aos seguintes itens:

1. Aprimoramento da qualidade e seguran¸ca: Previne acidentes e reduz erros, resultando em uma maior qualidade de produtos e servi¸cos.

2. Aprimoramento da entrega: Reduz o tempo de entrega ponta a ponta, sem afetar negativamente a qualidade.

3. Aprimoramento da produtividade: (Throughput ) Os mesmos recursos (mes-mas pessoas utilizando os mesmos equipamentos) s˜ao habilitados e motivados a aprimorar a sua maneira de trabalho para obter melhores resultados (JONES; MIT-CHELL, 2006)

4. Aprimoramento da dinˆamica: Um ambiente com procedimentos padronizados que promovem a melhoria cont´ınua.

3.2 Desenvolvimento de Software Lean

Os princ´ıpios do pensamento Lean originalmente direcionados à manufatura, foram mape-ados ao desenvolvimento de software inicialmente por Mary e Tom Poppendieck ( POPPEN-DIECK; POPPENDIECK, 2003). Os autores examinaram os princ´ıpios básicos de engenharia que a Toyota utiliza para desenvolver seus ve´ıculos e buscaram adaptá-los ao contexto de desenvolvimento de software. A filosofia Lean permite as organiza¸cões definirem o que é tomado como valor na perspectiva do cliente, organizar as atividades responsáveis pela cria¸cão de tal valor e conduzir tais atividades da melhor maneira poss´ıvel, de forma a desempenha-las de maneira cada vez mais efetiva (WOMACK; JONES, 2010).

Desta forma, o desenvolvimento de software Lean provê um conjunto de princ´ıpios para analisar e aperfei¸coar o processo de desenvolvimento de software de maneira a minimizar desperd´ıcios e maximizar o valor para o cliente. Os autores apontam que esta abordagem tem levado diversas organiza¸cões a reconsiderar suas práticas de engenharia de software, adquirindo melhorias na qualidade, custos e velocidade no desenvolvimento de produtos

(39)

(POPPENDIECK; POPPENDIECK, 2003). Tais resultados tˆem impulsionado empresas de desenvolvimento de software a adotar Lean (POPPENDIECK, 2011).

Para introduzir Lean no desenvolvimento de software, é necessário compreender a dife-ren¸ca entre seus princ´ıpios e práticas. Os princ´ıpios (POPPENDIECK, 2011) (WANG; CON-BOY; CAWLEY, 2012) são ideais e introspeçcões sobre disciplinas, enquanto as práticas são a¸cões que concretizam os princ´ıpios. Organiza¸cões de software buscam adaptar os princ´ıpios Lean para aprimorar a qualidade, custo e velocidade de entrega dos seus pro-dutos. Os mesmos são detalhados a seguir.

3.2.1 Princ´ıpios Lean no Desenvolvimento de Software

Diversos princ´ıpios inerentes ao Lean foram propostos ao desenvolvimento de software por autores como (POPPENDIECK; POPPENDIECK, 2003), (HIBBS; JEWETT; SULLIVAN, 2009), (REINERTSEN, 1996) e (ANDERSON, 2010). Tais princ´ıpios estão alinhados aos fundamen-tos do Lean e estão em constante evolu¸cão. Segundo a (WANG; CONBOY; CAWLEY, 2012), dentre os princ´ıpios presentes na literatura destacam-se:

• Eliminar desperd´ıcios; Fortalecer o time; Entregar rapidamente; Construir quali-dade; Adiar decis˜oes; Amplificar o conhecimento (POPPENDIECK; POPPENDIECK, 2003) ;

• Utilizar uma visão econômica; Gerenciar filas; Explorar variabilidade; Limitar o trabalho em execu¸cão; Controlar o fluxo sobre incerteza; Utilizar feedback rápido; Descentralizar o controle; (HIBBS; JEWETT; SULLIVAN, 2009);

• Visualizar e controlar o fluxo de trabalho; Tornar explicitas as pol´ıticas do pro-cesso; Melhorar colaborativamente (utilizando-se de modelos e m´etodos cient´ıficos); (ANDERSON, 2010).

Assim como na manufatura, o princ´ıpio de maior destaque do Desenvolvimento de Soft-ware Lean é a identifica¸cão e elimina¸cão de desperd´ıcios no processo, de forma que seja respeitado o valor gerado ao cliente (HIBBS; JEWETT; SULLIVAN, 2009). Os tipos de des-perd´ıcios que se apresentam no desenvolvimento de software são discutidos na se¸cão 3.2.2.

3.2.2 Desperd´ıcios do Desenvolvimento de Software

Assim como na manufatura, no desenvolvimento de software Lean desperd´ıcio é definido como qualquer atividade que não seja conducente a cria¸cão de valor ao cliente

(40)

(MIDDLE-TON; JOYCE, 2012). O desenvolvimento de software Lean tem como foco eliminar itens e processos desnecess´arios, sem que as medidas tomadas causem novos desperd´ıcios como defeitos e reaprendizagem.

A elimina¸cão de desperd´ıcios depende da compreensão dos diferentes tipos de desperd´ıcios que podem ocorrer no desenvolvimento de software. Mary e Tom Poppendieck adaptaram os 7 desperd´ıcios da manufatura (Muda) para a engenharia de software (POPPENDIECK; POPPENDIECK, 2003). Tais desperd´ıcios são ilustrados na Figura 5 e discutidos nas se¸cões a seguir.

Figura 5: Mapeamento dos desperd´ıcios da manufatura ao desenvolvimento de software. Fonte: Adaptado de Poppendieck e Poppendieck (2003)

3.2.2.1 Defeitos

Defeitos requerem retrabalho e podem ser custosos. O desenvolvimento de software Lean enfatiza a preven¸cão de defeitos com atividade cont´ınua, realizada sempre que poss´ıvel, en-quanto abordagens tradicionais de desenvolvimento de software tendem a dedicar tempos e recursos para a deteçcão de defeitos. Estat´ısticas demonstram que no desenvolvimento de software legado, em média 40 a 50% do tempo de desenvolvimento é consumido na

(41)

deteçcão e elimina¸cão de defeitos (POPPENDIECK; CUSUMANO et al., 2012). O dano cau-sado por um simples defeito pode ser mensurado como produto do impacto caucau-sado pelo defeito e o tempo que este permaneceu no produto sem ser percebido. Isto significa que um defeito cr´ıtico que é detectado nas etapas iniciais do desenvolvimento pode não ser uma grande amea¸ca ou fonte de desperd´ıcio. Todavia, um pequeno defeito não detectado no sistema durante um longo per´ıodo de tempo pode trazer grandes preju´ızos ao produto e ao cliente, causando manuten¸cões futuras.

3.2.2.2 Funcionalidades Extra

De acordo com Hibbs, Jewett e Sullivan (2009), o princ´ıpio de Pareto (80-20) aplicado ao desenvolvimento de software sugere que 80% das necessidades dos clientes são atendi-das por 20% atendi-das funcionalidades do produto. As demais funcionalidades são raramente, ou nunca utilizadas. Funcionalidades extras se configuram no maior tipo de desperd´ıcio do desenvolvimento de software, de maneira que consome deliberadamente recursos do projeto. Durante o ciclo de vida do software, cada linha de código escrita deve ser inte-grada, testada e mantida por diversas vezes. As funcionalidades ou peda¸cos de códigos que não podem ser relacionadas às necessidades ou requisitos reais se tornarão poss´ıveis pontos de falha. Desta forma, recomenda-se que códigos ou funcionalidades que não são necessários imediatamente não sejam constru´ıdos ou inclu´ıdos na solu¸cão (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.3 Mudan¸ca de Contexto (Task Switching )

Ao contrário do que diversas organiza¸cões acreditam, de acordo com Poppendieck e Pop-pendieck (2003), envolver o mesmo recurso em múltiplos projetos ao mesmo tempo pode se tornar uma fonte de desperd´ıcio, de forma que esta medida afeta negativamente o fluxo e a produtividade dos profissionais. Toda vez que desenvolvedores de software alteram o foco entre diferentes tarefas ou projetos, uma considerável quantidade de tempo é ne-cessária para que se compreenda os pré-requisitos das tarefas e para que um ritmo estável seja alcan¸cado. Desta forma, enquanto alternam entre diferentes tarefas, os desenvolve-dores de software devem reaprender diversas vezes para que retomem o mesmo n´ıvel de produ¸cão que possu´ıam quando atuando na mesma tarefa (HIBBS; JEWETT; SULLIVAN, 2009).

(42)

3.2.2.4 Atrasos

Relacionados a esperas ociosas no processo, atrasos no desenvolvimento de software são detectados frequentemente em situa¸cões onde pessoas estão aguardando a ocorrência de alguma a¸cão, como por exemplo, aguardando a inicia¸cão do projeto, aguardando a cria¸cão e revisão de documentos, aguardando decisões pendentes, aguardando pela configura¸cão de ambientes etc. Na perspectiva do cliente, estes atrasos no ciclo de desenvolvimento prejudicam o tempo de resposta para as suas necessidades, que podem inclusive se alterar rapidamente, impedindo que stakeholders obtenham o valor do produto no tempo esperado (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.5 Trabalho Parcialmente Completo

O trabalho parcialmente completo é um trabalho que foi iniciado, mas não foi finalizado. Este tipo de desperd´ıcio diz respeito a items como, requisitos não aprovados, requeri-mentos não implementados, código não testado, defeitos identificados e não corrigidos e funcionalidades não entregues. Existe o risco que o trabalho realizado parcialmente se torne obsoleto no ciclo de desenvolvimento. Assim como o desperd´ıcio relacionado a es-toque na manufatura (se¸cão 3.1.1.3), trabalho realizado parcialmente no desenvolvimento de software pode ser visto como capital já aplicado, mas que não gera qualquer lucro para o produtor ou para o cliente (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.6 Transferˆencia de Conhecimento (Handoff )

Abordagens tradicionais de desenvolvimento requerem a movimenta¸cão de diversos ar-tefatos, incluindo documenta¸cão de requisitos, de design ou de testes, de um grupo de profissionais para outro. Esta transferência de conhecimento ou de tarefas, definidos como Handoffs, pode gerar desperd´ıcios na medida que tais documentos são por vezes incapazes de refletir o que os especialistas que os criaram (programadores, arquitetos ou testadores) aprenderam ou descobriram durante o seu trabalho. Isto pode resultar em perda de uma grande quantidade de conhecimento tácito, que permanece com o criador e não é trans-mitido para os passos seguintes do processo. Hibbs, Jewett e Sullivan (2009) descrevem que a perda de conhecimento é agravada a cada handoff realizado.

(43)

3.2.2.7 Extra Processamento

Este desperd´ıcio diz respeito a etapas do processo que poderiam ser eliminadas para que o fluxo de produ¸cão seja otimizado. Como exemplo, a burocracia ou documenta¸cão des-necessária consome recursos, reduz os tempos de resposta, omite problemas de qualidade e se torna obsoleta. Em alguns cenários de desenvolvimento de software, onde requisitos mudam frequentemente, existe a necessidade de se alinhar o produto com as expectativas do cliente regularmente.(POPPENDIECK; POPPENDIECK, 2003)

O termo extra processamento foi convertido posteriormente para reaprendizado em ( POP-PENDIECK; POPPENDIECK, 2006). Todavia, o sentido permanece semelhante, uma vez que o reaprendizado pode ser visto com um processo ou atividade desnecess´aria, que poderia ser evitada para eliminar desperd´ıcios no processo.

3.2.2.8 Desbalanceamento (Mura ) e Sobrecarga (Muri )

Não foram identificadas na literatura adapta¸cões diretas de Muri e Mura ao desenvol-vimento de software. Todavia, problemas de fluxo não são exclusivos da manufatura (GEORGAKOPOULOS; HORNICK; SHETH, 1995). Problemas como sobrecarga e varia¸cões podem ocorrer em diversos tipos de processo. Portanto, presume-se que tais desperd´ıcios podem se apresentar também em processos de desenvolvimento de software.

3.3 Scrum

Inicialmente formalizado como um processo de desenvolvimento de software (SCHWABER, 1997) e posteriormente definido como um framework para desenvolvimento e sustenta¸cão de produtos complexos (SCHWABER; SUTHERLAND, 2013), o Scrum é um conjunto de práticas e regras que aplica uma abordagem iterativa e incremental para execu¸cão de projetos ou constru¸cão de produtos. De acordo com Schwaber (2004), o Scrum implementa os requisitos de transparência, inspe¸cão e adapta¸cão inerentes ao controle de processos emp´ıricos.

No âmbito do desenvolvimento de softwares, o Scrum é considerado como um método ágil com foco no gerenciamento de projetos (SCHWABER, 2004), sendo um dos percussores e influenciadores do manifesto ágil (FOWLER; HIGHSMITH, 2001). O movimento ágil articula uma série de valores e princ´ıpios a respeito de como desenvolver softwares com qualidade e de forma eficiente, com alta responsividade à mudan¸cas de negócio. Estudos como

(44)

(VERSION ONE, 2011), (SCHWABER; LEGANZA; D’SILVA, 2007) apontam o Scrum como o processo de desenvolvimento ´agil mais popular no mercado.

3.3.1 Origem

O Scrum foi originalmente formalizado como um processo de desenvolvimento de softwa-res por Ken Schwaber and Jeff Shutterland nos anos 1990 (SCHWABER, 1997). De acordo com Larman e Basili (2003), o método foi inspirado na abordagem interativa e incre-mental utilizada na constru¸cão de produtos complexos na indústria japonesa em empre-sas como Honda, Canon e Fujitsu. Shutterland e Schwaber (SUTHERLAND; SCHWABER, 2007) definem Scrum como uma abordagem enxuta para o desenvolvimento de softwares influenciada pelas melhores práticas da indústria japonesa, particularmente por princ´ıpios Lean.

O termo Scrum é originário do estudo publicado por Takeuchi e Nonaka em 1986 ( TAKEU-CHI; NONAKA, 1986), que indica que times pequenos e multifuncionais tem historicamente produzido resultados superiores no desenvolvimento de produtos complexos. Os autores comparam tais times a forma¸cões Scrum, do Rugby. No Rugby, cada time atua como uma unidade integrada onde cada membro contribui com um papel no time, buscando um objetivo em comum. Esta é a forma que times Scrum atuam no desenvolvimento de software (SCHWABER, 2004).

3.3.2 Caracter´ısticas Principais

O Scrum emprega um processo iterativo e incremental estruturado em em ciclos chama-dos de Sprint. A Sprint é uma itera¸cão, ou seja, um espa¸co de tempo fixo, onde ocorre a aplica¸cão de esfor¸cos visando a entrega de uma parcela funcional do produto. No in´ıcio de cada itera¸cão o time revisa o que deverá realizar e então seleciona os requisitos que acre-dita poder transformar em um incremento, ou funcionalidade potencialmente utilizável ao fim da itera¸cão. O time então coletivamente decide qual a melhor forma para realizar o trabalho planejado para a Sprint, analisando aspectos como requisitos, tecnologia e habi-lidades dos membros. Esta abordagem é adaptada e modificada diariamente, na medida em que novas complexidades, dificuldades ou surpresas são encontradas no caminho ao longo da itera¸cão. Ao final da itera¸cão, o time apresenta os incrementos constru´ıdos para que os stakeholders possam inspecionar e realizar adapta¸cões ao projeto.