1. Прикладная модель строится на основе предоставляемых услуг, побуждая разработчиков рассматривать любое приложение как сеть услуг, в которой характеристики и функциональность можно пакетировать вне зависимости от функциональных границ и в расчете на многократное использование.
2. Итерационная модель процесса жизненного цикла разработки ориентирована на поставки, отталкивается от рисков и включает четыре основных этапа.
3. Используется модель масштабируемой группы разработчиков, состоящей из шести равнозначных ролей.
Не сомневаюсь, что вы с нетерпением ожидаете изложения упомянутых «четырех этапов» и «шести ролей». Сходите на курсы Microsoft – я не хочу рекламировать специалистов Microsoft больше, чем они того заслуживают. Они высказали ряд замечательных идей, которые мне удалось приспособить к своей методологии разработки. Ну ладно – полагаю, у вас не так много времени, чтобы проводить собственные исследования, так что, коль скоро вы купили мою книгу, поговорим о деталях.
Что касается этапов MSF, то здесь группа разработчиков должна принять на вооружение ряд принципов.
Роли в MSF распределяются следующим образом.
Все очень складно, не правда ли? На самом деле максимальной продуктивности, вооружившись методикой MSF, можно достичь лишь при наличии достаточно многочисленного персонала, который позволит сформировать группы и исполнять процессы согласно рекомендациям. Преподаватели на курсах утверждают, что метод MSF применяется в самой компании Microsoft. Учитывая характер литературы, выпущенной Microsoft Press за последние 10 лет, полагаю, что это действительно так[117].
Вам лишь остается выяснить, насколько успешно методология MSF может проявить себя в условиях конкретной группы и компании. Она ведь не ограничивается одной разработкой. В ней предпринимается попытка направить усилия всего предприятия на достижение одной цели – поставки достойного по качеству программного обеспечения. Лично я положительно оцениваю свой опыт применения MSF – правда, этот метод требует адаптации к реалиям корпоративной культуры и корректировки отдельных характеристик рекомендованных групп.
Экстремальное программирование
С одной стороны, экстремальное программирование (Extreme Programming, ХР) позиционируется как новаторская методика; с другой – эта методика существует, пожалуй, с тех давних пор, когда в реле находили тараканов[118]. Позвольте пояснить. Основное внимание в ХР уделяется командному программированию с акцентом на код сам по себе. Последний понимается как средство передачи требований и изменений, а также ключ к пониманию задачи программного продукта. Один из ведущих проповедников ХР Кент Бек (Kent Beck) утверждает, что ХР обещает радужные перспективы двум группам заинтересованных лиц:
«Программистам ХР предоставляет возможность каждый день сосредоточиваться только на тех вопросах, которые действительно важны. Им больше не придется сталкиваться с устрашающими ситуациями один на один. Они смогут проявить свои способности на все сто, направить их всецело на обеспечение качества системы. Им не придется принимать решения в тех областях, в которых они не слишком много понимают, – они могут сосредоточиться на своих прямых обязанностях».