Процесс разработки

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

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

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

Наша компания имеет большой практический опыт с использованием традиционных моделей и методологий (таких как Waterfall или RADH), а также успешно завершены и сданы в эксплуатацию проекты, осуществлённые с использованием таких моделей как RUP, MSF, CMMI, и SCRUM.

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

На рисунках 1 и 2 представлены Waterfall и RAD модели.

Модель Waterfall

Модель Waterfall Рис. 1.

Итеративная RAD модель

Итеративная RAD модель Рис. 2.

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

Методология SCRUM подразумевает что анализ, дизайн, и процессы разработки в фазе Спринта (об этом ниже) сложно определить заранее, поэтому для этого в SCRUMe используется механизм контроля для управления этим и для контроля рисков. Результаты, которые дает SCRUM это гибкость, возможность быстрого реагирования, и надежность.

Методология SCRUM

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

Основные характеристики:
  • самонаправляющаяся и самоорганизующаяся команда;
  • дополнительная работа не добавляется во время выбранной итерации;
  • ежедневные митинги;
  • строго 30-дневные (или меньше) итерации;
  • демонстрации приложения заказчикам в конце каждой итерации;
  • в каждой итерации, заказчик заново расставляет приоритеты требованиям и выбирает цели для следующей итерации.

SCRUM состоит из следующих 3 фаз (рис. 3):

I. Пред-игровая фаза
  • Планирование — дефиниция нового выпуска продукта, основанного на известных, на сегодняшний день, свойств продукта, вместе с оценкой по его стоимости и срокам. Если разрабатывается новая система, данная фаза включает в себя как концептуализацию, так и анализ. Если существующая система усовершенствуется, то данная фаза состоит только из небольшого [ограниченного] анализа.
  • Архитектура — создание дизайна того как свойства продукта будут внедрены. Эта фаза включает в себя модификацию архитектуры системы и дизайн высокого уровня.

II. Игра (Разработка)
  • Спринты разработки (рис. 4) — разработка релиза новых функций с отслеживанием по, иногда, изменяющимся времени, требованиям, качеству, стоимости и т.д. Интерактивность с этими переменными определяет конец этой фазы. Существует множество итеративных спринтов разработки, или циклов, которые используется для создания системы.

III. После-игровая фаза
  • Завершение (закрытие) — подготовка к релизу включает в себя финальную документацию, предрелизное поэтапное тестирование и сам релиз.

Фазы спринта

Фазы спринта Рис. 3.

Характеристики методологии SCRUM

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

Схема Спринта

Фазы спринта Рис. 4.

Роли в SCRUM

В SCRUMe используются следующие три роли:

  1. Владелец продукта (Product Owner)
  2. SCRUM Мастер (SCRUM Master)
  3. SCRUM команда (SCRUM Team)

Владелец продукта:

  • Определяет свойства/функциональность продукта.
  • Определяет сроки релиза и контент.
  • Отвечает за рентабельность проекта (ROI).
  • Расставляет задачи (функции продукта) по приоритетам, соответствии с ценностью для рынка.
  • Регулирует функции и приоритет задач, если требуется.
  • Принимает результаты работы.

SCRUM Мастер:

У SCRUM Мастера, помимо проведения ежедневных совещаний, есть три основные обязанности:

  • SCRUM Мастер отслеживает задачи, которые уже выполнены, новые задачи, и задачи, которые были выявлены командой, а также отслеживает предварительные оценки (estimations), которые были изменены. Это позволяет обновлять таблицу Burndown Chart, которая показывает всю оставшуюся работу за день.
  • SCRUM Мастер также отслеживает открытые задачи и делает всё возможное для выравнивания производительности.
  • Выявляет зависимости и/или всё то, что даёт задержку в SCRUMe и, в соответствии с этим, предпринимает необходимые действия для преодоления этих задержек.
  • SCRUM Мастер также отвечает за решение любых проблем, возникающих в SCRUM команде, функциональность и производительность которой должна быть всегда на нужном уровне.

SCRUM команда:

  • Занимается непосредственно разработкой функциональности.
  • SCRUM команда должна быть многофункциональной, с перекрёстным дополнением друг друга в количестве (+/-) 7 человек.
  • Отмечает цель Спринта и определяет результаты, к которым команда должна прийти.
  • Команда имеет право на любые действия в рамках проекта для достижения цели Спринта.
  • SCRUM команда является самоорганизующимся образованием, включая свою работу, и демонстрирует результаты работы Владельцу продукта.

Артефакты SCRUMa

Свойства продукта

Свойства продукта, по сути, являются требованиями системы, выраженными в списке приоритетов, включающим в себя как функциональные, так и нефункциональные требования заказчика, а также рекомендации и предложения, выработанные SCRUM командой. Все данные, поступающие в Свойств продукта [Product Backlog] должны быть разбиты по приоритетам, и эта ответственность лежит полностью на Владельце продукта.

Во время совещаний Планирования спринта данные, соответствующие своим приоритетным позициям, переходят из Свойств продукта в Спринт.

Задачи спринта (Sprint Backlog)

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

Эти задачи разбиты на такие меньшие задачи, для выполнения которых требуется не более 2-х рабочих дней (или 16-ти часов разработки). Когда задачи спринта составлены, то сравнивают затраты/сроки всей работы с первоначальной оценкой из свойств продукта. Если разница ощутима, то команда совещается с владельцем продукта по предмету, и уже здесь определяется количество часов (дней) которые необходимо затратить для проведения спринта с высокой вероятностью успеха.

Таблица Burndown Chart

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

В процессе завершения задач в спринте, SCRUM Мастер периодически пересчитывает все оставшиеся задачи, и таблица заметно уменьшается с периодом времени [Burndown Chart]. Когда в спринте задач не остаётся, то спринт завершен.

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

Преимущества методологии SCRUM

Традиционные методологии разработки созданы для решения непредвиденных проблем только на старте, включая более новые методы, такие как спиральная методология Boehm(a) и её варианты, которые также ограничены для своевременного и эффективного реагирования на изменения требований на старте.

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

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