Виды игр, коллективные игры, последовательность игр

Любая игра состоит из "движений" по направлению к цели и некоего учета расстояния между целью и игроком. Некоторые игры рассчитаны на одного участника, в другие играют целые группы людей. Одни игры направлены на достижение цели, другие - на взаимодействие участников. При этом продолжительность игр может варьироваться от нескольких минут или даже секунд, до лет или всей жизни игрока. Определяя место производства программного обеспечения среди прочих игр, можно руководствоваться тремя основными характеристиками:

1. Оно (производство ПО) может быть конечным или бесконечным.
2. Оно может быть основано на конкуренции или на взаимопомощи.
3. Оно может быть прекращено после достижения конкретной цели (включая прекращение игры по истечению определенного срока) или же у него вообще может не быть никакой определенной конечной точки (когда закончится, тогда и закончится).

Цель бесконечной игры - в ее продолжении. Люди, организации и целые государства играют в бесконечную игру под названием "выживание". Некоторые люди играют в игру, которая называется "Сделай карьеру" (можно, например, повышать свою рыночную стоимость за счет проекта) и т.д. Легко догадаться, что отдельные бесконечные игры могут мешать оптимальному ходу большого проекта, поэтому борьба с такими помехами обычно является частью стратегии руководства.

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

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

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

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

Таким образом, программисты ставят перед собой две цели:

1. Поставить заказчику систему;

2. Создать основу для следующей игры.

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

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

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

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

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

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

Проекты с открытым исходным кодом - тоже игры, но немного другого рода. Во-первых, в них нет ограничений по ресурсам, а во-вторых, конечной точки. Линус Торвальдс не мог сказать: "Сейчас вот выпустим приличную версию Линукса - и по домам". Нет, Линус остается в игре, поэтому игра ширится, развивается, и будет развиваться. Игра продолжается до тех пор, пока не надоедает своим участникам. Играть может любое количество людей - без каких-либо временных рамок или ограничений. Как только игрокам станет неинтересно, игра закончится. В этом смысле разработка программного обеспечения с открытым исходным кодом больше похожа на музыкальные джем-сейшны или на конструктор LEGO. Это коллективная игра, которая не направлена на достижение конечной цели и не предусматривает руководства или распределения ограниченных ресурсов. Поэтому те приемы, которые будут прекрасно работать в проектах с открытым кодом, не сработают в обычных проектах по разработке ПО - ограниченных в ресурсах и направленных на достижение конечной цели коллективных играх.

Кооперация и коммуникация

В сущности, вся разработка программного обеспечения состоит в том, что люди что-то изобретают в процессе общения:

• Они работают над проблемой, которую могут недопонимать, причем проблема может изменяться в процессе работы;

• Они вырабатывают решение, правильность которого не гарантирована, и которое может изменяться в процессе работы;

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

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

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

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

Способность (Ability). Сочетание таланта, умения и навыков. Талант, взятый сам по себе, дает возможность изобретать лучшие решения или быстрее видеть шаблоны и успешно их применять. Сочетание таланта и умения дает в сумме способность человека работать в данной области. Команды, в которых наблюдается это сочетание, могут делать все гораздо лучше (а вот будут они это делать или нет, зависит от многих вещей: общей стратегии, общения, сообщества, в котором существуют разработчики, а также мотивации).

Сообщество (Community). В это понятие входит дружелюбие, доверие, моральное состояние, а также общие переживания и опыт. Под дружелюбием следует понимать "готовность и желание слушать". Когда оно пропадает, люди перестают делиться информацией друг с другом, и не слушают, когда эту информацию сообщает им кто-то другой. Дружелюбие подпитывается доверием и моральным состоянием. Некоторые из нас изначально склонны доверять всем подряд, и меняют свою привычку только после того, как их обидели или ущемили в правах. Другие, напротив, склонны не доверять никому, и меняют свое отношение только после того, как неоднократно убедятся в компетентности и доброй воле окружающих. Развитию доверия, морального духа и дружелюбия в команде способствуют общие переживания и опыт.

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

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

Можно легко вообразить, что "объяснить текущий дизайн программного продукта" не что иное, как запечатлеть существующие проектные решения в каком-то графическом формате (например, Unified Modeling Language, UML). Но передача информации - далеко не механическое занятие Общение больше похоже на "прикосновение к общим переживаниям и опыту" . При этом конечно, общение будет принимать те формы, которые подсказывает людям их опыт. Разработчики, которые работали раньше над другими проектами, будут обращаться к прошлым проектным решениями и ситуациям. Те, кто раньше вместе не работал, но обладают взаимопониманием, будут более подробно описывать свое понимание алгоритмов и шаблонов проектирования. Третья группа будет вынуждена использоваться простую буквенную документацию - UML диаграммы или комментарии в программном коде.

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

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

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

