gestÃo do conhecimento e scrum uma … · processo de desenvolvimento monografia apresentada à...
TRANSCRIPT
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
Fonte: PRESSMAN, 2011, p. 63.
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
Fonte: PRIKLADNICKI; WILLI; MILANI, 2014, p. 4.
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
Fonte: PRIKLADNICKI; WILLI; MILANI, 2014, p. 25.
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
Fonte: PRESSMAN, 2011, p. 96.
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
Fonte: PRIKLADNICKI; WILLI; MILANI, 2014, p. 31.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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
Fonte: Do autor, 2016.
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.