« "Четвертое измерение или Как обмануть Железный Треугольник", Алистэр Коуберн | | "Deadline", Том Демарко, глава 6 - "Лучший в мире руководитель" »

"Создание программного обеспечения как коллективная игра", Алистэр Коуберн

По материалам статей Алистэра Коуберна за период 1997-2004 гг1

Программная инженерия (software engineering) представляет собой неверную метафору для большинства проектов по разработке ПО. Используя техническую метафору, мы забываем об истинной природе программирования - деятельности социальной и интеллектуальной, но никак не технической. Неудивительно, что проблема "мифического человеко-месяца" жива до сих пор, ведь рассуждая о разработке ПО, мы продолжаем рассматривать людей как "заменимые компоненты для программирования" и нанимать "группу Java-программистов".

Питер МакБрин, автор книги "Software Craftsmanship" 2


Введение (от переводчиков)

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

Ответов на них нет. Вернее, их множество, что, по сути, то же самое. И единственно возможным вариантом становится сочетание собственного опыта и учебы на чужих открытиях и ошибках.

Алистэр Коуберн (Alistair Cockburn, http://alistair.cockburn.us) - один из немногих методологов, которые все свои изыскания подкрепляют многолетним опытом работы среди программистов. Его статьи и книги - не академические изыскания, это летопись успешных и неудачных проектов, бесценный опыт, которым он щедро делится, не скрывая своих прошлых ошибок и заблуждений.

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

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

За последние семь лет Алистэр написал несколько статей и книг на эту тему. Некоторые из них вошли в уже классический набор трудов по так нызываемым "гибким методологиям".4

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

Но обратимся к работам Алистэра на эту тему.5

Инженерная модель программирования не оправдывает себя

Разработка программного обеспечения не всегда относилась к инженерным наукам. Таковой ее предложили считать в 1968 году, чтобы спровоцировать людей к участию в работе новой отрасли [Naur-Randell]. Провокация оказалась очень удачной. К сожалению, этого нельзя сказать о полезности такой модели для тех, кто в ней работает. Даже после 35-летнего опыта использования инженерной модели процент успешных проектов в сфере производства ПО продолжает оставаться низким [Standish]. Мы не можем определить взаимосвязь между успехом проекта и "чистотой" процесса его разработки [Cockburn 2003a]. Наконец, мы видим, что эта модель не помогает профессионалам решать практические вопросы, находить выход из сложных ситуаций в реальных проектах.

Некоторые могут возразить, что "инженерная" модель не работает, потому что мы недостаточно хорошо ей следуем. Однако во время "разбора полетов" нередко выясняется, что проекты, в которых разработчики не следовали никакому четкому процессу, оканчивались успешно, в то время как строгие процессы далеко не всегда приводили проект к благополучному завершению. Конечно, можно привести и обратные примеры, но это нисколько не проясняет ситуацию. Скорее, наоборот - так еще труднее догадаться, что же является залогом успеха проекта. Впрочем, что бы это ни было, оно не имеет ни малейшего отношения к "чистоте" используемого процесса или усердности следования "инженерной" модели. [Cockburn 2000a, 2003a].

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

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

Таким образом, нашей отрасли надо найти другую модель, которая могла бы

Модель коллективной игры

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

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

В современной науке в категорию игр попадает такое количество разнообразных видов деятельности, что иногда трудно найти в них что-то общее. Витгенштейн [Wittgenstein, 1953] считает, что обязательным условием игры является следование правилам. Как только участники игры перестают следовать ее правилам, игра прекращается (таким образом, игрой можно назвать только добровольную деятельность, при условии, что у участников всегда есть возможность прекратить ее и действовать другим образом). Любая игра состоит из "движений" по направлению к или от цели и некоего учета расстояния между целью и игроком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Способность (Ability). Сочетание таланта, умения и навыков. Талант, взятый сам по себе, дает возможность изобретать лучшие решения или быстрее видеть шаблоны и успешно их применять. Сочетание таланта и умения дает в сумме способность человека работать в данной области. Команды, в которых наблюдается это сочетание, могут делать все гораздо лучше (а вот будут они это делать или нет, зависит от многих вещей: общей стратегии, общения, сообщества, в котором существуют разработчики, а также мотивации).
  • Сообщество (Community). В это понятие входит дружелюбие, доверие, моральное состояние, а также общие переживания и опыт. Под дружелюбием следует понимать "готовность и желание слушать". Когда оно пропадает, люди перестают делиться информацией друг с другом, и не слушают, когда эту информацию сообщает им кто-то другой. Дружелюбие подпитывается доверием и моральным состоянием. Некоторые из нас изначально склонны доверять всем подряд, и меняют свою привычку только после того, как их обидели или ущемили в правах. Другие, напротив, склонны не доверять никому, и меняют свое отношение только после того, как неоднократно убедятся в компетентности и доброй воле окружающих. Развитию доверия, морального духа и дружелюбия в команде способствуют общие переживания и опыт [Brown] [Tyler].
  • Общение (Communication). Основывается на наличии общего словаря, близости и коммуникационных технологиях. Общий опыт не только служит основой для развития взаимного доверия, но также дает членам команды определенный словарь, который они используют для облегчения взаимопонимания и ускорения общения. Общение подразумевает не только преднамеренную передачу сигналов, но также и то, что люди могут интерпретировать как сигнал: выражение озабоченности, счастья или довольства, переданное посредством телодвижений или мимики. Причем чем ближе люди находятся друг к другу, тем больше вербальных и невербальных сигналов они получают, что значительно ускоряет процесс общения. Соответственно, чем больше расстояние, тем выше роль коммуникационных технологий, с помощью которых можно создать иллюзию близости (см., например, работы Херринга [Herring]).
  • Индивидуальность (Individuals). Сейчас в мире существуют многие сотни тысяч специалистов, разрабатывающих программное обеспечение. Статистика дает нам некие усредненные данные об общем уровне способностей в нашей отрасли. Однако разработка программного обеспечения как процесс создания и передачи знания, очень чувствительна к тонким химическим реакциям между каждой парой общающихся между собой разработчиков и их группами. Таким образом, в любом проекте людей нужно направлять (и управлять ими) на индивидуальном уровне. В любой момент времени эти люди представляют собой работающих на проектом индивидуумов, но никак не роли, как это часто считается.

Можно легко вообразить, что "объяснить текущий дизайн программного продукта" не что иное, как запечатлеть существующие проектные решения в каком-то графическом формате (например, 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]. В целом же в этой области нужны дополнительные исследования.

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

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

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

  • Напоминание. Артефакты такого рода должны напоминать участникам игры о предмете дискуссии и принятых решениях. Можно сказать, что это способ общения с самим собой в будущем. Фотографии того, что было нарисовано на доске во время дискуссии, плакаты, всевозможные салфетки из кафе представляют собой очень эффективные "напоминания". Причем не потому, что они дешевы, а потому что само несовершенство их формы помогает воссоздать в памяти контекст - ситуацию, в которой они были созданы. Естественно, для тех, кто не присутствовал при этом, такой артефакт будет нести очень мало информации. Команда должна помнить, что "напоминания" она создает для себя самой, поэтому изготавливать их можно из чего угодно, лишь бы они выполняли свою функцию. В гибких методологиях [Highsmith] маркеры-напоминания используются очень широко.
  • Вдохновение. Такой реквизит должен помочь нам изобрести, выдумать что-то новое (необходимая составляющая любого исследования). Реквизит такого рода должен быть ощутимым, осязательным, например, бумажные прототипы пользовательских интерфейсов [Snyder], CRC-карточки [Beck], карточки для мозгового штурма, даже чучела животных - все это стимулирует наши нейроны и помогает усилить мозговую деятельность. Визуально-аналитический реквизит, к которому можно отнести различные симуляторы, графики и диаграммы, спецификации, аналитические или описательные (UML) модели, позволяет разработчикам осознать свое понимание проблемы. Такие артефакты не нацелены на использование в будущем. Они призваны стимулировать нашу деятельность в настоящем. Чтобы донести информацию, которая в них содержится, в будущее, их нужно преобразовать в "напоминания". При этом решение о выборе конкретной формы "напоминания" принимается исходя из экономических соображений. В конце дискуссии команда должна сама решить, в какой форме составить "напоминание", кому его адресовать и с какой целью.
  • Информирование. Информационные маркеры необходимы для включения в игру новых участников. Как только в команде появляется новичок, его нужно как можно скорее ввести в курс дела, чтобы он приобщился к общему пониманию и опыту команды. Конечно, сделать это сразу и полностью невозможно [Naur] [Cockburn 2002a], поэтому главное при создании таких маркеров - решить, сколько времени команда может затратить на их создание, и сколько информации они должны вмещать. Среди всех маркеров этот - самый дорогостоящий, потому что новички не обладают тем самым общим знанием и пониманием проекта, поэтому он должен вводить их в курс дела, используя общий подход к проблеме и разнообразные ссылки на другие материалы. Маркер в своей "информационной" ипостаси используется в нашей отрасли довольно давно (для обеспечения возможности глобальных изменений в персонале).

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

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

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

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

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

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

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

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

Во второй части статьи расскажем о том, как Алистэр Коуберн советует применять новую модель программирования и как идея коллективной игры объясняет успех или неудачу проектов, которые не ложатся в привычную "инженерную" модель, и которые принято считать "аномальными".

Библиография

На русском

На английском

  • Ambler, S., Agile Modeling, John Wiley & Sons, 2002.
  • Beck, K., Cunningham, W., "A laboratory for teaching object-oriented thinking," ACM SIGLPLAN 24(10):1-7, 1989.
  • Boehm, B., Software Cost Estimation with COCOMO II, Prentice Hall PTR, 2000.
  • Bordia, P., Prashant, K., "Face-to-face versus computer-mediated communications: A synthesis of the literature", The Journal of Business Communication 34(1),U of Illinois, Champaign, IL, Jan 1997, pp. 99-120.
  • Brown, K., Klastorin, T. & Valluzzi J., "Project Performance and the Liability of Group Harmony," IEEE Transactions On Engineering Management, 37(2), May 1990, pp. 117-125.
  • Carse, J., Finite and Infinite Games, Ballantine Books, 1987.
  • Chase, T., "Revelation 13: The Big Dig" http://www.revelation13.net/bigdig.html
  • Cockburn, A. [2003a], People and Methodologies in Software Development, Dr. Philos. dissertation, Faculty of Mathematics and Natural Sciences dissertation no. 264, University of Oslo, 2003, online at http://alistair.cockburn.us/htdocs/crystal/books/pamisd/peopleandmethodologiesinsoftwaredevelopment.pdf.
  • Ehn, P., Work-Oriented Development of Software Artifacts, Arbetslivscentrum, Stockholm, 1988.
  • Herring, R., Rees, M., "Internet-Based Collaborative Software Development Using Microsoft Tools", in Proceedings of the 5th World Multiconference on Systemics, Cybernetics and Informatics SCI'2001. 22-25 July, 2001. Orlando, Florida., online at http://erwin.dstc.edu.au/Herring/SoftwareEngineering0verInternet-SCI2001.pdf.
  • Highsmith, J., Agile Software Development Ecosystems, Addison-Wesley, 2003.
  • Markus, M., "Asynchronous technologies in small face to face groups," Information Technology & People, Apr 92, 6(1), p.29.
  • Maturana, H., Varela, F., The Tree of Knowledge, Shambhala Publications, 1988.
  • McCarthy, J., Monk, A., "Channels, conversation, cooperation and relevance: all you wanted to know about communication but were afraid to ask," in Collaborative Computing, Vol. 1, No. 1, March 1994, pp. 35-61.
  • Naur, P. Randell, B, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, Naur, P., Randell, B., eds., 1969, online at http://homepages.cs.ncl.ac.uk/brian.randell/NATO/
  • Naur, P., "Programming as Theory Building", pp.37-48 in Computing: A Human Activity, ACM Press, 1992.
  • Snyder, C., Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, Morgan Kaufmann, 2003.
  • Standish, 2003 CHAOS Chronicles, The Standish Group International (http://www.standishgroup.com), summarized at http://www.findarticles.com/cf_dls/m0EIN/2003_March_25/99169967/p1/article.jhtml
  • Tyler, T., Kramer, R., eds., Trust in Organizations: Frontiers of Theory and Research, Sage Publications, 1996.
  • Weisband, S., Schneider, S., Connolly, T., "Computer-mediated communication and social information: status salience and status differences", in Academy of Management Journal 38(4), Mississippi State, Aug 95, pp. 1124-1143.
  • Wittgenstein, L., Logical Investigations, Basil Blackwell, Oxford, UK, 1953.

Сноски из текста

  1. Перевод и цитирование дается по следующим работам: "Software Development as a Cooperative Game" (http://alistair.cockburn.us/crystal/articles/sdacg/softwaredevelopmentasacooperativegame.html), "The Cooperative Game Manifesto for Software Development" (http://alistair.cockburn.us/crystal/articles/cgm/manifesto.html), "The End of Software Engineering and the Start of Economic-Cooperative Gaming" (http://alistair.cockburn.us/crystal/articles/teoseatsoecg/theendofsoftwareengineering.html) с ведома и разрешения автора (Alistair Cockburn, Humans and Technology, arc@acm.org).
  2. http://www.mcbreen.ab.ca/SoftwareCraftsmanship
  3. "Software Development as a Cooperative Game" (http://alistair.cockburn.us/crystal/articles/sdacg/softwaredevelopmentasacooperativegame.html)
  4. Книга "Agile Software Development" (на русском языке издана издательством "Лори", "Быстрая разработка программного обеспечения", 2002 г), статьи "People as nonlinear…" , "Methy per project" , "Pair programming" , "Just in time methodology construction" , etc (переводы всех четырех статей есть на сайте http://www.maxkir.com).
  5. Поскольку материалов довольно много, мы решили разделить статью на две части. В первой части мы приведем высказывания Алистэра Коуберна о том, что такое модель кооперативной игры, из каких компонентов она состоит, и какое место занимает разработка программного обеспечения среди других коллективных игр. Во второй части мы остановимся на вопросах применения этой модели в действии на примере реальных проектов и ситуаций.

kirsa September 11, 2004 6:30 PM

Комментарии

Сделать комментарий




Запомнить меня?