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

• Название: Человеческий фактор в программировании
• Автор: Ларри Константин
• Жанр: Управление, подбор персонала

Хорошее программное обеспечение создается людьми. Так же как и плохое. Именно поэтому основная тема этой книги — не аппаратное и не программное обеспечение, а человеческий фактор в программировании (peopleware). Первое издание «Constantine on Peopleware» признано классическим трудом в области информационных технологий. Новая книга Ларри Константина включает все 52 легендарные статьи из предыдущей книги и 25 новых эссе.

Peopleware охватывает все аспекты, связанные с ролью людей в разработке программного обеспечения. Это качество и продуктивность, модели и методы, динамика поведения коллектива, руководство проектами, разработка интерфейсов и взаимодействие между человеком и компьютером, психология и процессы мышления. В данное издание включены два новых раздела, посвященных организационной культуре и юзабилити программных продуктов.

Название оригинала на английском языке: The Peopleware Papers by Larry L. Constantine

---

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

На случай каких-либо сомнений важно отметить, что я и сам являюсь одиночкой (по крайней мере, мне так говорили). На самом деле я был официально отнесен к типу одиночек Полом Вордом (Paul Ward) — методистом, ставшим историком, — в его истории структурного анализа (Ward, 1992 [64]). Он лично заверил меня, что это нужно воспринимать как комплимент. Конечно, большую часть моей профессиональной жизни я не был конформистом. Современная разработка программного обеспечения может охватывать многие основные принципы структурного проектирования. В качестве ортодоксальной технической иконографии могут применяться инструменты CASE, среды комплексной разработки, схемы потоков данных и блок-схемы, однако так было не всегда. В это трудно поверить, но все эти схемы когда-то считались отступлением от традиций и даже радикальным бредом индивидуалистов.

Я верю в индивидуалистов; многие из моих друзей — одиночки. И я верю в индивидуалистское воображение, в индивидуальное творчество как источник почти всех подлинных новшеств. Я также считаю, что индивидуализм — это истинная причина большинства глупых ошибок. На каждого

Эйнштейна находится целая толпа Великовских.[16] Иногда нововведения и идиотизм даже исходят из одного и того же источника, как от Теслы (Tesla) или Вильгельма Рейха (Wilhelm Reich)2. Так или иначе, индивидуалис-ты-одиночки обогатили нашу жизнь — если не всегда чем-то полезным, то хотя бы развлечениями.

Выть ковбоем — это не то же самое, что быть независимым или быть индивидуалистом. Это определение не связано с тем, использует или нет кто-либо какую-то конкретную методологию разработки программ, если вообще использует какую-то методологию. Ковбой — это некий тип мышления или стиль жизни. Программисты-ковбои — это всего лишь те оппозиционные разработчики, которые ненавидят ограничения в виде стандартов, условий или дисциплины. Это специалисты, которые сопротивляются всем попыткам руководить ими с помощью контроля или сотрудничества с другими и ставят свою уникальную оригинальность выше понятий юза-билити и надежности.

Естественно, не каждый программист, который предпочитает работать самостоятельно, является кодером-ковбоем. Некоторые люди являются одиночками по своему темпераменту. Некоторых, наверное, можно охарактеризовать как отшельников, другие всего лишь любят составлять компанию самим себе, а многим просто кажется, что компания других людей отвлекает их или даже подавляет. Некоторые из моих лучших работ были сделаны, когда в комнате находились только я и мой верный компьютер.

Как руководить индивидуалистами

Почему это важно — руководить индивидуалистами? Почему бы просто не дать им волю, чтобы они могли объединиться с такими же ковбоями в качестве программистов-контрактников и независимых консультантов? Во-первых, их довольно много. Во-вторых, многие их них являются неплохими профессионалами и потенциально могли бы стать еще большими доками, если бы их творческое упрямство можно было хотя бы немного умерить с помощью сотрудничества. Индивидуалисты и кодеры-ковбои способны внести существенный вклад в процесс разработки программного обеспечения. Хорошее руководство создает условия для того, чтобы принять и использовать этот вклад с пользой для организации и для самих ковбоев.

Некоторые руководители являются сторонниками либерального стиля управления кодерами-ковбоями. По их мнению, дисциплина или навязывание стандартов только удерживает программистов от полного раскрытия их потенциала блестящих кодеров-ковбоев.

