От сбора требований до релиза: этапы разработки ПО и лучшие методологии
Как упорядочить процесс на основных этапах разработки, избежать хаоса и найти баланс в выбранной модели
Если ваша команда тратит часы и дни на доработку из-за нечетких требований или постоянных изменений, а сроки горят — вам срочно нужна правильная методология разработки. Рассказываем, как выбрать подход, при котором процесс станет прозрачным и предсказуемым.
Основные этапы разработки ПО
Каждый из этапов основан на результатах предыдущего и влияет на конечный продукт. Успех всего проекта часто зависит от того, насколько четко и качественно выполняются все процессы — от сбора требований до релиза и доработки.
Сбор и анализ требований
У заказчика собирают бизнес-требования к будущему ПО. Затем руководитель проекта определяет:
- задачи — что делает готовый продукт;
- аудиторию — кто и как использует решение;
- ресурсы для воплощения идеи — сотрудники, время, бюджет;
- критерии — как оценивать успех продукта.
Когда эта информация собрана, команда фиксирует все задачи и разбивает на более мелкие этапы. Так будет проще управлять проектом, определять последовательность и приоритетность работ.
Проектирование и архитектура
Архитектура системы — скелет, на котором команда строит все ПО. Она помогает разработчикам понять необходимый функционал решения и структурировать требования, которым будущая программа должна соответствовать.
Что делает команда на этом этапе:
- разрабатывает общую структуру системы и полное техническое описание;
- выбирает технологии и методологию для разработки;
- прорабатывает алгоритмы, структуры данных и логику работы внутри каждого модуля;
- взаимодействует с базами данных, API и внешними системами;
- реализует прототипы пользовательских интерфейсов.
Результатом этапа станет готовая проектная документация, по которой можно разрабатывать ПО.
Чтобы ничего не терять и быстро сверяться с планом, загружайте всю документацию в таск-трекер, например, в Kaiten. Прикрепляйте ссылки на документы или создавайте полноценную базу в самом сервисе.
Разработка/кодинг
Команда создает продукт на основе готовой документации. Разработчики выбирают язык и пишут код на основе технических спецификаций. А потом объединяют все модули в одно приложение и проводят систематическое тестирование. Итог этапа — рабочее решение.
В некоторых системах управления проектами есть отчеты для отслеживания прогресса и качества работы команды. Например, в Kaiten есть «Накопительная диаграмма потока», где отражаются выполненные и запланированные работы, а также темп работы с задачами. Этот отчет будет помогать следить за общим состоянием проекта и возможными трудностями до самого релиза.
Приведем пример. На графике количество задач на этапе разработки увеличивается, а в тестирование они не переходят в том же объеме. Это значит, что у команды появились сложности с завершением работ по разработке продукта.
Тестирование
Команда еще не закончила работу над программой. Тестировщики проверяют, как решение справляется с задачами потребителя и как оно работает, сверяют со стандартами качества.
Для этого команда проверяет ПО на ошибки и баги с помощью:
- юнит-тестирования — насколько корректно работают отдельные компоненты;
- интеграционного тестирования — как взаимодействуют модули;
- системного и приемочного тестирования — как функционирует у конечных пользователей.
Если на любом из этапов тестировщик найдет ошибки, то вернет ПО разработчикам для исправления. Важно не игнорировать результаты тестов и правильно анализировать полученные данные, чтобы не отправить в реализацию «сырое» ПО.
Результатом этапа станет готовый продукт, который готов к развертыванию.
Развертывание (деплой) и выпуск продукта
Команда передает решение заказчику для переноса в продуктивную среду. Он выкладывает ПО в магазины приложений и передает клиентам для установки на их серверы.
На этом этапе важно полностью создать всю техническую документацию и при необходимости подготовить пользователей к работе с ПО. Команда еще не заканчивает взаимодействие с продуктом.
Доработка
Клиенты используют решение и дают первую обратную связь, которую команда анализирует.
На основе фидбэка разработчики:
- вносят исправления;
- адаптируют ПО к новым требованиям;
- следят за производительностью всей системы;
- готовят обновления и улучшения.
Важно настроить работу отдела технической поддержки. Он поможет клиентам разобраться в продукте и решать их проблемы во взаимодействии с ПО.
Оптимизируйте процесс получения обратной связи с помощью модуля Service desk в Kaiten — все заявки от пользователей будут попадать на доску.
Если вы настроите интеграцию с Webhooks, то будете получать отчеты о багах в форме карточек на вашем пространстве.
Классические модели разработки ПО
Чтобы правильно выбрать модель для управления проектом разработки, учитывайте:
- размер команды;
- вероятность изменения требований;
- запросы рынка;
- размер и количество конкурентов.
Определите формат работы в соответствии с моделью жизненного цикла ПО — так проще выстраивать процессы, внедрять новые функции и создавать сильный продукт.
Waterfall или каскадная модель
Логика работы. Команда ведет разработку последовательно по этапам — заканчивает один, а потом приступает к следующему. Движение возможно только вперед — нельзя возвращаться на предыдущий этап.
Где применяется. В космической и медицинской отраслях, где действует база СНиПов и различных спецификаций, в государственных и банковских учреждениях. А также в проектах, где требования известны заранее и не будут меняться. В сочетании с гибкими методиками подходит для других отраслей и направлений.
Преимущества:
- простой контроль задач и работы команды;
- определение стоимости на начальных этапах;
- низкая вероятность ошибок благодаря детальной документации;
- прозрачные процессы для заказчика — он знает о времени на каждый этап и результатах.
Недостатки:
- тесты на последних этапах разработки;
- демонстрация продукта заказчику на последних этапах;
- выше вероятность срочных изменений;
- возврат на предыдущий этап невозможен или очень дорогой;
- много документации до начала работ;
- длительные согласования;
- сложное и дорогое устранение ошибки или недостатка продукта.
Больше о методологиях рассказали в статье «Waterfall, Agile, Scrum или Kanban — в чем разница?».
Итерационная (итеративная) модель
Логика работы. Команда работает итерациями — создает работоспособную часть функционала. Делит проект на части, выпускает MVP-версию, затем по шагам добавляет инструменты и развивает решение. Каждая итерация должна приносить результат, а каждая версия продукта — быть работоспособной. Требования можно менять на основе обратной связи от пользователей или заказчика.
Где применяется. В больших проектах, где заранее заказчик заранее определил требования к конечному продукту, но может поменять детали реализации. Подходит компаниям в условиях жесткой конкуренции, которым срочно нужно рабочее решение.
Преимущества:
- быстрая разработка MVP;
- прозрачность процессов для заказчика;
- регулярная обратная связь от пользователей.
Недостатки:
- иногда сложное создание и корректировка архитектуры из-за неясных требований.
Спиральная модель (Spiral Model)
Логика работы. Команда разработчиков вместе с заказчиком оценивает риски и действует итерациями, где каждую следующую строят на предыдущей. В конце каждого витка заново принимают решение, нужно ли продолжать проект. Работа модели похожа на итерационную, но с упором на анализ рисков.
Где применяется. Подходит для сложных и дорогих проектов, например, создание документооборота банка. Обычно используют для выполнения бизнес-задач, неудачный результат в которых критически повлияет на существование компании.
Преимущества:
- постоянная проработка и управление рисками;
- внесение изменений в проект на любом «витке»;
- работа в условиях неопределенных требований.
Недостатки:
- остановка на первом «витке» для постоянного совершенствования версии;
- чем больше циклов, тем дороже и дольше работа над решением;
- при появлении новых требований новый запуск цикла;
- дорого для небольших проектов;
- сложности в оценке времени и количестве циклов.
V-модель
Логика работы. Более современный вариант Waterfall со строгими регламентами и упором на тестирование. Команда одновременно описывает требования к будущей системе и варианты тестирования ПО. После разработки решение снова проходит все тесты перед выпуском продукта.
Где применяется. В проектах, где надежность в приоритете и нежелательны ошибки. Например, производство систем безопасности и контроль состояния больных в клиниках.
Преимущества:
- низкий риск ошибок;
- постоянное тестирование;
- повышенная надежность продукта.
Недостатки:
- дорогое и сложное исправление любой ошибки;
- переработка всего продукта из-за новых требований.
Гибкие (Agile) методологии разработки ПО
Эти методы подойдут для работы в условиях резких изменений рынка, когда заказчик не до конца понимает требования или нужно быстро доставить ценность пользователю. В этих случаях команда выпускает MVP, а потом улучшает его короткими итерациями. Например, при разработке мобильного приложения, игры или запуска стартапа.
Agile
Это не совсем модель — скорее набор подходов и методов гибкого управления разработкой ПО.
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 сначала пишут тесты, а потом код. Каждую маленькую часть кода тестируют и добавляют в систему.
Где применяется. В условиях стартапов и инновационных продуктов, в проектах, где постоянно меняются требования из-за корректировки бизнес-целей, и в направлениях с жестко ограниченными сроками.
Преимущества:
- код высокого качества;
- частые релизы и итеративная разработка;
- постоянное взаимодействие с заказчиком и конечным потребителем;
- единый процесс, уход сотрудника не влияет на качество и сроки.
Недостатки:
- неэффективен для команды новичков или долгосрочных проектов;
- высокий расход ресурсов из-за непрерывной интеграции;
- зависимость успеха от вовлеченности заказчика.
Сравнение методологий
Выбор зависит от конкретного проекта, его характеристик, требований заказчика и особенностей команды разработчиков. Чтобы вам было проще выбирать, мы сравнили популярные методологии и модели управления разработкой ПО:
С помощью правильной методологии вы сможете навести порядок в процессах, улучшить коммуникацию в команде и создавать продукты, которые действительно нужны вашим пользователям. Не бойтесь экспериментировать и искать свой путь. Главное – начать действовать прямо сейчас.
