Человеческий фактор в программировании - Ларри Константин

Хорошая групповая память должна вмещать много информации. Одна часть этой памяти является непостоянной или временной памятью, другая часть — постоянной. Часть групповой памяти является активной и может оперативно использоваться в обсуждениях и решении повседневных задач. К другой части памяти команда обращается реже. Для удобства функции управления информацией можно разделить на функции сессионной памяти и функции проектной памяти. Сессионная память состоит из записей, созданных и задействованных во время групповых сессий, когда участники команды встречаются и вырабатывают групповые решения. В проектной памяти хранятся постоянные записи и документация, написанная и применяемая группой. Она включает в себя рабочий продукт, под которым понимается не только код, но и все проектные и анали-тЕческие модели и документы, созданные при написании кода. Кроме того, в проектной памяти хранятся входные данные, такие как требования, спецификации и другие основополагающие документы. Для управления проектной памятью нужен библиотекарь, и часто эта роль известна именно под этим названием.

Модульная память

Важнейшая функция сессионной памяти — хранение отчета о процессах, который отражает проведенные обсуждения и решения, принятые в группе (Дойл (Doyle) и Страус (Strauss), 1982 [35]). Наверное, идея о ведении записей в ходе процесса нова для большинства групп, разрабатывающих программное обеспечение, однако на различных собраниях это практиковалось десятилетиями. Ведя записи, начинающие писари часто допускают одну из двух ошибок. Они либо пытаются записывать все подряд, словно под диктовку, либо ждут, пока группа не придет к какому-то заключению, и просто записывают итог. Для технической работы, выполняемой командой, записи вида «он(а) сказа л (а)» не особенно подходят и не являются необходимыми. В хорошем протоколе отмечены ключевые события на пути к конечному результату, особенно рассмотренные альтернативы, принятые решения и представленные аргументы. Такие записи вносят наибольший вклад в групповое приобретение опыта. Они могут стать бесценными, когда необходимо оценить проект или когда проект вступает в фазу «post mortem».[4]

Для разработки программного обеспечения сплошной неструктурированный протокол не подходит. Некоторые виды данных так часто анализируются в ходе сессий, что требуют ведения отдельных записей для последующего особого рассмотрения. Полезно также вести записи под заголовком «нужно сделать», где отмечать те идеи, которые возникают в обсуждениях, но сразу не воплощаются. Уже одно это может оправдать утомительное ведение сессионных записей, поскольку позволяет избежать нелепых оплошностей, обычно выявляемых во время системной интеграции или уже после отправки продукта заказчикам: «О, да мы совсем забыли о проблеме с висячим указателем!»

Хорошая сессионная память также включает отложенные решения, которые лучше всего хранить отдельно от уймы записей в списке «нужно сделать». Наличие специального места для отложенных решений может также ускорить их принятие. Вместо того чтобы тратить время на бесконечные споры, вызванные недостаточным пониманием или отсутствием данных, группа может занести этот вопрос в список отложенных реше-ний. Зачастую к тому времени, когда группа возвращается к этому вопросу, уже многое известно для принятия быстрого решения. Третий специальный раздел записей, который тоже полезен команде разработчиков, — это раздел «запасных частей». Сюда можно временно откладывать фрагменты хороших технических идей или частичные решения, чтобы не нарушать основной ход обсуждения. «Мусорная корзина» играет противоположную роль. Здесь можно отмечать все неиспользованные идеи и пути наряду с вескими причинами для их отклонения.

Все четыре специальных списка («нужно сделать», «отложенные решения», «запасные части» и «мусорная корзина») служат для записи того, что могло быть потеряно или забыто. Помимо всего прочего, такие записи помогают группе эффективно использовать время. Отмечая в одном из специальных списков факты отхода от основной темы, группа не теряет главной нити своего обсуждения и не упускает полезную информацию. Все это также может помочь группе избежать никчемных споров. Для того чтобы не пробуксовывать, тот или иной вопрос можно поместить в одну из «корзин» для более позднего рассмотрения. Кроме того, сами корзины служат в качестве механизмов обеспечения качества (QA, quality assurance). В конце проекта все содержимое корзин должно быть уничтожено или каким-то образом учтено.

Как же определить того счастливчика, который станет выполнять роль писаря? Согласно некоторым методикам, таким как «Joint Application Design» (Совместная разработка приложений) Вуда (Wood) и Силвера (Silver), 1989 [69], специально подготовленные помощники и писари привлекаются со стороны. Это позволяет разгрузить участников проекта для того, чтобы они смогли сосредоточиться на создании программного обеспечения. В некоторых группах эти обязанности вменяются одному из членов команды (обычно младшему сотруднику или стажеру). Для большинства команд, разрабатывающих программное обеспечение, более эффективным является совмещение этих подходов. Информацией заведует вся команда в целом, а реальная ответственность может по очереди возлагаться на всех участников проектной команды. При таком подходе никто не освобождается от обязанности играть роль писаря, однако никто не играет ее слишком долго. В течение одного собрания обязанности сессионного протоколиста могут переходить от одного человека к другому или же такая работа может оставаться в одних умелых руках в течение всей сессии. Однако для сохранения рассудка и поддержания хорошей рабочей атмосферы обязанности писаря, возможно, должны передаваться по крайней мере на каждом новом собрании. Если собрания проходят довольно долго, то такая смена должна происходить не менее одного раза в час. Дело в том, что для хорошего выполнения обязанностей писаря требуется чрезвычайная концентрация внимания, и очень мало людей планете действительно получает удовольствие от этой роли.

Заботы об архивах, автономной или проектной памяти могут переклад ваться реже. Если передавать «эстафетную палочку» каждый день, а приведет лишь к беспорядку и неисполнительности. В течение годичнс проекта обязанности, закрепленные за должностью так называемого «ь неджера проектной информации», или «проектного писаря», могут не] даваться из одних рук в другие не более одного-двух раз.

Так что, пригласите писаря на ланч. Возможно, на следующей неделе г сарем станете вы.