Какие есть методологии

Ещё раз про семь основных методологий разработки

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

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

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.

Модель быстрой разработки приложений включает следующие фазы:

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

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

5. «Agile Model» (гибкая методология разработки)

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

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

Когда использовать Agile?

• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

6. «Iterative Model» (итеративная или итерационная модель)

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

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

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

Когда оптимально использовать итеративную модель?

• Требования к конечной системе заранее четко определены и понятны.
• Проект большой или очень большой.
• Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

Модели и методологии разработки ПО

Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

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

Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

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

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

• Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
• Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.

V-образная модель (разработка через тестирование)

Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

• Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.
• Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

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

Преимущества итеративной модели

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

Недостатки итеративной модели

• Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
• Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

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

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

• Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.

В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!

Какие методологии управления проектами лучше использовать? Как выбрать подходящую методологию для вашего проекта?

Анна Захарченко, консультант проектного управления и администратор проектного офиса Ключевых Решений.

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

Согласно опросу Hubstaff от 2021 года, 39% компаний, опрошенных в 2021 году, заявили, что их организация внедрила гибридные методы управления проектами.

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

Давайте разберемся, что такое стандарты и методологии? Стандарт, в частности PMBоK, является сводом знаний, который служит для создания методологии, то есть он не является пошаговой инструкцией «как выполнить проект», в нем указывается процесс управления проектами с входами и выходами.

Методология представляет набор принципов, инструментов и методов, и эти принципы, инструменты и методы используются для планирования, выполнения и управления проектами.

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

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

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

Рассмотрим простой пример описания процесса «разработки плана управления проектом» из PMBoK 6-е издание:

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

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

Самыми известными международными стандартами и методологиями по управлению проектами являются ISO 21500, C-PMBOK, APMBOK, которые в свою очередь ориентированы на PMBoK PMI (США), также известны и применяются во всем мире PRINCE2, P2M, ICB IPMA – эти методологии используют собственные подходы и никак не ориентируются на стандарт PMBoK.

Рис.1. Мировые стандарты и методологии управления проектами

В статье мы вместе рассмотрим, когда лучше использовать наиболее популярные подходы к управлению проектами и сравним PMBoK, PRINCE2 и гибкий фреймворк Scrum.

1. Начать хотела бы с наиболее распространенного и универсального стандарта PMBoK. Первое издание PMBoK было опубликовано в 1987г. для управления проектами оборонной и космической промышленности США, стандарт описан более, чем на 700 страницах.

PMBоK относится к пяти этапам процесса управления проектом: инициализация, планирование, исполнение, контроль и завершение. Он содержит множество процессов и методов управления проектами, с помощью которых можно оценить или завершить то, как вы управляете своими проектами, или используемую вами методологию.

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

Но! Хочу отметить, что PMBоK предусматривает большое количество процессов, в 6-м издании их 49, эти процессы не всегда подходят для конкретной компании и на практике не все можно адаптировать под конкретную отрасль, также стандарт ориентирован на крупные проекты.

Рис.2. Группы процессов управления проектом по стандарту PMBоK6.

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

На данный момент PMI (Институт проектного управления) выпустил 7 изданий стандарта. Последний свод знаний по управлению проектами (PMBoK 7-го издания) имеет значительные отличия от предыдущих версий и ориентирован на гибкость к управлению, ценность, переход от процессов к принципам и от областей знаний к доменам исполнения.

2. Перейдем к рассмотрению методологии PRINCE2, первая редакция которого вышла в 1989 г. и была ориентирована на управление проектами по созданию IT в государственном секторе. PRINCE2 является процессно-ориентированной методологией, разделяющей проекты на несколько этапов, каждый со своими собственными планами и процессами. Методология определяет входы и выходы для каждого этапа проекта, чтобы ничего не оставалось на волю случая.

Рис.3. Процессы методологии PRINCE2.

