GESTÃO DO CONHECIMENTO E SCRUM UMA ASSOCIAÇÃO …€¦ · GESTÃO DO CONHECIMENTO E SCRUM : UMA...

INSTITUTO DE EDUCAÇÃO TECNOLÓGICA - IETEC CURSO DE PÓS-GRADUAÇÃO EM

ENGENHARIA DE SOFTWARE - T07

Ellen Antonieta de Souza Oliveira Rezende Marcelo José da Silva

GESTÃO DO CONHECIMENTO E SCRUM: UMA ASSOCIAÇÃO OPORTUNA PARA MELHORIAS CONTÍNUAS NO

PROCESSO DE DESENVOLVIMENTO

BELO HORIZONTE, ABRIL / 2016

Ellen Antonieta de Souza Oliveira Rezende Marcelo José da Silva

GESTÃO DO CONHECIMENTO E SCRUM: UMA ASSOCIAÇÃO OPORTUNA PARA MELHORIAS CONTÍNUAS NO

PROCESSO DE DESENVOLVIMENTO

Monografia apresentada à Coordenação do Instituto de Educação Tecnológica – IETEC, para a obtenção de título de especialista em Engenharia de Software. Orientador: Prof. Dr. Fernando Zaidan

BELO HORIZONTE, ABRIL / 2016

AGRADECIMENTO

Agradecemos a Deus por iluminar nossos caminhos e nos dar forças para seguirmos

sempre em frente.

Eu, Ellen, agradeço ao meu esposo Fabiano pelo carinho, companheirismo,

compreensão e apoio incondicional. Aos meus pais pelo exemplo de força e

dedicação. Aos professores pelos novos aprendizados.

Eu, Marcelo, agradeço a minha esposa Maria Luiza por compreender meus

momentos de ausência para a elaboração deste trabalho e por sempre estar ao meu

lado em todos os momentos. Agradeço a minha família que mesmo longe sempre

me apoiaram e me ensinaram a lutar para alcançar os meus objetivos, com

humildade e perseverança. Agradeço aos professores por compartilharem os seus

conhecimentos e pelo apoio durante todo o curso.

RESUMO

As constantes evoluções no setor de desenvolvimento de software e a alta

competitividade do mercado faz com que as organizações busquem o

aprimoramento de seus processos de desenvolvimento de software e novas

metodologias com o objetivo de elaborar produtos com melhor qualidade e custo

reduzido. As organizações atualmente tem optado pela utilização do framework

Scrum e por melhorias na área da gestão do conhecimento (GC) para alcançar tais

objetivos. Este trabalho apresenta uma pesquisa exploratória e qualitativa com o

objetivo principal de avaliar as melhorias geradas pela associação do Scrum com a

GC. Foi realizado também um estudo sobre a importância de formar uma equipe

multidisciplinar e como compartilhar o conhecimento desde as primeiras fases de

desenvolvimento de um software. Por fim elaborou-se uma proposta de modelo de

desenvolvimento de software unificando o Scrum com as técnicas da GC, garantindo

entregas constantes aos clientes e focando na disseminação do conhecimento

através das fases de socialização e externalização do processo de Socialização,

Externalização, Combinação e Internalização (SECI), conhecida também como a

espiral do conhecimento.

Palavras-chave: Gestão do conhecimento. Scrum. Processo de desenvolvimento de

software. Métodos ágeis.

LISTA DE ILUSTRAÇÕES

Figura 1 - Processo SECI ....................................................................................... 15

Figura 2 - O ciclo de gestão do conhecimento de Turban, Mclean e Wetherbe ..... 16

Figura 3 - O ciclo de gestão do conhecimento de Bukowitz e Williams .................. 17

Figura 4 - Modelo cascata ...................................................................................... 22

Figura 5 - Modelo incremental ................................................................................ 23

Figura 6 - Prototipação ........................................................................................... 24

Figura 7 - O Scrum é a base sobre a qual os processos ágeis são construídos .... 30

Figura 8 - Fluxo do processo Scrum ....................................................................... 31

Figura 9 - Representação esquemática de uma Sprint .......................................... 33

Figura 10 - Base do modelo ..................................................................................... 38

Figura 11- Modelo de desenvolvimento de software ............................................... 39

Figura 12 - Fluxo da fase de especificação .............................................................. 40

Figura 13 - Fluxo da fase de análise ........................................................................ 41

Figura 14 - Fluxo da fase de projeto ......................................................................... 42

Figura 15 - Fluxo da fase de construção .................................................................. 43

Figura 16 - Fluxo da fase de teste ............................................................................ 44

Figura 17 - Fluxo da fase de implantação ................................................................. 45

Quadro 1 - Comparativo entre o desenvolvimento tradicional e o desenvolvimento

utilizando métodos ágeis ........................................................................ 26

Quadro 2 - Autores do manifesto ágil ....................................................................... 27

Quadro 3 - Princípios dos métodos ágeis de desenvolvimento de software ............ 28

Quadro 4 - Práticas do Scrum .................................................................................. 31

LISTA DE ABREVIATURAS

GC Gestão do Conhecimento

SECI Socialização Externalização Combinação e Internalização

SGBD Sistema de Gerenciamento de Banco de Dados

SUMÁRIO 1 INTRODUÇÃO ................................................................................................. 7

1.1 Objetivos ........................................................................................................... 8

1.2 Questão de pesquisa ........................................................................................ 8

1.3 Justificativas ..................................................................................................... 8

1.4 Estrutura do trabalho ........................................................................................ 9

2 REFERENCIAL TEÓRICO ............................................................................. 10

2.1 Dado, Informação e Conhecimento ................................................................ 10

2.2 Tipos de Conhecimento .................................................................................. 11

2.3 Importância do Conhecimento em um Ambiente Corporativo ......................... 12

2.4 Gestão do Conhecimento ............................................................................... 13

2.5 Metodologias da Gestão do Conhecimento .................................................... 16

2.6 O uso da tecnologia na Gestão do Conhecimento ......................................... 18

2.7 Equipes de Desenvolvimento ......................................................................... 19

2.8 Processos de Desenvolvimento ...................................................................... 21

2.8.1 Modelo Cascata .............................................................................................. 21

2.8.2 Modelo Incremental ........................................................................................ 22

2.8.3 Prototipação .................................................................................................... 23

2.9 Métodos Ágeis ................................................................................................ 24

2.10 Scrum ............................................................................................................. 29

3 METODOLOGIA ............................................................................................. 35

4 APRESENTAÇÃO DA PESQUISA ................................................................ 36

4.1 Princípios do modelo ...................................................................................... 37

4.2 Base do modelo .............................................................................................. 37

4.3 Fases do modelo ............................................................................................ 38

4.3.1 Especificação .................................................................................................. 39

4.3.2 Análise ............................................................................................................ 40

4.3.3 Projeto ............................................................................................................ 41

4.3.4 Construção ..................................................................................................... 42

4.3.5 Teste ............................................................................................................... 43

4.3.6 Implantação .................................................................................................... 44

5 CONSIDERAÇÕES FINAIS ........................................................................... 46

REFERÊNCIAS .............................................................................................. 48

7

1 INTRODUÇÃO

Com as constantes mudanças e evoluções que ocorrem no ambiente de

desenvolvimento de produtos, de forma geral, as exigências de que as empresas se

adaptem para atender ao mercado cada vez mais exigente e competitivo tornou-se

uma questão de sobrevivência. Para as empresas de desenvolvimento de software o

cenário não é diferente. As exigências em função das evoluções vão desde a

produção de softwares com qualidade, baixo custo, até aos aspectos de rapidez e

flexibilidade. A mudança necessária nas empresas para se adequar a essa nova

realidade pode implicar em alterações em toda a linha do processo produtivo.

No que tange os processos de desenvolvimento de softwares as evoluções foram

consideráveis, passando de abordagens sequenciais, onde se considerava a

finalização de cada fase, fazendo uma “passagem de bastão”, para abordagens de

maior iteração entre os membros das equipes, com pequenas entregas e

participação dos profissionais em toda a cadeia do processo, gerando desde já uma

difusão do conhecimento.

A origem dessa nova abordagem de equipes de trabalho multifuncionais e

multidisciplinares trabalhando com ciclos curtos e combinados para gerar inovação,

agilidade e qualidade foi apresentada por Takeuchi e Nonaka (1986) no artigo The

New New Product Development Game. A essa metodologia, na qual, a equipe

trabalha em conjunto do início ao fim do processo de desenvolvimento, existe uma

integração de papéis, um canal de comunicação direto com os envolvidos e um

comprometimento com a experimentação e os resultados, deu-se o nome de Scrum.

