Управление проектами - статьи
         

Антипаттерны мнительности


«Агрессия». «На то и волк в лесу, чтоб пастух не дремал!» Руководитель стремится удерживать подчиненных вне «зоны комфорта». («Настоящие лидеры задают трудные вопросы и выбивают людей из зоны их комфорта. Затем они управляют возникающим стрессом!», (с) Р.А. Хейфетц, Д.Л. Лори, «Работа лидера», 1997.) Постоянное давление. Нереальные сроки. Сверхурочные. Авралы. Непрерывная критика и понижение самооценки («заодно можно сэкономить на зарплате!»). Грубость. Запугивание. «У нас незаменимых нет!» «Поощрение непричастных и наказание невиновных». Назначение в несколько проектов одновременно. («Чем больше, тем лучше - обязательно что-нибудь провалит! Сотрудник должен все время ощущать свою вину!») Постоянные перемещения людей по горизонтали и вверх-вниз. Обязанности определены самым общим образом: «Ты в ответе за все!» Поручения не зависят от обязанностей. Правила меняются по ходу игры.

«Управление грибами». (Почему грибами? Потому, что грибы держат в темноте и кормят навозом.) Удержание работников в неинформированном и постоянно занятом состоянии. Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Зависимость исполнителей от более информированного начальника. Строгое разграничение прав доступа к проектной документации и исходным кодам. Ограничение доступа в Интернет («а вдруг узнают среднюю зарплату на рынке?»), запрет ICQ, препятствование общению с коллегами из других компаний. Загрузить работой так, чтобы времени на обдумывание чего-либо не оставалось. Постоянно находить какие-нибудь «важные и неотложные» дела.

«Микроменеджмент». Отсутствие делегирования в любом виде. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам.
Считает себя самым компетентным. Влезает во все самые мелкие работы, от структуры таблиц в БД до цвета шрифтов в интерфейсе. Вместо объяснения того, что надо делать, постоянные указания на то, как надо делать. Навязывает собственные идеи. «Думать – это моя работа! Просто, делай, как я сказал!» Жестко контролирует, каждый шаг исполнителей.

«Методологическое безумие». Безграничная вера руководителя в методологию с большой буквы «М» - всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Многоступенчатая бюрократия. Все процессы регламентированы. Все делается по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Установлен тотальный контроль соблюдения регламентов. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. Большая часть времени исполнителей тратится на соблюдение правил и писанину, которую никто никогда не читает. Большая доля «сизифова труда».


Антипаттерны некомпетентности


«Я сделал все, что мог!» Руководитель не способен оценить сложность решаемых задач, эффективность способов их решения и реальное состояние проекта. Постоянные негативные оценки прогресса проекта: «Все плохо! Надо делать быстрее! Надо делать лучше!», не вдаваясь в подробности «как это надо делать». Раздувание недостатков до глобальных размеров. Постоянная публичная критика участников команды и жалобы вышестоящему руководству на некомпетентность исполнителей. Надежда на то, что если проект провалится, то удастся свалить вину на команду: «Я сделал все, что мог!». Если же проект окажется успешным – присвоить успех себе: «Если бы я не «строил» команду, ничего бы не получилось!»

«Yes-man!» Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. Руководствуется принципом: «Возлюби Босса своего и никогда не спорь с ним!». Интересы фирмы, команды, продукта и его пользователей не учитываются вовсе. «Босс хочет, что бы мы закончили проект в два раза быстрее. Как? Это ваша забота, вам за это деньги платят!». Не принимает ни одного решения без согласования с Боссом. Испытывает постоянную потребность «угадать и угодить» Культивирует любимчиков в команде, которые никогда с ним не спорят.

«Охота на ведьм». Руководитель сознает свою некомпетентность и опасается, что если он не возглавит борьбу с «врагами» проекта, то «врагом» проекта может оказаться он сам. Постоянный поиск виновных и «козлов отпущения». Наказания. Разжигание конкуренции в команде: «После проекта останутся только лучшие!». Действия по принципу «разделяй и властвуй». Исполнители проекта распадаются на несколько противоборствующих клик.
Пресечение любой критики и опасного для себя поведения подчиненных: «Ваше поведение непрофессионально / некорпоративно!» (вы ни разу не слышали этой фразы – завидую, вам везло с начальниками).

«Нет времени точить пилу!» (в англоязычной википедии у этого антипаттерна другое, более жесткое название – «Headless chicken»). Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический труд («у плохих генералов всегда много героев»). Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. «Это надо было сделать еще вчера!» Работа постоянно выполняется под давлением нереальных сроков. Обучение, анализ, проектирование и рефакторинг – «Это все потом!». Постоянные сверхурочные и авралы. Большой проблемный код.


Антипаттерны руководства командами разработки ПО


Сергей Архипенков

Прокомментировать статью можно здесь

«Программист рожден для счастья…,
а приходится работать!»

(с) В. Короленко + программисты



Что такое эффективность?


Эффективность это количество полученных результатов на единицу затрат. В новых условиях надо осознать, что люди – это теперь не затраты. Люди - это капитал. Затраты: плата за аренду, коммунальные услуги, электроэнергию и проч., - не надо путать с инвестициями, которые увеличивают капитализацию. Вложение в людей это увеличение числителя в формуле эффективности. Создание и закрепление эффективной команды - это стратегическое приобретение компании. Обучение участников проекта новым технологиям – инвестиции. Уход из компании всех профессионалов после проекта, выполненного по принципу «любой ценой», – затраты, причем очень тяжело восполняемые. Это все равно, что «зарезать курицу, которая несет золотые яйца». Что стоит выигранное сражение, если мы проиграли войну?

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

Принципы «Одно предприятие на всю жизнь», «Работай продуктивно, а предприятие о тебе позаботится» - ушли в прошлое. Посмотрите на рынок рабочей силы в ИТ - правила устанавливают профессионалы. Мало кого интересует, в каких компаниях вы работали, зато всех интересует, в каких проектах вы участвовали и ваш вклад в их успех.

Цель предприятия, которое стремиться к эффективности, сделать счастливыми не только своих клиентов, но и своих работников. Сегодня у проекта разработки ПО не три, а четыре фактора успеха:

Выполнен в соответствие со спецификациями. Выполнен в срок. Выполнен в пределах бюджета. Каждый участник команды уходил с работы в 18:00 с чувством успеха.

Задача эффективных руководителей сделать так, чтобы этот четвертый фактор успеха был воспроизводимым.


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

Тотальная демотивация исполнителей. Вместо мотивирования сотрудников на успех, мотивирование их на избежание риска и негативных для себя последствий. Подавление свободы, самостоятельности, творчества и инициативы. Деструктивное подчинение. (Это когда все работают строго по инструкции и только в соответствие с указаниями руководства.) Отсутствие ответственности исполнителей. («А какие ко мне претензии? Как сказали, так я и сделал!») Низкая эффективность и качество работы. Ухудшение морального климата. Вместо доверия и сотрудничества подозрительность и формальное взаимодействие. (А вы никогда не видели, как тимлид беседует с программистом только «под протокол» и с подписями на каждом листе?) Стрессы. Усталость участников. Личные проблемы. Увольнение наиболее профессиональных сотрудников. Провал проекта. Атипаттерны руководства командами разработки ПО можно разделить на два класса, исходя из «диагноза заболевания» - источника их устойчивого повторения.

Некомпетентность. Руководитель не самостоятелен. Не имеет необходимого опыта. Не является специалистом в своей области. Сильно зависим от окружения и обстоятельств. Не готов брать на себя ответственность. «Армия львов под управлением барана всегда проиграет армии баранов под управлением льва», (с) Наполеон Бонапарт.

Мнительность. Отсутствие доверия между участниками проекта. Чрезмерная настороженность. Скрытность. Неспособность делегировать полномочия. Руководитель не осознал синергию взаимозависимости и взаимопомощи. Все взаимодействия рассматривает только в духе «выиграл/проиграл».Исходит из предпосылок индустриальной эпохи Генри Форда: «Работники ленивы, поэтому им необходимы внешние стимулы для работы. У людей нет честолюбия, и они стараются избавиться от ответственности. Чтобы заставить людей трудиться, необходимо использовать принуждение, контроль и угрозу наказания». Манфред Кетс де Врис называет данное отклонение «параноидальным управлением».

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


О чем?


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



Об авторе


Стаж в разработке ПО 30 лет. Занимался созданием имитационных моделей сложных космических систем в Центре управления полетами. Руководил коммерческой разработкой ПО в компаниях PriceWaterhouseCoopers, Luxoft, CBOSS, в подчинении до 150 человек. Выполнял проекты по заказу Европейского космического агентства (ESA), Даймлер-Бенц Аэроспейс (Германия), Боинг (США), ЦБ РФ, ОАО «Газпром».

