http://habrahabr.ru/post/244003/

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

В 1958 году консалтинговая компания «Booz Allen Hamilton Inc.» совместно с центром разработки «Lockheed Martin Space Systems» и подразделением программных разработок специального проектного центра департамента ВМС США разрабатывают технику оценки и анализа программ (проектов) «Program Evaluation and Review Technique» под кодовым названием PERT — для проекта разработки системы вооружения подводных лодок «Polaris» [1] (баллистические ракеты).

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

Данная методология применялась при подготовке к зимним олимпийским играм 1968 года в Гренобле [2], она же была первая в своем роде, возрождающая подход «Научной организации труда» [3] впервые описанный Тейлором Фредериком Уинслоу в 1911 году, пытавшегося применить науку для инженерии процессов и управления.

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


Рис. 1. Сетевая диаграмма методологии PERT

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

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

В 1970 году выходит в свет публикация доктора Уинстона У. Ройса «Managing the development of large software systems» [4] (управление разработкой крупных программных приложений), в которой он описывает приемы разработки, которые в последующем будут известны как «каскадная модель разработки», также «waterflow» или «водопад». В оригинальной модели предполагается следующая последовательность этапов разработки:

• определение системных требований;
• определение программных требований;
• анализ;
• проектирование;
• разработка;
• тестирование;
• эксплуатация.

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

В 1991 году публикуется книга Джеймса Мартина «Rapid Application Development» (RAD), в которой описывается концепция быстрой разработки программного обеспечения, использующая построение прототипов при минимальном планировании Помимо прочего данную методологию отличает расстановка приоритетов: если каскадная модель отталкивается от функционала, то здесь упор делается на время и затрачиваемые ресурсы. Таким образом, если разработка не критичной части функционала не будет укладываться в сроки, RAD подразумевает отказ от данного функционала. RAD включает следующие этапы разработки:

• планирование – определяются требования;
• пользовательское проектирование – определение функционала;
• конструирование – разработка;
• переключение – внедрение;

В 1993 году компания Microsoft выпускает «Microsoft Solutions Framework» (MSF 1.0), как набор моделей дисциплин, концепций и принципов для создания информационно-технологических решений. В MSF упор делается на следующие ценности [5]:

• соответствие технических и коммерческих целей;
• определение четких целей, распределение ролей и ответственностей;
• реализация итеративного процесса, разделенного на этапы или контрольные точки;
• проактивное управление рисками;
• эффективная реакция на изменение.

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

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

В 1994 году консорциумом из 17 британских компаний на основе концепции быстрой разработки приложений RAD создается фреймворк (от англ. «framework» – каркас) разработки программного обеспечения «Dynamic Systems Development Method» (DSDM). Фреймворк представляет собой набор принципов, предопределённых типов ролей и следующих техник [6]:

• таймбокс,
• принцип назначения приоритетов «MoSCoW»,
• семинары,
• построение прототипов.

Методика таймбоксов является основной техникой DSDM, использующаяся для того, чтобы выполнить проект в срок, уложиться в бюджет и сохранить качество. Таймбокс представляет собой итерацию, в рамках которых проект делится на логичные участки, разнесенные во времени. Таймбоксы не делятся на под события, а функционал не критичен, в следствие чего он может быть частично исключен в целях экономии времени, в порядке, определенном методом расстановки приоритетов «MoSCoW». Метод расстановки приоритетов «MoSCoW» определяет 4 уровня приоритетов:

• должно быть (must have),
• следует чтобы было (should have),
• нужно (could have) и
• можно (want have).

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

В DSDM уделяется особое внимание участию в процессе разработки пользователя (потребителя), что закреплено в принципах, являющихся неотъемлемой частью фреймворка [7]:

• Активное вовлечение пользователей в процесс разработки;
• Команда разработчиков может принимать решения;
• Частая поставка результатов;
• Критерием приемлемости результатов является их соответствие бизнесу;
• Итеративная и инкрементальная разработка;
• Любые действия могут быть отменены;
• Стабильность высокоуровневых требований;
• Тестирование выполняется постоянно и непрерывно;
• Взаимодействие и кооперация.

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

• менеджер проекта – общее руководство;
• провидец – следит за соответствием коммерческим целям и задачам;
• чемпион проекта – распоряжение ресурсами;
• лидер команды – руководит разработчиками;
• технический координатор – архитектура;
• разработчик – разработка;
• тестировщик – тестирование;
• представительный пользователь – представляет интересы потребителей;
• пользователь консультант – консультирует по вопросам использования продукта;
• секретарь – отвечает за протоколирование;
• посредник – отвечает за взаимодействие между членами комманды;

