От сбора требований до релиза: этапы разработки ПО и лучшие методологии

Если ваша команда тратит часы и дни на доработку из-за нечетких требований или постоянных изменений, а сроки горят — вам срочно нужна правильная методология разработки. Рассказываем, как выбрать подход, при котором процесс станет прозрачным и предсказуемым.

Основные этапы разработки ПО

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

Сбор и анализ требований

У заказчика собирают бизнес-требования к будущему ПО. Затем руководитель проекта определяет:

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

Когда эта информация собрана, команда фиксирует все задачи и разбивает на более мелкие этапы. Так будет проще управлять проектом, определять последовательность и приоритетность работ. 

Проектирование и архитектура

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

Что делает команда на этом этапе:

• разрабатывает общую структуру системы и полное техническое описание;
• выбирает технологии и методологию для разработки;
• прорабатывает алгоритмы, структуры данных и логику работы внутри каждого модуля;
• взаимодействует с базами данных, API и внешними системами;
• реализует прототипы пользовательских интерфейсов.

Результатом этапа станет готовая проектная документация, по которой можно разрабатывать ПО. 

Чтобы ничего не терять и быстро сверяться с планом, загружайте всю документацию в таск-трекер, например, в Kaiten. Прикрепляйте ссылки на документы или создавайте полноценную базу в самом сервисе.

Разработка/кодинг

Команда создает продукт на основе готовой документации. Разработчики выбирают язык и пишут код на основе технических спецификаций. А потом объединяют все модули в одно приложение и проводят систематическое тестирование. Итог этапа — рабочее решение. 

В некоторых системах управления проектами есть отчеты для отслеживания прогресса и качества работы команды. Например, в Kaiten есть «Накопительная диаграмма потока», где отражаются выполненные и запланированные работы, а также темп работы с задачами. Этот отчет будет помогать следить за общим состоянием проекта и возможными трудностями до самого релиза. 

Приведем пример. На графике количество задач на этапе разработки увеличивается, а в тестирование они не переходят в том же объеме. Это значит, что у команды появились сложности с завершением работ по разработке продукта.

Тестирование

Команда еще не закончила работу над программой. Тестировщики проверяют, как решение справляется с задачами потребителя и как оно работает, сверяют со стандартами качества. 

Для этого команда проверяет ПО на ошибки и баги с помощью:

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

Если на любом из этапов тестировщик найдет ошибки, то вернет ПО разработчикам для исправления. Важно не игнорировать результаты тестов и правильно анализировать полученные данные, чтобы не отправить в реализацию «сырое» ПО.

Результатом этапа станет готовый продукт, который готов к развертыванию. 

Развертывание (деплой) и выпуск продукта

Команда передает решение заказчику для переноса в продуктивную среду. Он выкладывает ПО в магазины приложений и передает клиентам для установки на их серверы.

На этом этапе важно полностью создать всю техническую документацию и при необходимости подготовить пользователей к работе с ПО. Команда еще не заканчивает взаимодействие с продуктом.

Доработка

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

На основе фидбэка разработчики:

• вносят исправления;
• адаптируют ПО к новым требованиям;
• следят за производительностью всей системы;
• готовят обновления и улучшения.

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

Оптимизируйте процесс получения обратной связи с помощью модуля Service desk в Kaiten — все заявки от пользователей будут попадать на доску.

Если вы настроите интеграцию с Webhooks, то будете получать отчеты о багах в форме карточек на вашем пространстве.

Классические модели разработки ПО

Чтобы правильно выбрать модель для управления проектом разработки, учитывайте:

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

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

Waterfall или каскадная модель

Логика работы. Команда ведет разработку последовательно по этапам — заканчивает один, а потом приступает к следующему. Движение возможно только вперед — нельзя возвращаться на предыдущий этап. 

