Skip to main content

Методики разработки

Software Development Lifecycle​

agile

Условное разбиение процесса разработки на этапы. Позволяет выбрать модель SDLC.

  • I этап: АНАЛИЗ и ПЛАНИРОВАНИЕ (ПОДГОТОВКА) (manager -> бизнес-аналитик)
    • идея, цели и задачи проекта
    • оценка сроков, команда и стоимость
    • анализ и формирование требований заказчика (конкуренты, фокус-группы, опросы и т.д.)
    • все вышесказанное формируется и оформляется ТЗ на разработку ПО
  • II этап: ПРОЕКТИРОВАНИЕ и ДИЗАЙН (manager -> designer)
    • прототипы, дизайн-мокапы, макеты, ui-kit, UI-framework
  • III этап: РАЗРАБОТКА (solution architect и developers и qa)
    • выбор технологий frontend, backend, database и т.д.
  • IV этап: ТЕСТИРОВАНИЕ (и ДОКУМЕНТИРОВАНИЕ) (manager -> qa и developers)
  • V этап: РЕЛИЗ (размещение на рынке) (manager -> dev ops)
  • VI этап: ПОДДЕРЖКА (manager -> тех. поддержка и developers)

Классические модели SDLC (устаревшие)​

Статья

  • Водопад (Waterfall, каскадная модель)

waterfall

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

  • V-образная (усовершенствованный Waterfall)

Каждый этап после закрытия отдельно тестирруется и дорабатывается.

v-model

  • Инкрементальная

Поэтапная разработка. Фича за фичей (то, что используется в Agile). Новая версия продукта в конце каждого инкремента.

  • Итерационная

Тоже поэтапная разработка, только если в инкрементальной модель конец каждого этапа - это новая версия продукта, то в итерационная - это отдельная часть продукта (как в водопаде), отличие от водапада в том, что здесь эта модель не так привязана к документации.

  • Спираль

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

  • Модель-хаоса

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

Agile - Выжимка всего лучшего из классических моделей​

Это просто набор правил, которые разработчики вынесли в манифест из 17-ти принципов для того, чтобы всем было проще работать в команде.

Разработана в 2001-году 17-тью разработчиками (Snowboard-17). Agile - "гибкий, проворный".

agile

Принципы Agile (манифест):​

  • Удовлетворить потребности заказчика - это главное в разработке.
  • Изменение требований приветствуется (модель гибкая, анти-водопад). Минимум правил и ограничений.
  • Выпускать продукт нужно как можно чаще (в конце спринта). В конце каждой итерации - рабочаяя сборка ПО.
  • Разработчики и представители бизнеса должны работать вместе.
  • Мотивация для команды. Нужно её постоянно усиливать.
  • Живое общение является наиболее эффективным способом коммуникации.
  • Работающий продукт - это главный показатель прогресса работы.
  • Спринт. Итеративный подход, постоянный ритм.
  • Параллельность задач. Минимализация лишнего.
  • Реторспективы. Самоорганизация команды и улучшение эффективности.
  • Работающий продукт важнее документации.

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

Каждая итерация - это спринт.

agile

SCRUM​

Самая популярная модель SDLC на текущее время.

Product owner -> Manager (SCRUM-мастер) -> Team (5-9 человек).

Перед спринтом планирование (2-4 ч), в конце спринта - ретоспектива (2-4 ч). Каждый день dayly-митинги (10-15 мин).

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели.

Хорошо подходит для MVP и стартапов.

Планирование спринта 1 --> Спринт 1 --> Демо 1 --> Ретроспектива 1 --> Планирование спринта 2 --> ...

Product owner​

Владелец бизнеса. От кого исхотят задачи. Генератор идей (backlog продукта).

Scrum-master​

Тот кто, управляет всеми процессами в SCRUM. Но важные решения должна принимать именно команда. Создает комфортные условия для всей команды. "Ведущий" митингов. "Разруливатель" проблем и конфликтов.

Scrum-team​

Команда, которая работает внутри SCRUM.

sprint

Ретроспектива​

  • Оценка спринта
  • Что было хорошо
  • Что было плохо
  • Оценка ретроспективы

Инструменты для SCRUM​

KANBAN​

kanban

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

Отличие от SCRUM в том, что в SCRUM задачи обычно зафиксированы спринтами, а в Kanban задачи можно добавлять/удалять хоть каждый день.

В Kanban оценка задач по времени нет так сильно важна как в SCRUM.

В Kanban главная цель закончить задачи, а в SCRUM - спринт.

Примерный рабор колонок в Kanban-доске:​

  • BACKLOG (Project backlog) - весь список задач проекта
  • OPEN (TODO, Sprint backlog) - открытые задачи в текущем спринте (уже назначенные на кого-либо или нет)
  • DEVELOPMENT (In process) - задача в работе, значит что над ней сейчас кто-то уже работает
  • CODE REVIEW - Задача на проверке кода
  • DEPLOYED ON TEST - Задеплоено на тестовый сервер, чтобы тестировщик мог проверять
  • QA (Testing) - Задача прошла CODE REVIEW и сейчас её проверяет тестировщик
  • DONE - Задача готова, получен апрув от тестировщика
  • DEPLOYED ON PROD - Задеплоено на основной сервер, пользователи уже видят обновления
  • CLOSED - Задача сделана и закрыта

Инструменты для KANBAN​

Scrumban​

В чистом виде отдельные методы встречаются редко.

Это по сути SCRUM, но для отображения видимости задача на спринте используют доску как в Kanban. В основном пользуются таким подходом.

Идея создания продукта​

MVP​

kanban

Концепция Minimal value product.

  • Не нужно тупо реализовывать какую-либо большую идею и тратить на неё большие деньги.
  • Разработай сначала что-то малое и проверь нужно ли это рынку.
  • Запусти сначала "Искуственный спутник Земли", не делай сразу МКС.

Продуктовый подход​

Создать что-то, за что клиенты будут готовы платить.

Нужно проверить идею заказчика:

  • Изучи (проверь гипотезы) ->
  • Построй (теоритическая идея MVP) ->
  • Измерь (подсчет затрат и примерной прибыли).

Почему проваливаются стартапы? (Возможно продукт очень сильно инновационный).

  • Нужен ли этот продукт рынку?
  • Готов ли рынок к этому продукту?
  • Есть ли у пользователей интерес к этому продукту?

Customer development (CusDev)​

Фреймворк для изучении идеи. Изучение потребностей рынка для анализа своих идей.

I - Ищем потребности (нереализованные на рынке)

  • есть ли потребность?
  • насколько она сильна?
  • не стоит доверять прогнозам, лучше сделать опросы
  • разные категории общества (хотя бы опросить 10-40 человек для получения информации о своих гипотезах, ищем повторяющиеся проблемы у разных людей)

II - Ценностное предложение

III - Проверяем решения

IV - Проверяем монетизацию

V - Итеративное улучшение