На CITForum.ru в 2004 г. было опубликовано эссе Сергея Архипенкова «».



Первоисточники


«Русские программисты никогда не читают руководств», (с) утерян в недрах FIDO. То, что приходится наблюдать в управлении проектами разработки ПО, убеждает, что российские менеджеры программных проектов так же, как и программисты, не читают руководства по работе с людьми. Вот перечень книг, которые, на мой взгляд, необходимо (но, разумеется, не достаточно) прочесть и усвоить каждому руководителю программных проектов, если он хочет быть эффективным.

Стивен Р. Кови, «7 навыков высокоэффективных людей. Мощные инструменты развития личности», 2-е изд., М., Альпина Бизнес Букс, 2007 Алан Картер, Колстон Сенджер, «Программистский камень», 1997 (русский перевод С.Козлов) Кьелл А. Нордстрем, Йонас Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта», Стокгольмская школа экономики в Санкт-Петербурге, 2005 г. Том Демарко, Тимоти Листер, Человеческий фактор: успешные проекты и команды, Санкт-Петербург, Символ-Плюс, 2005

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



В какое время мы работаем?


Скажу сразу, что ответ: «с 9:00 до 18:00» - неправильный. Мы работаем в век «информатики и кибернетики», который еще называется «постиндустриальное общество». Отличительные особенности этой новой общественно-экономической формации следующие.

Эпоха перемен. Все в мире стало непрерывно и стремительно изменяться. Изобилие стало причиной острейшей конкуренции. Инновации - неотъемлемый атрибут нашего времени. «Если у вас медленный доступ в Интернет, вы можете навсегда отстать от развития информационных технологий». Практика должна постоянно перестраиваться применительно к новым и новым условиям. Пример. Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали.

Глобализация. Всеобщая взаимозависимость и взаимосвязанность. Транснациональные компании, бизнес идет туда, где дешевле рабочая сила. Интернет. Конкуренция без границ. Пример.Google. За ночь любой из нас в принципе может создать многомиллионную компанию у себя в гараже. С помощью Интернета вы можете выйти на рынок, на котором более 100 млн. потребителей.

Все решают таланты. Простая мобилизация средств и усилий уже не может обеспечить прогресс. Вспомним Ф. Брукса, «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Идею богатства теперь связывают не с деньгами, а с людьми — не с финансовым капиталом, а с «человеческим». Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора. Работники интеллектуального труда начинают самостоятельно определять себе цену.

Интеллект - основная производственная сила постиндустриального общества. От 70 до 80% всего, что сегодня делается людьми, делается при помощи их интеллекта. В любом товаре, сделанном в США доля зарплаты - 70 процентов (в России, пока, - только 30). Но, как писал Алан Картер, «Мы, программисты, - из числа наиболее мыслящих людей в обществе», и все, что делается в разработке ПО, создается исключительно при помощи интеллекта.


Известно, что производительность программистов может отличаться в десятки раз. В индустриальную эпоху производительность ручного труда увеличилась более чем в 50 раз. Задача менеджеров XXI века - сделать воспроизводимой высокую эффективность интеллектуальной деятельности.

Наш ответ на вызов времени – это:

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

Команды. Самоорганизация и самоуправление совместной деятельностью, взаимный контроль, взаимопомощь и взаимозаменяемость, ясность общих ценностей и целей, коллективная ответственность за результаты труда, всемерное развитие и использование индивидуального и группового потенциалов.

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


Заключение или Что надо программисту для счастья?


Что? В вашей компании эти методы работают? Сочувствую. Это означает, что вы наняли не тех, кого следует.

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

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

Все, кто пытается примерить методы управления фаст-фудом к разработке ПО, обречены.

Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа. Телу необходимы деньги и безопасность. Сердцу - любовь и признание. Разуму – развитие и самосовершенствование. Душе – самореализация. Предоставьте все это вашим сотрудникам, и эффективность их труда возрастет многократно. (Как? Это вопрос из другой области – теории мотивации. А мы здесь, в основном, - о практике демотивации.) В противном случае профессионалы найдут все это в другой компании, а в вашей останутся только посредственности.



Человеческий фактор


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

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

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

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

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

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

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


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

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

Оптимальная величина команды для проекта даже высокой сложности составляет приблизительно 6–8 человек. В это число не входят коллективы подрядчиков и исполнителей заказных работ. Группа в 6–8 человек является функциональным, ответственным и одновременно исполнительным коллективом проекта. Создание команд, которые работали бы слаженно и задействовали ресурсы всей компании как бы извне, сводит к минимуму организационные потери при притирке и, прежде всего, притупляют «природный» конфликт между техниками и экономистами.

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


Мотивация в функциональной группе внедрения проекта


В последнее время все чаще применяют так называемые программы мотивации. Их цель — повышение эффективности работы в коллективах. Сегодня данные программы получили особое распространение именно в проектно-ориентированных компаниях.

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

Логично, что комплекс мер для разных уровней сотрудников относительно иерархической лестницы различен. В общем случае, деление производят на рядовых сотрудников, то есть тех, от кого зависит только порученная им работа, и руководящих — ответственных за выполнение проекта, и технических лидеров, от которых зависит успех проекта в целом.

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

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

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


Победа любой ценой


&laquoЭкспресс-Электроника&raquo

Закон Лермана гласит: «любую техническую проблему можно преодолеть, имея достаточно времени и денег». И с этим трудно не согласиться. Впрочем, следствие из этого закона не столь обнадеживающе, сколь он сам: «вам всегда будет не хватать либо времени, либо денег». И на самом деле, любой менеджер, которому хоть раз приходилось сталкиваться с выполнением проекта, знает, что существует определенное соотношение между длительностью выполнения проекта и его стоимостью. А значит, должен существовать оптимальный темп выполнения работ, позволяющий получить эффективный результат при нормальной ставке капитальных затрат.

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

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

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



Project Risk Management


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

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

В процессе учета и анализа рисков (PRM) можно выделить две стадии — оценка риска (Risk Assessment) и управление риском (Risk Control). При оценке рисков принимаются во внимание такие факторы, как ясность целей проекта, точность оценки затрат, соответствие требованиям конечных пользователей, разночтения в документации и, не в последнюю очередь, атмосфера в коллективе.

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



четкое структурирование стадий выполнения проекта,


Пять составляющих успешного проекта — четкое структурирование стадий выполнения проекта, диаграмма Гантта, методы определения критического пути CPM и PERT, а также соотношение «время/затраты» — являются той основой, на которой строится большинство современных проектов. Оценка рисков позволяет существенно повысить вероятность успешного и своевременного окончания работ. Роль лидера команды — менеджера проекта — также трудно переоценить, и вовсе не тривиальной задачей является поиск подходящей кандидатуры, способной возглавить большой проект. Однако все-таки следует понимать, что предложенные методы лишь инструменты оптимизации ведения проекта, и их использование, равно как и неиспользование не сможет повлиять на успешность или неуспешность проекта. Даже оставив большую часть рутинной организационной работы машинам, человеку все равно придется мыслить и творить.

Как добиться успеха в безнадежных проектах


