(организационные проблемы программирования)
выступление на краевом семинаре по
информационным системам
Проблемы организации программистских коллективов не случайно считаются сейчас одним из самых важных в технологии программирования. Это связано, во-первых, с тем, что большие размеры разрабатываемых систем требуют именно коллективного труда, а во-вторых, с тем, что, кроме собственно, разработки, нужно ещё организовывать размножение, внедрение, сопровождение и т.д. Особенно остро эти проблемы встали, когда потребовалось наладить промышленное производство программ, т.е. от технологий, ориентированных на индивидуальное программирование и носящих рекомендательный характер, перейти к жёстким автоматизированным технологиям, нацеленным на работу коллектива. В программировании ещё нет хорошей нормативно-справочной базы, не разработаны технологические стандарты /если не считать ГОСТ ЕСПД/, не решены многие вопросы распределения ролей в коллективе.
Одной из перспективных идей в области организации разработки программных систем является идея Х. Милза о "хирургической бригаде". Концепции "хирургической бригады" общеизвестны, я не буду на них останавливаться, но, видимо, представит интерес сообщение об эксперименте, проведённом с целью практической отработки этих идей. Эксперимент был проведён в Красноярском госуниверситете группой разработчиков системы ДЕЛЬТА в 1982-1983. Состав бригады был такой:
Остальные роли были совмещены - инструментальщиком был один из проблемных программистов, языковедом - хирург, административные вопросы и взаимодействие с заказчиком взял на себя руководитель работ. Поскольку разработка была не очень большой, секретари не потребовались.
Второй пилот наиболее активно использовался при проектировании. Ситуаций, когда он должен был заменять "хирурга", почти не было, поэтому на этапе отладки он работал как проблемный программист. Во время же проектирования основным его занятием было - подвергать критике решения "хирурга", испытывать прочность его концепций, выискивать несоответствия, промахи и т.д. Эта работа шла ежедневно - общались лишь хирург со вторым пилотом. В конце недели подготавливался текст коммюнике, в котором описывались принятые решения, спорные моменты и нерешённые и нерешённые проблемы. На еженедельном семинаре это коммюнике обсуждалось, делались замечания и предлагались способы преодоления возникших трудностей; но никакие решения не принимались - все решения принимал хирург после семинара. Правда, в тех случаях, когда требовалось знать мнение заказчика , окончательное решение принимал руководитель работ.
Проектная документация проходила тот же путь - писалась "хирургом", критиковалась вторым пилотом, обсуждалась на семинаре и, наконец, утверждалась руководителем работ.
Такая организация проектирования, действительно, оказалась весьма эффективной - ведь при коллективном проектировании трудно достигнуть концептуальной целостности, трудно избежать горячего обсуждения незначительных подробностей. С другой стороны, если человек проектирует систему в одиночку, ему трудно критически относиться к своим деяниям. Можно, в общем, сказать, сто мысль Брукса о том, что идеальное количество проектировщиков - два, полностью подтвердилась. Проектная документация за время программирования и отладки почти не изменилась - это говорит о том, что почти все ситуации были учтены и полнота документации была достигнута.
Очень полезной фигурой оказался тестировщик. По важности он, пожалуй, не уступает хирургу.
Во-первых, тестировщик лучше всех знает текущее состояние системы. В этом плане он хорошо дополняет хирурга: тестировщик знает систему "снаружи", а хирург - "изнутри". С вопросами о том, насколько отлажен модуль, обращались обычно к тестировщику, а не к автору модуля.
Во-вторых, тестировщик оказался полезным на стадии проектирования. Тесты начали готовиться ещё до кодирования, как только были готовы внешние спецификации, поэтому некоторые ляпы успели ликвидировать до того, как они воплотились в текст программы. Тестировщик - это, фактически, первый пользователь системы, единственный человек в коллективе, чья работа заключается не в создании, а в использовании. Бывает так, что система не имеет ошибок, соответствует проектной документации, но в работе неудобна, нетехнологична; обычно это обнаруживается после сдачи, тестировщик же обнаруживает эти неудобства и погрешности значительно раньше, и исправить их можно "по-семейному", среди своих.
В третьих, централизация тестирования повышает его качество. Есть известный психологический феномен: то, что человек сам создал, он с трудом разрушает, поэтому тестирующий собственные модули невольно выбирает "щадящие" тесты. Тестировщик же действует намного жёстче и объективнее. Вообще, у нас тестировщику с самого начала было предъявлено два условия: 1. Что он лично отвечает за каждую ошибку, найденную заказчиком, но не найденную им. 2. Что качество его работы будет оцениваться по количеству непрошедших тестов.
Что касается первого условия: действительно, заказчик, интенсивно используя систему, не нашёл в ней новых для нас ошибок - все они были обнаружены тестировщиком, но не все удалось вовремя исправить. Второе условие тоже существенно: на первых порах тестировщик огорчался, когда очередной тест не проходил (по своим старым программистким привычкам), и стоило больших трудов его убедить её что на самом деле это хорошо, что это показывает её хорошую работу.
В-четвёртых, централизация тестирования убрала рутину с программистов и исключила дублирования усилий. Тесты теперь хранятся в одном месте, один и тот же тест с различными вариациями может использоваться для различных случаев, а главное, работа с тестами ведётся специалистом именно в области тестирования.
Наш опыт показывает, что независимо от того, используется или нет "хирургическая бригада", выделение отдельного тестировщика очень полезно, а в условиях промышленного производства программ и необходимо, в сущности, это ОТК и даже нечто большее.
По Бруксу, всю документацию должен писать хирург, а редактор выполняет лишь техническую работу. Мы пробовали нагрузить редактора ещё и составлением инструкций пользователю, поскольку имелась довольно неплохая проектная документация, написанная хирургом. Эта попытка не удалась. Редактор вообще на всех этапах разработки оказывается пассивной фигурой. Он не имел ни хорошего понимания системы, как хирург, ни опыта работы с ней, как тестировщик, и поэтому система для него была довольно абстрактной и инструкции получились вялым приложением проектной документации, к тому же довольно далёкими от истинного состояния дел. По-видимому, редактору действительно нужно поручать только техническую работу, а документацию "на выход" должны писать совместно хирург и тестировщик Тогда она будет максимально адекватна продукту. Кроме того, тестировщик может дать ценные советы по технологии использования системы, а этот очень важный момент часто отсутствует в документации.
По-видимому, отдельный редактор нужен независимо от того, бригадой идёт работа или нет: тогда программисты освобождаются от рутинной работы при оформлении своих программ. Правда, тут есть одна психологическая тонкость - рутинность работы редактора отпугивает программистов, и назначение на эту должность воспринимается как наказание, как намёк на отсутствие в нём творческого начала, и это может привести к конфликтам. В какой-то степени это относится и к тестировщику. В нашей бригаде и редактор, и тестировщик продолжали работу над модулями, оставшимися им с предыдущей версии системы, можно сказать, для души.
Работа с проблемными программистами велась так: модули писались ими совместно с хирургом. Это оказалось полезным для обеих сторон - с хирурга была снята рутинная работа (перебеливание программ, перфорация, исправление синтаксических ошибок и мелких ошибок в программах), а начинающие программисты избежали многих ошибок, обычных в начале, и очень быстро овладели языком и приёмами программирования. Ошибки в программах искались, как правило, так: проблемный программист сначала сам пытался найти ошибку, если не мог, то с хирургом; в любом случае исправление согласовывалось с хирургом. Такой стиль работы оказался довольно эффектным.
В целом опыт работы бригадным методом оказался удачным - система была сдана в срок, психологический климат в коллективе был хорошим, концептуальное единство было достигнуто. Однако, как оказалось, производительность существенно не повысилась. Хирургом параллельно делалась ещё одна разработка, уже в одиночку. По классу системы были близки, использовались сходные концепции программирования и один и тот же язык. Разница была лишь в размерах - "одиночная" система была втрое меньше. Регистрировались затраты времени на ту и на другую системы. По окончании работ были подсчитаны длины программ (по методике Холстеда) и определена производительность труда. Для бригады она была 2.50 минуты на единицу текста, для одиночной работы - 3.40, т.е. бригадный метод повышает производительность труда главного программиста всего в полтора раза, но нужно ещё учесть, что на него работала бригада! Возможно, выигрыш от "хирургической бригады" не столько в повышении производительности труда, сколько в повышении качества продукта, за счёт концептуальной целостности, например.
Затраты времени "хирурга" при переходе от одиночной к бригадной работе не столько уменьшились, сколько перераспределились: время, которое при одиночной работе уходит на программирование и отладку, при бригадном уходит на коммуникации. Время на проектирование и на документацию почти не меняется. Дополнительный штрих: "хирург" должен быть не просто хорошим специалистом, но и коммуникабельным человеком - столь резкое повышение объёма общения может переноситься очень тяжело.
Следует отметить, что работа бригадой существенно увеличивает отторжимость программ: каждую программу знают как минимум два человека, и мы этим пользовались - например, хирург продолжал отладку, пока проблемные программисты были в отпуске. В целом опыт работы хирургической бригадой оказался очень полезным. Особенно следует выделить роль второго пилота при проектировании и роль тестирование во всём процессе разработки.
© Алексей Бабий 1984