Associado a origem dessa nova metodologia podemos considerar, de acordo com o

mesmo artigo citado anteriormente, a origem de um importante conceito: a Gestão

do Conhecimento. Segundo seus precursores, Takeuchi e Nonaka (1986) o

ambiente gerado a partir da utilização da metodologia do Scrum é o ambiente

necessário para a divulgação de conhecimento, ambiente esse chamado de “ba”.

Tendo a mesma origem e utilizando de um mesmo ambiente é perceptível o quanto

a associação da gestão do conhecimento e do Scrum podem contribuir para

8

melhorias nos processos de desenvolvimento, ponto esse que objetivamos mostrar

nesse trabalho.

1.1 Objetivos

1.1.1 Objetivo Geral

O objetivo principal é identificar as melhorias que podem ser geradas no processo

de desenvolvimento de software em função da associação da gestão do

conhecimento com a metodologia ágil Scrum.

1.1.2 Objetivos Específicos

Os objetivos específicos são:

• Descrever as origens da gestão do conhecimento e do Scrum;

• Identificar uma forma de como compartilhar o conhecimento com os demais

membros da equipe de desenvolvimento do software desde as primeiras

fases;

• Descobrir a importância da formação de equipes para otimizar a

disseminação do conhecimento;

• Propor um modelo de desenvolvimento unificando o framework Scrum e as

técnicas da gestão do conhecimento.

1.2 Questão de pesquisa

Quais as vantagens que a aplicação de um modelo ágil de desenvolvimento

associado à disseminação do conhecimento pode gerar no resultado de

desenvolvimento de um software?

1.3 Justificativas

Em função da grande competitividade no mercado de desenvolvimento de software,

as empresas tem procurado realizar melhorias em seus processos, em busca de

9

sobrevivência. Dentre as melhorias podemos citar a utilização de metodologias

ágeis, como o Scrum, e como consequência a difusão e gestão de conhecimento.

Em um ambiente de trabalho conhecido, estamos tendo a percepção de que a

combinação desses dois conceitos podem trazer melhorias significativas. Sendo

assim, do ponto de vista corporativo, identificamos que este estudo pode abrir novas

oportunidades para a evolução dos processos, melhorando o gerenciamento das

informações que todos os dias são geradas pelos seus colaboradores e produzindo

resultados de melhor qualidade e com melhor produtividade.

Do ponto de vista acadêmico, este estudo possibilita gerar novos conhecimentos

sobre os processos envolvidos no desenvolvimento de software e contribuir como

material de estudo para pesquisas futuras.

1.4 Estrutura do trabalho

Este trabalho está organizado em cinco capítulos, conforme será detalhado. Após a

introdução, o Capítulo dois apresenta o referencial teórico composto por dez partes,

onde são descritos sobre os temas: gestão do conhecimento, expondo sobre a

informação, tipos de conhecimento bem como sua importância em ambientes

corporativos; as metodologias da gestão do conhecimento e a associação com o uso

de tecnologias; equipes e processos de desenvolvimento; os métodos ágeis e em

detalhes o modelo Scrum.

O Capítulo três apresenta a metodologia demonstrando o tipo e abordagem da

pesquisa, assim como a técnica utilizada. No Capítulo quatro é feita a apresentação

de uma proposta de modelo de desenvolvimento de software.

A conclusão é realizada no Capítulo cinco, onde se apresenta o resultado da

pesquisa com a proposta do modelo e indicam-se as limitações e sugestões para

outros estudos.

10

2 REFERENCIAL TEÓRICO

Nos dias atuais é perceptível a importância de converter o conhecimento existente

nas empresas em novas oportunidades proporcionando uma inovação contínua.

Uma forma de tornar isso possível seria com a utilização de metodologias ágeis,

como o Scrum (RORIZ; RORIZ FILHO, 2011).

O referencial teórico desse trabalho apresenta os conceitos e características

necessários para o entendimento e visualização das melhorias que a associação da

gestão do conhecimento e do Scrum podem trazer para as equipes de

desenvolvimento de software.

2.1 Dado, Informação e Conhecimento

Para compreender o conhecimento, primeiramente é necessário distingui-lo de dado

ou informação.

Segundo Ribeiro (2007) dado é um “conjunto de caracteres (símbolos, sinais),

colocado num meio físico, que de acordo com um alfabeto específico, permite a

representação de certa informação à cerca do mundo real. Corresponde ao lado

sintático de uma comunicação”. De acordo com Setzer (2015, p. 2), dado é “uma

sequência de símbolos quantificados ou quantificáveis. Quantificável significa que

algo pode ser quantificado e depois reproduzido sem que se perceba a diferença

para com o original”.

Para Ribeiro (2007) informação “é a interpretação de fenômenos ocorridos,

mensagens ou dados, que corresponde ao crescimento marginal do conhecimento

de uma pessoa à cerca do mundo real. Corresponde ao lado semântico de uma

comunicação”. Na opinião de Setzer (2015, p. 3) informação é “uma abstração

informal (isto é, não pode ser formalizada através de uma teoria lógica ou

matemática), que está na mente de alguém, representando algo significativo para

essa pessoa”.

11

Ribeiro (2007) afirma que conhecimento é um “modelo da realidade que o próprio

ser humano dispõe, na mente ou fora dela, construído através de experiência,

aprendizado e comunicação.” Segundo Davenport e Prusak (1998, p. 6)

conhecimento é “uma mistura fluida de experiência condensada, valores, informação

contextual e insight experimentado, a qual proporciona uma estrutura para a

avaliação e incorporação de novas experiências e informações”. Para Marakas

(1999, p. 264), “o conhecimento é dependente do contexto, porque o significado está

relacionado às condições, ou seja, o conhecimento é um significado feito pela

mente”.

2.2 Tipos de Conhecimento

De acordo com Cruz existem dois tipos de conhecimento, tácito e explícito: “O

conhecimento tácito é aquele que nós possuímos dentro de nós mesmos, fruto do

aprendizado e da experiência que desenvolvemos ao longo de nossa vida. O

conhecimento explícito é aquele que externamos formalmente ou não” (CRUZ, 2002,

p. 262).

Os autores Takeuchi e Nonaka (2008, p. 19) afirmam que:

• O conhecimento explícito pode ser expresso em palavras, números ou sons, e compartilhado na forma de dados, fórmulas cientificas, recursos visuais, fitas de áudio, especificações de produtos ou manuais. O conhecimento explícito pode ser rapidamente transmitido aos indivíduos, formal e sistematicamente. • O conhecimento tácito, por outro lado, não é facilmente visível e explicável. Pelo contrário, é altamente pessoal e difícil de formalizar, tornando-se de comunicação e compartilhamento dificultoso. As intuições e os palpites subjetivos estão sob a rubrica do conhecimento tácito.

A respeito do conhecimento explícito, Fialho et al. (2006, p.77) afirma que:

O conhecimento explícito é o modo dominante de conhecimento na filosofia ocidental. É o conhecimento da racionalidade que envolve o conhecimento de fatos e é adquirido principalmente pela informação. Pode ser articulado na linguagem formal e sistemática, em afirmações gramaticais, expressões matemáticas, especificações, manuais, etc. Esse tipo de conhecimento pode ser transmitido formal e facilmente entre os indivíduos e comunicado e compartilhado de maneira simples sob forma de dados brutos, fórmulas científicas, procedimentos codificados ou princípios universais. É processado, armazenado e transmitido eletronicamente de forma rápida. O conhecimento explícito é mais facilmente adquirido e transferido do que o tácito, pois é obtido principalmente pela educação formal.

12

Sobre o conhecimento tácito, Fialho et al. (2006, p. 76) afirma que:

É difícil formalizar o conhecimento tácito. Isso conduz a grandes dificuldades na transmissão e compartilhamento por métodos sistemáticos ou lógicos. Ademais, o compartilhamento do conhecimento tácito exige participação e envolvimento de todos na empresa. Sem isso, a criação do conhecimento na organização fica prejudicada.

2.3 Importância do Conhecimento em um Ambiente Corporativo

O conhecimento é que faz as organizações funcionarem. É necessário reconhecer o

conhecimento como um ativo corporativo e entender a necessidade de geri-lo e

cercá-lo do mesmo cuidado dedicado à obtenção de valor de outros ativos mais

tangíveis (DAVENPORT; PRUSAK, 1998).

Em um ambiente organizacional os fatores de extrema importância são as

competências dos funcionários, seus relacionamentos e, não mais o capital ou a

mão de obra. As competências dos funcionários não podem ser estocadas na

empresa, pois residem em suas cabeças e todos os dias vão para as suas casas

