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

Исправляйте процесс, а не только программу

В названии одной известной песни 60-х годов можно найти действенный принцип улучшения качества:

Пусть светит солнце

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

Опыт показывает, что качество программного обеспечения можно значительно улучшить, если просто увеличить объем работы, выполняемой лицом к лицу (глава 26). Когда двое или более людей вместе работают над одной задачей, качество повышается. Как правило, повышение видимости рабочего процесса повышает его качество. Почему? В принципе, для того чтобы два программиста, вместе создающие программу, внесли ошибку или отступили от стандартов и правил, они должны сговориться об этом. Однако заметить ошибку или отступление от правил может и один человек. Забудьте о том, что вы слышали про «групповое мышление» или коллективную посредственность. Все эти эффекты существуют, но они зависят от определенных условий. Групповые лидеры могут легко способствовать улучшению качества решения задач и избежанию недостатков группового мышления. Для этого лидерам любых групп достаточно просто воздерживаться от выражения своего собственного мнения или откладывать его на какое-то время (Anderson и Balzer, 1991 [2]).

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

Паролем нынешнего дня является «собственность» или «участие». Прогрессивные организации стремятся повысить значимость личного владения. Это своего рода эго-инвестиции служащих в продукты, создаваемые их усилиями. Например, открытая модель командной работы (см. главу 16) является подходом к организации проектных команд, в котором применяется решение задач на основе консенсуса. Такая модель повышает видимость рабочего процесса и увеличивает долю индивидуального участия каждого.

Видимость рабочего процесса тесно связана с идеей о разделении труда. Такое разделение присуще методу «динамический дуэт». Пока один программист сидит за клавиатурой, другой «смотрит через его плечо». Программист за клавиатурой имеет свой круг обязанностей, связанных с определением алгоритма и планированием кода. Другой программист следит за «дырами» в логике и пытается отследить ошибки и слабые места в коде.

* Применяйте разделение труда

Этот принцип является важнейшим компонентом метода «чистого» (clean room) программирования. С помощью этого подхода были созданы некоторые средние и крупные системы, которые практически не содержали ошибок (Cobb и Mills, 1990 [8]). В этой модели один человек или группа пишет код, стараясь «все сделать правильно». Еще кто-нибудь выполняет компиляцию и тестирование, стараясь обнаружить ошибки и погрешности. В этой модели есть и другие приемы, но даже простое разделение обязанностей само по себе может повысить качество. Знание того, что кто-то другой в команде не только просматривает код, но и занимается компиляцией и тестированием, повышает ответственность и побуждает принимать правильные решения с первого раза.

Десятилетия исследований и практический опыт показали нам, что по продуктивности лучшие программисты зачастую на порядок отличаются от худших и в два раза от средних программистов (DeMarco и Lister, 1987 [33]).

[3]Некоторые группы значительно повысили качество своей работы и продуктивность путем простого сокращения штата программистов, оставив только самых лучших. Один подход к повышению качества заключается в том, чтобы взять только самых лучших игроков, предоставить в их распоряжение все ресурсы, создать мотивацию для достижения наилуч-ших результатов в работе и позволить им ее сделать. Такой подход может быть особенно привлекательным в эпоху «сокращения расходов».

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

Пусть все друг друга учат

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

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

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