Всё, что нужно знать об SDLC и Agile, это то, что это про деньги. Чем чаще релизы, тем чаще можно брать за это деньги.

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

Аналогия со строительством дома не подходит к разработке. Ближайшая метафора - конструкторское бюро или исследовательский центр.

Традиционные подходы

Waterfall

Без комментариев, все знают что такое waterfall и как долго заказчику приходится ждать первых результатов.

RUP

Компания Rational Software изобрела унифицированный язык описания объектно-ориентированной модели UML, и описала фазы разработки как:

• Inception (discovery)
• Elaboration (architecture)
• Construction (MVP)
• Transition (production)

У каждой из фаз может быть несколько итераций, и у каждой из фаз есть свои вехи и дедлайны.

В разработке в той или иной степени (в зависимости от фазы) учавствуют следующие дисциплины:

• Моделирование бизнеса
• Требования
• Анализ и дизайн
• Разработка
• Тестирование
• Публикация (deployment)
• Управление конфигурациями
• Проектный менеджмент
• Среда (environment)

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

Ранний Agile

DSDM

Чтобы делать продукты быстрее и дешевле, в 1994-м году энтузиасты создали DSDM (Dynamic System Development Method) консорциум, который в 2014-м году выпустил публичный handbook и переименовался в Agile Business Consorcium.

DSDM состоит всего из трех фаз:

• Предпроектная подготовка - анализ, оценка реализуемости, бизнес-кейсы
• Проектный жизненный цикл - итеративная разработка, определение максимального лимита времени, MoSCoW-приоретизация (Must, Should, Could, Won't)
• Постпроектный этап - ретроспектива

FDD

Ещё один подход к разработке - очень легковесный и простой - FDD (Feature Driven Development). Фича - это работающая функция, которая приносит бизнес-ценность. Продукт - это просто набор готовых фич. В результате, поставляются только готовые фичи. Описание фичи содержит в себе действие, объект и результат.

Жизненный цикл FDD состоит из пяти этапов:

• Разработка общей модели (доменная модель)
• Написание списка фич
• Планирование фич
• Дизайн фич
• Разработка фич (dev, test, deploy)

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

Crystal Methods

Это семейство методологий, помеченных цветами. Выбор метода зависит от размера команды и критичности фейла продукта. Критичность оценивается возможными потерями и ранжируется по следующей шкале - комфорт, деньги, большие деньги, жизнь. Размеры команд - 1-6, 7-20, 21-40, 41-80, 81-200.

Чем больше команда и чем выше риски, тем больше формализованных процессов добавляется к методу.

Основные ценности этого метода - люди, близкие и открытые коммуникации, легкий доступ к экспертам, персональная безопасность, частые поставки и ретроспективы, а также все современные техники, такие как автотесты и CI/CD

Современные методы разработки

Scrum

Как методология был описан ещё в 1995-м. В одном предложении это маленька кросс-функциональная команда, которая короткими итерациями работает над созданием работающего продукта. Итерации называются спринтами (от дня до 30 дней).

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

Основные артифакты:

• Продуктовый бэклог - пополняемый набор задач
• Бэклог спринта - задачи, готовые к работе
• Ежедневные планёрки - что сделано, что будешь делать, есть ли проблемы
  • План действий
• Продуктовый инкремент - релиз

Роли: владелец продукта (PO), скрам-мастер (SM) и команда разработки (Team).

PO владеет продуктовым бэклогом - задачами, дефектами, пользовательскими историями, требованиями, улучшениями и тд. Он определяет что будет сделано и в каком порядке.

SM это Agile-коуч, это лидер и фанатик оптимизации, он не рулит, он толкает.

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

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

Lean Software Development

Смоделирована по принципам производства Toyota. Фокусируется на минимизации затрат, визуализации продуктивности и находить узкие места.

Один из артифактов - Value Stream Map. Он должен содержать только важные шаги и никаких лишних телодвижений.

Основные принципы этого метода

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

Kanban

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

Kanban позволяет получить усредненное значение времени, необходимого на работу над задачей путем простого разделения количества задач в колонке на время прихода этих задач.

Kanban позволяет визализировать узкие места и вовремя среагировать на них благодаря ограничению на количество задач. Каждая колонка может быть разделена ещё на две - в процессе и сделано.

Единственная церемония - ежедневные стендапы перед доской. Итерации отсутствуют, происходит непрерывная поставка по мере готовности.

Экстремальное программирование (XP)

Состоит из коротких недельных итераций, клиенто-ориентированной колаборации и ежеквартального макро-планирования. На дизайн тратится не более 10 минут, также часто используется парное программирование и TDD.

Spotify Agile

Фишка в том, что Spotify отказался от использования любых методологий в пользу изучения реальных кейсов и создание культуры взамен какой-либо одной методологии ради гибкости. Подход к релизам у них следующий - небольшие группы людей работают над задачами в параллели и выпускают небольшие частые релизы. Релиз должен быть рутиной, а не драмой. Они также ввели понятия "поезда релизов" и фича-тогглинг (выключание фич по запросу и готовности сторонних систем)

Для постоянных улучшений используется Kata Board - описание проблемы, идеальное решение, реалистичный вариант и как выход - 3 топ действия которые приведут к улучшению.

Также Spotify широко используют понятие гильдий - людей с одинаковыми интересами, объединенные в комьюнити для обмена знаниями.

CI/CD

Все просто

• CI требует от разработчиков стабильных инкрементов
• CD требует от продакшн-сред стабильности и безболезненных релизов

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

Несколько дополнительных подходов

CMMI - Capability Maturity Model Integration

Это модель и гайд для улучшения процессов организации, используется практически во всех сферах.

Модель содержит оценку зрелости от 1 до 5, где:

1. Непредсказуемость и реактивность - не укладываемся в сроки и бюджеты
2. Менеджмент на уровне проекта - присутствует планирование, оценки, контроль
3. Проактивность - менеджмент на уровне организации - стандартизация проектов, програм и портфолио
4. Количественный менеджмент и контроль - предсказуемые улучшения, основанные на фактах, полученных системами учета
5. Стабильность и гибкость - организация сфокусированна на постоянных улучшениях, а стабильный фундамент позволяет гибко встречать изменения и возможности

Six Sigma

Это техника для решения проблем из Моторолы. И тема для отдельного поста ввиду обширности тулсета, от PDCA до DMAIC.

Обзор методологий описаны по мотивам курса Software Development Life Cycle (SDLC) with Shashi Shekhar на LinkenIn Learning.