Интересно, что такая изменчивая и непредсказуемая игра, какой является создание программного обеспечения, допускает и прямо противоположные техники работы. Один из примеров приведен в статье Cone of Silence (можно перевести как "Тихая гавань" - в этой статье описана стратегия преднамеренного затруднения общения между некоторыми членами команды разработчиков).

Изобретательность

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

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

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

Реквизит и маркеры для игр

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

Напоминание. Артефакты такого рода должны напоминать участникам игры о предмете дискуссии и принятых решениях. Можно сказать, что это способ общения с самим собой в будущем. Фотографии того, что было нарисовано на доске во время дискуссии, плакаты, всевозможные салфетки из кафе представляют собой очень эффективные "напоминания". Причем не потому, что они дешевы, а потому что само несовершенство их формы помогает воссоздать в памяти контекст - ситуацию, в которой они были созданы. Естественно, для тех, кто не присутствовал при этом, такой артефакт будет нести очень мало информации. Команда должна помнить, что "напоминания" она создает для себя самой, поэтому изготавливать их можно из чего угодно, лишь бы они выполняли свою функцию. В гибких методологиях маркеры-напоминания используются очень широко.

Вдохновение. Такой реквизит должен помочь нам изобрести, выдумать что-то новое (необходимая составляющая любого исследования). Реквизит такого рода должен быть ощутимым, осязательным, например, бумажные прототипы пользовательских интерфейсов , CRC-карточки , карточки для мозгового штурма, даже чучела животных - все это стимулирует наши нейроны и помогает усилить мозговую деятельность. Визуально-аналитический реквизит, к которому можно отнести различные симуляторы, графики и диаграммы, спецификации, аналитические или описательные (UML) модели, позволяет разработчикам осознать свое понимание проблемы. Такие артефакты не нацелены на использование в будущем. Они призваны стимулировать нашу деятельность в настоящем. Чтобы донести информацию, которая в них содержится, в будущее, их нужно преобразовать в "напоминания". При этом решение о выборе конкретной формы "напоминания" принимается исходя из экономических соображений. В конце дискуссии команда должна сама решить, в какой форме составить "напоминание", кому его адресовать и с какой целью.

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

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

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

Вместо заключения

Итак, подведем итоги. Мы познакомились с критикой привычной "инженерной" модели создания программного обеспечения и перечислили основные ее недостатки:

1. Она не описывает необходимые составляющие успешного проекта, например, талант и навыки, единство и сплоченность команды, межличностную коммуникацию [Boehm].
2. "Инженерная" модель не может объяснить неожиданный успех или провал многих проектов. В частности, она не может объяснить успех легких, даже "небрежных" методологий и предпочтение, которое оказывают этим методологиям опытные и известные разработчики.
3. Несмотря на 35-летний опыт использования термин "software engineering" люди до сих пор не могут однозначно его интерпретировать, что приводит к прямо противоположным рекомендациям относительно процесса работы.
4. Ни сам термин, ни модель, не предлагают разработчикам эффективных решений в сложных ситуациях.

После этого мы рассмотрели новую модель, которую Алистэр Коуберн предлагает в качестве альтернативы - модель коллективной игры:

1. Производство программного обеспечения представляет собой ничто иное, как серию коллективных игр, ограниченных в ресурсах, направленных на достижение определенной цели, состоящих из изобретения и общения.
2. Главная цель каждой игры - поставка действующей системы заказчику.
3. В результате игры остается некий набор маркеров, который призван помочь игрокам в следующей игре.
4. Разработчики используют маркеры и прочий реквизит для напоминания, вдохновения и информирования при переходе к следующему шагу игры.
5. Следующая игра представляет собой изменение или дополнение поставленной заказчику системы. Таким образом, вторая основная цель каждой игры - это создать выгодную позицию для ее продолжения.
6. Первая и вторая цель игры претендуют на одни и те же ресурсы и конкурируют между собой.

Контрольные вопросы

1. Чем продиктован коллективный характер разработки ПО?

2. Каковы функции главного программиста в бригаде программистов?

3. Чем бригада главного программиста похожа на бригаду хирургов?

4. Какова структура бригады главного программиста?

5. Поясните главные компоненты организационной структуры разработки большого программного проекта?

6. Какова особенность организации работы программистов в ХР-процессе?

7. Почему психологические факторы играют особую роль при формировании программистских коллективов?

8. Каким образом психологические факторы участвуют в конкретных моделях конструирования, например, в ХР-процессе?

9. В каких случаях, при создании каких проектов инженерная модель программирования не оправдывает себя? Почему?

10. Каким образом модель «коллективной игры» используется в программировании?

11. В каких известных вам моделях конструирования присутствуют элементы коллективной игры?

12. Без каких концепций, свойств, реквизитов и маркеров коллективная игра невозможна?