(MAGNANI; HEBERLÊ, 2010).

Atualmente estamos vivendo a era do conhecimento e da informação, que é

destacada pelo desenvolvimento intenso da ciência e das tecnologias em geral. No

ambiente organizacional há uma grande valorização no setor de serviços e na

consciência sobre a preservação ambiental. Pois suas riquezas são geradas a partir

do conhecimento, que é considerado o fator mais importante para a produção

(MAGNANI; HEBERLÊ, 2010).

Antigamente para as empresas, os funcionários eram considerados engrenagens

que contribuíam para o processo produtivo. Mas com o passar do tempo, observou-

se que as pessoas podiam contribuir com a evolução de seus processos através do

conhecimento. Por isso nos dias de hoje, as pessoas não são consideradas mais

como engrenagens, mas sim como ativos determinantes para o sucesso da empresa

(ANSOFF, 1990).

13

As empresas estão desenvolvendo e instalando metodologias e tecnologias para

transformar o conhecimento tácito em explícito. Elas procuram reter o conhecimento,

pois este capital tem se tornado um grande diferencial na obtenção de melhores

resultados. Podemos citar como exemplo a redução de custos, tomada de decisões,

aumento de produtividade, entre outros benefícios (TURBAN; MCLEAN;

WETHERBE, 2004).

2.4 Gestão do Conhecimento

Cerca de 300 anos atrás a sociedade vivia a era industrial, que foi marcada pelas

indústrias, surgimento de novas fontes de energias (carvão, petróleo e eletricidade)

e evolução da tecnologia, como por exemplo, o surgimento da máquina a vapor,

motores de combustão, motores elétricos, etc. Mas a partir da década de 1980

surgiu uma nova era conhecida como a do conhecimento, que foi marcada pelo

grande avanço da ciência e da tecnologia (MAGNANI; HEBERLÊ, 2010).

Nesta era, que Takeuchi e Nonaka (1986) publicaram um artigo sobre um novo

conceito de desenvolvimento de software. Os autores afirmam que a tarefa de

desenvolver um software deve ser atribuída a uma equipe multidisciplinar que esteja

disposta a compartilhar o conhecimento. Quando se trabalha em uma equipe

multidisciplinar os problemas são resolvidos mais rápidos e novos conhecimentos

são adquiridos durante todo o projeto.

Os mesmos autores citam como exemplo, o desenvolvimento da primeira mini

impressora da Epson. O projeto foi conduzido por engenheiros mecânicos que

tinham pouco conhecimento sobre eletrônica. O líder do projeto (que também era

engenheiro mecânico) estudou engenharia elétrica durante os dois anos de projeto e

compartilhou seus conhecimentos. No final todos os engenheiros adquiriram novos

conhecimentos sobre eletrônica (TAKEUCHI; NONAKA, 1986).

Nesta época que popularizou o termo “gestão do conhecimento”, que os autores

Turban, Mclean e Wetherbe (2004, p. 326), definem como:

14

[...] um processo que ajuda as empresas a identificar, selecionar, organizar, distribuir e transferir informação e conhecimento especializado que fazem parte da memória da empresa e que normalmente existem dentro delas de forma não-estruturada. A estruturação do conhecimento permite a resolução eficaz e eficiente de problemas, aprendizado dinâmico, planejamento estratégico e tomada de decisão.

De acordo com Nonaka e Takeuchi (1997, p. 12) a gestão do conhecimento é um

“processo interativo de criação do conhecimento organizacional, definindo-o como a

capacidade que uma empresa tem de criar conhecimento, disseminá-lo na

organização e incorporá-lo a produtos, serviços e sistemas”.

Para Dalkir (2005, p. 3):

Gestão do conhecimento é a coordenação deliberada e sistemática de pessoas de uma organização, tecnologia, processos e estrutura organizacional, a fim de agregar valores através da reutilização e da inovação. Esta coordenação é alcançada através da criação, compartilhamento e aplicação do conhecimento, bem como através das valiosas lições aprendidas e das melhores práticas adquiridas na memória corporativa, fomentando continuamente o aprendizado organizacional.

Uma organização cria e utiliza o conhecimento através da conversão de

conhecimento tácito para explicito, e vice-versa. O processo SECI ou espiral do

conhecimento descreve como o conhecimento é amplificado em termos de

qualidade e quantidade (TAKEUCHI; NONAKA, 2008).

Segundo Nonaka e Takeuchi (1997, p. 82) “a criação do conhecimento

organizacional é um processo em espiral, que começa no nível individual e vai

subindo, ampliando comunidades de interação que cruzam fronteiras entre seções,

departamentos, divisões e organizações”.

15

Figura 1 - Processo SECI

Fonte: TAKEUCHI; NONAKA, 2008, p. 24.

O conhecimento tácito é criado na fase de socialização e o compartilhamento ocorre

de indivíduo para indivíduo. O conhecimento é criado a partir da experiência direta e

a conversão acontece de tácito para tácito (TAKEUCHI; NONAKA, 2008). Para

exemplificar a fase de socialização, Mendes (2008) cita a maneira que um estagiário

pode adquirir conhecimentos observando e recebendo orientações de seu

orientador.

Na fase de externalização o compartilhamento ocorre de um indivíduo para um

grupo e a conversão do conhecimento ocorre de tácito para explicito. Nesta fase o

conhecimento é articulado através do diálogo e reflexão (TAKEUCHI; NONAKA,

2008). Um indivíduo que transcreve seu conhecimento tácito para um documento,

por exemplo, está realizando a conversão de conhecimento conforme explicado na

fase de externalização (MENDES, 2008).

Na fase de combinação o compartilhamento ocorre de um grupo para a organização

e a conversão do conhecimento ocorre de explícito para explicito. Esta fase consiste

em sistematizar e aplicar o conhecimento explícito e a informação (TAKEUCHI;

NONAKA, 2008). Mendes (2008) exemplifica esta fase citando a apresentação de

um relatório feito por analistas aos gerentes de uma empresa. O resultado desta

reunião pode gerar acréscimo de informações, e com isso combinações que geram

novos conhecimentos.

16

Na fase de internalização o compartilhamento ocorre da organização para o

indivíduo através de manuais, normas, livros, etc. A conversão do conhecimento

ocorre de explícito para tácito. Com a aquisição do novo conhecimento, o indivíduo

amplia os seus conceitos e se torna capaz de gerar novos conhecimentos, que

serviram como base para reiniciar o processo SECI (TAKEUCHI; NONAKA, 2008;

MENDES, 2008).

O processo SECI contribui para a cristalização do conhecimento, gerando novos

elementos que se tornarão parte da rede de conhecimento da organização. E o que

impulsiona este processo são as interações e as dinâmicas de conversão de

conhecimento tácito e conhecimento explícito (TAKEUCHI; NONAKA, 2008).

2.5 Metodologias da Gestão do Conhecimento

Turban, Mclean e Wetherbe (2004) afirmam que para implantar um sistema de GC,

seis passos devem ser seguidos em um ciclo. O ciclo é utilizado, pois um

conhecimento nunca é terminado, sempre há mudanças no ambiente e o

conhecimento precisa ser atualizado.

Figura 2 - O ciclo de gestão do conhecimento de Turban, Mclean e Wetherbe

Fonte: TURBAN; MCLEAN; WETHERBE, 2004, p. 331.

17

Segue a explicação dos seis passos citados por Turban, Mclean e Wetherbe sobre o

ciclo de gestão do conhecimento (FIGURA 2):

1. Criar conhecimento. O conhecimento cria-se à medida que as pessoas descobrem novas formas de fazer as coisas ou que desenvolvem know-how. Às vezes, o conhecimento externo é trazido para dentro do sistema.

2. Capturar conhecimento. É preciso reconhecer o valor do novo conhecimento e representa-lo de forma razoável.

3. Depurar o conhecimento. O novo conhecimento precisa ser colocado dentro do contexto correto para que possa ser acionado. É onde os insights humanos (qualidades tácitas) precisam ser capturados juntamente com os fatos explícitos.

4. Armazenar conhecimento. O conhecimento útil deve então ser armazenado em formato razoável em um repositório de conhecimento, de modo que os outros na empresa possam acessá-lo.

5. Administrar o conhecimento. Da mesma forma como em uma biblioteca, o conhecimento precisa ser mantido em movimento. Ele também precisa ser revisado para certificar-se de que seja relevante e preciso.

6. Difundir o conhecimento. O conhecimento precisa ser disponibilizado em formato útil para qualquer pessoa da empresa que dele precise, a qualquer hora e em qualquer lugar (TURBAN; MCLEAN; WETHERBE, 2004, p. 331-332).