17.10.2002

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

Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные инструменты.

Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в разряд безнадежных:

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

Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием (ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки зрения.
«Оптимизму» разработчиков что- то противопоставить трудно. Каждый программист учитывает время на собственно разработку модуля, не принимая во внимание коммуникации с другими членами команды и вопросы интеграции подсистем. Решение, как обычно в таких случаях, «лежит» на поверхности: необходимо привлекать к обсуждению плана проекта не только руководство, но и непосредственных разработчиков.

Главной причиной недовольства заказчика обычно является непрозрачность процесса разработки. Заказчик выдвигает требования к информационной системе, объясняет бизнес-правила, а системный аналитик, общаясь с ним, разрабатывает ТЗ. Однако «на выходе» система часто не вполне соответствует исходным запросам, особенно в случае изменения условий бизнеса. Поэтому важно сделать заказчика частью команды. В этом смысле очень привлекательна методология экстремального программирования, одним из постулатов которой является присутствие заказчика «в одной комнате с программистами». Заказчик объясняет user story (ключевые функции информационной системы), и ее реализуют за строго определенное время.

К сожалению, «идеальных» заказчиков мало и проблемы прозрачности и изменяющихся требований приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач программистам (рис. 2).





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


Чтобы совещание было успешным, следует учесть ряд моментов. Тему совещания надо четко определить, подготовив список конкретных вопросов; приглашаются только нужные люди с полномочиями принятия решений; оптимальное число участников — 4–7 человек; по каждой проблеме нужно достичь хотя бы временного, «промежуточного» решения.

Разработку легче, эффективнее и самое главное дешевле вести, используя дорогих профессионалов: системных аналитиков, архитекторов, проектировщиков, кодировщиков и тестировщиков. Однако эти рекомендации применимы только для тех организаций, которые вышли на достаточно высокий уровень финансовой и информационной зрелости. В наших условиях больше подходит вариант, когда к одному «гуру» прикрепляется от одного до трех «учеников». Большинство сотрудников заинтересовано в профессиональном росте и, как следствие, в повышении самооценки и возможности успешной карьеры. Не менее важно обеспечить получение удовлетворения от сделанной работы и налаживание атмосферы сотрудничества в команде.

Как известно, среди проблем проектирования ключевое место занимает проблема отсутствия концептуальной целостности и непротиворечивости архитектуры. Поэтому важно назначить архитектора продукта, ответственного за все его стороны. Кроме того, необходимо отделить архитектуру (т.е. определение продукта в восприятии пользователя) от его разработки [1]. Однако ничто так не вредит переходу от проектирования к программированию, как оторванность ТЗ от реального кода. Системного аналитика и проектировщика нужно подключить к программированию. Это позволит добиться осведомленности системного аналитика (а, следовательно, и заказчика) и проектировщика о реальном положении дел, лучшей согласованности между архитектурой и реализацией, более действенной коммуникации. Именно так можно построить эффективную команду, а не просто группу разработчиков.

В этих аргументах есть некоторые расхождения с «постулатами» RUP, но на практике безусловное разделение функций между архитекторами и исполнителями, чьи творческие таланты и идеи подавляются, приводит к плачевному результату.


Архитекторы «витают в облаках», разрабатывая маловразумительные спецификации, а кодировщики вынуждены заполнять информационные пробелы собственным пониманием проблемы, о чем аналитик и заказчик узнают последними. Дело вовсе не в том, чтобы дать кодировщикам широкие возможности по реализации своих творческих замыслов, напротив, «собственное мнение» кодировщику противопоказано — программирование сегодня не искусство, а ремесло. Однако довести до архитекторов проблемы непосредственно кодирования необходимо; менеджер проекта должен представлять себе, как диаграммы, прекрасно выглядевшие на бумаге, реализуются в коде. Поэтому наиболее эффективно привлечение многофункциональных специалистов, имеющих знания в нескольких смежных областях. Разработка программного обеспечения более сложна, многообразна и непредсказуема, чем конвейерное производство типовых моделей.

Непонимание между заказчиком и разработчиком требует создания единого словаря терминов разрабатываемой информационной системы. У нас такой глоссарий системы представляет собой продукт совместной разработки системного аналитика и проектировщика. С учетом того, что модели ТЗ и ТП создаются с помощью CASE-инструментария Rational Rose, мы используем возможность автоматизированного управления глоссарием, который находится в отдельной модели, доступной по сети всей команде. Только один человек добавляет или модифицирует данные глоссария, остальные же автоматически получают его текущую версию при работе со своими моделями. Эта возможность обеспечивается за счет синхронизации информации в разрабатываемой модели (\\Project.mdl) и глоссария, встроенного «по ссылке» в модель, но в то же время существующего отдельно (\\Glossary.cat). Благодаря этому становится реальной параллельная работа системных аналитиков и проектировщиков при централизованном управлении глоссарием и последовательной обработке запросов на его изменение (рис. 3).





Рис. 3. Работа с глоссарием
Для разделения информационных систем на модули используется множество методов — от описания предметной области на английском языке (при этом существительные станут классами, а глаголы их методами), до практики использования CRC-карт (Class-Responsibility-Collaborator — идентификация объектов информационных систем, меры их «ответственности» и механизма взаимодействия).


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

Среди проблем собственно кодирования, следует выделить нежелание использовать компоненты сторонних производителей; между тем, часто дешевле купить готовый модуль, чем разработать, протестировать и внедрить собственный. При написании кода также могут использоваться готовые программные конструкции, так называемые «паттерны» (design pattern). Последняя версия Rational Rose XDE поддерживает паттерны и интегрирует их с Visual Studio .Net.

Хорошим проектным решением является стандарт на оформление программных форм, нормативы на количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т.п. Помочь в данном случае может стандартный репозиторий программных форм. Кроме того, программный код обязательно оформлять с учетом так называемых «правил кодирования», приняв соглашение по форматированию, названиям объектов, механизмам использования памяти и обработки ошибок и т.п. Нашей организации разработать полноценный стандарт кодирования еще предстоит, поэтому пока для нужд непосредственно программирования используется репозиторий объектов. Сотрудник, ответственный за техническую поддержку репозитория, модифицирует его с учетом изменяющихся требований по функциональности и эффективности форм. Кроме того, в связи с использованием метода round-trip engineering (синхронизация между кодом и моделью в обоих направлениях) с помощью RoseDelphiLink_3_2, разработано положение о документировании программного кода, цель которого — автоматическое получение документации через шаблоны Rational SoDA. В перспективе будет использоваться инструментарий компании BoldSoft, средства которого вошли недавно и в Borland Delphi7 Architect Studio.



Ни один заказчик не станет читать ТЗ на две сотни страниц, но лучше иметь избыточную и плохо структурированную информацию, чем не иметь ее вовсе. В [3] приводится график сравнения ее разновидностей — на первом месте по эффективности стоит живое общение, а далее следуют телефонная связь, электронная почта, видео- и аудиоконференции, и, наконец, бумажная документация (рис. 4).





Рис. 4. Эффективность различных видов коммуникаций
Мы решили задачу автоматизированного создания и модификации ТЗ и ТП за счет использования шаблонов Rational SoDA. При этом из моделей Rose формируются готовые файлы в формате Word, соответствующим образом оформленные и готовые для согласования (рис. 5). Таким образом, достигается главная цель — налаживается взаимодействие удаленных друг от друга участников проектной команды, а ее создание не является обременительным процессом.





Рис. 5. Принцип работы автодокументирования
И последний вопрос — тестирование, которому по-прежнему уделяется мало внимания. Между тем, сохраняет свою актуальность мнение, высказанное в [1]: 1/3 времени проекта должно занимать планирование, 1/6 — написание программ, 1/4 — тестирование компонентов и предварительное системное тестирование, 1/4 — системное тестирование при наличии всех компонентов. В нашей организации имеются планы по использованию средств типа Ghost, TestComplete, систем сбора дефектов (Rational ClearQuest), программ определения утечки памяти, «охват» кода и скоростные параметры функций (Rational Purify, PureCoverage и Quantify), но из-за недооцененности этих проблем тестирования руководством, серьезных инвестиций в данную область пока нет. Одним из показателей зрелости ИТ-компании, как известно, является наличие у нее стандарта тестирования, где представлена функциональная модель тестирования, определены сроки, роли и обязанности участников, изготовлены тестовые классы, подсистемы, скрипты, инструменты, имеется соответствующая документация.

Однако технике RUP присущи и ограничения: «вольность» при трактовке формулировок и концепций, обилие документации и проработка только этапа моделирования бизнес-процессов.


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

Литература

Ф. Брукс. Мифический человеко-месяц. М.: Символ, 2001 Э. Йордан. Путь камикадзе. М.: Лори, 2001 А. Коуберн. Каждому проекту своя методология, TR 99.04, 1999, Oct.

Рис. Три этапа реализации Model-Driven Architecture

Разработка в соответствии с принципами MDA проходит в три этапа (рис.4). На первом создается полностью независимая от среды разработки и платформы визуальная UML-модель, описывающая бизнес-логику будущего приложения (доменная модель). Для ее формирования стандарт OMG MDA предоставляет несколько базовых моделей, описывающих структуру определенной бизнес-среды, например, базовая модель Enterprise Computing с компонентной структурой и взаимодействием на основе транзакций или модель Real-Time Computing с специальными механизмами контроля ресурсов. На следующем этапе абстрактная модель «конкретизируется», преобразуясь в UML-модель приложения для определенной платформы. Модель приложения включает специфические для данной архитектуры элементы построения и интеграции прикладных систем, сохраняя семантику доменной модели. Третий этап завершает трансформацию модели в коды программы. Для автоматизации последовательного преобразования модели от этапа к этапу используются шаблоны, отображающие специфику технологической платформы и языка реализации приложения.

Формирование логики приложения на самом высоком уровне абстракции и автоматическая генерация всех элементов, связанных с платформой реализации приложения способствуют сокращению сроков проектирования, тестирования и развертывания, полностью исключая затраты времени и сил на кодирование. Последнее обстоятельство гарантирует высокое качество кода. Примеры реализации MDA — системы Compuware OptimalJ и Borland ECO.



Определение требований


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

По определению IEEE [2], требование — это «условие или возможность, необходимые пользователю для решения той или иной проблемы или достижения той или иной цели». Управление требованиями определяется аналитиками Meta Group [3] как процесс, гарантирующий, что все специалисты, вовлеченные в проект разработки, знают об определенных требованиях к программному продукту и реализуют процессы, позволяющие эти требования удовлетворить. При всей очевидности того, какое значение имеет четкое задание требований для получения качественного конечного продукта и повышения продуктивности участников разработки, этот этап — и тем более его поддержка с помощью специальных автоматизированных средств — далеко не всегда реализуется со всей необходимой тщательностью. Разработчики часто избегают формализации требований как лишней бюрократической нагрузки, мешающей главному, по их мнению, процессу — собственно программированию. Заказчики также не всегда готовы формализовать и детализировать свои проблемы, полагая, что общей постановки задачи достаточно для того, чтобы разработчики поняли их нужды. Обе стороны заблуждаются. Формальное определение требований со стороны заказчика помогает ему прояснить свои потребности и избежать неясностей в толковании постановки задачи разработчиками. Последние, в свою очередь, получают большую свободу в выборе средств и методов реализации, когда задача понятна до деталей.

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

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

По данным Meta Group, 75% инсталляций систем управления требованиями принадлежит Borland, IBM Rational и Telelogic. При этом все три компании — относительные новички на этом рынке, поскольку решения по управлению требованиями были приобретены ими за последние два года. Так, система CaliberRM стала частью семейства продуктов Borland в результате покупки компании Starbase. В CaliberRM формируются шаблоны для наборов требований заказчика, которые собираются в центральном репозитории. Система предоставляет встроенную поддержку обсуждения требований различными участниками процесса. Права доступа к данным требований, привилегии и ответственность пользователей определяются в системе на ролевой основе.



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

Система обеспечивает экспорт данных в таблицы MS Access и импорт из Word, но пока не поддерживает обмен данными на базе XML Metadata Interchange. Табличное представление требований упрощает их сортировку и задание приоритетов в зависимости от затрат на реализацию и значимости. Для каждого требования реализуется независимый контроль версий. Предоставляются глоссарии для определения специфичных для отрасли, проекта или компании терминов с целью избежать нечеткости определения и двусмысленности толкования требований. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

CaliberRM обеспечивает функциональную (на базе прикладных интерфейсов) интеграцию с другими ALM-решениями Borland — системой конфигурационного управления StarTeam и средой моделирования Together, что позволяет отслеживать влияние изменений в требованиях на исходный код и гарантировать соответствие архитектуры системы задачам заказчика. Интеграция системы со средствами тестирования компании Mercury Interactive обеспечивает быстрый выбор необходимых тестовых испытаний для проверки выполнения заданных и измененных требований, а возможность экспорта данных в систему календарного планирования MS Project — отображение требований как задач проекта.


Разработка


В течение почти всей своей 20-летней истории деятельность Borland была сосредоточена именно на создании сред разработки, причем отличительной чертой этой компании был стабильный нейтралитет в отношении платформ — Borland предлагала инструментарий как для Java (JВuilder), так и для Windows (Delphi, C++Builder). Принципиальная позиция этой «Швейцарии» в мире разработки получила логическое продолжение в выпуске новых систем для платформы .Net.

Основные усилия по совершенствованию сред разработки Borland сосредотачивает сегодня на интеграции с другими этапами жизненного цикла приложений, прежде всего, с решениями по анализу и проектированию Together. Уже упоминалась редакция Together для системы JВuilder, которая обеспечивает разработку компонентных приложений на платформе J2EE. Связь со средствами моделирования программ реализована и в новой среде разработки C#Builder для платформы .Net Framework, которая имеет также возможности интеграции с системами тестирования и средствами развертывания приложений.

C#Builder — среда разработки на языках С# и Visual Basic .Net. Одно из ключевых свойств этой системы — предоставление единого интерфейса для работы с разными базами данных. В C#Builder поддерживаются драйверы доступа к данным из ADO.Net, но их возможности существенно расширены с помощью модуля Borland Data Provider (BDP). Пользователь выполняет все операции с данными и SQL-запросы с помощью общего для всех разновидностей баз данных интерфейса Data Explorer, а BDP осуществляет автоматическое преобразование типов данных .Net в типы для различных баз данных, включая Oracle 9i, IBM DB2, Microsoft SQL Server 2000, Borland InterВase. C#Builder включает широкий спектр технологий, необходимых для работы распределенных приложений: Web-сервисы, компонентные среды СОМ+ и .Net Remoting, а также CORBA и EJB, для которых используются механизмы еще одной новой разработки Borland — системы Janeva.

C#Builder поддерживает новую парадигму разработки, определяемую проектированием (design-driven development), известную также под названием МDA (model-driven architecture). Спецификации MDA разработаны консорциумом OMG [6], а Borland одной из первых реализовала MDA в конкретном инструментарии. Речь идет о системе Enterprise Core Objects (ECO), которая позволяет без программирования получить работающую программу для .Nеt непосредственно по UML-модели, созданной средствами Together или импортированной из другой системы моделирования с помощью механизмов XMI. На C# пишется только пользовательский интерфейс. Усилия разработчиков могут быть сосредоточены на бизнес-логике и ее воплощении в модели, а программу на C# они даже не видят.



Развертывание


У того, кто ведет разработку на Java, есть широкие возможности выбора сервера приложений для развертывания готовой системы, в частности, Borland предлагает сервер приложений Enterprise Server: AppServer Edition для J2ЕЕ-приложений и Web-сервисов; VisiBroker Eition для распределенных приложений в гетерогенной среде, требовательных к времени отклика и ориентированных на инфраструктуру CORBA; Web Edition для Web-приложений.

Для платформы .Net выбор среды развертывания ограничен, и, хотя компьютерный мир все более склоняется к мысли, что война между J2EE и .Net не имеет смысла — каждая из платформ найдет свою нишу применения. Компании, ведущие свой бизнес в сфере финансов или телекоммуникаций, уже сделали значительные инвестиции в приложения на базе J2EE и CORBA, поскольку эти среды гарантируют масштабируемость, безопасность и высокую производительность транзакций. С другой стороны, в тех же организациях может возникнуть интерес к использованию .Net на уровне фронт-офиса. Вполне жизненна ситуация, когда новые приложения для .Net должны внедряться в корпоративную инфраструктуру, давно и успешно использующую технологии J2EE и CORBA. Интеграция двух сред с помощью Web-сервисов не эффективна, если речь идет о компонентах одной прикладной системы, поскольку Web-сервисы больше рассчитаны на взаимодействие слабо связанных приложений и не обеспечивают быстрого и надежного транспорта для передачи данных. Развитие протокола SOAP в сторону обеспечения более высокой производительности и защищенности передачи не изменит его сути, которая не позволяет реализовать на базе Web-сервисов тесную интеграцию, необходимую для многих приложений и поддерживаемую CORBA. Предлагаются и технологии специальных «мостов» между двумя платформами, но для них, как правило, требуются дополнительные аппаратные и программные ресурсы. Кроме того, такие мосты порождают точки потери производительности и отказа системы.

Для Borland отсутствие приверженности отдельно взятой платформе или стеку протоколов — почти религиозный принцип.
Очередной важный шаг на этом пути состоит в выпуске продукта, обеспечивающего прозрачную совместимость приложений для .Net с инфраструктурами J2EE и CORBA. Речь идет о системе Janeva.

Janeva предоставляет клиентским и серверным программам для .NET возможность обращаться к гетерогенным серверным компонентам J2EE и CORBA, причем совершенно прозрачно для разработчика этих программ и не требуя использования дополнительных аппаратных или программных ресурсов (см. рис. 3). Janeva включает компиляторы Java-to-C# и CORBA IDL-to-C#, которые автоматически генерируют коммуникационные элементы — стабы (stubs) и сборки (assemblies) на языке C#. Тем самым обеспечивается возможность обращения к .Net из Java-программ и объектов CORBA. Кроме того, Janeva предоставляет библиотеки времени выполнения, которые вызываются .Net-приложением для преобразования удаленных вызовов этой платформы в вызовы по IIOP (Internet Intеr-ORB Protоcol) — производительному, масштабируемому и защищенному протоколу для связи распределенных компонентов в среде CORBA. Таким образом, пользователь Janeva продолжает работать в привычной среде .Net, используя интерфейсы, процедуры определения свойств и вызова методов и типы данных, и при этом получает доступ к объектам CORBA и компонентам EJB. В результате совместимость двух платформ достигается минимальными усилиями и практически без риска для проекта. Janeva поддерживает Microsoft Common Language Runtime, поэтому может быть использована для любого языка программирования, совместимого с CLR, включая C#, J#, Visual Basic .Net и Visual C++ .Net.





Рис. 3. Интеграция платформ средствами Janeva
В целом, Borland предлагает три основные возможности интеграции для развертывания разнородных систем:

интеграция низкого уровня на базе технологий Janeva; создание модели бизнес-системы и затем разработка компонентов этой системы для разных платформ. Поскольку среда проектирования Together позволяет генерировать исходные тексты программ как на C#, так и на Java, на основе одной UML-модели с помощью средств Together можно создавать прикладные компоненты для разных платформ.


Тестирование и профилирование


Чем позже будут обнаружены ошибки и уязвимые места программы, тем дороже обойдется их исправление, поэтому наиболее оптимальное время разрешения проблем — разработка (рис. 2).

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

Серия соответствующих инструментальных средств появилась в составе пакета поддержки жизненного цикла от Borland в результате покупки компании Optimizeit. В семейство продуктов контроля производительности входят Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace. Первые две системы позволяют до развертывания системы выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и Microsoft .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности с наименьшими затратами. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-приложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.

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

Средства профилирования семейства Borland Optimizeit интегрированы с системой нагрузочного тестирования LoadRunner от Mercury Interactive. Кроме того, в среду разработки JВuilder интегрирован продукт Mercury ТestDirector для управления скриптами тестирования.


В круге разработки


Наталья Дубова

18.09.2003

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

Для удовлетворения общих требований к разработке — снижения затрат путем повышения продуктивности труда разработчиков и уменьшения сложности разработки, не в ущерб качеству конечного продукта — традиционно используются интегрированные среды разработки (integration development environment, IDE), предоставляющие базовые инструменты. Однако за их пределами остаются ключевые этапы жизненного цикла приложений, такие как определение требований, моделирование, тестирование, развертывание и управление изменениями. Поддерживающие эти этапы инструменты, как правило, изолированы друг от друга. В результате группы специалистов, отвечающие за разные задачи в проекте — бизнес-аналитики, архитекторы, программисты, тестировщики — работают разрозненно. Как отмечают в Meta Group [1], подобное состояние вполне соответствует традиционной методологии разработки, когда отдельные процессы идут последовательно друг за другом, но отнюдь не отвечает современным требованиям повышения продуктивности и сокращения затрат. Метод «водопада», как правило, удлиняет время реализации программного проекта, приводит к превышению бюджета и не способствует созданию продукта, отвечающего ожиданиям заказчика. Это своего рода производственный конвейер, рассчитанный на массовый выпуск однотипной продукции.

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

Цикличному ходу разработки больше подходят итеративные методики, подразумевающие постоянное сотрудничество между разными функциональными группами в команде программного проекта и конечными пользователями и тесную взаимосвязь между разными этапами жизненного цикла приложения. Однако для эффективной реализации итеративных принципов нужны интегрированные среды совсем иного качества. Концепцию такой среды предлагает, в частности, компания Borland, которая в результате развития собственных разработок и приобретения целого ряда компаний представила пакет интегрированных систем, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM).



