Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

Концептуальная основа метода MSF (Microsoft Solutions Framework – каркас решений Microsoft) предполагает координацию групп, тем или иным способом ответственных за процесс разработки. Вместо того чтобы воспроизводить яркие рекламные лозунги, я сосредоточу ваше внимание на отдельных деталях метода – по-моему, они лучше любых сообщений информационных служб и даже лучше научного изложения концепции отражают позицию Microsoft. Согласно выпущенному компанией руководству [116] Solutions Development Discipline Workbook (Redmond, WA: Microsoft Corporation, 1996), pp. 1-17. , предлагаемая методика основывается на «трех китах».

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

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

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

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

Что касается этапов MSF, то здесь группа разработчиков должна принять на вооружение ряд принципов.

1. Видение/рамки. Основное внимание уделяется не требованиям, а рамкам работ.

2. План проекта. Заказчики и участники группы должны договориться о поставках, приоритетах и ожиданиях.

3. Закрытые рамки/Первое применение. Первая бета-версия готового продукта.

4. Выпуск. Продукт или услуга предоставляется рабочей группе и группе поддержки.

Роли в MSF распределяются следующим образом.

1. Руководство продуктом. Особое внимание уделяется оценке продукта с коммерческой точки зрения.

2. Управление программой. Разработка функциональных спецификаций, утверждение и корректировка графика.

3. Разработка. Конструирование продукта (или услуги), соответствующего спецификации и ожиданиям заказчиков.

4. Тестирование. Выявление всех проблем перед выпуском программы.

5. Обучение пользователей. Каждый пользователь должен получать от продукта максимум возможностей.

6. Логистика. Обеспечение беспрепятственных выпуска, установки и миграции.

Все очень складно, не правда ли? На самом деле максимальной продуктивности, вооружившись методикой MSF, можно достичь лишь при наличии достаточно многочисленного персонала, который позволит сформировать группы и исполнять процессы согласно рекомендациям. Преподаватели на курсах утверждают, что метод MSF применяется в самой компании Microsoft. Учитывая характер литературы, выпущенной Microsoft Press за последние 10 лет, полагаю, что это действительно так [117] В первую очередь, я имею в виду работу Jim McCarthy, Dynamics of Software Development (Microsoft Press, 1995). Вероятно, именно в ней впервые сформулированы некоторые основополагающие принципы MSF. .

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

С одной стороны, экстремальное программирование (Extreme Programming, ХР) позиционируется как новаторская методика; с другой – эта методика существует, пожалуй, с тех давних пор, когда в реле находили тараканов [118] Термин «жучок» (bug), очевидно, появился еще в эпоху наиболее древних (до 1950-х годов) компьютеров, в которых реле выходили из строя вследствие попадания в них всякого рода насекомых. . Позвольте пояснить. Основное внимание в ХР уделяется командному программированию с акцентом на код сам по себе. Последний понимается как средство передачи требований и изменений, а также ключ к пониманию задачи программного продукта. Один из ведущих проповедников ХР Кент Бек (Kent Beck) утверждает, что ХР обещает радужные перспективы двум группам заинтересованных лиц:

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

«При помощи ХР заказчики и руководители смогут каждую неделю разработки получать максимальный результат. С регулярностью в несколько недель они будут оценивать конкретный результат работы над решением задач, которые для них наиболее важны. Корректировать направление разработки проекта можно будет в самый разгар трудовой деятельности программистов, причем никаких сверхъестественных затрат на это не потребуется» [119] Kent Beck, Extreme Programming Explained (Reading, MA: Addison-Wesley, 2000), p. xvi. Русский перевод книги доступен на http://lib.rus.ec/b/101297 (прим. сост. FB2) .

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

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