Знания о разрабатываемой системе
Это те знания, которые участники команды разделяют между собой. Сюда относятся как знания об архитектуре и исходном коде, так и то общее представление о разрабатываемой системе, из которого архитектура и код материализуются. Проектная документация – спецификации, руководства и пр. - лишь частичное, пусть и упорядоченное отражение этих знаний. В отличие от управляющей информации, такие знания более естественно распространяются в горизонтальной плоскости, от одного участника к другому. Так или иначе, стоит подумать о том, как сделать этот обмен эффективнее. Рассмотрим несколько возможных подходов.
- Узнавание по факту. Т.е. один сделал – все остальные видят, когда попадается на глаза. Такой подход говорит о том, что взаимодействия между участниками команды нет вообще. Наиболее вероятным следствием станет то, что разрабатываемое приложение будет состоять из разнородных частей, слабо сочетающихся друг с другом.
- Неформальная передача информации. Существенно отличается от предыдущего варианта тем, что здесь речь как раз идет о постоянной коммуникации внутри команды. В таких условиях знания передаются легко и быстро, а излишний формализм только препятствует этому процессу. Чтобы добиться такой коммуникации, недостаточно, однако, посадить всех членов команды в одну комнату, хотя это и совершенно необходимо. (Конечно, надо разделить технических и нетехнических специалистов).
- Ведение проектной документации. При всем желании, в документацию, в первую очередь, попадают самые важные и наиболее общие решения. Если документация достаточно детализирована, скорее всего, она будет неактуальной – на поддержание ее в актуальном состоянии требуется слишком много времени и сил. Это главная из причин, по которой многие не придают документации большого значения. Надо согласиться, полностью заменить непосредственное общение документация не сможет. В то же время, отдельные документы могут быть чрезвычайно полезны. Кстати, самые нужные и полезные документы часто возникают сами собой, когда люди записывают что-то «для себя», а потом оказывается, что это давно нужно всем.
Я бы предпочел создавать документы только по мере необходимости, всегда обсуждая этот вопрос с группой разработки. - Рассылка информации о принятых решениях по электронной почте. Один из наиболее частых вариантов, подходящий для информирования о более-менее крупных решениях. Присущи все недостатки коммуникации по электронной почте. Живого контакта в любом случае не заменяет, в то же время, рассылаемая таким образом информация чаще всего все равно попадает в документацию. В общем, рассылка - она рассылка и есть.
- Регулярные встречи. Первый вопрос – насколько регулярные. В команде, которая встречается раз в неделю, накапливается столько нерешенных частных вопросов, что удержаться в рамках регламента может быть очень сложно. Встречи с периодичностью раз в месяц, скорее всего, будут посвящены только самым общим организационным вопросам. Так или иначе, многие, особенно технические вопросы бывает гораздо удобнее обсудить «в процессе», чем на специально назначенном совещании. Почти все технические решения необходимо проверять на реализуемость и эффективность, их часто приходится корректировать и пересматривать много раз.
- Неформальная передача информации внутри команды и регулярные встречи представителей отдельных команд. Подход выглядит привлекательно в случае, если разрабатываемое приложение имеет компонентную архитектуру. Внутри команды знания распространяются благодаря ежедневным совместным обсуждениям и коллективному владению кодом, интерфейсы на компоненты разрабатываются и утверждаются на общих встречах представителей команд. Границы компонентов в этом случае могут определяться исходя из естественных ограничений на объем информации, которую каждая команда может охватить одновременно.
