Ниже приводятся краткие описания различных подходов для управления проектами применительно к ИТ сфере (ИТ - информационные технологии).

 

Водопадная (каскадная) модель (еще называют классической моделью)

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

 

Характеристики водопадной (классической) модели

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

•       Исчерпывающее предварительное планирование

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

•       Управление проекта производится обычно сверху-вниз (от менеджера проекта и далее), конечную ответственность несет МП

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

•       Необходимо уделять большое внимание контролю проекта

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

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

•       Нет проблем с доступностью программистов нужной квалификации.

•       В относительно небольших проектах.

Один из примеров проекта: Автообновление службы Windows через AWS для бедных - здесь. 

 

Более подробнее (для ИТ проектов) - здесь.  

 

V-Model

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

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

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

•       Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.

•       Для малых и средних проектов, где требования четко определены и фиксированы.

•       В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

 

Более подробнее - здесь.

RUP (Rational Unified Process)

Что в RUP было нового по сравнению с каскадной моделью?       

В первую очередь, это итерации. Кроме того, этот процесс был инкрементальный. То есть в конце каждой итерации надо было получить существенный прирост к продукту - инкремент. Как результат, каждая итерация выдавала какой-то существенный результат (в каскадной модели результат получали только в конце). Именно в RUP были сформулированы так называемые пользовательские сценарии и вовсю пропагандировалось описание требований в виде этих сценариев. Это позволяло разработчикам смотреть на систему со стороны пользователей. Главные люди этого процесса были архитекторы, так как все требования и построение системы развивались вокруг архитектуры. Также в RUP была разработана полноценная система работы с рисками. RUP появился и был сформулирован в 1999 году, такими людьми как: Ивар Якобсон, Гради Буч, Джеймс Румбах.

Кратко о RUP

•       Итеративный и инкрементальный.

•       Основан на пользовательских сценариях.

•       Архитектура является образующей.

•       Акцентирован на риски.

 

Более подробнее - здесь. 

 

RAD Model

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

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

•       Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.

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

•       Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.

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

•       Тестирование: тестируются новые компоненты и интерфейсы.

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

 

Более подробнее - здесь.

 

Feature Driven Development (FDD), 1997 г.

Методология Feature Driven Development (FDD) изначально была разработана Jeff De Luca. Основные практики, описанные в FDD, следующие:

•       Моделирование объектной модели домена.

•       Разработка на основе фич.

•       Индивидуальное владение кодом.

•       Команды, организованные по фичам.

•       Инспекции.

•       Управление конфигурацией.

•       Регулярные сборки продукта.

•       Видимость прогресса и результатов.

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

 

Более подробнее - здесь.

 

Dynamic Systems Development Method (DSDM), 1994 г.

В отличие от остальных практик и методологий, DSDM был разработан консорциумом, являющимся объединением поставщиков и производителей программного обеспечения. Целью их работы было - совместными усилиями разработать и распространить независимый фреймворк для быстрой разработки приложений, с использованием накопленного опыта. Нет одного лишь человека, которого можно считать создателем этого метода, однако, Jennifer Stapleton являясь одним из основателей и членом DSDM, внесла существенный вклад в компиляцию исходных идей и мыслей. Arie van Bennekum является одним из автором Agile-манифеста и принимал активное участие в работе консорциума DSDM начиная с 1997 года. DSDM фокусируется на восьми основных принципах:

Фокус на потребностях бизнеса.

•       Поставлять во время.

•       Взаимодействовать.

•       Никогда не снижать качество.

•       Создавать постепенно с самых основ.

•       Разрабатывать итерационно.

•       Непрерывно и ясно общаться.

•       Демонстрировать управляемость.

И вновь вы можете видеть основы Agile-манифеста.

 

Более подробнее - здесь.

 

Crystal Methods, 1992 г.

Семейство методологий Crystal послужила отправной точкой в развитии методологий разработки программного обеспечения, что в итоге привело к тому, что мы сейчас называем Agile-движением. Честь создания Crystal принадлежит Алистеру Коберну (Alistair Cockburn). Методология была названа Crystal в 1997 году. Методология может быть применима к командам, состоящим из 6 - 8 участников, расположенных в одном месте, работающих над созданием программных систем, не являющихся критичными для жизни пользователей. Вы можете обнаружить зачатки Agile-манифеста в методологии Crystal, поскольку она фокусируется на:

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

•       Разумных улучшениях.

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

 

Более подробнее - здесь.

 

XP (Extreme programming), 1995 г.

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. Эта методология сфокусирована на разработке качественного продукта. В ней много разработческих практик, например:

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

•       Test-driven development (TDD). Разработка через тестирование — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.

•       Непрерывная интеграция (CI, англ. Continuous Integration). Это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. Он нацелен на то, чтобы команда отвечала за качество продукта и дает им для этого соответствующие инструменты.

 

Более подробнее - здесь.

 

Scrum, ~2000 г.

Scrum – это «подход структуры» (на английском - framework, фрэймворк). Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

 

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

 

Более подробнее - здесь. 

 

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

Скомпилировано из открытых источников Интернета