Последняя версия методологии, вышедшая в 2007 году и именуемая DSDM Atern, предполагает следующие 7 этапов жизненного цикла проекта:

1. Пре-проект. На первом этапе жизненного цикла проекта определяется целесообразность проекта и помимо прочего допускается выпуск акта об инициации проекта.
2. Осуществимость. На данном этапе определяется технико-экономическая возможность реализации проекта, в том числе возможность эффективного достижения целей бизнеса.
3. Определение бизнес процессов – подразумевает определение требований, стратегии, архитектуры, используемых стандартов и возможных рисков сопутствующих процессу реализации проекта.
4. Разведка. На данном этапе предполагается построение бизнес-прототипов и формирование списка функциональных требований.
5. Инжиниринг. Проектно-конструкторские изыскания направленные на решение нефункциональных требований (например, производительности, безопасности, возможностей поддержки и сопровождения). В том числе реализация всех требований для успешной работы продукта.
6. Развертывание – подразумевает цикл работ для предоставления продукта конечному потребителю, обучение и написание документации. Также выявляется соответствует ли продукт всем установленным бизнес требованиями.
7. Пост-проект. На данном этапе подводятся итоги и оценивается эффективность принятых решений, рекомендуется делать это спустя 3-6 месяцев чтобы обладать большим количеством информации о результатах работы проекта.

В 1995 году на ежегодной практической конференции «Объектно-ориентированное программирование, системы, языки и приложения» (OOPSLA) проводимой «Ассоциацией вычислительной техники» доктор Джефф Сазерленд и Кен Швабер представили методологию под названием «Scrum» [8]. Впервые подход был описан учеными Hirotaka Takeuchi и Ikujiro Nonaka в 1986 году, как гибкая, целостная, стратегия развития продукта, где команда разработчиков работает как единое целое, для достижения общей цели, в противопоставление традиционному, последовательного подходу [9].

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

• команда;
• мероприятия;
• артефакты.

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

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

В 1997 году выходит статья «MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT» [11] Джима Хигсмита, в которой он описывает адаптивную методологию разработки программного (Adaptive software development, сокращенно ASD). Ключевой особенностью данной методологии является новый взгляд на отношение к требованиям и проекту, подразумевается возможность их постоянного изменения, к чему она и стремиться адаптироваться. Превалирующий классический жизненный цикл проекта: планирование-проектирование-конструирование здесь модифицирован и представлен последовательностью: обдумывание-взаимодействие-обучение (speculate-collaborate-learn).

В 1999 году выходит книга «Extreme Programming Explained: Embrace Change» [12], описывающая методологию экстремального программирования, авторами которой являются Кент Бек, Уорд Каннингем и Мартин Фаулер. Экстремальное программирование как и ASD ориентируется на постоянное изменение требований и предлагает 12 методик способствующих эффективному процессу разработки в подобных условиях:

• Игра в планирование (planning game) – быстрое создание приблизительного плана работы и его постоянное обновление;
• Небольшие версии (small releases) – частый выпуск небольших версий продукта;
• Метафора (metaphor) – краткое описание работы системы;
• Простой дизайн (simple design) – применительно к архитектуре;
• Тестирование (testing) – стоит отметить что данная методика в дальнейшем выделилась в отдельную методологию разработки именуемую «Test Driving Development» (TDD);
• Переработка (refactoring);
• Парное программирование (pair programming) – одновременное участие в работе над задачей двух разработчиков;
• Коллективное владение кодом (collective ownership);
• Непрерывная интеграция (continuous integration) – частое внедрение разработок;
• 40-часовая неделя (40-hour week);
• Заказчик на месте разработки (on-site customer);
• Стандарты кодирования (coding standards).

В 2001 году в США, штате Юта, подписывается манифест гибкой методологии разработки программного обеспечения «Agile Manifesto», Agile представляет собой семейство методологий разработки в которое вошли такие как: экстремальное программирование, SCRUM, DSDM, ASD, мало известная методология Crystal, FDD, Pragmatic Programming и прочие. Agile определяет 12 принципов, которых стоит придерживаться [13]:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, обеспечиваемой посредством регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

В том же 2001 году выходит методология разработки от компании IBM, называющаяся Rational Unified Process (RUP), которая описывает как эффективно использовать коммерчески проверенные подходы к разработке программного обеспечения. RUP обеспечивает членов команды руководящими принципами, шаблонами и инструментальными наставлениями, необходимыми для всей команды, чтобы в полной мере воспользоваться следующими практиками:

• Разрабатывайте программное обеспечение итеративно;
• Управляйте требованиями;
• Используйте компонентную архитектуру;
• Визуализируйте модель программы;
• Проверяйте качество программы;
• Контролируйте изменения программы.