Виды интеграции


Концепцию управления жизненным циклом приложения невозможно реализовать без интеграции инструментальных средств, используемых на разных этапах. Стратегическая задача Borland на ближайшие несколько лет — обеспечить полную прозрачность и отслеживаемость всех процессов разработки в течение жизненного цикла; она решается путем интеграции всех систем в полное ALM-решение [7]. Уже сегодня многие системы Borland имеют развитые возможности взаимосвязи не только друг с другом, но и с системами других поставщиков. Так, совместная работа системы проектирования Together с системой согласования требований CaliberRM позволяет рассматривать в процессе проектирования только те функции, которые предусмотрены на этапе определения требований. Интеграция Together Edition for Jbuilder и IDE Jbuilder обеспечивает непосредственное отображение изменений UML-модели в тексте программы. Аналогичные возможности существуют для среды IBM WebSphere. Система StarTeam управляет этими изменениями, а новые редакции инструментов Borland для платформы .Net позволяют использовать в качестве среды разработки не только C#Builder, но и Visual Studio .Net.

В Borland выделяют три уровня интеграции. Большинство реализованных сегодня возможностей взаимосвязи систем основано на принципах «функциональной» (touch-point) интеграции, которая позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системе проектирования Together и системах разработки C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и подчас приводит к дублированию процессов управления структурой проекта.