Я думаю, что у руководителей есть варианты получше — по крайней мере, я надеюсь, что это так. Такой свободный подход, возможно, объясняет ненадежность и плохую работу продуктов, поставляемых многими крупными компаниями-разработчиками. Этот подход также проявляется в пользовательских интерфейсах большинства программ, которые страдают прогрессирующим функционизмом и начинены мешаниной из несогласованных между собой кнопок и переключателей, добавляемых чуть ли не каждым членом компании разработчиков.

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

Одиночки могут делать хорошую работу и могут делать плохую. Именно руководитель должен найти способ использования одиночек таким образом, чтобы они могли делать хорошую работу. Отчасти секрет заключается в том, как работа разбита и распределена между членами команды. Тем сотрудникам, которые лучше работают в уединении, следует поручать задачи, которые в той или иной мере могут быть автономными, то есть те части системы, которые можно определить как черные ящики с простыми интерфейсами и четкими внешними спецификациями. Таким разработчикам нужно давать задачи по созданию компонентов, которые не сильно связаны с другими частями системы и не требуют тесной координации или постоянного общения с другими разработчиками.

Другой частью секрета является тщательный контроль и наблюдение. Уменьшение взаимозависимости между индивидуалистами и остальной частью команды разработчиков не означает, что индивидуалистов нужно игнорировать. На самом деле, когда часть системы разрабатывается отдельно, еще более важно следить за остальными интерфейсами и взаимосвязями. Руководители часто понимают это, когда имеют дело со сторонними исполнителями или удаленными сотрудниками, работающими до-ма. Однако они склонны забывать эту истину, когда имеют дело с индивидуалистом, который сидит в соседней комнате.

Когда работа выполняется в открытых группах, повышенная видимость помогает сократить ошибки и повысить качество (см. главы 26 и 33). Поэтому работа, выполненная в некоторой степени изолированности от остальной группы, требует большего внимания к соответствию внешним спецификациям и более пристального наблюдения за качеством продукта. Если приемочные испытания показывают, что код работает, то этого недостаточно; для обеспечения качества следует также изучить его с точки зрения соответствия стандартам ясности и надежности.

Индивидуалисты и методы

Самостоятельная работа не подразумевает работу без дисциплины или без хорошей методологии, а работа в группе не гарантирует получение результата. Работа в группе гарантирует только то, что в нее будет вовлечено большее количество людей. Однако с точки зрения руководителя использование системной методологии в разработке приобретает большее значение, когда разработчики трудятся отдельно друг от друга. И здесь для обеспечения качества особенно полезны регрессивные испытания и критический разбор внедрения программы. Настоящее качество не может быть достигнуто после факта разработки — его нужно продумывать и встраивать в процесс с самого начала. Системные и формальные методы разработки программного обеспечения являются проверенными способами обеспечения качества. Работа даже самого независимого кодирующего ковбоя может быть улучшена и, конечно, может стать более надежной, если в процессе применяется системная методология.

Для того чтобы заставить кодирующих ковбоев применять системные методы разработки, руководству, возможно, придется искать компромисс в отношении того, какой именно метод будет выбран. Если независимые исполнители будут применять собственные уникальные методы, то это лучше, чем не использовать никаких.

Модели проектирования могут не только ускорить разработку и улучшить качество, но и способствовать трассируемости. Это достигается с помощью частичного протоколирования мыслительного процесса разработчика, то есть с помощью ведения журнала контроля, в котором отражаются источники проблем и их решения. Необходимость соответствующих проектных документов (таких как схемы потоков данных, блок-схемы, структурные схемы потоков и т. п.) должна быть отражена в спецификациях для подсистем, которые предполагается разрабатывать независимо.

Для руководителей проектов, стремящихся удержать в голове набор подходов к управлению программистами-одиночками, может быть полезной аналогия с выпасом скота. Старшим ковбоям приходилось перегонять стада на пастбища, следя за тем, чтобы животные не отбивались от стада, и периодически собирая их вместе. Они внимательно следили за своими работниками и скотом. Они также не забывали про то, чтобы ковбои могли выпустить пар в субботние вечера.