O modelo de Bukowitz e Williams é composto por sete passos. Segundo os autores,

esse modelo descreve “como uma organização gera, mantêm e implanta um

estoque de conhecimento com o objetivo de gerar valores” (BUKOWITZ; WILLIAMS,

2000, p. 9).

Figura 3 - O ciclo de gestão do conhecimento de Bukowitz e Williams

Fonte: DALKIR, 2005, p. 32 Nota: Tradução do autor – Figura adaptada

18

Segue a explicação dos sete passos do ciclo (FIGURA 2) de Bukowitz e Williams

(2000):

Obter, consiste em buscar informações necessárias para tomar decisões, resolver problemas, ou inovar. Utilizar, lida com a forma de combinar informações de maneiras novas e interessantes, a fim de promover a inovação organizacional. O foco está principalmente em indivíduos e, em seguida, em grupos. Aprender, refere-se ao processo formal de aprendizagem a partir de experiências como um meio de criar vantagem competitiva. Uma memória organizacional é criada para que a aprendizagem organizacional se torne possível a partir dos sucessos (melhores práticas) e fracassos (lições aprendidas). Contribuir, nesta fase os funcionários postam o que eles aprenderam na base do conhecimento (por exemplo, um repositório). Somente desta forma o conhecimento individual pode tornar-se visível e disponível para toda a organização, se necessário. Avaliar, lida mais com o grupo e nível organizacional. Avaliação refere-se à avaliação do capital intelectual e exige que a organização defina a missão critica do conhecimento e o mapa atual do capital intelectual contra futuras necessidades de conhecimento. Construir/Sustentar, garante que o futuro capital intelectual da organização irá manter a organização viável e competitiva. Os recursos devem ser alocados para o crescimento e manutenção do conhecimento, e eles devem ser canalizados de tal forma a criar novos conhecimentos e reforçar o conhecimento existente. Despojar, a organização não deve manter seus ativos físicos ou intelectuais, se eles já não estão criando valores. Na verdade, um pouco de conhecimento pode ser mais valioso se for transferido para fora da organização. Nesta etapa do ciclo de GC, organizações precisam examinar seu capital intelectual em termos de recursos necessários para mantê-lo e se esses recursos seriam melhores utilizados em outro lugar. Isso envolve a compreensão do por que, quando, onde e como desinvestir formalmente partes da base de conhecimento (DALKIR, 2005, p. 32-35).

2.6 O uso da tecnologia na Gestão do Conhecimento

Segundo Turban, Mclean e Wetherbe (2004) a tecnologia é essencial para o

sucesso de um sistema de gestão do conhecimento. Para implantar um sistema de

GC são necessárias três tecnologias: comunicação, colaboração e armazenagem.

A tecnologia da comunicação permite aos usuários acessarem o conhecimento de

que precisam e comunicar-se com outros usuários. Podemos citar como exemplo, e-

mail, internet, intranet corporativa, etc. (TURBAN; MCLEAN; WETHERBE, 2004).

A tecnologia da colaboração auxilia no trabalho em grupo, pois permite aos usuários

acessarem os mesmos documentos ao mesmo tempo ou em horários e lugares

diferentes (TURBAN; MCLEAN; WETHERBE, 2004).

19

A tecnologia de armazenagem, a princípio foi utilizada para armazenar e administrar

o conhecimento explícito através de um SGBD. Com a evolução da tecnologia,

surgiram os sistemas de gestão de documentos eletrônicos e sistemas

especializados em armazenagem, que são capazes de capturar e armazenar o

conhecimento tácito (TURBAN; MCLEAN; WETHERBE, 2004).

Dalkir (2005) também classifica a tecnologia em três categorias. Para a captura e

criação de conhecimento, o autor cita como exemplo a mineração de dados e os

blogs. Para o compartilhamento e a disseminação de conteúdo, o autor cita as

ferramentas wikis e os portais que ficam hospedados na intranet de uma corporação.

E para a aquisição e aplicação do conhecimento, o autor cita os sistemas de suporte

a decisões e a inteligência artificial.

2.7 Equipes de Desenvolvimento

Segundo Fiorelli (2000, p.41) equipe é um “tipo especial de grupo em que, entre

outros atributos, evidencia-se elevada interdependência na execução das

atividades”.

Bressano (2012) pontua que “a cooperação é base para o trabalho em equipe, e é

preciso pensar no coletivo e no resultado do grupo”. Até que o grupo se torne

efetivamente uma equipe passa-se por algumas fases, ou estágios de

transformação, onde em cada fase a equipe apresenta determinadas características.

As fases pontuadas pelo autor são: Formação, Confusão/Conflito, Normatização,

Desempenho e Desintegração (BRESSANO, 2012).

Cada integrante de uma equipe, bem como as empresas e o próprio mundo atual

são movidos a conhecimento. Na área de desenvolvimento de software

especificamente a existência e geração de conhecimento é muito intensa, já que se

busca uma solução para diferentes problemas de negócio. Em equipes de

desenvolvimento de software grande parte do trabalho é intelectual, as pessoas

envolvidas precisam tomar uma série de decisões e os fatores de sucesso podem

estar relacionados com a experiência das pessoas envolvidas. Ou seja, por ser o

20

desenvolvimento de software uma atividade em grupo, os profissionais precisam se

comunicar e compartilhar conhecimento (GUIMARÃES, 2009).

As empresas têm apresentado grande preocupação com o compartilhamento do

conhecimento entre os membros de uma equipe e também entre equipes diferentes,

já que pode se tornar uma vantagem competitiva, além de outros inúmeros

benefícios. Essa preocupação engloba também o fator de identificar formas

adequadas de como compartilhar o conhecimento, além do fator de como retê-lo

(GUIMARÃES, 2009).

Segundo Gattoni (2001, p. 10), algumas ações práticas que podem ser aplicadas

pelo gerente de um projeto, por exemplo, para promover o compartilhamento de

conhecimento e informação se resumem em:

1. Fomentar a criação de mapas de conhecimento do projeto (ou da organização); 2. Estimular a criação de fóruns para a apresentação de narrativas e histórias orais; 3. Estimular a criação de protótipos das soluções desenvolvidas; 4. Realizar cenários e simulações para o planejamento e a tomada de decisões; 5. Lançar mão de processos de flutuação e caos criativo; 6. Empregar largamente metáforas, analogias e modelos; 7. Solicitar aos executivos patrocinadores do projeto a implantação de meritocracia das ideias; 8. Criar e estimular o armazenamento de informações críticas em repositórios do conhecimento; 9. Ser um facilitador e um incentivador das comunidades de prática; 10. Procurar facilitar a transferência do conhecimento por tradição; 11. Estimular a formação de equipes de projeto multidisciplinares.

Estabelecer um clima favorável ao aprendizado, com envolvimento e recompensas

aos membros da equipe; ter uma equipe com profissionais com diferentes níveis de

conhecimento e canais para o fluxo desse conhecimento são algumas práticas

importantes a serem aplicadas no ambiente de desenvolvimento de software, para o

compartilhamento de conhecimento em todo o ciclo de um projeto (GUIMARÃES,

2009).

21

2.8 Processos de Desenvolvimento

Pressman (2011, p. 52) define o processo de software “como uma metodologia para

as atividades, ações e tarefas necessárias para desenvolver um software de alta

qualidade.”

Segundo Sommerville (2011, p. 18) todo processo de desenvolvimento de software

deve incluir quatro atividades fundamentais para a engenharia de software:

Especificação de software. A funcionalidade do software e as restrições a seu funcionamento devem ser definidas. Projeto e implementação de software. O software deve ser produzido para atender as especificações. Validação de software. O software deve ser validado para garantir que atenda às demandas do cliente. Evolução de software. O software deve evoluir para atender às necessidades de mudança dos clientes.

O processo de software é complexo e depende de pessoas para realizar

julgamentos e tomar decisões. Não existe o processo ideal, a maioria das

organizações cria o seu próprio processo. Os processos buscam tirar o melhor

proveito das capacidades das pessoas e das características do software em

desenvolvimento (SOMMERVILLE, 2011).

2.8.1 Modelo Cascata

Conhecido também como “ciclo de vida de software”, o modelo em cascata é

considerado um processo onde você deve planejar e programar todas as atividades

antes de inicia-las. Este processo é considerado sequencial e se inicia com o

levantamento dos requisitos junto ao cliente, avança pelas fases de planejamento,

modelagem, construção, emprego e manutenção do software (SOMMERVILLE,

2011; PRESSMAN, 2011).

22

Figura 4 - Modelo cascata

Fonte: PRESSMAN, 2011, p. 60.

De acordo com Pressman (2011, p. 61) o modelo cascata possui alguns problemas:

• Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Embora o modelo linear possa conter iterações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue. • Frequentemente, é difícil para o cliente estabelecer explicitamente todas as necessidades. O modelo cascata requer isso e tem dificuldade para adequar a incerteza natural que existe no início de muitos projetos. • O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não estará disponível antes de estarmos próximos do final do projeto. Um erro grave, se não detectado até o programa operacional ser revisto, pode ser desastroso (PRESSMAN, 2011, p. 61).

2.8.2 Modelo Incremental

Devido às limitações da modelagem sequencial, Barry Boehm sugeriu uma nova

abordagem para o desenvolvimento de software, conhecida como “incremental”. O

objetivo desta modelagem é dividir o desenvolvimento em incrementos até que se

alcance a finalização do software. Em cada incremento é realizado todo o ciclo de

desenvolvimento de software (comunicação, planejamento, modelagem, construção

e implantação) e ao final se tem um sistema totalmente funcional (NEPOMUCENO,

2012).

23

Figura 5 - Modelo incremental

Fonte: NEPOMUCENO, 2012.

De acordo com Pressman (2011) o desenvolvimento incremental é útil em casos

onde há um número reduzido de pessoas disponíveis para uma completa

implementação na época de vencimento do projeto. Os primeiros incrementos são

disponibilizados e caso o produto seja aceito, posteriormente é possível adicionar

novos integrantes para ajudar no desenvolvimento.

2.8.3 Prototipação

Prototipação é considerado um modelo evolucionário que pode ser utilizado como

um modelo de processo isolado. Geralmente é utilizada como uma técnica para

facilitar a comunicação e interpretação dos requisitos do software (PRESSMAN,

2011).

A prototipação se inicia com uma reunião entre os envolvidos, para definir os

objetivos do sistema e identificar os requisitos que necessitam de uma definição

24

mais ampla. A iteração é planejada e a modelagem se inicia, com foco em

representar os aspectos de software que serão visíveis aos usuários finais. O

protótipo é construído e apresentado para os interessados com o objetivo de obter o

feedback, que servirá para aprimorar os requisitos (PRESSMAN, 2011).

Figura 6 - Prototipação


Segundo Nepomuceno (2012) o protótipo pode ser apresentado de diversas

maneiras diferentes. Podemos desenhar as telas em folhas de papel, criar um

executável com a finalidade de o cliente entender a interação com o sistema ou até

utilizar um programa existente para representar uma funcionalidade a construir.

2.9 Métodos Ágeis

Conforme Pressman (2011, p. 82), “em essência, métodos ágeis se desenvolveram

em um esforço para sanar fraquezas reais e perceptíveis da engenharia de software

convencional.”

De acordo com Pressman (2011, p. 82) “as condições de mercado mudam

rapidamente, as necessidades dos usuários finais se alteram e novas ameaças

competitivas emergem sem aviso. [...] É preciso ser ágil o suficiente para dar uma

resposta ao ambiente de fluido negócios.” Deve-se entender como agilidade a rápida

25

capacidade de responder a mudanças, desde mudanças no software, na equipe de

desenvolvimento até as tecnologias (PRESSMAN, 2011).

Diante dessa nova realidade e das exigências apresentadas foram criados métodos

próprios, conforme Prikladnicki, Willi e Milani (2014, p. 4) “em resposta àqueles

tradicionais, considerados excessivamente regrados, lentos, burocráticos e

inadequados”, os quais agrupados deram origem aos Métodos Ágeis. Dessa forma,

[...] os Métodos Ágeis podem ser considerados uma coletânea de diferentes técnicas e métodos, que compartilham os mesmos valores e princípios básicos, alguns dos quais remontam de técnicas introduzidas em meados dos anos 70, como os desenvolvimentos e melhorias iterativos (COHEN et al., 2003, p. 2).

Segundo Prikladnicki, Willi e Milani (2014, p. 19), “o que diferencia os Métodos Ágeis

dos outros métodos é o enfoque maior nas pessoas e não em processo, e o seu

conjunto de valores, princípios e práticas”.

É possível verificar em pouco mais de uma década como as empresas têm mudado

sua forma de trabalho, procurando se adaptar ao moderno cenário, apesar de saber-

se da existência de resistência às mudanças.

No Quadro 1 a seguir, visualizamos o comparativo de alguns aspectos do

desenvolvimento de software baseado nos modelos tradicionais e nos Métodos

Ágeis.

26

Quadro 1 - Comparativo entre o desenvolvimento tradicional e o desenvolvimento utilizando métodos ágeis

Fonte: PRIKLADNICKI; WILLI; MILANI, 2014, p. 22.

Apesar de em meados dos anos 90 esses novos processos iterativos começarem a

surgir, eles “só passaram a ser chamados de ágeis em 2001, quando um grupo de

17 especialistas (QUADRO 1) se reuniu, [...] nos Estados Unidos, para discutir

maneiras de desenvolver software de uma forma mais leve, rápida e centrada em

pessoas” (PRIKLADNICKI; WILLI; MILANI, 2014, p. 3-4).

27

Quadro 2 - Autores do manifesto ágil


Como resultado do encontro, foi criada a Agile Alliance, sendo publicado o Manifesto

para Desenvolvimento Ágil de Software ou o Manifesto for Agile Software

Development (BECK et al., 2001). O Manifesto inicia-se da seguinte forma:

Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando formas melhores de desenvolvimento. Por meio deste trabalho passamos a valorizar: Indivíduos e interações acima de processos e ferramentas Software operacional acima de documentação completa Colaboração dos clientes acima de negociação contratual Respostas a mudanças acima de seguir um plano

28

Ou seja, embora haja valor nos itens à direita, valorizaremos os da esquerda mais ainda (BECK et al. 2001).

Além do Manifesto foram definidos os 12 princípios, apresentados na Tabela 2 a

seguir, que formam os pilares que regem os Métodos Ágeis de Desenvolvimento de

Software (BECK et al., 2001).

Quadro 3 - Princípios dos métodos ágeis de desenvolvimento de software

Fonte: BECK et al., 2001.

Pode-se dizer, então, que os Métodos Ágeis caracterizam-se, de acordo com

Sommerville (2011, p. 40) como “incremental para a especificação, o

desenvolvimento e a entrega do software.” Ainda o mesmo autor pontua que esses

Métodos “são mais adequados ao desenvolvimento de aplicativos nos quais os

requisitos de sistema mudam rapidamente durante o processo de desenvolvimento.”

(SOMMERVILLE, 2011, p. 40). Concluindo, Sommerville (2011, p. 40) descreve que

os Métodos Ágeis “têm como objetivo reduzir a burocracia do processo, evitando

qualquer trabalho de valor duvidoso de longo prazo e qualquer documentação que

provavelmente nunca será usada.”

Dentre os principais Métodos Ágeis podem ser citados: Crystal, Desenvolvimento de

Software Adaptativo, LSD (Desenvolvimento de Software Enxuto), DSDM, Extreme

Programming (XP), FDD e Scrum (PRESSMAN, 2011). Nesse trabalho o foco será

apresentar em detalhes o Método Scrum.

29

2.10 Scrum

Nas palavras de Pressman (2011, p. 95) “Scrum (o nome provém de uma atividade

que ocorre durante a partida de rugby1) é um método de desenvolvimento ágil de

software” que teve sua origem em:

1986, Takeuchi e Nonaka publicaram um estudo na Harvard Business Review (The New New Product Development Game, HBR, Janeiro-Fevereiro, 1986) no qual comparavam equipes de alto desempenho e multidisciplinares com a formação Scrum existente nas equipes de rugby. Eles descobriram que equipes pequenas e multidisciplinares produziam os melhores resultados. Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka (1986) (PRIKLADNICKI; WILLI; MILANI, 2014, p. 24).

A formalização do processo do Scrum ocorreu em 1995, por Jeff Sutherland e Ken

Schwaber com a publicação de um artigo na conferência OOPSLA (PRIKLADNICKI;

WILLI; MILANI, 2014).

De acordo com Prikladnicki, Willi e Milani (2014, p. 25), “o Scrum foi elaborado tendo

como foco a resolução de problemas complexos em ambientes de alta

imprevisibilidade [...] já que há pouca estabilidade nas tecnologias utilizadas e o

trabalho a ser feito está sempre respondendo à dinâmica intensa do mercado.” Os

mesmos autores descrevem ainda que o Scrum foi estruturado como um framework

fornecendo uma estrutura como suporte, sobre a qual podem ser construídos novos

processos (PRIKLADNICKI; WILLI; MILANI, 2014).