Рис. 2. Рабочие процессы RUP

Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 2., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:

• Бизнес моделирование (Business Modeling);
• Требования (Requirements);
• Анализ и дизайн (Analysis & Design);
• Реализация (Implementation);
• Тестирование (Test);
• Развертывание (Deployment);
• Управление проектами (Project Management);
• Конфигурация и изменение (Configuration & Change);
• Управление (Management);
• Среда (Environment).

К самым последним новшествам в области методологий разработки программного обеспечения можно отнести вышедшую в 2006 году книгу компании 37signals «Getting Real» [14], в которой описывается одноименная методология, всецело направленная на минимизацию каких либо бюрократических издержек, вроде составления спецификации или штатного расписания. В данном подходе к разработке рекомендуется начинать разработку с дизайна интерфейса, затем переходить к самому интерфейсу и уже в конце к программированию. Таким образом, подразумевается в кратчайшие сроки выпустить минимальную версию продукта и развивать ее, что в наибольшей степени подходит для веб проектов.

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

• Управление приоритетами;
• Управление коммуникациями;
• Управление персоналом;
• Управление ценообразованием;
• Продвижение;
• Поддержка.

Заключение

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

В области развития методологий управления информационными проектами были изучены самые ранние, среди которых представлены такие, как PERT, которая, впрочем, является универсальной методологией управления проектами, где время является критическим показателем, и применялась в том числе для организации зимних олимпийских игр 1968 года. Рассмотрена итеративная модель жизненного цикла проекта представленная Уинстоном У. Ройсом, описаны такие популярные методологии проектами, как RAD, MSF, DSDM, Скрам, ASD, Экстремальное программирование, RUP. Представлен обзор принципов манифеста гибкой разработки Agile и особенностей самой последней методологии разработки Getting Real от 37signals.

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

Список литературы

1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (№ 2), 1959, С. 10.
2. Официальный доклад международного олимпийского комитета по результатам проведения зимних олимпийских игр в Гренобле, 1968, С. 49
3. Taylor F.W., The Principles of Scientific Management, New York, NY, USA and London, UK: Harper & Brothers, – LCCN 11010339, OCLC 233134
4. Royce W.W., Managing The Development Of Large Software Systems // Reprinted from Proceedings, IEEE WESCON, August 1970, pages 1-9. Copyright©1970 by The Institute of Electrical and Electronics Engineers, Inc. Originally published by TRW.
5. Обзор Microsoft Solutions Framework (MSF) [Интернет ресурс] / Microsoft Developer Network – Режим доступа: msdn.microsoft.com/ru-ru/library/jj161047.aspx (дата обращения: 03.11.2014).
6. DSDM Atern Handbook [Интернет ресурс] / DSDM Consortium – Режим доступа: www.dsdm.org/dig-deeper/book/dsdm-atern-handbook (дата обращения: 03.11.2014).
7. Шопырин Д.Г., Управление проектами разработки ПО: Учебно-методическое пособие по дисциплине «Гибкие технологии разработки программного обеспечения», СПб: СПбГУ ИТМО, 2007. – 131 с.
8. Sutherland J.V., Business object design and implementation / Sutherland J.V. Schwaber K. // OOPSLA '95 Workshop Proceedings, The University of Michigan, 1995, – 118 c.
9. Takeuchi H., New New Product Development Game [Интернет источник] / Takeuchi H., Nonaka I. // Harvard Business Review, 1986 – Режим доступа: hbr.org/1986/01/the-new-new-product-development-game/ar/1 (дата обращения: 03.11.2014).
10. Исчерпывающее руководство по Скраму: Правила Игры [Интернет Источник] / Scrum.org – Режим доступа: www.scrum.org/scrum-guide (дата обращения: 03.11.2014).
11. Highsmith J.M., Exciting, And Anxiety-Ridden: Adaptive Software Development // American Programmer, Volume X (№1), 1997 – Электронный ресурс: www.adaptivesd.com/articles/messy.htm (дата обращения: 03.11.2014).
12. Beck K., Extreme Programming Explained: Embrace Change. US: Addison-Wesley Professional, 2005. – 224 c. – ISBN-10: 0201616416
13. Основополагающие принципы Agile-манифеста [Интернет источник] / Beck K., Beedle M., Arie van Bennekum, Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., C. Martin R.C., Mellor S., Schwaber K., Sutherland J., Thomas D. – Режим доступа: agilemanifesto.org/iso/ru/principles.html (дата обращения: 03.11.2014).
14. Getting Real [Интернет источник] / 37signals, 2014 – Режим доступа: gettingreal.37signals.com (дата обращения: 03.11.2014).