Страсти вокруг MCSD

В номере 16 (393) была опубликована статья Сергея Козлова - рецензия на книгу "Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD" - официальное пособие Microsoft для самостоятельной подготовки к экзамену 70-100, обязательному для сдачи кандидату на сертификацию MCSD. (Публикуется полная версия материала)

В номере 16 (393) была опубликована статья Сергея Козлова - рецензия на книгу "Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD" - официальное пособие Microsoft для самостоятельной подготовки к экзамену 70-100, обязательному для сдачи кандидату на сертификацию MCSD.

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

В книге же рассматривается: 1) технология разработки (approach) Microsoft Solution Framework (MSF), 2) применение MSF на практике, 3) понемногу отовсюду - какие средства в каких случаях Microsoft советует применять.

Меня крайне порадовало, что в такой учебник авторы не поленились встроить "почти реальную историю" - историю разработки некоего программного продукта для внутреннего использования. Это самый большой case-study, который я вообще когда-либо видел ;-).

Книга на 80% посвящена технологии разработки Microsoft Solution Framework (MSF), созданной Microsoft для создания продуктов под конкретного заказчика. Хотя, надо сказать, эти же подходы прекрасно работают и при создании коробочного продукта.

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

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

Так вот. Технология MSF предлагает методы, которыми можно снизить вероятность провала проекта.

Вкратце, предлагаемые методы таковы:

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

2. Разбить работу над проектом на пересекающиеся фазы анализа, планирования, разработки и стабилизации (внедрения), далее по спирали.

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

4. Работать над историей развития проекта (компилировать исполняемые файлы только из исходников, хранящихся в системе контроля версий, анализировать риски и предпринятые ранее действия по уходу от рисков, повторные бизнес анализы, ...)

Тезисы все знакомые, но реализация тезисов может быть весьма нетривиальной. Что в книге хорошо показано на примерах.

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

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

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

Каждый раз, когда я читаю западный учебник по управлению (а данная книга как раз этот случай, ведь MSF - управленческая технология), я сомневаюсь в изложенных методиках. Действительно, я еще не видел ни одной западной книжки, в которой бы рассматривалась ситуация, когда нужного товара нет не только у твоего поставщика, но и вообще во всей стране, потому что грузы через таможню не пропускают ;-). А ведь в такой ситуации никакой самый продвинутая SCM система (supply chain management) не поможет, потому что в цепочке "поставщик-потребитель" образовался затык, который невозможно предугадать и с которым невозможно бороться исключительно рассматриваемыми в западных учебниках средствами.

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

Оказывается, знают. Жадность интернациональна ;-)

Мое мнение - все описано очень разумно.

Исходя из личного опыта - в основном применимо. При этом заказчиком является отдел маркетинга. Если такого отдела нет - это проблема уже другого плана ;-)

Сам сертификационный экзамен Microsoft 70-100 не похож на другие экзамены и состоит из нескольких секций case study (дается проблема - надо построить схему БД или нарисовать потоки данных или дать рекомендации) + вопросы по разным темам, в том числе и не затрагиваемым в учебнике вообще. Case study, естественно, не локализованы и затрагиваемые в них проблемы и предлагаемые средства страшно далеки от обычного российского разработчика. Здесь учебник будет полезен хотя бы с точки зрения осознания, чем в США дышит бизнес, если из другого источника такого знания не почерпнуть.

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

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

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

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

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

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

Рынок разработки информационных систем для крупных предприятий у нас в основном занимают команды, работающие с западным софтом. А почему? Не потому, что в таких системах встроены все бизнес-процессы предприятия (на Западе о многих наших бизнес-схемах даже не догадываются), а потому, что отлажены технологии внедрения и доработки. Российских же комплексных информационных систем, разработанных с точки зрения удобства для внедрения у заказчика - единицы.

Резюме

Коллеги-программисты! Не пытайтесь конкурировать по качеству разработки компонент с Microsoft, который вбухал в разработку $4 миллиарда в прошлом году! Попытайтесь сконцентрироваться на процессе разработки софта с точки зрения эффективности его внедрения, а не с точки зрения увеличения эффективности низкоуровневых компонент.

Не изобретайте велосипед. Постройте систему управления качеством разработки в вашей компании на основе любого подхода, не обязательно MSF. И к Вам придут проекты, в которых надо освоить $10K за 2 недели.

[i40046]