Где применяется. В космической и медицинской отраслях, где действует база СНиПов и различных спецификаций, в государственных и банковских учреждениях. А также в проектах, где требования известны заранее и не будут меняться. В сочетании с гибкими методиками подходит для других отраслей и направлений. 

Преимущества: 

• простой контроль задач и работы команды;
• определение стоимости на начальных этапах;
• низкая вероятность ошибок благодаря детальной документации;
• прозрачные процессы для заказчика — он знает о времени на каждый этап и результатах.

Недостатки: 

• тесты на последних этапах разработки;
• демонстрация продукта заказчику на последних этапах;
• выше вероятность срочных изменений;
• возврат на предыдущий этап невозможен или очень дорогой;
• много документации до начала работ;
• длительные согласования;
• сложное и дорогое устранение ошибки или недостатка продукта.

Больше о методологиях рассказали в статье «Waterfall, Agile, Scrum или Kanban — в чем разница?».

Итерационная (итеративная) модель

Логика работы. Команда работает итерациями — создает работоспособную часть функционала. Делит проект на части, выпускает MVP-версию, затем по шагам добавляет инструменты и развивает решение. Каждая итерация должна приносить результат, а каждая версия продукта — быть работоспособной. Требования можно менять на основе обратной связи от пользователей или заказчика. 

Где применяется. В больших проектах, где заранее заказчик заранее определил требования к конечному продукту, но может поменять детали реализации. Подходит компаниям в условиях жесткой конкуренции, которым срочно нужно рабочее решение. 

Преимущества: 

• быстрая разработка MVP;
• прозрачность процессов для заказчика; 
• регулярная обратная связь от пользователей.

Недостатки: 

• иногда сложное создание и корректировка архитектуры из-за неясных требований.

Спиральная модель (Spiral Model)

Логика работы. Команда разработчиков вместе с заказчиком оценивает риски и действует итерациями, где каждую следующую строят на предыдущей. В конце каждого витка заново принимают решение, нужно ли продолжать проект. Работа модели похожа на итерационную, но с упором на анализ рисков.

Где применяется. Подходит для сложных и дорогих проектов, например, создание документооборота банка. Обычно используют для выполнения бизнес-задач, неудачный результат в которых критически повлияет на существование компании. 

Преимущества: 

• постоянная проработка и управление рисками;
• внесение изменений в проект на любом «витке»;
• работа в условиях неопределенных требований.

Недостатки:

• остановка на первом «витке» для постоянного совершенствования версии; 
• чем больше циклов, тем дороже и дольше работа над решением;
• при появлении новых требований новый запуск цикла;
• дорого для небольших проектов;
• сложности в оценке времени и количестве циклов.

V-модель

Логика работы. Более современный вариант Waterfall со строгими регламентами и упором на тестирование. Команда одновременно описывает требования к будущей системе и варианты тестирования ПО. После разработки решение снова проходит все тесты перед выпуском продукта.

Где применяется. В проектах, где надежность в приоритете и нежелательны ошибки. Например, производство систем безопасности и контроль состояния больных в клиниках.

Преимущества: 

• низкий риск ошибок;
• постоянное тестирование; 
• повышенная надежность продукта.

Недостатки: 

• дорогое и сложное исправление любой ошибки; 
• переработка всего продукта из-за новых требований.

Гибкие (Agile) методологии разработки ПО

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

Agile

Это не совсем модель — скорее набор подходов и методов гибкого управления разработкой ПО.

4 главные ценности гибкого управления:

1. приоритет людей и взаимодействий над процессами и инструментами;
2. создать рабочий продукт важнее, чем разработать исчерпывающую документацию;
3. сотрудничать с заказчиком важнее, чем согласовывать условия по контракту;
4. команда должна быть всегда готова к изменениям, это важнее, чем следовать плану.

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

Scrum

Логика работы. Команда работает спринтами по 2-4 недели, у каждой итерации есть цель и задачи. В конце спринта проводят ретроспективу, где обсуждают результаты, продумывают точки роста и планируют следующий спринт. Разработчики часто проводят тестирование и проверяют продукт, поэтому выявляют ошибки на ранних этапах.