Когда использовать: если у вас большой и неоднозначный проект, ведь PRINCE2 редко подходит для мелких проектов, прежде всего он предназначен и используется во всех правительственных учреждениях Великобритании и ООН. PRNCE2 достаточно гибкий и легко адаптируется под особенности организации, предполагает четкое распределение обязанностей между командой проекта, акцентирует внимание на постоянном совершенствовании и фиксации опыта команды.

Но! В описании PRINCE2 отсутствуют отраслевые практики и конкретные инструменты для работы в проекте; плохо раскрывает навыки «soft management», ориентирован на крупные компании.

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

3. Перейдем к рассмотрению более гибких методологий, за основу возьмем SCRUM, который представляет собой короткий «спринтерский» подход, он считается самым структурированным и наиболее популярным из гибких методов Agile. Сразу поясню, что Agile не является методологией, так как он, в первую очередь, включает особые подходы к производству и управлению проектами, и предполагает более гибкие подходы, именно поэтому мы рассматриваем Scrum.

Scrum популярен тем, что сочетает в себе элементы классического процесса и идеи гибкого подхода. В итоге чего и получилось сбалансированное сочетание структурированности и гибкости.

Особенность Scrum в том, что он разбивает ваш проект на части, своеобразные результаты, которые сразу могут быть использованы для получения ценности, которые называются product backlog.

Рис.4. Процесс методологии Scrum.

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

Работа делится на «спринты», цикл разработки обычно длится 2-4 недели, в течение которых проходят ежедневные «Scrums», на которых команда сообщает о прогрессе и препятствиях.

Но! Важно отметить, что методология предъявляет высокие требования к команде проекта, которая должна быть кроссфункциональной и иметь определенную степень зрелости и сработанности; предполагает необходимость активной вовлеченности клиента в процесс разработки и учета особенности создаваемого продукта. И, в отличие от PMBoK, не подходит для проектов, требующих точное планирование и последовательность выполнения (пример, Строительство дома).

Сравним рассмотренные методологии между собой:

Но какая методология подходит именно Вам? Как же выбрать правильную методологию управления Вашими проектами?

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

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

1. Сперва необходимо рассмотреть факторы вашего проекта по их простоте или сложности. Например, начать с клиента, доступных ресурсов и ограничений проекта (склонность к изменениям и риску), сроков, инструментов и людей. Перечислите эти факторы и обозначьте их в соответствии с их простотой или сложностью.
2. Определить жесткость или гибкость работы в проекте. Если вы работаете в среде, где есть стремление к развитию и изменениям, гибкие методологии подойдут вам больше. Если работаете с фиксированными требованиями, сроками и бюджетом, то вам лучше использовать стандарт PMBoK.
3. Затем стоит разобраться в том, какую задачу нужно решить. Лучше та методология, которая ведет вас к вашим стратегическим целям самым непосредственным образом, с наибольшей выгодой и наименьшим негативным воздействием.
4. Объективно определите размер компании и команды — они имеют весомое и решающее значение при выборе методологии.
5. При применении конкретного подхода или метода, применяйте его, но адаптируйте под особенности именно вашей компании.

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

Предпочитаете ли вы гибкие методологии, как Scrum, который в большей степени подходят для управления IТ-проектами или более традиционное и классическое управление проектами, как издания PMBoK, чаще используемые в строительстве и производстве – для каждой команды найдется своя методология управления проектами.

Но независимо от того, какую методологию вы выберете, вам нужен удобный, гибкий и простой в использовании инструмент управления проектами, который будет поддерживать вас на каждом этапе жизненного цикла проекта.

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

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

Вам может понравится прочитать и эти материалы

Методологии управления проектами: 10 эффективных методик

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

Что такое методологии проектного управления

Методология — это совокупность методов, принципов и подходов, используемых при ведении проекта. Обычно разработкой этих инструкций и нормативов занимается project manager или руководитель компании, филиала, отдела. Это выработанные и закрепленные письменно стандарты, которые предписывают, как управлять проектом на каждой стадии от его запуска до завершения. Обычно они включают:

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

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

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