Более перспективны высокие уровни интеграции. «Встроенная» (embedded) интеграция обеспечивает работу с окном одной системы, находясь при этом в другой. Например, не выходя из среды разработки Jbuilder можно просматривать графики производительности, которые создает система испытаний Optimizeit. И наконец, самый высокий уровень интеграции — «синергетический» (synergistic), позволяющий прозрачно сочетать функции двух различных продуктов, так чтобы разработчики даже не замечали, что работают с разными системами. Для большинства решений Borland и других поставщиков синергетическая интеграция — дело будущего, однако ее принципы уже реализованы с помощью технологий Janeva. Janeva обеспечивает взаимное конвертирование между платформами J2EE и .Net, так что программные продукты для .Net могут напрямую использовать компоненты на Java, при этом от разработчиков таких приложений не требуется знаний в области объектных технологий CORBA и EJB.



и развертывания приложений, испытавший определенный


По прогнозам IDC [8], рынок средств разработки и развертывания приложений, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой положительной тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу на сделанные инвестиции. Инструментом для достижения этих целей становится использование сред разработки, позволяющих снизить сложность процессов создания программных продуктов, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств — их сквозная интеграция, переход от сред к интегрированным пакетам, объединяющим возможности определения требований, моделирования, разработки, тестирования, управления изменениями и развертывания приложений. В ближайшие годы такие пакеты поддержки жизненного цикла, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам.
Литература
T. Murphy, Accelerating J2EE Application Delivery. Meta Group White Paper, June 2003. IEEE Standard Glossary of Software Engineering Terminology, 1997. T. Murphy, Mastering the requirements of requirements management. Meta Group, April 2003. W. Kernochan, Design-driven development: good only if done well. Aberdeen Group, March 2003. R.C. Gronback, Software remodeling: improving design and implementation management. TogetherSoft, 2002. R. Soley and the OMG Staff Strategy Group, Model Driven Architecture. OMG White Paper, November 2000. Наталья Дубова, Управление жизненным циклом приложений. Интервью с Дэвидом Интерсимоном. // Открытые системы, 2003, № 6. Worldwide application development and deployment forecast summary, 2003-2007.
IDC, March 2003.
В методологии Rational Unified Process (RUP), предложенной компанией Rational Software, определяются пять уровней зрелости управления требованиями:
требования записаны в согласованном формате; требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий; структурированы типы требований: функциональные, бизнес-требования, системные; требования отслеживаются в соответствии с их типом; требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.
Чтобы соответствовать первому уровню, достаточно взять стандартный тестовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие информационные модели в жизненном цикле разработки.

«Живое» программирование


Требования рынка заставляют ускорять циклы разработки, но не позволяют снижать качество. Необходимость делать все быстро подчас вынуждает отказываться от следования строго документированным процессам разработки, однако отсутствие четкой организации труда отрицательно сказывается на продуктивности команды и, в итоге, на конечном результате их работы. Поиск компромисса между сложными формальными процессами и облегченными методами быстрой разработки привел к появлению методологии разработки под названием agile («проворный», «быстрый», «живой»). Принципы данного подхода сформулированы в Agile Manifesto (www.agilemanifesto.org), который был написан в феврале 2001 года семнадцатью представителями ряда «нетрадиционных» направлений в программировании, включая XP [1], Feature Driven Development, Crystal, Adaptive Software Development, SCRUM.

В новом подходе на первый план выходят креативные возможности ярких индивидуальностей в коллективе программистов. При этом стимулируется максимальное использование потенциала совместной разработки в сочетании с минимумом ограничений, накладываемых формальными методами и процессами. Постоянное взаимодействие с заказчиками предпочитается строгому следованию формальным спецификациям, и работа организуется таким образом, чтобы быстро реагировать на изменения в требованиях, а не пунктуально реализовывать изначально заданный план. Процесс создания программного обеспечения по принципам agile должен обладать рядом ключевых характеристик [2].

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

Литература

К. Бек, Экстремальное программирование. // Открытые системы, 2000, № 1-2. R. Miller, The Dynamics of Agile Software Processes. Borland Development Network, February 2003.


Жизненный цикл программного продукта


Рис. 1. Жизненный цикл приложений и его реализация с помощью продуктов Borland

Процесс создания программы включает в себя пять основных этапов (см. рис. 1).

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

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

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

Тестирование и профилирование. Испытания разрабатываемой программы проводятся по мере готовности промежуточных версий. Взаимосвязь этого этапа с этапами проектирования и разработки позволяет подготавливать тесты на основе точных знаний о структуре и тонкостях реализации программы.

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

Цементирует все этапы в жизненном цикле процесс управления изменениями, который обеспечивает координацию действий между членами различных групп единой команды проекта. Здесь применяются системы управления конфигурацией программного обеспечения (software configuration management, SCM), в чьи функции входит централизованное хранение данных по проекту, контроль версий, управление внесением изменений в проект и т.д.



Лирическое вступление


