1. Начало (Inception)
На этом этапе:
Формируются видение и границы проекта.
Создается экономическое обоснование (business case).
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении начальной стадии оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Проектирование (Elaboration)
На этапе проектирования производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
Документирование требований (включая детальное описание для большинства прецедентов).
Спроектированную, реализованную и оттестированную исполняемую архитектуру.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.
Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).
3. Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Гибкие методологии
Основная идея: максимальная адаптация к любым изменениям в проектной ситуации, отсутствие бессмысленного долгосрочного планирования, максимально частая поставка продукта заказчику.
Гибкая методология разработки (англ. Agile software development, agile-методы)— серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.
Плюсы |
Минусы |
|
|
SCRUM
SCRUM (от англ.scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.
Весь проект делится на итерации (Sprints) продолжительностью 30 дней каждый. Из Product Backlog, путем планирования (например, Planning Poker), выбирается список функций системы (Sprint Backlog), которые планируется реализовать в течение следующего спринта. Самые важные условия — неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Scrum Master проводит ежедневные 15-20 минутные совещания, которые так и называют — Daily Scrum Meeting, результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать. По окончанию спринта, заказчик может посмотреть уже работающую тестовую версию проекта с приростом функций. В системе уже будут реализованы и протестированы самые важные с точки зрения его бизнеса - функции, причем их можно будет посмотреть, проверить, и потыкать, а так же высказать команде все ласковые слова и предложения, которые должны быть учтены на следующих этапах работ.
После демонстрации команда, воодушевленная напутствиями заказчика, проводит ретроспективу (анализирует ход прошедшего этапа работы с целью улучшения процессов разработки) и приступает к следующему этапу работ.
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
В методологии Scrum всего три роли:
Scrum Master (проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера)
Product Owner (представляет интересы конечных пользователей и других заинтересованных в продукте сторон)
Scrum Team (кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.)
Основные артефакты:
Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе. Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти". Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.
Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Плюсы |
Минусы |
|
|
KANBAN
KANBAN – гибкая методология разработки программного обеспечения, ориентированная на задачи. Это высоко адаптивный инструмент, который требует от команды, решившей использовать его, соответствующего уровня самоорганизации и дисциплины:
Визуализируйте производственный процесс (Для этого обычно используют доску, размеченную по этапам работы над задачей.
Ограничивайте количество незавершенной работы (WIP, Work In Progress) (У каждого столбца-состояния команда указывает максимальное количество задач, которые могут в нем находиться. Таким образом, минимизируется переключение между задачами и связанные с этим потери при производстве.
Оптимизируйте процесс (Третье правило – основа оптимизации производства в рамках канбана. Необходимо отслеживать среднее время задачи и уменьшать его.)
Ввиду малого количества директив, начать использовать KANBAN можно легко и просто, но для того, чтобы использовать данный инструмент эффективно, нужно не отклоняться от процесса непрерывного совершенствования.
Плюсы |
Минусы |
|
|
________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________