В зависимости от количества участников может быть выбран более или менее обширный тип управления проектами. Например, для сотрудничества заказчика напрямую с небольшой командой часто применяются онлайн-доски с задачами: Kaiten, Trello, Аспро.Agile или Jira, их функционала бывает достаточно. Но вот для командной работы крупной компании этого явно не хватит, в больших организациях чаще пользуются более комплексными системами, например, Аспро.Cloud. Иначе сотрудники разных отделов будут вести работы в разных сервисах, и взаимодействие будет затруднительным.

Что можно понимать под проектом? Как крупную работу над одним продуктом или услугой, IT-разработкой, рекламной кампанией, так и конкретную задачу, поставленную руководителем.

Задачи использования методик управления проектами

Существует Международная ассоциация управления проектами (IPMA). По ее исследованиям методологии проектного менеджмента и использование современных инструментов позволяет сэкономить 20-30% временных ресурсов и до 15-20% финансовых. В России эти показатели ниже, но если принять во внимание рост экономики, доли малого и среднего бизнеса, то можно предположить увеличение эффективности использования инструментов и методов ведения проектов. Это можно назвать глобальной целью. Ею обусловлен ряд задач:

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

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

Какие бывают методологии управления проектами: 10 видов

Существуют десятки методов, которые активно применяют менеджеры проектов. Они отличаются сложностью, функционалом, количеством используемых инструментов. Выбор методологического подхода зависит, в первую очередь, от формы организации и сферы деятельности компании. Мы кратко расскажем про методы управления проектами, востребованные в ИТ и Digital, их особенности.

1. Waterfall (Водопад или Каскад)

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

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

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

Такая концепция хорошо показала себя на массовом производстве, например, когда нужно разработать продукт и вывести его на рынок. А вот для IT-проектов такая методология управления не подходит, так как сфера требует большей гибкости.

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

• отсутствие гибкости и адаптивности, если появятся непредвиденные обстоятельства, планирование нужно начинать с начала;
• нельзя вести большой объем работ параллельно, следует придерживаться принципа последовательности;
• результат виден только в самом конце.

2. Agile

Это наиболее современная методология управления проектами в ИТ, она была создана именно для компаний, связанных с информационными технологиями, в 2001 году. Но сейчас эта методика применяется в других сферах и ценится благодаря своей гибкости.

По сути это не методология, а определенные принципы работы:

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

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

Часто Agile используется вместе с другими системами и инструментами, она как бы дополняет своими принципами общую стратегию проектного управления.

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

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

Подробнее отличия Agile и Waterfall мы разобрали в другой статье.

3. Гибридная методология

Она включает все преимущества Waterfall и Agile — подробное планирование в сочетании с высокой адаптивностью. Проект ведется циклами, но сами они имеют достаточно четкую каскадную структуру и сроки.

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

• нельзя внести сильные изменения и сорвать сроки без нарушения общего плана;
• более сложная система отчетности, чем в Waterfall.

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

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

Шаблоны ТЗ

Собрали для вас шаблоны ТЗ для разных сфер бизнеса. Получите их на свою почту вместе с примерами заполнения.

4. Critical Path Method

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

• подробное и наглядное планирование;
• четкая расстановка приоритетов;
• снижение рисков: наиболее приоритетные задачи выполняются первыми, поэтому вы точно знаете, что на них хватит времени и других ресурсов.

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

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

5. Critical Chain Project Management

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

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

• не удобно вести учет ресурсов, если сотрудники одновременно работают над несколькими проектами.

6. Kanban

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

Это очень удобный инструмент, который может использоваться изолированно, а может быть встроен в большую CRM-систему. Например, доска kanban есть внутри Аспро.Cloud. С ее помощью можно вести работу над проектом всей командой удаленно.