1 Um grupo de jogadores faz uma formação em torno da bola e seus companheiros de equipe trabalham juntos (às vezes de forma violenta!) para avançar com a bola em direção ao fundo do campo.

30

Figura 7 - O Scrum é a base sobre a qual os processos ágeis são construídos


Para Pressman (2011, p. 95) “o Scrum engloba um conjunto de padrões de

processos enfatizando prioridades de projeto, unidades de trabalho

compartimentalizados, comunicação e feedback frequente por parte dos clientes.”

Para Cohen et al. (2003, p. 16-17) as características principais que norteiam o

Scrum são:

- Tamanho da equipe: O trabalho é dividido em equipes de até sete pessoas. - Duração das iterações: Duração usual de quatro semanas por iteração. - Equipes distribuídas: Como o projeto pode ser constituído por várias pequenas equipes, há a possibilidade de que estas estejam distribuídas (descentralizadas). - Aplicações de alta criticidade: Não há menção específica quanto à aplicabilidade do método para desenvolvimento de software de alta criticidade.

De acordo com Pressman (2011, p. 95) no Scrum, “em cada atividade metodológica,

ocorrem tarefas a realizar dentro de um padrão de processo chamado Sprint. O

trabalho realizado dentro do Sprint é adaptado ao problema em questão e definido, e

muitas vezes modificado em tempo real, pela equipe Scrum.”

O fluxo do processo Scrum é ilustrado na Figura 8.

31

Figura 8 - Fluxo do processo Scrum


Conforme Schwaber e Sutherland (2013, p. 3), o “Scrum consiste nos times

associados a papéis, eventos, artefatos e regras.” No Quadro 4, podem ser

visualizadas as práticas desse framework.

Quadro 4 - Práticas do Scrum

Fonte: Desenvolvimento Ágil, 2016.

Segundo Schwaber e Sutherland (2013, p. 5), “o Time Scrum é composto pelo

Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são

32

auto-organizáveis e multifuncionais. [...] O modelo do Time Scrum é projetado para

aperfeiçoar a flexibilidade, criatividade e produtividade.”

Descrevendo os papéis que compõem o Time Scrum, pode-se citar que “O Product

Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do

trabalho do Time de Desenvolvimento. [...] O Product Owner é a única pessoa

responsável por gerenciar o Backlog do Produto” (SCHWABER; SUTHERLAND,

2013, p. 5). Os mesmos autores descrevem ainda que “O Time de Desenvolvimento

consiste de profissionais que realizam o trabalho de entregar uma versão usável que

potencialmente incrementa o produto “Pronto” ao final de cada Sprint” (SCHWABER;

SUTHERLAND, 2013, p. 5).

Sommerville (2011, p. 50) define que “o papel do Scrum Master é proteger a equipe

de desenvolvimento de distrações externas”, bem como descreve que o Scrum

Master é um “facilitador, que organiza reuniões diárias, controla o backlog de

trabalho, registra decisões, mede o progresso comparado ao backlog e se comunica

com os clientes e a gerência externa à equipe” (SOMMERVILLE, 2011, p. 51).

O Backlog do Produto é um dos artefatos que compõe o Scrum e segundo

Pressman (2011, p. 96) consiste na “priorização das funcionalidades do produto

desejadas pelo cliente.” Em corroboração, Schwaber e Sutherland (2013, p. 13)

descrevem que ele “é uma origem única dos requisitos para qualquer mudança a ser

feita no produto.”

Outro artefato do Scrum é o Backlog da Sprint que corresponde ao “conjunto de

itens selecionados para serem implementados durante a Sprint mais o plano para

transformá-los em um Incremento” (PRIKLADNICKI; WILLI; MILANI, 2014, p. 29).

As iterações que ocorrem no fluxo do processo Scrum, chamadas de Sprint, “são

compostas de pela reunião de planejamento da Sprint, reuniões diárias, o trabalho

de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.”

(SCHWABER; SUTHERLAND, 2013, p. 8). A Figura 9 demonstra essas

atividades/cerimônias que compõe a Sprint.

33

Figura 9 - Representação esquemática de uma Sprint


Sobre a Reunião de Planejamento da Sprint Prikladnicki, Willi e Milani (2014, p. 32)

descrevem que é a reunião onde “a Equipe Scrum se reúne para planejar o que será

feito naquela Sprint”. Esses mesmos autores pontuam que os itens a serem

analisados para compor a Sprint são selecionados a partir do Backlog do Produto, e

todos os participantes da Equipe colaboram para realizar a definição. À partir desses

itens selecionados têm-se a meta da Sprint, que vai compor o Backlog da Sprint,

tendo então definido o compromisso entre a Equipe de Desenvolvimento e o Dono

do Produto, dos itens a serem entregues (PRIKLADNICKI; WILLI; MILANI, 2014).

A reunião Scrum Diária consiste de um evento de 15 minutos, “feita para inspecionar

o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito

antes da próxima Reunião Diária” (SCHWABER; SUTHERLAND, 2013, p. 11).

Pressman (2011, p. 96) descreve que nessas reuniões diárias:

São feitas três perguntas-chave e respondidas por todos os membros da equipe: O que você realizou desde a última reunião de equipe? Quais obstáculos está encontrando? O que planeja realizar até a próxima reunião de equipe?

Para Schwaber e Sutherland (2013, p. 11) “a reunião diária é mantida no mesmo

horário e local todo dia para reduzir a complexidade.” Esses mesmos autores

34

descrevem ainda que “O Time de Desenvolvimento usa a Reunião Diária para

inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o

progresso tende para completar o trabalho do Backlog da Sprint” (SCHWABER;

SUTHERLAND, 2013, p. 11). Prikladnicki, Willi e Milani (2014, p. 33) complementam

que “essa reunião permite que os membros se comuniquem e sincronizem seu

trabalho. Como os grupos auto-organizados, a reunião não tem como objetivo

qualquer tipo de relatório.”

A reunião de Revisão da Sprint ocorre ao final de cada Sprint (PRIKLADNICKI;

WILLI; MILANI, 2014) e tem como objetivo “inspecionar o que a Equipe de

Desenvolvimento produziu e colher opiniões e impressões dos presentes para, caso

seja necessário, adaptar o plano para a Sprint seguinte” (PRIKLADNICKI; WILLI;

MILANI, 2014, p. 33). De acordo com os autores Schwaber e Sutherland (2013, p.

12), o resultado dessa reunião “é um Backlog do Produto revisado que define o

provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode

também ser ajustado completamente para atender novas oportunidades.”

A Retrospectiva da Sprint é o último evento que ocorre. De acordo com Prikladnicki,

Willi e Milani (2014):

Participam dessa reunião todos os membros da Equipe Scrum, e seu foco é o aprimoramento do processo – a interação entre os membros da Equipe de Desenvolvimento, as práticas e ferramentas utilizadas, o que funcionou e o que precisa ser melhorado na próxima Sprint. Além de identificar problemas, é importante também identificar medidas a serem tomadas para a melhoria do processo para as próximas Sprints (PRIKDADNICKI; WILLI; MILANI, 2014, p. 33).

Schwaber e Sutherland (2013, p. 12), descrevem além de outros que a

Retrospectiva tem como propósito “Criar um plano para implementar melhorias no

modo que o Time Scrum faz seu trabalho.”

35

3 METODOLOGIA

Neste estudo foram realizadas pesquisas sobre a Gestão do Conhecimento e o

Scrum com a finalidade de demonstrar suas origens e as melhorias que esses dois

temas em conjunto podem trazer para o processo de desenvolvimento de software,

objetivo principal dessa pesquisa. Esse tipo de pesquisa é caracterizado como

exploratória, que segundo Gil (2002) possui como objetivo proporcionar maior

familiaridade com o problema, e estimular a compreensão através do levantamento

bibliográfico.

A abordagem desta pesquisa é considerada qualitativa, que de acordo com

Prodanov e Freitas (2013) é composta pela interpretação dos fenômenos e a

atribuição de significados. Ainda os mesmos autores afirmam que, “os dados

coletados nessas pesquisas são descritivos, retratando o maior número possível de

elementos existentes na realidade estudada. Preocupa-se muito mais com o

processo do que com o produto” (PRODANOV; FREITAS, 2013, p. 70).

A técnica utilizada para este trabalho é documental, que de acordo com Severino

(2007, p. 124) a técnica documental “no contexto da realização de uma pesquisa, é

a técnica de identificação, levantamento, exploração de documentos fontes do objeto

pesquisado e registro das informações retiradas nessas fontes e que serão

utilizadas no desenvolvimento do trabalho”.

36

4 APRESENTAÇÃO DA PESQUISA

