37ВИДЫ И ТЕНДЕНЦИИ ПРИМЕНЕНИЯ МЕТОДОЛОГИЙ
РАЗРАБОТКИ В СОВРЕМЕННЫХ РОССИЙСКИХ
ОРГАНИЗАЦИЯХ
А.Г. Сербин
ООО «АйТи Мониторинг» ул. Рашпилевская 287, 350051, г. Краснодар, Россия
Ключевые слова: методологии разработки ПО, Waterfall, Agile, Scrum, Spiral, стартап.
Аннотация
Статья посвящена современным подходам к разработке программных продуктов. В рамках статьи выделены наиболее востребованные методологии разработки в российских компаниях в настоящее время. В статье выделены основные особенности процесса разработки ПО, выделены основные специалисты, которые входят в команду разработки. Так же выделены основные риски, с которыми компании сталкиваются в процессе разработки ПО и пути их снижения.
В условиях быстро изменяющейся рыночной обстановки, дефицита бюджетов начинающих стартапов, конкуренции за идеи и покупателя, на одно из первых мест выходит процесс организации разработки ПО.
Классический процесс разработки любого продукта состоит из 7 основных стадий, они представлены.
Данные стадии условно можно разделить на бизнес, и системные процессы. Первая группа заканчивается сбором требований от заказчика и формирования бизнес требований к программному продукту. Данный процесс выполняет бизнес-аналитик, цель работы которого собрать и проверить первоначальные требования от заказчика и сформировать видение конечного результата.
Правильно проведенный бизнес-анализ требует затрат времени и средств на работу опытных аналитиков, которые должны иметь опыт и знания в финансовой, маркетинговой, инженерно-конструкторской и производственной областях, а также в стратегическом планировании.
На следующем этапе бизнес требования поступают уже системному аналитику и архитектору продукта, цель этих
специалистов перевести бизнес требования заказчика на технический язык.
Системный аналитик должен разработать техническую документацию для дальнейших этапов производства ПО: технические задания или user stories, прототипы программного продукта, описания компонентов и алгоритмы работы, а также выделить пользователей системы.
После этого техническое задание поступает архитектору системы. Архитектор - это человек, который решает, как в конечном итоге будет выглядеть программный продукт в целом и в деталях. Основная цель ИТ-архитектора в проекте заключается в том, чтобы обеспечить решение задач бизнеса при помощи информационных технологий.
Причем, он должен не только сформировать решение, но и контролировать правильность его реализации.
Архитектор в свою очередь декомпозирует требования, формирует общую концепцию и передает требования разработчикам, для непосредственной реализации программного комплекса.
Для построения пользовательских интерфейсов на данной стадии разработки подключается дизайнер. Данный специалист, делает его удобным для конечного пользователя и реализует графические нефункциональные требования к продукту со стороны заказчика.
После написания каждого из компонентов продукта, к процессу подключается инженер-тестировщик. Цель данного этапа производства ПО - проверить работу компонента продукта, на соответствие заявленным требованиям.
Это схема работы над любым ПО, но с учетом специфики компании, масштабов программного продукта, а также специфики самого продукта могут применяться различные методологии разработки. Существует множество подходов, но я хотел бы остановиться на наиболее востребованных в современных компаниях.
Первой методологией, с которой хотелось начать, является «Waterfall» (каскадная модель или «водопад»). Данный подход подразумевает последовательное прохождение стадий разработки продукта, каждая из которых должна завершиться полностью до
начала следующей. На всех стадиях проекта ведется документация, что впоследствии существенно облегчает развитие продукта и анализ проблемных блоков. Благодаря жестко регламентированным стадиям, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах [1].
Каскадная модель будет давать отличный результат только в проектах, с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Данная методология в компаниях используется, но в чистом виде уже достаточно редко [2].
И еще одна из каскадных моделей на котором хотелось бы остановиться является (спиральная модель). Данный подход хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.
Наиболее быстрой по получению конечного результата является «Agile Model» или гибкая методология разработки. В «Agile» методологии после каждой итерации, заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов, сложно оценить трудозатраты и стоимость требуемой разработки [3].
Примерами «Agile Model» являются два, ставшими уже самостоятельными подходами к разработке, которые особенно часто применяются для реализации стартапов, это Scrum и Kanban.
Scrum - система разработки ПО, основанная на делении всего процесса на итерации, где в конце каждой из них, команда
готова предоставить демо-версию продукта.
Основой Scrum является Sprint, в течение которого выполняется работа над продуктом. По окончанию Sprinta должна быть получена новая рабочая версия продукта. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog [4].
Канбан - система, построенная на визуализации процесса выполнения задач команды. Основным инструментом при применении данного метода становится доска Kanban.
Доска Kanban — это инструмент управления agile-проектами, с помощью которого можно наглядно представить задачи, ограничить объем незавершенной работы и добиться максимальной производительности (или скорости). С помощью карточек и столбцов, на доске Kanban команды по техническим вопросам и сервисные команды могут понять, какой объем работы следует взять на себя, и выполнять этот объем, придерживаясь принципов непрерывного совершенствования.
В наше время аналитика и организация процесса разработки ПО в современных российских компаниях выходит на новый уровень, приобретает уже свой колорит, используя различные методологии разработки, каждая из организаций начинает уже их компоновать и модифицировать с учетом специфики деятельности и стоящим задачам. На эффективность данного процесса оказывают влияние различные факторы
Первый, который хотелось бы выделить, это ведение документации в различном объеме. Если в классических моделях разработки таких как Waterfall или Spiral процесс ведения документации не просто задекларирован, но и жестко регламентирован, то во многих набирающих сейчас популярность "гибких методологиях разработки", на первом месте стоит "продукт".
Да, конечно, ведение документации по продукту требует ресурсов команды и влияет на сроки готовности, но в то же время актуальная полная документация снимает множество рисков.
Одним из основных, который есть в каждом проекте является "бас-фактор" (риск потери ключевого участника команды), но при наличии актуальной структурированной
документации данный фактор будет минимальным,
Кроме того, при масштабировании команды это позволит сэкономить ресурсы, так как новый участник сможет самостоятельно погрузиться в детали проекта.
Еще один фактор — это выбор методологии, не отталкиваясь от специфики разрабатываемого продукта, а основываясь на уже имеющимся опыте в компании или опыте работы по конкретной методологии руководителя проекта или архитектора, иногда даже в угоду современным веяньям, потому что сейчас так принято.
Не верный выбор методологии разработки продукта может в последствии выльется не только выходом за сроки проекта и увеличением бюджета, но и закрытием проекта при потере его актуальности и рентабельности.
Подытожив, можно отметить, что, каждая методология, каждый подход к разработке это всего лишь рекомендации, но никак не жесткие требования.
Методологии призваны помочь команде, участвующей в разработке ПО максимально качественно и в разумные сроки выпустить продукт.
К каждому процессу будь то формирование требований, разработка, тестирование или другой процесс нужно подходить взвешено, искать ту разумную грань между объемом документации, наличии и количестве определенных специалистов в команде, а также выбору методологии, которая больше всего подойдет для подготовки продукта.
Так же приступая к разработки любого ПО не стоит забывать, что успешность разрабатываемого продукта зависит не только от программистов, но и от работы других участников команды, и не зависимо от выбранного подхода, именно профессиональная работа всей команды позволяет получить качественный и конкурентоспособный продукт.
Библиографический список
1. ThomasAlva [Электронный ресурс] // Статья: ещё раз про семь основных методологий разработки. - 2015. - Режим доступа: https://habr.com/ru/company/edison/blog/269789/ (дата обращения 24.04.2020)
2. Jetgear [Электронный ресурс] // Waterfall model каскадная модель или водопад. Водопадная (каскадная) модель. Что же выбрать. 2020. -
Режим доступа: https://jetgear.ru/poleznoe/waterfall-model-kaskadnaya-model-ili-vodopad-vodopadnaya-kaskadnaya-model-chto-zhe.html (дата обращения 24.04.2020)
3. Wrksection [Электронный ресурс] // Agile или Waterfall — какой вариант соответствует вашему бизнесу? 2017. - Режим доступа: https://worksection.com/blog/waterfall-vs-agile.html (дата обращения 24.04.2020)
4. Kornelik [Электронный ресурс] // Разработка ПО по методикам SCRUM и Критическая цепь: различия и общие черты. 2017. - Режим доступа: http://integral-mssia.m/2017/05/28/razrabotka-po-po-metodikam-scmm-i-kriticheskaya-tsep-razlichiya-i-obshhie-cherty/ (дата обращения 24.04.2020)