Управление требованиями начинается на самых ранних этапах работы над проектом и не заканчивается даже после его завершения (актом сдачи Заказчику), продолжаясь и далее — на этапе сопровождения.

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

Далее это зародившееся Нечто развивается, разукрашивается для Заказчика-Инвестора, обрастая все новыми и более четко очерченными (опять-таки) требованиями — и вырастает в Ого-го-что, пока не получит "путевку в жизнь" в виде финансирования и четко определенных сроков.

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

Выскочившее из передряг с требованиями, наше детище имеет вид "изрядно общипанного, но непобежденного" Чего-то — готового и даже работающего.

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

…И так до тех пор, пока какое-нибудь новое требование своими убийственными ограничениями не превратит наше детище в Ничто.

Но это — лирика эволюции требований. Пора приступить к физике их структуры и свойств.



Простейший случай диаграмм


Итак, в простейшем случае на диаграмме имеем область всех мыслимых и "немыслимых" требований — наш аналог универсального множества в математике.

В рамках этого универсального множества всех требований выделяем две большие области: область компетенции и состоятельности Заказчика и область компетенции и состоятельности Разработчика.


Рис. 1. Простейший случай диаграммы (вертикальное измерение — уровень компетенции)

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

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

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


Рис. 2. Возможность конструктивного диалога

Другими словами, информационное образование экспертов Заказчика должно позволять им формулировать свои требования пусть на ломаном, но все-таки "человеческом" языке, с одной стороны. А с другой — иметь элементарные представления об автоматизации для необходимой оценки и критики предлагаемых Разработчиком методов.

В свою очередь, опыт аналитиков Разработчика должен достичь такого уровня, чтобы они имели возможность разобраться в плохо структурированных лекциях экспертов Заказчика, состоящих на 80% из изложения частных случаев и исключений, каждый из которых просто "вопиит гласом велиим" о высочайшем уровне и исключительности данного эксперта в его области деятельности.


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



Рис. 3. Возможность полноценного сотрудничества

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



Рис. 4. "Высокие договаривающиеся стороны" принимают решение и проводят две красные черты

Эти две руководящие директивные черты отрезают две небольшие, но очень интересные области:

излишние требования к автоматизации от особо грамотных сотрудников Заказчика; излишняя формализация предметной области от особо рьяных аналитиков Разработчика.

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

Пример для второй области — система автоматического ценообразования для работы дизайнеров или парикмахеров, основанная на эстетических признаках.

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



Рис. 5. Результат встречи "в верхах"

Итак, сроки и бюджет скрупулезно подсчитаны, скорректированы и утверждены на высшем уровне.



Приступаем к воплощению… и с ужасом обнаруживаем: для реализации требования В необходима реализация требований, оставшихся за пределами внимания руководства,— А или C.



Рис. 6. Первые неожиданности: обнаружение новых, не учтенных в документах, но обязательных требований: B или C

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

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



Рис. 7. Область контекста реализации

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

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


В случае же отношений с повременной оплатой все финансовые потери ложатся на плечи руководства Разработчика.

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

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

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

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

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



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

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

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

Существует еще одна область требований, реализация которых необходима для поддержания естественной и полноценной работы системы в соответствии со взаимно понятными и задокументированными требованиями (рис. 8). Изначально, требования из этой области не были замечены аналитиками Разработчика и считались в равной мере как очевидными, так и обязательными, с точки зрения экспертов Заказчика.

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



Рис. 8. Область контекста использования/функционирования

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


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

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

Но вернемся к нашей диаграмме и выделенной там области… и зададимся вопросом: "А почему, собственно, область поддерживающих требований должна иметь именно такой вид?" Почему не так, как на рис. 9?

Другой интересный вопрос: а какой смысл в двух различных подобластях данной области? Чем, по сути, отличаются требования A и C? Но об этом чуть далее.



Рис. 9. Та же область контекста реализации — но при более глубоком рассмотрении

А по перовому вопросу очевидно, что диаграмма на приведенном рисунке является просто проявлением более глубокого подхода и дает более интересные результаты, обсуждение которых следовало бы вынести за пределы данной ознакомительной статьи. Мы же ограничимся упрощенным вариантом (рис. 7) и пойдем далее.

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





Рис. 10. Семантика горизонтального измерения — стандартизация или уникальность разработки

Теперь настало время "показать семантику второго измерения". Проще говоря, ответить на поставленный ранее вопрос: а чем, собственно, отличается левая подобласть от симметричной ей правой? Если для полноценной работы Заказчика в соответствии с требованием E необходима реализация одного из поддерживающих требований D или F (рис. 9), то чем они между собой отличаются и что общего у них с зеркальными им требованиями A и C?

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

И не случайно стрелочка, указывающая стремление использовать стандартные методы, расположена в верхней части, соответствующей стремлениям Разработчика. Именно от него зачастую звучат размашистые предложения в стиле: да, для решения задач такой серьезной и представительной организации, как Заказчик, ну просто необходимы: СУБД — не меньше и не дешевле Oracle 9, CRM-системы — не ниже самого "Сибел-системз", а для решения задач коммуникации без приобретения спутника с антеннами вообще не обойтись.

В ответ на такие предложения со стороны Заказчика активно выдвигаются возражения, что подобная мощь (читай — такие большие расходы) ему абсолютно ни к чему, что вполне достаточно существующей базы и что сотрудники Заказчика успешно справляются со своими задачами чуть ли не с калькулятором и на бумаге …

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


Требования к проекту. Классификация — первый шаг к пониманию


Наталья Чернявская, Юрий Чернявский,

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



Относительно свободная форма изложения, принятая


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

Благодарности


За последние несколько лет я заимствовал и крал идеи у огромного количества замечательных людей. По большей части их имена исчезли в дебрях моей памяти. Впрочем, я еще помню, что перехватил несколько хороших идей у Джошуа Кериевски. Кроме того, я помню, сколько замечательных замечаний получил от Фреда Джорджа (Fred George) и Рона Джеффриза. Не могу не сказать о том потоке идей, которые беспрестанно исходят из Кента и Уорда.

Я всегда испытываю благодарность к людям, которые задают вопросы и находят опечатки. Я поленился заводить длинный список всех тех, кто мне в этом помог, но в этом списке обязательно были бы имена Крэйга Джоунса (Craig Jones), Нигела Торна (Nigel Thorne) и Свена Гортса (Sven Gorts).

© Copyright Martin Fowler, все права защищены

© Copyright , перевод, 2002-2004



Малыш, хочешь быть архитектором, когда вырастешь?


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

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

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

Все это напоминает положение дел с проектированием в целом. Я не думаю, что при использовании методологии ХР исчезает необходимость в умении хорошо проектировать. Более того, именно благодаря основоположникам ХР - Кенту Беку, Бобу Мартину, и конечно же, Уорду Каннингэму - я, в свое время, узнал, что такое настоящее проектирование. Однако сейчас многим может показаться, что эти люди перестали играть роль технических лидеров (в общепринятом понимании).

Для примера можно взять одного из технических лидеров компании "ThoughtWorks", по имени Дэйв Райс (Dave Rice).
Дэйв уже давно работает в компании и заслужил неофициальную мантию технического лидера в проекте, над которым работает около пятидесяти человек. Что же означает его лидерство? В первую очередь, то, что он проводит большую часть времени с программистами. Он помогает тем, кому это необходимо, и старается быть рядом на случай, если его помощь понадобится. Интересно отметить, где располагается его рабочее место. Как заслуженный сотрудник компании, он мог бы выбрать любое помещение по своему желанию. Какое-то время назад он сидел в офисе с Кара (Cara), который отвечал за выпуск системы. Тем не менее, вот уже несколько месяцев, как Дэйв перебрался в комнату к программистам (в том самом стиле "war room", который превозносит ХР). Для него очень важно находиться вместе с разработчиками, потому что в этом случае он знает, что происходит, и всегда может протянуть руку помощи тем, кто находится в затруднении.

Те, кто уже знаком с методологией ХР, поймут, что я описал имеющееся там понятие "тренера" ("coach"). Это еще один пример игры словами, которую так любят в ХР. Технический лидер команды называется "тренером". Подтекст понятен каждому: в ХР лидер учит программистов и помогает им принимать решения. Чтобы быть тренером, нужны не только отличные технические знания, но и хорошие качества человеческой натуры. Как заметил Джек Боллс (Jack Bolles) на конференции ХР 2000, для знатоков-одиночек скоро вообще не останется места. Ключ к успеху - обучение и взаимопомощь.