Este trabalho focará em propor um modelo de desenvolvimento de software

utilizando como base o framework Scrum associado a técnicas da gestão do

conhecimento. Por utilizar como base um framework, adaptações podem ser feitas

considerando a necessidade de cada empresa ou projeto.

O modelo proposto é constituído por seis fases que tem como base em sua

execução o fluxo do Scrum, tendo ao final da última fase uma entrega funcional do

sistema implantada para uso do cliente. Esse processo se repetirá tantas vezes

quanto forem necessárias até a última entrega do software. Em cada uma das fases

do modelo são gerados “artefatos” como documentação, à medida da evolução.

Essa documentação constitui-se no mínimo necessário para o entendimento da

equipe participante do projeto, incluindo o cliente.

Foi previsto na proposta do trabalho, a execução do fluxo do Scrum em cada uma

das fases do modelo, de modo que a entrega de uma fase mostra-se “funcional”

para o start da fase seguinte, não sendo necessário finalizar todo o escopo do

projeto de uma fase para iniciar a seguinte. Visualizamos dessa forma a participação

em cada fase de pequenas equipes de trabalho organizadas de modo a maximizar a

comunicação e validação das entregas contribuindo além de tudo para a realização

das modificações necessárias para garantir a produção de um software melhor.

Pela identificação da importância e contribuição para melhorias no desenvolvimento

de software, foram aplicadas ao modelo algumas técnicas da gestão do

conhecimento. Conforme a proposta do processo SECI, a criação do conhecimento

ocorre em algumas fases, das quais consideramos para esse modelo,

principalmente, a Socialização e a Externalização.

No modelo consideramos e reforçamos a importância da formação da equipe de

desenvolvimento, no qual propomos que seja uma equipe multidisciplinar, com

profissionais com experiências diversas, para que ocorra o compartilhamento e

criação de conhecimento tácito, considerando a experiência dos envolvidos -

processo de Socialização.

37

Num processo de desenvolvimento de software circula uma enorme quantidade de

informação e conhecimento, ao longo de todo o ciclo, que precisam ser geridas. No

modelo proposto nesse trabalho sugerimos utilizar para o compartilhamento e

disseminação do conhecimento, além das reuniões do Scrum utilizadas no modelo,

os portais, como a ferramenta Enterprise Architect, onde os artefatos gerados em

cada fase serão registrados e armazenados, para acesso de toda a equipe.

4.1 Princípios do modelo

O modelo apresenta como princípios básicos a utilização do framework Scrum e de

técnicas da gestão do conhecimento.

Outros princípios são aplicados ao longo do fluxo:

• Formação de uma equipe multidisciplinar;

• Preocupação com a definição de “pronto” das funcionalidades dos

incrementos a serem entregues;

• Entrega de partes funcionais do software para o cliente;

• Participação do cliente em pontos estratégicos do processo, para o

entendimento e definição das necessidades bem como o feedback sobre as

entregas realizadas;

• Gerir, propagar e validar o conhecimento gerado sobre o software ao longo do

ciclo de desenvolvimento.

4.2 Base do modelo

A base do modelo é montada a partir do framework Scrum, com a definição do fluxo,

papéis, artefatos e eventos. Em pontos considerados estratégicos destacamos de

forma mais clara a aplicação da técnica de Externalização do conhecimento, do

processo SECI. Os pontos vislumbrados onde ocorre a Externalização é no contato

inicial com o Dono do Produto para o entendimento das necessidades e montagem

38

do Backlog do Produto, nas reuniões de Planejamento do Sprint bem como nas

Reuniões Diárias.

Figura 10 - Base do modelo

Fonte: Do autor, 2016.

O fluxo base de execução do modelo é o próprio fluxo do Scrum, assim como as

atividades e papéis. Em cada fase propõe-se a utilização desse modelo base, de

acordo com a necessidade, e tem-se a participação de determinados profissionais

da equipe, bem como são usados e gerados artefatos como documentação.

4.3 Fases do modelo

O modelo é dividido em seis fases, a saber: Especificação, Análise, Projeto,

Construção, Teste e Implantação.

39

Figura 11- Modelo de desenvolvimento de software


Em cada fase é proposto a execução do fluxo do Scrum, conforme modelo base

apresentado, tendo ao final uma entrega que permite a realização dos trabalhos da

próxima fase. Ao final de todas as fases tem-se um incremento funcional do produto

implantado no cliente.

4.3.1 Especificação

O start da fase de especificação ocorre no surgimento de uma demanda de

desenvolvimento de software, por parte de um cliente.

40

Figura 12 - Fluxo da fase de especificação


Participam exclusivamente dessa fase o analista de sistemas e o cliente, para o

levantamento das necessidades e bases de conhecimento tendo a partir de então a

definição do Backlog do produto. Após a execução do fluxo, é gerada a

documentação contendo a lista de requisitos e regras de negócio que permitirá o

início da próxima fase do modelo, enquanto novas Sprints são planejadas e

executadas até o atendimento de todos os itens definidos no Backlog do produto.

4.3.2 Análise

A fase de análise pode ter seu início logo após a primeira entrega da fase de

especificação. Os artefatos gerados na fase anterior vão compor o Backlog do

produto dessa fase.

41

Figura 13 - Fluxo da fase de análise


A equipe participante dessa fase é constituída pelo analista de sistemas, o cliente, o

desenvolvedor e o analista de teste. O objetivo já é o envolvimento de profissionais

que executarão atividades de fases posteriores para que já obtenham conhecimento

e informações importantes, bem como de apoiar em determinadas decisões sobre o

software a ser desenvolvido. A participação do cliente já permite validações e

feedbacks dos pontos já verificados.

Após a execução do fluxo, é gerada a documentação contendo os casos de uso e

protótipos, podendo-se dar o start na próxima fase do modelo. Novas Sprints são

planejadas e executadas até o atendimento de todos os itens definidos no Backlog

do produto.

4.3.3 Projeto

A fase de projeto inicia-se após a primeira entrega da fase de análise, tendo seu

Backlog do produto composto pelos artefatos gerados na fase anterior.

42

Figura 14 - Fluxo da fase de projeto


Nessa fase participam o analista de sistemas e o desenvolvedor. Após a execução

do fluxo, é gerada a documentação contendo os diagramas de classe e de

sequência, podendo-se dar o start na próxima fase do modelo. Novas Sprints são

planejadas e executadas até o atendimento de todos os itens definidos no Backlog

do produto.

4.3.4 Construção

Na fase de construção participam exclusivamente o analista de sistemas e o

desenvolvedor. O start dessa fase se dá após a primeira entrega da fase de projeto.

Com o envolvimento mais forte desses dois profissionais nessa fase e também na

anterior, a execução das atividades torna-se bem mais facilitada uma vez que o

conhecimento sobre as demandas a serem trabalhadas já é grande.

43

Figura 15 - Fluxo da fase de construção


Após a execução do fluxo, é gerado o setup de instalação bem como o manual

correspondente, podendo-se dar o start na próxima fase do modelo. Novas Sprints

são planejadas e executadas até o atendimento de todos os itens definidos no

Backlog do produto.

4.3.5 Teste

Na fase de teste o start ocorre após a entrega do primeiro setup para instalação.

Com a participação do analista de teste em fases anteriores, a estrutura base para o

início dos testes já existirá, como por exemplo, os planos de testes.

44

Figura 16 - Fluxo da fase de teste


Participam nessa fase o analista de teste, o analista de sistema e o desenvolvedor.

Esses dois últimos profissionais principalmente para atuações nos casos de erros

encontrados no software, ajustando quando necessário, alguma documentação bem

como o código fonte.

Ao final dessa fase tem-se o software homologado e pronto para ser implantado no

cliente. São gerados os casos de testes além de ter-se o resultado das execuções

dos testes automatizados, que podem ser enviados ao cliente para averiguação.

4.3.6 Implantação

A fase de implantação tem seu início após a primeira entrega funcional e

homologada do software. Seguindo um dos princípios do Scrum essa entrega pode

ser implantada para uso no cliente.

45

Figura 17 - Fluxo da fase de implantação


Com o envolvimento do cliente em algumas fases do processo, retornos e

validações já foram feitos por ele, mas considera-se que ao utilizar de fato o

software, novas demandas e necessidades possam surgir. Nesses casos elas vão

compor o Backlog do produto, sendo trabalhadas ao longo das fases propostas no

modelo.

46

5 CONSIDERAÇÕES FINAIS

Os objetivos estabelecidos no trabalho foram cumpridos, identificando-se as

melhorias que a associação da gestão do conhecimento com a metodologia ágil

Scrum podem trazer para o processo de desenvolvimento de software, retratando as