Где применяется. Небольшие и средние проекты в динамичной среде с нестабильными требованиями. Scrum хорошо себя показывает, если на рынке жесткая конкуренция и нужно как можно быстрее доставить ценность заказчику.

Преимущества: 

• вовлечение и сосредоточенность на результатах;
• частое тестирование и анализ продукта;
• быстрая реакция на изменение требований;
• высокая мотивация благодаря видимому результату.

Недостатки: 

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

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

Kanban

Логика работы. Это не модель управления разработкой ПО, а подход для использования вместе с методологией. Kanban улучшает организацию, помогает визуализировать и отслеживать прогресс по стадиям выполнения. Команда отображает все задачи и этапы работы на доске, распределяет карточки между сотрудниками и собирает отчеты. 

Где применяется. Подходит любому проекту, больше всего тем, где важно прогнозировать сроки выполнения.

Преимущества: 

• визуализация задач в работе и отображение ответственных;
• выставление WIP-лимитов для снижения нагрузки на команду;
• управление всеми задачами на одной доске или пространстве;
• минимальный риск потери задач и пропуска сроков выполнения.

Недостатки: 

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

Для работы по Kanban нужна система управления проектами. Например, в таск-трекере Kaiten вы сможете разбить разработку на стадии и двигать карточки с задачами по мере их выполнения. Команда сможет отслеживать прогресс и видеть, на каком этапе возникли сложности, чтобы быстро найти решение.

Скопируйте в свое пространство готовый шаблон для работы по Kanban. Добавьте элементы для вашей команды и начните выстраивать процессы прямо сейчас. 

Lean 

Логика работы. Основная цель — максимизировать прибыль, оптимизировать процессы и минимизировать потери, убрать все лишнее из проекта и повысить эффективность. Команда выпускает MVP и регулярно его улучшает на основе обратной связи. 

Где применяется. В проектах, где важно устранить потери и максимизировать ценность для пользователя — логистика, строительные проекты, производственные линии. Используется в ПО больниц и поликлиник для снижения времени ожидания приема и управления лекарствами. 

Преимущества:

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

Недостатки: 

• сложности внедрения при сопротивлении команды;
• риск создания «сырого» продукта;
• низкая эффективность без выстроенных каналов обратной связи.

Работу по Lean легко организовать с помощью таск-трекера, например, Kaiten. Создайте доски на одном пространстве по циклу Build-Measure-Learn, чтобы вам было проще отслеживать прогресс и вносить изменения. Также в Kaiten можно строить отчеты — они детально показывают состояние проекта и помогают принимать решения. 

Extreme Programming

Логика работы. Команда фокусируется на гибкости, адаптивности и постоянном тесном контакте. Разработчики записывают задачи на карточки и действуют по указанному приоритету от заказчика. В Extreme Programming сначала пишут тесты, а потом код. Каждую маленькую часть кода тестируют и добавляют в систему. 

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

Преимущества:

• код высокого качества;
• частые релизы и итеративная разработка;
• постоянное взаимодействие с заказчиком и конечным потребителем;
• единый процесс, уход сотрудника не влияет на качество и сроки.

Недостатки: 

• неэффективен для команды новичков или долгосрочных проектов;
• высокий расход ресурсов из-за непрерывной интеграции;
• зависимость успеха от вовлеченности заказчика. 

Сравнение методологий

Выбор зависит от конкретного проекта, его характеристик, требований заказчика и особенностей команды разработчиков. Чтобы вам было проще выбирать, мы сравнили популярные методологии и модели управления разработкой ПО:

С помощью правильной методологии вы сможете навести порядок в процессах, улучшить коммуникацию в команде и создавать продукты, которые действительно нужны вашим пользователям. Не бойтесь экспериментировать и искать свой путь. Главное – начать действовать прямо сейчас.