Позже, на обеде, который состоялся после конференции, Дэйв и я разговаривали с человеком, который критиковал ХР. Мы начали обсуждать все более подробно, и к удивлению, выяснили, насколько похожи наши подходы. Все мы предпочитали адаптивные, итеративные разработки. Все соглашались с важностью тестирования. Мы с Дэйвом никак не могли понять, откуда же тогда такое неприятие ХР? И тут наш оппонент сказал замечательную фразу: "последнее, что я допущу у себя на работе, это чтобы мои программисты делали рефакторинг и совали нос в проектирование".После этого все стало ясно. Итог нашим концептуальным разногласиям подвел Дэйв, когда сказал мне напоследок: "Интересно, зачем брать на работу программистов, если ты им не доверяешь?" В ХР самое ценное, что может сделать опытный разработчик - это передать свои знания младшим коллегам. Вместо архитектора, который один уполномочен принимать все важные решения, у вас есть тренер, который учит, как нужно принимать такие решения. Как говорит Уорд Каннингэм, таким образом опытный разработчик распространяет свои знания, и приносит проекту гораздо больше пользы, чем любой герой-одиночка.


Наращивание архитектуры


Что мы называем архитектурой программного продукта? С моей точки зрения, термин "архитектура" передает идею основных элементов системы, тех ее частей, которые трудно изменить. Они являются фундаментом, на котором можно построить все остальное.

Какую роль играет архитектура в эволюционном проектировании? Критики ХР считают, что эта методология вообще не признает работы над архитектурой, что вся суть ХР - сразу садиться за написание кода, и уповать на то, что рефакторинг решит все проблемы с проектированием. Смешно сказать, но они правы, и, может быть, в этом заключается некоторая слабость ХР. Всем известно, что самые агрессивные приверженцы ХР - Кент Бек (Kent Beck), Рон Джеффриз (Ron Jeffries) и Боб Мартин (Bob Martin) - прикладывают очень много сил, чтобы вообще избежать любого предварительного проектирования архитектуры. Не добавляйте в систему базу данных, пока она вам действительно не понадобилась. Работайте поначалу с файлами, а база данных появится в следующей итерации, в результате рефакторинга.

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

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

Интересно, а если перевернуть все наоборот? Если бы вы вначале решили не использовать EJB, не было бы сложнее в последний момент внести его в систему? Действительно ли не стоит начинать делать систему с EJB, пока вы окончательно не убедитесь, что без этого не обойтись? Этот вопрос затрагивает сразу несколько факторов. Разумеется, работать без такого сложного компонента легче и быстрее. Однако иногда легче что-то выбросить из системы, чем вставить.

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



Нарушает ли рефакторинг принцип YAGNI?


Эта тема сравнительно недавно всплыла в списке рассылки, посвященном XP, и коль скоро мы заговорили о роли проектирования, нам стоит ее обсудить.

Дело в том, что процесс рефакторинга требует времени, но не добавляет новой функциональности. С другой стороны, принцип YAGNI гласит, что надо проектировать только для текущей функциональности, а не для того, что понадобится в будущем. Не сталкиваемся ли мы здесь с противоречием?

Принцип YAGNI состоит в том, чтобы не делать систему более сложной, чем того требует реализация текущих задач. Это является частью практики "Простой дизайн". Рефакторинг же необходим для поддержания системы в максимально простом состоянии. Его нужно проводить сразу же, как только вы обнаружите, что можете что-либо упростить.

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



О метафоре


Ну вот, теперь я могу признаться публично - я до сих пор не могу понять, что же это за штука такая, эта метафора. Я видел, как она работает (в проекте С3 она сработала просто великолепно), однако это вовсе не означает, что я понимаю, как это сделать, не говоря уже о том, чтобы объяснять это другим.

Метафора - одна из практик ХР. Она строится на системе имен, подходе, разработанном Уордом Каннингэмом (Ward Cunningham). Суть этого подхода в том, что вы определяете некий набор имен, которые служат словарем для описания предметной области проекта. В дальнейшем система имен из этого набора служит для именования классов и методов системы.

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

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

Часто критики ХР указывают на то, что для работы над проектом необходима хотя бы приблизительная архитектура системы. На что приверженцы этой методологии отвечают: "Так это и есть метафора". На самом деле, я до сих пор не слышал, чтобы кто-нибудь внятно объяснил, что же это такое, метафора. Мне кажется, что такой пробел все же нужно как-то ликвидировать.



Обратимость решений


На конференции XP 2002 Энрико Цинанотто (Enrico Zaninotto) прочитал интереснейший доклад, в котором указал на связь между гибкими методологиями и "облегченным" процессом производства в промышленности (lean manufacturing). С его точки зрения, одним из основных положений обоих методов является уменьшение сложности процесса путем повышения его обратимости.

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

Стремление к выработке обратимых решений является основной причиной, по которой гибкие методологии настоятельно рекомендуют держать весь код в системах управления исходным кодом (source code control systems). Разумеется, это не гарантирует обратимость решений, особенно если они долгосрочные. Однако это придает команде некоторую уверенность в такой возможности, даже если она используется очень редко.

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

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



Основополагающие практики ХР


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

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

В основе XP лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. Именно это является основным предметом споров вокруг XP. Многие начинают критиковать использование, не разобравшись в том, как его нужно достигать с помощью осуществления. Зачастую тому виной собственный опыт критикующего, который упустил в разработках те практики, которые позволяют осуществлять другие. В результате, раз обжегшись, такие люди при упоминании об ХР и на воду дуют.


У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Непрерывная интеграция необходима для синхронной работы всех разработчиков, так чтобы любой человек мог вносить в систему свои изменения и не беспокоиться об интеграции с остальными членами команды. Взятые вместе, эти две практики могут оказывать существенное влияние на кривую стоимости изменений в программном продукте. Я получил еще одно подтверждение этому в компании "ThoughtWorks". Даже применение всего двух практик, тестирования и непрерывной интеграции, существенно сказалось на результатах. Можно даже усомниться, действительно ли нужно (как это принято считать в ХР) следовать всем практикам, чтобы получить заметный результат.

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

Джим Хайсмит (Jim Highsmith) в своем великолепном изложении методологии XP

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

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


Паттерны и ХР


Пример JUnit постоянно наводит меня на размышление о паттернах. Вообще, отношение, существующее между ХР и паттернами, довольно интересно и часто обсуждается. Так, Джошуа Кериевски считает, что ХР отводит паттернам недопустимо маленькую роль. Его аргументация настолько красноречива, что я воздержусь от пересказа. Однако хочу заметить: многим кажется, что использование паттернов противоречит принципам ХР.

Суть в том, что часто паттерны используются чересчур активно. Известна история о программисте, который, прочитав в первый раз книгу Банды Четырех

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

Согласно одной из существующих теорий, стремясь к простому дизайну, вы придете именно к паттернам. Для некоторых видов рефакторинга это происходит совершенно явно, однако и без рефакторинга, принимая простые проектные решения, вы начинаете использовать паттерны, даже если до этого вы ничего о них не знали. Может быть, это и так, но так уж ли хорош этот путь? Конечно же, лучше заранее представлять себе, с чем вы столкнетесь, и иметь при себе книгу, чтобы не изобретать все самому. Каждый раз, когда я чувствую, что на подходе ситуация, когда можно использовать паттерн, я достаю с полки книгу Банды Четырех. Для меня само словосочетание "эффективный дизайн" свидетельствует о том, что использование паттерна оправдано. В конце концов, назначение паттернов состоит как раз в облегчении создания простого дизайна системы.
Точно так же и Джошуа предлагает уделять больше внимания вопросу, как можно упростить постепенный переход к использованию паттернов. С этой точки зрения, паттерны в ХР используются несколько непривычным образом, однако это совершенно не означает, что при этом их значение как-то принижается.

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

Мои советы тем, кто работает по методологии ХР и использует паттерны:

Не бойтесь потратить время на изучение паттернов

Хорошо подумайте, когда лучше всего применить паттерн (не слишком рано)

Хорошо подумайте, как лучше всего реализовать паттерн в его наипростейшей форме, а уже потом вносите дополнения

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

Мне кажется, что в методологию ХР стоило бы включить отдельным пунктом изучение паттернов. Боюсь, что мне не под силу придумать, как это можно внести в практики ХР, но у Кента это наверняка получится.


Преимущества простого дизайна


В ХР очень популярны два лозунга: "Do the Simplest Thing that Could Possibly Work" ("Ищите самое простое решение, которое может сработать") и YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится"). Оба они олицетворяют собой одну из практик ХР под названием Простой дизайн.

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

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

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

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

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

Такой стиль работы многим кажется абсурдным, и надо сказать, что они правы. Правы при одном условии - абсурд получится, если эту практику начать применять в обычном процессе разработки, а все остальные практики ХР игнорировать. Если же изменить существующий баланс между эволюционным и предварительным проектированием, то YAGNI становится очень полезным принципом (тогда и только тогда).

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


Проектирование это или нет?


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

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

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

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

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



Проектирование предварительное и проектирование эволюционное


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

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

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

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