origens desses dois importantes temas, demonstrando a importância da formação

das equipes de trabalho e as formas de como compartilhar o conhecimento entre os

membros da equipe, ficando esse item bem evidente no modelo de desenvolvimento

de software proposto.

No referencial teórico, foi descrito as origens da gestão do conhecimento e do

Scrum, percebendo-se uma grande similaridade entre os temas já que retratam a

importância de se trabalhar com equipes multidisciplinares, uma vez que como

importantes resultados têm-se o compartilhamento de conhecimento entre os

envolvidos para a obtenção de um produto com melhor qualidade, e realizar

entregas mais ágeis e constantes para o cliente.

Identificou-se a importância do conhecimento nos ambientes corporativos e o quanto

criar, difundir e gerir esse conhecimento pode hoje se tornar um diferencial

competitivo para as empresas. E para que esse processo ocorra é de extrema

importância a formação das equipes de trabalho, com profissionais com experiências

diversas e conscientes da necessidade do compartilhamento do conhecimento.

Complementando reforçou-se a importância da utilização de tecnologias que

permitam o armazenamento e o acesso a informação gerada durante o processo de

desenvolvimento.

Percebeu-se durante as pesquisas a importância que os métodos ágeis têm

adquirido, considerando a necessidade de respostas rápidas para mudanças em

diversos cenários que hoje é uma realidade no mercado, além das exigências de

qualidade e produtividade. E nesse contexto o Scrum aparece como uma forte

tendência, uma vez que visa um desenvolvimento iterativo e incremental, com

entregas rápidas e funcionais ao cliente possibilitando feedbacks constantes.

47

Diante de todas as evidências levantadas, concluiu-se com a proposta de um

modelo de desenvolvimento de software aliando as técnicas da gestão do

conhecimento com o Scrum no qual foram visualizadas as possibilidades de

compartilhamento de conhecimento desde a primeira fase do modelo, com a

socialização e a externalização, a participação do cliente em pontos importantes e

estratégicos, objetivando seu feedback, e entregas rápidas e funcionais para a

implantação e utilização pelo cliente.

Limitações do estudo e sugestão de continuidade

Embora este trabalho tenha sido concluído atingindo os objetivos inicialmente

propostos, devem ser pontuadas as limitações encontradas e sugestões de novos

estudos acerca do tema.

Como limitação do trabalho deve ser pontuada a impossibilidade de implantar neste

momento o modelo de desenvolvimento de software proposto. Desta maneira não foi

possível determinar as melhores tecnologias a serem utilizadas no modelo para se

trabalhar com a gestão do conhecimento e analisar todas as suas vantagens e

desvantagens.

Portanto, sugerimos para próximos estudos realizar a prática de implantação do

modelo em uma empresa de desenvolvimento, fazendo uma avaliação por completo

do modelo, assim como também explorar novas possibilidades de melhorias.

48

REFERÊNCIAS

ANSOFF, Harry I. A nova estratégia empresarial. 1. ed. São Paulo: Atlas, 1990. BECK, K. et al. Manifesto for agile software development. 2001. Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 02 jan. 2016. BRESSANO, A. Formando equipes de alto desempenho, parte 1: início e fases de evolução. Disponível em: <http://www.infoq.com/br/articles/equipes-alto-desempenho-p1>. Acesso em: 31 jan. 2016. BUKOWITZ, W.; WILLIAMS, R. The knowledge management fieldbook. London: Prentice Hall, 2000. p. 9. COHEN, D. et al. Agile software development. 2003. Disponível em <https://www.researchgate.net/publication/245234822_Agile_Software_Development_A_DACS_State-of-the-Art_Report>. Acesso em: 02 jan. 2016. CRUZ, Tadeu. Sistemas, organização & métodos: estudo integrado das novas tecnologias da informação. 3. ed. São Paulo: Atlas, 2002. DALKIR, Kimiz. Knowledge management in theory and practice. Boston: Elsevier, 2005. DAVENPORT, Thomas H.; PRUSAK, Laurence. O que queremos dizer com conhecimento? In: _____. Conhecimento empresarial: como as organizações gerenciam o seu capital intelectual. 4. ed. Tradução de Lenke Peres. Rio de Janeiro: Campus, 1998. cap. 1, p. 6-14. DESENVOLVIMENTO ÁGIL: SCRUM. Disponível em: <http://www.desenvolvimentoagil.com.br/scrum/>. Acesso em: 08 jan. 2016. FIALHO, Francisco Antônio P. et al. Gestão do conhecimento e aprendizagem: as estratégias competitivas da sociedade pós-industrial. Florianópolis: Visual Books, 2006. FIORELLI, J. O. Psicologia para administradores. São Paulo: Atlas, 2000.

49

GATTONI, R. L. C. A atuação do gerente de projetos na era do conhecimento. Disponível em: <http://portal.crie.coppe.ufrj.br/portal/main.asp?View=%7B30577D41-37BF-4904-90FF-7EB642DD9004%7D >. Acesso em: 03 fev. 2016. GIL, Antônio C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002. GUIMARÃES, M. V. A. F. Compartilhamento de informação e conhecimento em equipes de desenvolvimento de software. 2009. 153 f. Dissertação (Mestrado em Ciência da Informação) - Universidade de Brasília, Brasília, 2009. MAGNANI, Marcio; HEBERLÊ, Antônio. A era do conhecimento. In: ____ Introdução a gestão do conhecimento: organizações como sistemas sociais complexos. 1. ed. Pelotas: Embrapa, 2010. cap. 1. MARAKAS, George M. Decision support systems in the twenty-first century. Englood Cliffs: Prentice Hall, 1999. MENDES, Alexandre. Gestão do conhecimento: a espiral do conhecimento 2008. Disponível em: <http://imasters.com.br/artigo/10659/gerencia-de-ti/gestao-do-conhecimento-a-espiral-do-conhecimento/>. Acesso em: 26 dez. 2015. NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criação de conhecimento na empresa: como as empresas japonesas geram a dinâmica da inovação. 4. ed. Rio de Janeiro: Campus, 1997. NEPOMUCENO, Dênys. Modelos incremental, espiral e de prototipação. 2012. Disponível em: <http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html>. Acesso em: 06 fev. 2016. PRESSMAN, R.S. Engenharia de software: uma abordagem profissional. 7. ed. São Paulo: MCGraw-Hill, 2011. PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software. Porto Alegre: Bookman, 2014. PRODANOV, Cleber C.; FREITAS, Ernani C. Metodologia do trabalho científico: métodos e técnicas da pesquisa e do trabalho acadêmico. 2. ed. Novo Hamburgo: Feevale, 2013.

50

RIBEIRO, Antônio M. Conhecimento: dos dados ao saber 2007. Disponível em: <http://peabirus.com.br/redes/form/post?topico_id=6336>. Acesso em: 24 dez. 2015. RORIZ, Maysa; RORIZ FILHO, Heitor. A gestão do conhecimento e a gestão ágil de projetos. 2011. Disponível em: <http://www.sbgc.org.br/sbgc/blog/gestao-do-conhecimento-e-gestao-agil-projetos>. Acesso em: 31 dez. 2015. SCHWABER, K.; SUTHERLAND, J. Guia do Scrum: 2013. Tradução de Fábio Cruz, Caio Cestari Silva, Eduardo Rodrigues Sucena, Daniel Racowsky. 2014. 19 p. SETZER, Valdemar W. Dado, informação, conhecimento e competência. DataGramaZero. Revista de Ciência da Informação, n. zero, dez. 1999. SEVERINO, Antônio J. Metodologia do trabalho científico. 23. ed. São Paulo: Cortez, 2007. SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011. TAKEUCHI, Hirotaka; NONAKA, Ikujiro. Criação e dialética do conhecimento. In: ____ Gestão do Conhecimento. Tradução de Ana Thorell. Porto Alegre: Bookman, 2008. cap. 1, p. 19-24. TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The New New Product Development Game. 1986. Disponível em: <https://hbr.org/1986/01/the-new-new-product-development-game>. Acesso em: 04 jan. 2016. TURBAN, Efraim; MCLEAN, Ephraim; WETHERBE, James. Tecnologia da informação para gestão: transformando os negócios na economia digital. 3. ed. Porto Alegre: Bookman, 2004.

GESTÃO DO CONHECIMENTO E SCRUM UMA ASSOCIAÇÃO …€¦ · GESTÃO DO CONHECIMENTO E SCRUM : UMA...

Documents

Transcript of GESTÃO DO CONHECIMENTO E SCRUM UMA ASSOCIAÇÃO …€¦ · GESTÃO DO CONHECIMENTO E SCRUM : UMA...