Já várias vezes, comunicando-me com colegas em conferências e palestras, recebi esta pergunta:
Parece que é hora de fixar em algum lugar a resposta e consultar ocasionalmente :)
Então, é necessário o gerenciamento do conhecimento Agile, onde as informações são transferidas de pessoa para pessoa? De fato, esse é o caso quando a resposta está contida na própria pergunta. As informações são transmitidas de pessoa para pessoa, ou seja, há uma troca de conhecimentos . A tradição oral é uma das ferramentas da gestão do conhecimento. Muito pouco confiável, mas certamente o mais popular. A tarefa do responsável pela gestão do conhecimento é criar um ambiente conveniente para o compartilhamento de conhecimento. Obviamente, em equipes ágeis, o ambiente será diferente das estruturas organizacionais clássicas. Mas basicamente a resposta, é claro, é "sim, é necessário". Vamos entender com mais detalhes.
Vamos começar com o próprio manifesto Agile . Seus autores dizem diretamente que
"Ou seja, sem negar a importância do que está à direita, ainda valorizamos mais o que está à esquerda"
O Manifesto Ágil não nos diz para "documentar nada"! Ele diz que o cliente paga dinheiro por um produto em funcionamento. Se ele recebeu, na ausência de documentação bonita, ele pode fechar os olhos, mas não vice-versa. O manifesto ajuda a priorizar, mas não coloca proibições. E mesmo que você não tenha tempo para grandes docas, no processo de trabalho, um grande número de artefatos de gerenciamento de conhecimento é criado, no qual você pode operar ao tomar novas decisões: tickets, changelogs etc.
"Pessoas e interação são mais importantes que processos e ferramentas."
Em um estudo realizado entre trabalhadores de TI, fica claro que as
pessoas do setor de TI colocam o compartilhamento de conhecimento (ou seja, a
interação ) em segundo lugar entre os desafios existentes no desenvolvimento de software.
De um modo geral, os resultados deste estudo confirmam a primeira tese do manifesto. Parece-me que as pernas da questão estão crescendo a partir do fato de que a gestão do conhecimento por muitos em desenvolvimento é entendida como documentação, e não a interação entre as pessoas na transferência de experiência.
Sim, a propósito, em um dos posts anteriores eu já disse que conhecimento não é documentação, mas experiência adquirida na implementação de um projeto específico por um funcionário específico . Mesmo que você não tenha criado a documentação do produto, definitivamente ganhou alguma experiência durante o projeto. Além disso, as ferramentas Agile indiretamente contribuem para o fato de que essa experiência é constantemente vasculhada.
Por exemplo, retrospectivas . O que é isso, se não um processo de compartilhamento de conhecimento? A equipe reúne, compartilha os problemas existentes (no campo da GC isso é chamado de "lições aprendidas" ) e desenvolve um plano de mudança para resolver esses problemas. Ou seja, as pessoas vasculharam sua experiência umas com as outras, discutiram, desenvolveram uma estratégia para superar inconvenientes no futuro próximo e fixaram em algum lugar esse mesmo plano de mudanças (artefato de gerenciamento de conhecimento). Geralmente, os resultados dessas reuniões são armazenados em algum lugar. Não tenho certeza de que existem comandos eficazes que, após a conclusão da iteração, excluam dados sobre todos os retrocessos anteriores.
Ou emparelhe a programação . Até a Wikipedia nos diz sobre essa ferramenta o seguinte:
Vantagens:
***
Mentoring
Todo mundo, mesmo um programador iniciante, sabe algo que outros não sabem. A programação em pares é uma maneira indolor de espalhar esse conhecimento.
***
Treinamento
Os programadores trocam constantemente conhecimento.
Dois programadores experientes se misturam, usando sua própria experiência. O senhor bombeia a juna, atuando como mentor. A orientação de equipes geralmente é uma das encarnações mais populares do gerenciamento de conhecimento no desenvolvimento de software. O mesmo Yandex começou a ensinar essa arte externamente.
Ou leve a situação ao usar o kanban. Suponha que os testadores testem 10 funções por mês e os desenvolvedores consigam implementar 20. Isso leva ao acúmulo de trabalho no controle de qualidade e, portanto, a riscos na qualidade de seu trabalho. Nesse caso, você pode, por exemplo, redistribuir recursos e conectar desenvolvedores à criação de autotestes. Como resultado da iteração, a equipe recebeu uma experiência negativa de planejamento e, com base nela, pode elaborar um novo plano de forma a garantir o rendimento máximo do pipeline com os mesmos recursos. Ou seja, no processo de desenvolvimento, foi adquirido conhecimento (= experiência), após analisar quais, a equipe chegou à otimização do processo.
Bem, há uma pergunta muito superficial: a equipe não usará a experiência adquirida ao trabalhar no projeto quando estiver trabalhando em outros projetos? Ou seja, experimentalmente para o projeto atual, eles descobriram que podem implementar com testes uma média de 15 funções por mês. Eles não estarão no novo projeto inicialmente previsto para 20?
Conhecimento é tudo o que aconteceu em torno do projeto. O processo de desenvolvimento não ocorre no vácuo. Coordenação, links úteis, interação com outras equipes, integração de iniciantes, etc. Qualquer equipe passa por isso. Com um conjunto de experiências, vários artefatos aparecem, como listas de verificação de adaptação para iniciantes ou um banco de dados de links úteis. Isso é conhecimento fixo ou o resultado da compreensão da experiência adquirida.
Todos nós participamos de processos de compartilhamento de conhecimento todos os dias (bem, na verdade, nos comunicamos constantemente!), E o trabalho na metodologia Agile não nos exclui desse processo. Além disso, já inclui ferramentas de gerenciamento de conhecimento muito eficazes. Resta apenas organizar o trabalho da equipe para que essas ferramentas ofereçam o máximo de exaustão.
Em um post, dei apenas alguns exemplos. Vamos discutir nos comentários o que outras ferramentas Agile também são ferramentas de gerenciamento de conhecimento. Bem, ou discutir por que estou errado :)