Для слаженной разработки любого продукта необходимо построить четкий план разработки, в котором будут выделены основные стадии работы.
У каждой команды разработчиков в зависимости от их особенностей строиться собственный план разработки. Но все равно в каждой из видов схем разработки присутствуют одни и те же пункты, которые представляют из себя важные этапы проекта.
Поэтому мы хотим представить обобщенный план разработки продукта, через пункты которого проходит каждая команда разработчиков:
Пояснения для схемы:
Под версией продукта может подразумеватся продукт, который ещё находиться в альфа или бета версии (то есть его необходимо дорабатывать) или же готовый продукт.
Важно то, что эта версия продукта способна уже хоть как-то решать основную проблему заказчика.
Существует множество возможных подходов для проработки схемы разработки продукта. В каждой отдельной компании может формироваться своя уникальная схема.
Но все равно каждая команда старается действовать по устоявшимся моделям разработки и используя при этом более удобные для них проработанные методологии.
Ниже мы рассмотрим попоулярные модели разработки и их методологии, которые расширяют и улучшают понимания работы модели:
Итеративный подход в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.
Преимущества итеративного подхода:
Rational Unified Process
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Agile
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели.
Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации.
По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Scrum
Набор принципов, на которых строится процесс SCRUM-разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет.
Спринт — итерация в скраме, в ходе которой создается инкремент бизнес-продукта. Жестко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении.
Разные команды подбирают длину спринта согласно специфике своей работы, кросс-функциональности команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка длины спринта фиксируется в бэклоге проекта.
Kanban
Метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками.
При данном подходе весь процесс разработки прозрачен для всех членов команды.
Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.
Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.
Канбан – это метод, инструмент с набором практик и принципов. Вы можете использовать все практики, часть практик или не использовать их вообще. В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан. Однако, разумное использование практик может существенно помочь вам сделать сервис максимально качественным и соответствующим ожиданиям клиентов.
Модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству.
Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным.
Представляет собой процесс разработки программного обеспечения, сочетающий в себе как итеративность, так и этапность.
Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
В спиральной модели жизненный путь разрабатываемого продукта изображается в виде спирали, которая, начавшись на этапе планирования, раскручивается с прохождением каждого следующего шага. Таким образом, на выходе из очередного витка мы должны получить готовый протестированный прототип, который дополняет существующий билд. Прототип, удовлетворяющий всем требованиям – готов к релизу.
Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена соответствующая стадия. Основные типы рисков, которые могут возникнуть в процессе разработки ПО:
Rapid Application Development (RAD)
Концепция организации технологического процесса разработки программных продуктов, ориентированная на максимально быстрое получение качественного результата в условиях сильных ограничений по срокам и бюджету и нечётко определённых требований к продукту.
Эффект ускорения разработки достигается путём использования соответствующих технических средств и непрерывного, параллельного с ходом разработки, уточнения требований и оценки текущих результатов с привлечением заказчика. RAD создана в конце 1980-х как альтернатива более ранним каскадной и итеративной моделям.
RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трёх-четырёх месяцев путём использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки.
Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях — обследование организации, выработка требований к системе. Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учётом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы.
Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
OpenUP
Это итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP.
OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи.
Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта.
Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов.
План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
OpenUP делит проект на итерации: планируемые, ограниченные во времени интервалы, длительность которых обычно измеряется неделями.
План итерации определяет, что именно должно быть сдано по окончании итерации, а результатом является работоспособная версия.
Коллективы разработчиков OpenUP строятся по принципу самоорганизации, решая вопросы выполнения задач итераций и передачи результатов.
