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

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

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

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

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

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

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

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

Из журнала Computer Language Magazine, том 9, № 6, июнь 1992 г.

Ваш коллега в офисе жует жевательную резинку, проигрывает на персональном компьютере «Where-in-the-World-is-Carmen-San-Diego?», охает и задает глупые вопросы. А в это время вы пытаетесь разобраться с ка-ким-то непонятным багом. В этой компании вы работаете несколько лет и чувствуете, что пришла пора получить отдельный кабинет. Вы идете к начальнику и говорите, что вам нужно большее пространство и защита от отвлекающего шума и помех. Вы говорите, что это повысит эффективность работы. Дескать, если у вас появится больше пространства и вас будут меньше отвлекать, вы станете работать более продуктивно. Вы ссылаетесь на научные исследования, подтверждающие это. Вы считаете, что вам нужн, по крайней мере сто квадратных футов выделенного пространства и тридцать квадратных футов для рабочего стола. Окно вам тоже не помешает. В Дании даже есть закон, по которому вы должны сообщить об этом начальнику. В Дании начальник обязан предоставить вам окно.

Народная мудрость гласит, что чем больше свободного пространства, чем тише в офисе, чем меньше помех, тем выше продуктивность и меньше ошибок в программном обеспечении. Сто квадратных футов свободного пространства и тридцать квадратных футов рабочего места просят программисты во всем мире. Эти представления вошли в отраслевой фольклор благодаря Тому ДеМарко (Tom DeMarco), Тиму Листеру (Tim Lister) и их классическому произведению «Peopleware: Productive Projects and Teams», 1987 [ЗЗ]. Исследовав несколько источников (главным образом их собственный ежегодник о «военных играх по кодированию»), они пришли к следующему выводу: программисты, работающие в отдельной комнате и имеющие больше места для раскладывания своих диаграмм и распечаток, обладают большей производительностью.