Инженерная модель программирования не оправдывает себя
Модель кооперативной игры
Изобретательность
Реквизит и маркеры для игр
Вместо заключения
Библиография
|
Введение (от переводчиков)
Инженерная модель программирования не оправдывает себя Модель кооперативной игры Изобретательность Реквизит и маркеры для игр Вместо заключения Библиография |
|
Программная инженерия (software engineering) представляет
собой неверную метафору для большинства проектов по
разработке ПО. Используя техническую метафору, мы забываем об
истинной природе программирования – деятельности социальной
и интеллектуальной, но никак не технической.
Неудивительно, что проблема «мифического человеко-месяца» жива до сих пор,
ведь рассуждая о разработке ПО, мы продолжаем рассматривать
людей как «заменимые компоненты для программирования» и
нанимать «группу Java-программистов».
Питер МакБрин, автор книги
«Sofware Craftsmanship»
| ПРИМЕЧАНИЕ Перевод и цитирование дается по следующим работам: «Software Development as a Cooperative Game», «The Cooperative Game Manifesto for Software Development», «The End of Software Engineering and the Start of Economic-Cooperative Gaming» с ведома и разрешения автора (Alistair Cockburn, Humans and Technology, arc@acm.org). |
Что же такое разработка программного обеспечения? Что включает в себя это понятие, и к какому виду деятельности его можно отнести? Каким правилам нужно следовать, чтобы проект окончился успешно? Почему при равных стартовых условиях проект А с треском проваливается, а проект Б приносит деньги и славу своим разработчикам? Каждый, кто работает в нашей области и занимается управлением и постановкой процесса, рано или поздно начинает задавать себе эти вопросы.
Ответов на них нет. Вернее, их множество, что, по сути, то же самое. И единственно возможным вариантом становится сочетание собственного опыта и учебы на чужих открытиях и ошибках.
Алистэр Коуберн (Alistair Cockburn) – один из немногих методологов, которые все свои изыскания подкрепляют многолетним опытом работы среди программистов. Его статьи и книги – не академические изыскания, это летопись успешных и неудачных проектов, бесценный опыт, которым он щедро делится, не скрывая своих прошлых ошибок и заблуждений.
«Разработку программного обеспечения в наши дни можно сравнить с созданием самурайских мечей, щитов, тактики и стратегии ведения боя. Вы создаете несколько мечей и отправляете их в сражение. У вас просто нет другого способа узнать, какой из мечей покажет себя наилучшим образом. Затем вы анализируете полученный опыт, создаете следующую партию мечей, и так далее. Невозможно определить, какой из мечей окажется лучше другого, сидя дома. Вам необходимо увидеть эти мечи в деле – в битве. Не могу себе представить, как бы я мог узнать то, что знаю сейчас, просто размышляя в кресле у себя в офисе. Более того, то, что я придумывал и предсказывал таким образом, оказалось полной ерундой. Поэтому, если вас интересуют подобные вопросы, вам придется поработать программистом или консультантом. Только так вы сможете непосредственно наблюдать за процессом и собирать исходные данные для своих теорий».
| ПРИМЕЧАНИЕ |
Основные положения, которые Алистэр защищает в каждой своей работе, касаются человекоцентричности процесса разработки ПО. Главное в любом проекте – люди, они решают все. Именно они могут вытащить проект из глубокого кризиса, но, с другой стороны, именно они создают проблемы с дисциплиной, не выполняют правила и предписания. Следовательно, заключает Коуберн, надо определить, какой подход будет лучше всего использовать сильные стороны человеческого характера, подавляя и регулируя слабые.
За последние семь лет Алистэр написал несколько статей и книг на эту тему. Некоторые из них вошли в уже классический набор трудов по так называемым «гибким методологиям».
| ПРИМЕЧАНИЕ Книга «Agile Software Development» (на русском языке издана издательством «Лори», «Быстрая разработка программного обеспечения», 2002 г), статьи “People as nonlinear…”, «Methy per project», «Pair programming», “Just in time methodology construction”, etc (переводы всех четырех статей есть на сайте http://www.maxkir.com). |
Одна из его излюбленных тем, которую он поднимает во многих своих работах – модель разработки ПО как коллективной игры, направленной на достижение определенного результата (создание программного обеспечения) при неких заданных условиях (ограниченность в человеческих, временных и финансовых ресурсах). Эта модель позволяет по-новому посмотреть на отрасль, работая в которой мы привыкли оперировать исключительно техническими и инженерными метафорами. Проблемы успешности и неудач проекта приобретают другую окраску, позволяют находить нестандартные выходы из сложных ситуаций.
Но обратимся к работам Алистэра на эту тему.
| ПРИМЕЧАНИЕ Поскольку материалов довольно много, мы решили разделить статью на две части. В первой части мы приведем высказывания Алистэра Коуберна о том, что такое модель кооперативной игры, из каких компонентов она состоит, и какое место занимает разработка программного обеспечения среди других коллективных игр. Во второй части мы остановимся на вопросах применения этой модели в действии на примере реальных проектов и ситуаций. |
Разработка программного обеспечения не всегда относилась к инженерным наукам. Таковой ее предложили считать в 1968 году, чтобы спровоцировать людей к участию в работе новой отрасли [Naur-Randell]. Провокация оказалась очень удачной. К сожалению, этого нельзя сказать о полезности такой модели для тех, кто в ней работает. Даже после 35-летнего опыта использования инженерной модели процент успешных проектов в сфере производства ПО продолжает оставаться низким [Standish]. Мы не можем определить взаимосвязь между успехом проекта и "чистотой" процесса его разработки [Cockburn 2003a]. Наконец, мы видим, что эта модель не помогает профессионалам решать практические вопросы, находить выход из сложных ситуаций в реальных проектах.
Некоторые могут возразить, что "инженерная" модель не работает, потому что мы недостаточно хорошо ей следуем. Однако во время "разбора полетов" нередко выясняется, что проекты, в которых разработчики не следовали никакому четкому процессу, оканчивались успешно, в то время как строгие процессы далеко не всегда приводили проект к благополучному завершению. Конечно, можно привести и обратные примеры, но это нисколько не проясняет ситуацию. Скорее, наоборот – так еще труднее догадаться, что же является залогом успеха проекта. Впрочем, что бы это ни было, оно не имеет ни малейшего отношения к "чистоте" используемого процесса или усердности следования "инженерной" модели. [Cockburn 2000a, 2003a].
Инженерная модель программирования не проходит один жизненно важный тест, а именно, не предлагает правильных решений в сложных ситуациях. Если мы посоветуем руководителю проекта или программисту "делать больше программного инжиниринга", смогут ли они хотя бы
Когда я задаю вопрос "Как вы понимаете слова: вам нужно больше заниматься программным инжинирингом?", люди смотрят на меня с недоумением. Если же дело все-таки доходит до ответа, то обычно говорят о более тщательном моделировании системы с целью создания изначально правильной архитектуры; более точных оценках времени и затрат; и вообще, о создании программного обеспечения наподобие производства продуктов массового потребления. Как мы увидим далее, все это не относится к инжинирингу, и что хуже, не является залогом успешности проекта по разработке ПО.
Таким образом, нашей отрасли надо найти другую модель, которая могла бы:
Хотя словари определяют игру как «развлечение», значение этого термина за последнее столетие существенно изменилось. Многим руководителям претит сама идея того, что производство программного обеспечения можно считать игрой: «Мы здесь серьезными вещами занимаемся», – недовольно рявкнул на меня один из них. Естественно, руководителям не хочется, чтобы люди проводили рабочее время в развлечениях. Причина проста – производство программного обеспечения является, с экономической точки зрения, игрой, крайне ограниченной в ресурсах (ниже мы рассмотрим это подробнее). Да, термин «игра» довольно часто подразумевает некий элемент развлечения, и, по-моему, это прекрасно, когда люди рассматривают работу над проектом как развлечение (это называется «командным» или «рабочим духом»). Однако сейчас термин «игра» все чаще лишается своей легкой, фривольной и непродуктивной составляющей.
В современной науке в категорию игр попадает такое количество разнообразных видов деятельности, что иногда трудно найти в них что-то общее. Витгенштейн [Wittgenstein, 1953] считает, что обязательным условием игры является следование правилам. Как только участники игры перестают следовать ее правилам, игра прекращается (таким образом, игрой можно назвать только добровольную деятельность, при условии, что у участников всегда есть возможность прекратить ее и действовать другим образом). Любая игра состоит из «движений» по направлению к или от цели и некоего учета расстояния между целью и игроком.
Некоторые игры рассчитаны на одного участника, в другие играют целые группы людей. Одни игры направлены на достижение цели, другие – на взаимодействие участников. При этом продолжительность игр может варьироваться от нескольких минут или даже секунд, до лет или всей жизни игрока. Определяя место производства программного обеспечения среди прочих игр, я руководствуюсь тремя основными характеристиками:
Цель бесконечной игры – в ее продолжении [Carse]. Люди, организации и целые государства играют в бесконечную игру под названием «выживание». Некоторые люди играют в игру, которая называется «Сделай карьеру» (можно, например, повышать свою рыночную стоимость за счет проекта) и т.д. Легко догадаться, что отдельные бесконечные игры могут мешать оптимальному ходу большого проекта, поэтому борьба с такими помехами обычно является частью стратегии руководства.
Среди конечных игр можно выделить те, которые заканчиваются по достижении заранее поставленной цели; другие заканчиваются в любой момент, когда того захотят участники. В обеих этих категориях есть игры-соревнования и кооперативные игры, основанные на взаимодействии и взаимопомощи участников. Теннис и шахматы, например, носят явный дух соперничества и заканчиваются после достижения цели. «Король горы», игра, в которую любят играть дети, (один игрок защищает вершину холма от других ребят, которые должны его оттуда столкнуть) тоже строится на соперничестве, однако заканчивается только тогда, когда совсем стемнеет, или когда участников позовут домой: место первого короля занимает следующий, потом следующий и так до бесконечности. Покер – еще один пример игры такого же рода. А вот джаз или танцы можно отнести к открытым кооперативным играм. В обоих случаях участники игры концентрируют свое внимание на качестве взаимодействия и выступлении всей группы, причем продолжается такая игра столько, сколько захотят в нее играть сами участники.
Итак, у нас осталась еще одна категория: кооперативные игры, которые заканчиваются после достижения определенной цели. Сюда можно отнести альпинизм и скалолазание, любые исследовательские экспедиции и, наконец, разработку программного обеспечения. Окончательная цель для группы альпинистов – покорить вершину. Именно это будет мерилом успеха экспедиции. Однако после возвращения альпинистов будут спрашивать, насколько хорошо прошло восхождение, были ли интересные переходы, опасные ситуации и т.д. Тем не менее, сначала группа должна завершить восхождение.
Неправда ли, в этом есть что-то от разработки ПО? Главная и основная цель – поставить заказчику работающую систему. Именно так будет оцениваться успех или неуспех проекта. Уже впоследствии люди будут спрашивать, насколько интересным был этот проект, хорошо ли им руководили, красивой ли получилась программа, и легко ли будет поддерживать ее в будущем. Если команда разработчиков не поставит заказчику никакой программы, все сочтут, что проект окончился неудачей. Иногда есть возможность выйти из игры, когда становится понятно, что цель того не стоит, и этой возможностью не стоит пренебрегать. Обратите внимание: это справедливо и для альпинизма, и для разработки ПО.
Правда, между альпинизмом и разработкой программного обеспечения есть одна существенная разница: разработка ПО продолжается от одного проекта к другому, в то время как альпинисты совершают всего одно восхождение. Закончив создание одной программы, разработчики тут же начинают работать над следующей ее версией, над другой программой, которая продолжает или дополняет первую, и т.д.
Таким образом, в отличие от альпинистов, программисты ставят перед собой две цели:
Оценка завершившегося проекта тоже производится двояко: во-первых, оценивается, была ли вообще поставлена программа и, во-вторых, насколько выгодную позицию занимает теперь команда для начала следующей игры.
Обе эти цели конкурируют между собой и претендуют на ограниченные ресурсы команды. Разработчики могут поставить заказчику продукт гораздо быстрее, если в будущем этот продукт не надо будет изменять и дополнять. (А насколько быстрее это можно было бы сделать, если не заниматься исправлением ошибок в программе!) С другой стороны, разработчики могут потратить время на создание более продуманной архитектуры приложения, написание документации и передачу системы команде преемников – но все это отложит срок поставки готовой системы (а иногда может и вообще помешать успешному завершению проекта).
При всем этом команда ограничена во временных, финансовых и человеческих ресурсах – их просто не хватит на то, чтобы идеальным образом справиться с обеими задачами. Большинство разработчиков остаются довольны тем, что сумели достичь первой цели и сделать хоть что-то для достижения второй. Даже те компании, которые обладают достаточным количеством ресурсов, едва ли могут позволить себе уделять второй цели большое внимание, так как она воистину безгранична. В целом же, лучшим из реалистичных вариантов будет поставить заказчику систему приемлемого качества в оговоренное время и сделать хоть какие-то приготовления к следующим играм.
Чтобы нагляднее показать, насколько меняется стратегия, когда мы имеем дело с последовательностью из нескольких игр, возьмем другой пример кооперативной игры. Представьте себе гонку через болотистую местность, цель которой – создать некий артефакт (возможно, вначале участники даже не знают, какой именно) в каком-то определенном месте. Команда, участвующая в соревновании, наверняка подберет себе разведчиков и других специалистов, которые будут создавать карты, прокладывать маршрут, возводить мосты через топкие места и т.п. При этом наша команда не будет стараться, чтобы ее карты, тропки и мосты были сделаны на высоком коммерческом уровне. В противном случае, они израсходуют на это все имеющиеся в наличии ресурсы. Вместо этого они будут определять, какой ширины дорогу надо расчистить для них самих, насколько крепок должен быть мост, какие именно вешки оставлять на болоте, и т.д.: все с одной целью – как можно быстрее выполнить поставленную задачу.
Если такое соревнование проходит в несколько приемов, то в конце первой игры (когда они найдут или создадут требуемый артефакт) появится команда-преемник, которая должна будет перенести полученный артефакт на новое место. В этом случае, первая команда должна будет тратить некоторое время на улучшение качества дорог, мостов и карт, потому что ими будет пользоваться следующая команда. При этом все будут помнить, что эта работа отодвигает завершение их основной задачи. Первая команда может также оставить нескольких человек, которые хорошо знают пройденную территорию, чтобы они вошли во вторую команду и помогли им быстрее справиться с их задачей. Как видите, стратегия единичной игры и последовательности игр могут довольно существенно отличаться друг от друга.
Проекты с открытым исходным кодом – тоже игры, но немного другого рода. Во-первых, в них нет ограничений по ресурсам, а во-вторых, конечной точки. Линус Торвальдс не может сказать: «Сейчас вот выпустим приличную версию Линукса – и по домам». Нет, Линус остается в игре, поэтому игра ширится, развивается, и будет развиваться. Игра продолжается до тех пор, пока не надоедает своим участникам. Играть может любое количество людей – без каких-либо временных рамок или ограничений. Как только игрокам станет неинтересно, игра закончится. В этом смысле разработка программного обеспечения с открытым исходным кодом больше похожа на музыкальные джем-сейшны или на конструктор LEGO. Это кооперативная игра, которая не направлена на достижение конечной цели и не предусматривает руководства или распределения ограниченных ресурсов. Поэтому те приемы, которые прекрасно работают в проектах с открытым кодом, не сработают в обычных проектах по разработке ПО – ограниченных в ресурсах и направленных на достижение конечной цели кооперативных игр.
На свете нет формулы, позволяющей выигрывать в играх. Есть только стратегические приемы и навыки, которые могут быть полезны в той или иной ситуации. Даже одно понимание этого может оправдать весь «игровой» подход к процессу разработки ПО. Люди, работающие над реальными проектами, начинают осознавать, что для победы в игре им необходимо постоянно использовать свой разум и смекалку – наблюдать за изменяющейся ситуацией и делать соответствующие выводы, запоминать и применять известные стратегические приемы, тут же изобретать и опробовать новые. И при этом всегда помнить, что в такой сложной и перегруженной требованиями области, как проект по разработке ПО, достичь обе цели невозможно, поэтому надо определить, какая из них имеет наибольший приоритет и двигаться к ней в ущерб другой.
В сущности, вся разработка программного обеспечения состоит в том, что люди что-то изобретают в процессе общения:
При этом каждое из возможных решений имеет экономические последствия, а ресурсы команды, как мы помним, ограничены. Вся наша ограниченная в ресурсах, направленная на достижение определенной цели кооперативная игра в производство программного обеспечения движется вперед благодаря двум составляющим – изобретению и общению. Между людьми, которые изобретают информацию, манипулируют ею и передают ее другим, должно происходить общение, иначе они не смогут выработать решение, изобрести новый программный продукт (который и является целью игры).
Таким образом, получается, что скорость развития проекта напрямую зависит от того, насколько быстро информация будет перемещаться из одной головы в другую. Любой фактор, усложняющий или ограничивающий распространение информации, будет замедлять весь проект. Чтобы успешно играть в игру по разработке ПО, этот факт надо усвоить особенно хорошо.
Ниже мы перечислим термины, которые относятся к лексикону кооперативных игр. Эти концепции помогут понять, что такое проект по разработке ПО, и как им лучше управлять:
Можно легко вообразить, что «объяснить текущий дизайн программного продукта» не что иное, как запечатлеть существующие проектные решения в каком-то графическом формате (например, Unified Modeling Language, UML). Но передача информации – далеко не механическое занятие [Maturana]. Общение больше похоже на «прикосновение к общим переживаниям и опыту» [Cockburn 2002a]. При этом конечно, общение будет принимать те формы, которые подсказывает людям их опыт. Разработчики, которые работали раньше над другими проектами, будут обращаться к прошлым проектным решениями и ситуациям. Те, кто раньше вместе не работал, но обладают взаимопониманием, будут более подробно описывать свое понимание алгоритмов и шаблонов проектирования. Третья группа будет вынуждена использоваться простую буквенную документацию – UML диаграммы или комментарии в программном коде.
Как показывает Питер Наур в своей работе «Программирование как построение теории» ("Programming as Theory Building" [Naur]), то, что должно передаваться от одного разработчика другому, называется «понимание», а понимание не передашь посредством документации или схем. Каждый человек строит его индивидуально на основе имеющихся знаний. Передать понимание проблемы гораздо проще, если показать человеку, что изменилось в дизайне программного продукта, объяснить, от чего пришлось отказаться, какие для того существовали причины, и почему сейчас решено делать программный продукт именно так, а не иначе. Но это зачастую требует прямого диалога между людьми.
Поскольку любые воспринимаемые телодвижения являются частью процесса общения, можно ускорить его, дав участника возможность находиться вблизи друг от друга, так чтобы у них была возможность слышать и видеть друг друга, жестикулировать, рисовать на доске, т.д. [McCarthy] [Cockburn 2002a].
Таким образом, если людям надо играть в интенсивное общение в условиях ограниченных ресурсов, то лучше всего позволить им общаться и работать в одной комнате, фотографировать решения, нарисованные на доске, и снимать обсуждения отдельных проблем на видео. Это позволит сделать общение одновременно более разнообразным, быстрым, экономичным, а главное, более удобным для передачи знаний.
Интересно, что такая изменчивая и непредсказуемая игра, какой является создание программного обеспечения, допускает и прямо противоположные техники работы. Один из примеров приведен в статье Cone of Silence (там описана стратегия преднамеренного затруднения общения между некоторыми членами команды разработчиков) [Cockburn 2003b].
Изобретать в нашей игре приходится постоянно. Пользователи изобретают то, что, как они считают, поможет им в дальнейшей работе; разработчики изобретают проектные решения; тестировщики придумывают тесты для разрабатываемых систем; руководители изобретают общую стратегию для разработки проекта в изменчивых ситуациях.
Приемам, которые позволяют улучшить процесс изобретения, посвящено довольно много исследований: техника мозгового штурма [Bordia], бумажное прототипирование пользовательских интерфейсов [Ehn] [Snyder], CRC-карточки для объектно-ориентированного проектирования [Beck], и даже техника ведения дискуссий у доски для рисования, с возможным использованием стандартизованных нотаций [Ambler]. При этом существуют некоторые не совсем очевидные факторы, влияющие на процесс выработки идей. Например, сокрытие социального статуса участников дискуссии способствует независимости суждений [Bordia] [Weisband] [Markus]. В целом же в этой области нужны дополнительные исследования.
В процессе изобретения и выработки новых идей люди используют разнообразный реквизит и особые виды коммуникации, благодаря которым эти идеи можно передать и продемонстрировать другим людям. Такой реквизит может быть довольно неформальным: плакаты, временные диаграммы, карточки для записи и липкие бумажки. К формальному реквизиту можно отнести большие сложные диаграммы, таблицы и модели. При этом реквизит обоих типов является временным. После того, как решение найдено, а дискуссия закончена, его ценность равна нулю. Правда, есть еще стратегия хранения архивов с целью их повторного использования (она относится к экономической стороне игры в коммуникацию). Кроме того, люди часто используют отдельные элементы временного реквизита с постоянными маркерами, чтобы не забыть о чем-то или иметь под рукой дополнительную информацию.
Человек может создать реквизит, который поможет ему сделать следующий шаг в игре. Кроме того, он может оставить маркер для того, кто пойдет следом за ним по этому же пути (в будущем этим человеком может оказаться он сам). Каждый элемент реквизита или маркер призван способствовать одной из трех нижеперечисленных функций и иметь некую оптимальную для этого форму:
Маркерами могут быть не только артефакты, но и люди. Самый лучший маркер, который команда разработчиков может оставить своим последователям – это кто-нибудь из разработчиков, способных ввести новую команду в курс дела. По эффективности этот способ не знает себе равных. Именно поэтому очень часто команда, завершив какой-нибудь проект, оставляет одного или нескольких человек для работы в следующей команде, которая будет продолжать игру. Без этого начать следующую игру можно будет нескоро, а чем медленнее идет игра по разработке ПО, тем менее выгодной она становится.
При этом неизбежно возникает конфликт, вызванный непониманием того, что произойдет при изменении состава команды разработчиков, и необходимостью время от времени такие изменения производить. «Напоминания» будут оптимальными маркерами, при условии, что состав команды практически не меняется. «Информирующие» маркеры необходимы при масштабных заменах в команде. Конечно, организация может позволить себе сохранить состав команды в течение нескольких игр, однако рано или поздно в проекте не останется ни одного из первоначального состава разработчиков. Таким образом, даже начиная работать над проектом, нельзя полагаться исключительно на маркеры-напоминания или только на информирующие маркеры, только на людей или только на искусственные артефакты.
Следовательно, руководители проекта и команда разработчиков, как всегда, должны выбирать какое-то свое сочетание возможных решений, зная, что все они не идеальны.
Итак, давайте подведем итоги первой части статьи. Мы познакомились с критикой привычной «инженерной» модели создания программного обеспечения и перечислили основные ее недостатки:
После этого мы рассмотрели новую модель, которую Алистэр Коуберн предлагает в качестве альтернативы – модель кооперативной игры:
Во второй части статьи расскажем о том, как Алистэр Коуберн советует применять новую модель программирования и как идея кооперативной игры объясняет успех или неудачу проектов, которые не ложатся в привычную «инженерную» модель, и которые принято считать «аномальными».