• хорошая визуализация процесса;
• легко увидеть загруженность каждого сотрудника;
• простая структура.

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

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

7. Scrum

Scrum похож по концепции на Agile. Но если Agile — это больше про принципы работы, то Scrum больше про конкретные методы и инструменты. Можно сказать, что это более практичный подход к философии гибкого менеджмента. При сравнении этих методологий управления проектами можно отметить, что Scrum используется самостоятельно, этот метод самодостаточен. В то время как Agile требует дополнительных инструментов.

Это отличная система для хорошо мотивированной команды. Обычно над ней стоит руководитель — тимлид, Scrum-мастер. Он руководит процессом, отслеживает результаты, проводит совещания, на которых озвучивает текущие цели спринтов. Спринты — это короткие циклы, на которые поделены все проектные задачи.

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

• нет четкого планирования, из-за чего проект может расширяться, требовать большего расхода ресурсов;
• наиболее оптимально подходит для небольших команд до 10 человек;
• высокая значимость каждого сотрудника, становится сложно адаптироваться при уходе одного из них.

Scrum используется как основная методология в таск-трекере Аспро.Agile. Она отлично подходит разработчикам ПО, Digital-агентствам и другим творческим проектам, которые требуют гибкого подхода.

Что выбрать: Scrum или Kanban

Поможет определиться короткий тест. Ответьте на 7 вопросов, чтобы подобрать методологию для своей команды.

8. Scrumban

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

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

• ограниченное количество участников;
• сложность долгосрочного планирования.

9. PRINCE2

Еще один основной вид методов управления проектами, разработанный в Великобритании. Он построен на основе каскадной системы, в которой каждый этап строится по четким принципам:

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

Метод часто применяется для крупных IT компаний. Выделяется 7 процессов управления проектом:

1. Запуск.
2. Руководство.
3. Инициация проекта.
4. Контроль этапов.
5. Создание продукта.
6. Управление границами этапов – временем.
7. Закрытие проекта.

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

• использование методологии в небольшой компании может привести к тому, что задачи будут требовать большего времени и сил, чем это требуется на самом деле;
• низкая адаптивность к изменениям.

10. Экстремальное программирование

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

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

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

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

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

Мы представили все основные методологии управления проектами, но ими не ограничивается менеджмент организаций. В реальной ситуации часто бывает сложно придерживаться одной выбранной изначально системы. Некоторые фирмы совмещают несколько разных приемов. Другие пробуют и перебирают, пока не найдут оптимальную именно для их бизнеса. Третьи — используют за основу готовые CRM-системы со встроенными инструментами для проектного менеджмента.

Как выбрать методологию управления проектом?

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

• сферу деятельности. У вас налаженный производственный процесс или нестандартные задачи? Насколько часто в проекты вносятся коррективы, правки, что может повлиять на планы? Для IT компаний выбирайте более гибкие системы, для многоступенчатого производства подойдут жесткие;
• приоритеты компании. Есть фирмы, которые строго нацелены на результат. Другие отличаются вниманием к сотрудникам, их комфорту. Для вторых, например, подойдут принципы Agile, гласящие, что личность всегда важнее проекта;
• распределение ролей в команде. Насколько важна специализация каждого сотрудника? Может ли один отдел выполнять параллельно несколько этапов или важна последовательность, так как каждый должен быть занят исключительно своей задачей;
• сложность проектов. Оцените, сколько этапов в каждой задаче, какое время в среднем на них уходит, а также какое количество людей задействованы в их реализации. Для очень крупных проектов редко подходят простые инструменты вроде kanban, зато для небольших циклов их функционала более чем достаточно;
• размер компании, количество заинтересованных сторон. Есть методы, которые подходят только для крупных организаций, например, PRINCE2. С другой стороны, есть методологии, которые отвечают потребностям небольших команд — Scrumban или Scrum.

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

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