Такой подход к разработке ПО не нов - им активно пользуется множество людей, начиная с 70 годов. По многим показателям он гораздо лучше, чем эволюционное проектирование в стиле "code and fix", однако и у него есть существенные недостатки. Один из главных недостатков заключается в том, что невозможно заранее продумать все вопросы, с которыми придется столкнуться во время кодирования системы. Таким образом, в ходе работ непременно возникнет ситуация, когда у программистов появятся вопросы относительно спроектированного дизайна. А что, если проектировщики, закончив свою часть работы, уже переключились на другой проект? Тогда программисты начинают самостоятельно решать сложившуюся проблему, отступая от уже принятых проектных решений, и внося при этом в программный продукт долю энтропии.


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

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

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

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



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

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

После всего этого можно подумать, что предварительное проектирование вообще невозможно. Но это не так. Да, есть серьезные трудности. Однако я вовсе не склонен полагать, что предварительное проектирование хуже эволюционного в его обычной манере "code and fix". Сам я предпочитаю предварительное проектирование, но тем не менее, прекрасно представляю себе все сложности, которые с ним связаны и пытаюсь найти новые пути их преодоления.


Проектирования больше нет?


Мартин Фаулер, Chief Scientist, ThoughtWorks

Перевод: , http://maxkir.com/

Original text at martinfowler.com

Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией. Кроме того, в ХР перед проектировщиком ставятся новые трудные задачи, требующие немалого мастерства. Во-первых, это необходимость проектировать максимально простым образом, во-вторых, рефакторинг, и наконец, использование паттернов в эволюционном стиле.

(Эта статья была написана для моего доклада на конференции XP 2000 и опубликована в ее материалах.)

Последнее обновление текста - май 2004 г.

Методология Extreme Programming (XP) бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Для тех, кто всячески чернит ХР, это возврат к разработкам типа "code and fix" ("пишем и правим"). Для приверженцев новой методологии, это отказ от техник проектирования (например, UML), их принципов и паттернов. Незачем беспокоиться о проектировании, считают они. Достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой.

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

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



"Простой дизайн" - что же это за зверь такой?


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

В книге Extreme Programming Explained Кент приводит четыре критерия простой системы. Вот они в порядке убывания важности:

Система успешно проходит все тесты

Код системы ясно раскрывает все изначальные замыслы

В ней отсутствует дублирование кода

Используется минимально возможное количество классов и методов

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

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

В своем докладе на конференции XP 2000, Джош Кериевски (Josh Kerievsky) приводит хороший пример на данную тему. Он подвергает анализу, возможно, самый открытый из всех кодов ХР - JUnit. JUnit использует декораторы (паттерн Decorator), для того, чтобы дополнить тестовые сценарии дополнительным поведением, таким как синхронизация доступа и установка начальных предусловий для групп тестов. Так как подобное поведение реализуется в отдельных классах-декораторах, код тестов становится проще, чем если бы эта функциональность присутствовала в них самих.

Однако в данном случае нужно задать себе вопрос: а понятнее ли будет код, полученный в результате этих операций? С моей точки зрения да, но я-то знаком с паттерном Decorator. Для тех, кто не имеет о нем ясного представления, этот код может показаться довольно сложным.
Аналогично этому, в JUnit используются методы-вставки (pluggable methods), которые, по моим наблюдениям, большинство программистов расценивают как что угодно, но только не как простое и понятное решение. Получается, что структура JUnit является простой для опытных проектировщиков, но сложной для менее опытных программистов?

Я думаю, что одним из самых очевидных и полезных советов, которые только можно дать, это избегать повторов в коде, как провозглашается в ХР ("Once and Only Once") и в книге

Pragmatic Programmer's

(принцип DRY - Don't Repeat Yourself). Следуйте этому принципу, вы уйдете далеко вперед. Но это далеко не все, что необходимо для простого дизайна. А создать простой дизайн - это весьма сложная задача.

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

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


Так что же, проектирования больше нет?


Ни в коем случае. Однако изменилась сама суть проектирования. Проектирование в ХР требует от человека следующих качеств:

Постоянное желание сохранять программный код простым и понятным насколько это только возможно

Навыки рефакторинга, так чтобы вы могли уверенно вносить в систему изменения, как только почувствуете в этом необходимость

Хорошее знание паттернов: рассматривать их не просто как готовые решения, а уметь оценивать их своевременность и использовать постепенно, от простого к сложному.

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

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



UML и XP


Мне задают довольно много вопросов относительно моей приверженности методологии ХР, причем чаще всего люди интересуются - как я могу сочетать ее с верностью UML. Разве они не исключают друг друга?

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

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

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

Вот мои советы тем, кто хочет правильно использовать диаграммы:

Во-первых, пока рисуете диаграмму, не забывайте, для чего вы это делаете. Основное ее достоинство - коммуникация с людьми. Чтобы коммуникация была эффективной, нужно отображать на диаграмме только важные аспекты, не обращая внимания на все второстепенные. Такая избирательность - основа правильной работы с UML.
Не надо отображать на диаграмме каждый класс - только самые важные. У классов не нужно задавать каждый атрибут или операцию - только самые важные. Не надо рисовать диаграммы последовательности для всех вариантов использования и сценариев - ну, и так далее. Самая распространенная проблема с использованием диаграмм это то, что их пытаются сделать максимально всеобъемлющими. Однако самый лучший источник всеобъемлющей информации - это программный код, так как именно его легче всего синхронизировать с кодом. Для диаграммы же всеобъемлимость - враг удобопонятности.

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

они должны быть действительно недолгими

не нужно обсуждать все подробности (только самое важное)

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

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

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



Многие ХР-шники используют CRC-карточки. Это не противоречит UML. Лично я все время задействую некую смесь из CRC и UML, и вообще, пользуюсь любыми техниками, которые облегчают мне выполнение текущей задачи.

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

нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае, они не будут соответствовать программному коду

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

Итак, если вы хотите иметь текущую документацию по проекту, учитывайте все вышеперечисленные проблемы:

Используйте только те диаграммы, которые вы можете поддерживать без особых усилий

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

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

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


Задачи, плохо поддающиеся рефакторингу


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

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

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

Кроме того, всегда стоит учитывать знание проблемы. Если вам уже приходилось несколько раз заниматься локализацией, то вы наверняка будете применять в работе некие паттерны, а значит, у вас больше шансов сделать все правильно с самого начала. Если вы опытный специалист, то, наверное, будет лучше разработать некие предварительные структуры (чего никак нельзя порекомендовать новичкам).
Я бы сказал, что те, кто знает, как это делается, могут сами судить о затратах, которые нужны для выполнения такой задачи. Однако, если вы никогда раньше не занимались такими проблемами, вы не только не можете верно оценить задачу, но и скорее всего, будете допускать ошибки в ее решении. В таком случае, лучше будет внести нужные дополнения в систему позже. Если же вы так и поступили, а теперь испытываете массу трудностей, то поверьте, вам было бы куда тяжелее, начни вы работать над этой задачей с самого начала. Теперь ваша команда уже более опытна, вы лучше понимаете предметную область и требования к системе. Часто, оглядываясь назад, вам будет казаться, что раньше это было бы сделать намного проще. Смею вас уверить, все могло быть гораздо сложнее, если бы начали работать над этим в начале проекта.
Эта проблема связана с вопросом порядка выполнения требований пользователя (user stories). В книге Planning XP
мы с Кентом ясно обозначили наши разногласия. Кент считает, что единственным фактором, определяющим порядок работ над задачами, должна быть их важность для заказчика. Теперь на такую же точке зрения встал и Рон Джеффриз, который раньше придерживался другого мнения. Я, все же, не могу с ними согласиться. Мне кажется, что должен существовать некий баланс между важностью задачи и техническим риском. Так, если использовать наш пример, то я стал бы заниматься локализацией раньше, чем это потребовалось бы, именно чтобы снизить риск. Впрочем, это было бы оправдано, только если локализация должна была бы присутствовать уже в первом выпуске системы. Выпустить программу как можно раньше - одна из жизненно важных задач. Все, что не нужно в первом выпуске, нужно вносить в систему после него. Впечатление, которое производит на заказчика работающий программный код, просто неописуемо. Первый выпуск программы заставляет его сосредоточиться на проекте, повышает уровень доверия к разработчикам, и кроме того, является мощным источником новых сведений. Делайте все от вас зависящее, чтобы этот день наступил как можно быстрее.Даже если вы знаете, что затратите больше усилий, если внесете новую функциональность позже, все равно лучше будет сделать это после первого выпуска системы.
(Недавно опубликованная статья Джима Шо
(Jim Shore) описывает некоторые ситуации, включая добавление в систему локализации и поддержки транзакций. Оказалось, что описанные здесь потенциальные проблемы вовсе не являются непреодолимым барьером).

Желание проектировать


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

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

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

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

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






Главная сайта