Гарантия квалификации

Скотт Ф. Уилсон, Брюс Мэйплс, Тим Лэндгрейв. «Прин­ципы проектирования и разработки программного обеспечения. Учебный курс MCSD» М.: Издательско-торговый дом «Рус­ская редакция», 2000, ISBN 5-7502-0179-1.

«Учите материальную часть! Бьют больно».
Совет вернувшегося из плена летчика

Эти заметки появились после изучения книги Скотта Ф. Уилсона, Брюса Мэйплса и Тима Лэндгрейва «Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD». Книга добротная, обстоятельная, насыщенная информацией. В ней прекрасным языком и очень наглядно описан фирменный подход к разработке программного обеспечения - Microsoft Solutions Framework (MSF). С учетом того, что это «Официальное пособие Microsoft для самостоятельной подготовки к экзамену 70-100» (обязательный экзамен для получения диплома сертифицированного разработчика программных решений на основе продуктов Microsoft - Microsoft Certified Solution Developer), - книга просто незаменима для желающих получить-таки заветный диплом. Да и вообще, она наверняка окажется полезной для разработчиков, поставивших на продукты этой фирмы.

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

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

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

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

«Допустим, в рамках проекта предполагалось реализовать пять операций за две недели и 10000 долларов. Однако за полторы недели было потрачено 7000 долларов, а реализовано только три функции. Как вы думаете, покажется ли этот проект заказчику успешным? Однако квалифицированный менеджер продукта мог бы ответить: „Был проведен второй этап переговоров, и мы договорились с заказчиком относительно самых важных операций, которые можно реализовать, не превышая финансирования и не выходя из графика. То, что мы обещали, мы выполнили. Сейчас же мы начинаем новый проект, в рамках которого реализуем две оставшиеся функции и еще две дополнительные“». Какое замечательное решение - новый проект (с дополнительным финансированием)! Продолжив эту последовательность, можно заставить заказчика бежать за подвешенной на веревочке морковкой, тем более что копытце уже увязло. Что мы обещали, мы выполнили.

Но что же может стать основой действительно успешного проекта? Прежде всего - глубокое понимание предметной области. Тем более что «несоблюдение всего одного требования способно «провалить» весь проект». И поэтому немного удивляет обсуждаемый на стр. 31 подход «10% охвата по глубине», который обосновывается тем, что написание «полного» проекта потребует тысяч страниц бумаги и он устареет к моменту написания. Да, но только глубокое понимание не измеряется числом страниц! Похоже, здесь происходит подмена понятий. Но смотрим дальше.

«Поэтому при проектировании производственных приложений необходимо тщательно взвесить и сбалансировать множество требований к приложению <…> Не разобравшись во взаимосвязях между этими сложными и часто конфликтующими требованиями, трудно определить, с чего начать. Поэтому прежде всего нужно выбрать способ разработки приложения и метод организации проектных работ, которые позволят наилучшим способом учесть множество требований». А не кажется ли, что начать все-таки стоит с того, чтобы разобраться в этих взаимосвязях? Сразу вспомнилось: «Если в руках молоток, то все вокруг кажется гвоздями». И предлагается побыстрее взять в руки этот молоток: «После выработки подхода и принятия основных проектных решений рекомендуется как можно быстрее начать выпуск версий».

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

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

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

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

Приведенные места из книги, конечно, выхвачены произвольно. Пришлось воспользоваться «10% охватом по глубине». Но и они складываются в красноречивую картинку, не правда ли?

[39354]