Дружат ли Agile и Knowledge Management?
Уже несколько раз, общаясь с коллегами на конференциях и лекциях, я получал вот этот вопрос:
Кажется, пора зафиксировать где-то ответ на него и ссылаться при случае:)
Итак, нужно ли управление знаниями при Agile, где информация передаётся от человека к человеку? На самом деле, это тот случай, когда ответ содержится в самом вопросе. Информация передается от человека к человеку, то есть, происходит обмен знаниями. Устная традиция — это один из инструментов управления знаниями. Очень ненадежный, но, безусловно, самый популярный. Задача человека, отвечающего за управление знаниями — создать удобную для обмена знаниями среду. Само собой, в agile-командах среда будет отличаться от классических оргструктур. Но принципиально ответ, разумеется, «да, нужно». Давайте разбираться подробнее.
Начнем с самого манифеста Agile. Его авторы прямо говорят, что
«То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева»
Agile-манифест не говорит нам «ничего не документируйте»! Он говорит, что заказчик платит деньги за работающий продукт. Если он его получил, то на отсутствие красивой документации он может закрыть глаза, но не наоборот. Манифест помогает выстроить приоритеты, но не ставит запретов. И даже если на большие доки времени не находится, в процессе работы создается огромное количество артефактов управления знаниями, которыми потом можно оперировать при принятии новых решений: тикеты, чейнж-логи и т.д.
«Люди и взаимодействие важнее процессов и инструментов».
В одном из исследований, проведенных среди работников ИТ-сферы, четко видно, что люди в ИТ-индустрии ставят обмен знаниями (то есть взаимодействие) на второе место среди существующих в сфере разработки ПО вызовов. 
По большому счету, результаты этого исследования подтверждают первый тезис манифеста. Мне кажется, что ноги у вопроса растут из того, что под управлением знаниями многими в разработке понимается документирование, а не взаимодействие между людьми по передаче опыта.
Да, кстати, в одном из прошлых постов я уже говорил, что знания — это не документация, а опыт, полученный при выполнении конкретного проекта конкретным сотрудником. Если даже вы не создали документацию к продукту, то определенный опыт во время выполнения проекта вы точно получили. Более того, инструменты Agile опосредованно способствуют тому, чтобы этот опыт постоянно шарился.
Например, ретроспективы. Что это, если не процесс обмена знаниями? Команда собирается, делится имеющимися проблемами (в сфере УЗ это называется «извлеченные уроки») и вырабатывает план изменений с целью решить эти проблемы. То есть, люди пошарили свой опыт друг с другом, обсудили его, выработали стратегию по преодолению неудобств на ближайший период и зафиксировали где-то этот самый план изменений (артефакт управления знаниями). Обычно результаты таких встреч где-то сохраняются. Не уверен, что есть эффективные команды, которые после завершения итерации удаляют данные обо всех прошлых ретро.
Или парное программирование. Даже Википедия говорит нам насчет этого инструмента следующее:
Преимущества:
***
Наставничество
Каждый, даже начинающий программист, знает что-то, чего не знают другие. Парное программирование — безболезненный способ распространить эти знания.
***
Обучение
Программисты постоянно обмениваются знаниями.
Два опытных программиста прокачивают друг друга, пользуясь собственным опытом. Сеньор прокачивает джуна, выполняя функцию наставника. Наставничество в команде — это вообще одно из самых популярных воплощений управления знаниями в сфере разработки ПО. Тот же Яндекс даже наружу начал обучать этому искусству.
Или возьмем ситуацию при использовании канбана. Предположим, тестировщики проверяют 10 функций в месяц, а разработчики успевают реализовать 20. Это приводит к накоплению работы у QA, а значит, рискам качества их работы. В таком случае можно, например, перераспределить ресурсы и подключить разработчиков к созданию автотестов. По итогам итерации команда получила негативный опыт по планированию и, основываясь на нем, может составить новый план таким образом, чтобы обеспечить максимальную пропускную способность конвейера при тех же ресурсах. То есть, в процессе разработки были получены знания (=опыт), проанализировав которые, команда пришла к оптимизации процесса.
Ну и совсем уж на поверхности вопрос:, а команда не будет использовать полученный за время работы над проектом опыт при работе над другими проектами? То есть, экспериментальным путем за текущий проект они выяснили, что могут реализовывать с тестами в среднем 15 функций за месяц. Не будут же они в новом проекте снова изначально закладываться на 20?
Знания — это все, что происходило вокруг проекта. Процесс разработки проходит не в вакууме. Согласования, полезные ссылки, взаимодействие с другими командами, онбординг новичков и т.д. Любая команда через это проходит. С набором опыта появляются различные артефакты, вроде адаптационных чек-листов для новичков или базы полезных ссылок. Это зафиксированные знания или результат осмысления полученного опыта.
Мы все каждый день участвуем в процессах обмена знаниями (ну правда, мы же постоянно друг с другом общаемся!), и работа по методологии Agile не исключает нас из этого процесса. Более того, она уже включает в себя очень действенные инструменты управления знаниями. Остается только организовать работу команды так, чтобы эти инструменты давали максимальный выхлоп.
В посте я привел всего лишь несколько примеров. Давайте в комментариях обсудим, какие еще инструменты Agile в то же время являются и инструментами управления знаниями. Ну или обсудим, почему я не прав :)
