Kanban/Agile/Scrum/Lean — гибкие методологии разработки

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

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

Что же такое продукт и продуктовый подход? Продукт – это не товар и не услуга в общем смысле. Продукт – это то, за что готовы платить ваши клиенты. Так, продукт компании BMW, это не средство передвижения, это драйв, удовольствие за рулем, статус и безопасность. Соответственно, продуктовый подход – это процесс создания ценности для удовлетворения потребности клиента. Создание продукта — это ключевой этап любого бизнеса. В особенности этот этап важен для бизнеса, связанного с производством высокотехнологичных и инновационных товаров.

Разработка любого продукт имеет свой жизненный цикл, который можно свести к следующим этапам:

• Генерирование идей
• Отбор идей
• Разработка и проверка концепции продукта (что именно и для кого мы делаем)
• Разработка и проверка маркетинговой стратегии (по каким каналам мы сможем продавать)
• Бизнес-аналитика (unit-анализ, проверка сходимости экономики)
• Разработка и проверка товара
• Пробный маркетинг (вывод на рынок MVP – минимально жизнеспособного продукта)
• Коммерциализация (масштабирование)

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

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

Но не все знают, что получили развитие эти методы с Пути Тойоты — Dao Toyota.

Тойота как компания, занимающаяся производством автомобилей, образовалась в 1933 году как отдельное подразделение фирмы Toyoda Automatic Loom, которая ранее выпускала станки для текстильной промышленности. До Второй мировой войны компания процветала, но после — Японию оказалась на проигравшей стороне. В следствии оккупации и инфляции компания Тойота была на грани банкротства. Для того, чтобы выйти из кризиса, владелец и основатель компании Киичиро Тойода был вынужден максимально сокращать расходы. Он вводит политику жесткой экономии, которая закладывает фундамент основного принципа компании – «производства с нулевым запасом». Так появилась философия бережливого производства Тойота. Сподвижником и последователем Киичиро Тойода стал Тайити Оно, который в 1954 году занял пост директора компании. Но уже с середины 50-х годов он начал выстраивать особую систему организации производства, названную производственной системой Toyota или Toyota Production System (TPS).

Тайити Оно сформировал 14 основных принципов управления компанией и сгруппировал их в четыре категории:

Принципы ведения бизнеса на Toyota:

TPS — следующая ступень в развитии эффективного бизнеса после системы массового производства, которую изобрел Генри Форд. За пределами Toyota, TPS часто называют бережливым производством — lean production (этот термин введен Джоном Крафчиком в 1988 году для обозначения методов организации производства, принятых в Toyota).

Т.е. философию Dao Toyota смело можно назвать прародителем как продуктового подхода, так и современных методологий разработки продукта.

Книгу по принципам ведения бизнеса Toyota можно прочесть по ссылке: https://vl.ucoz.org/_ld/0/44_dao_toyota.pdf.

Помимо принципов ведения бизнеса, в Toyota сформировали основные виды потерь. К потерям относится все, что не создает ценности для продукта:

• Перепроизводство (лишний созданный продукт);
• Ожидание (потеря времени);
• Лишняя транспортировка или передвижение;
• Излишняя обработка (например, за счет плохого качества инструмента);
• Избыток запасов;
• Лишние движения;
• Дефекты;
• Неиспользованный человеческий потенциал (это пункт добавил Джеффри К. Лайкер в своей книге «Dao Toyota14 принципов менеджмента ведущей компании мира»);

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

Производственная система Toyota TPS представляет собой уникальный подход к производству. Именно она породила движение за бережливое производство, которое (вместе с концепцией шести сигм) стало одной из доминирующих тенденций в разработке. Однако есть мнение, что несмотря на схожесть TPS и Lean, первое – это путь конкретной компании, а Lean production – набор методов и инструментов, которые базируются на философии Toyota, но могут быть реализованы на других производствах.

Сам термин «Бережливое производство» был введен Джоном Крафчиком в 1988 г. в рамках его работы в Международной автомобильной программе Массачусетского технологического институту. Исследования Крафчика в области бережливого производство были использованы Деймсом Вомеком и Дэниелем Джонсом в книге «Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании». Именно они определили этот термин в 1998 году. Бережливое производство, согласно Джеймсу П. Вомек и Дэниелу Т. Джонсу включает пять этапов:

• Определение ценности для потребителя;
• Выстраивание последовательного потока создания этой ценности;
• Обеспечение непрерывности этого потока;
• Обеспечение «вытягивания» от заказчика;
• Стремление к совершенству;

Таким образом, Lean — это не методология, так как в ней нет набора готовых инструментов. Это часть философии эффективной разработки, которая вышла из философии Toyota и впоследствии стала частью философии Agile. Lean бережливое производство призвано бороться со всеми видами потерь. В основе данной философии лежат принцип вытягивания и принцип «точно в срок» (Just in Time).

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

Принцип «точно в срок» (Just in time) предполагает, что система планирования и организации работы компании построена так, что все необходимые элементы поступают в производственный процесс в нужный момент и в необходимом количестве. Также этот принцип предполагает бездефектное производство, так как брак может сломать всю четкую систему планирования.

К Lean бережливому производству можно отнести следующие методы организации труда и разработки:

• Правило 5 Сигм (сейчас правило 5 Сигм выросло в правило 6 Сигм, в статье указан шестой пункт Дисциплина и привычка) — правильно организованное рабочее место:

• Сортировка (нужное под рукой, не очень нужное – дальше от рабочей зоны);
• Соблюдение порядка (ненужные вещи не должны мешать процессу);
• Содержание в чистоте;
• Стандартизация (процесс должен быть прописан в инструкциях);
• Совершенствование (нужно постоянно развиваться и узнавать новое);
• Дисциплина и привычка;

• Poka-Yoke – «защита от дурака».

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

• Метод быстрой переналадки оборудования (SMED)

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

• Kanban. Остановимся на этом методе подробнее.

Слово Kanban имеет японское происхождение и переводится как «рекламный щит, вывеска».

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

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

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

Основные принципы:

• Визуализация – доска с карточками-задачами (user-stories в разработке продукта). Доска может быть физическая или виртуальная.
• Имеется план разработки, отсортированный по приоритету (backlog в разработке продукта). Может меняться в любой момент.
• Ограничение одновременно выполняемых задач.
• Постоянная оптимизация процессов.

Из этих принципов можно сформулировать и ограничения метода:

• При наличии срочных задач их невозможно запустить в разработку до завершения хотя бы одной из задач в работе (в отличие от Scrum, в Kanban можно взять срочные задачи в разработку сразу по завершении предыдущей задачи, не дожидаясь начала следующего спринта)
• Сложно отслеживать качество выполнения задачи и эффективность отдельного сотрудника.
• Команда должна работать как единый механизм, если кто-то тормозит процесс, страдают все. В связи с этим метод плохо работает для команды более 5 человек.
• Сложно совместить кросс-функциональные команды на одной доске.
• Не предназначен для долгосрочного планирования.

Параллельно с внедрением различных методологий в производстве, развивается процесс разработки программного обеспечения. Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х — начале 70-х годов 20 века в связи с резким увеличением производительности ЭВМ при значительном снижении его стоимости. Именно в этот период программирование из простого кодирования становится инженерной дисциплиной и обрастает дополнительными видами деятельности, такими как разработка требований, создание документации, планирование, тестирование, проектный менеджмент и т.п. Появляются различные методы и практики, а из них стандарты и методологии.

Формируется жизненный цикл разработки ПО, который в общем виде можно представить так:

Методология разработки может быть жесткой (или традиционной), например, по каскадной модели, или гибкой.

Каскадная модель (waterfall) была представлена доктором У. Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывается компетентными сотрудниками, документируется и передаётся дальше. Вся работа идет последовательно от этапа к этапу. Пока предыдущий этап полностью не завершен, следующий запрещено начинать. Подходит для консервативных бюрократических структур. Каскадная модель — это пример жесткой методологии разработки.

Среди гибких моделей разработки наиболее известна модель Agile. Концепция Agile не нова, поскольку гибкое управление проектами широко использовалось еще с 1957 года. Но как философия разработки, Agile пришла благодаря публикации «Манифеста Agile» в 2001 году (можно ознакомиться по ссылке: https://agilemanifesto.org/iso/ru/manifesto.html) . В этом документе особое внимание уделяется взаимодействию участников и возможности изменений, которых не хватает жесткой методологии управления проектами. В манифесте сформулированы 4 ценности и 12 принципов гибкой разработки (вспомним, что у Тайити Оно были сформированы 14 основных принципов управления компанией, сгруппированные в четыре категории).

Основные идеи Agile:

• Люди и взаимодействие важнее процессов и инструментов;
• Работающий продукт важнее исчерпывающей документации;
• Сотрудничество с заказчиком важнее согласования условий контракта;
• Готовность к изменениям важнее следования первоначальному плану;

Сам по себе Agile не является полноценным методом управления проектами, это философия управления разработкой, аналогично тому, как TPS – философия управления производством. Lean, Kanban и другие методы управления проектами, основанные на идеях TPS, адаптированы под разработку ПО с помощью Agile. Если попытаться представить схему взаимодействия этих понятий, то получится сложная структура связанных друг с другом принципов, философий и методологий (под XP можно подразумевать другие инструменты гибкой методологии разработки):

Основное преимущество Agile заключается в его гибкости. Этот подход можно любым способом менять под себя. Вот почему так много других систем управления проектами основываются именно на нём.

Agile, помимо Kanban и Lean, включает в себя такие практики, подходы и методологии, которые помогают создавать продукт более эффективно, например:

• экстремальное программирование (Extreme Programming, XP);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистои комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);

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

Если Agile – это принципы и философия, то Scrum – это набор конкретных правил и регламентов, которые говорят о том, как именно организовывать работу. Довольно часто можно встретить Scrum в сочетании со словом фреймворк, а не словом методология. Фреймворк — это более сформированная методология со строгими правилами.

Scrum появился в 1986 году как способ «наладить взаимодействие нескольких команд, работающих ради единой цели», согласно его изобретателям Икуджиро Нонаке и Такеучи Хиротаке, Scrum сочетает в себе идеи традиционного проектного управления и Agile, являясь одновременно структурированным и гибким способом управления проектами.

Итак, в Scrum все роли и процессы чётко прописаны. Основные категории Scrum – это команда, события, артефакты и метрики.

Scrum команда:

• Product owner – управляет бэклогом. BackLog – набор требований, которые надо реализовать для того, чтобы продукт был готов. Задачи product owner собрать BackLog, сделать его понятным для команды, выставить приоритеты. BackLog постоянно обновляется в зависимости от текущих целей разработки.
• Development team – команда разработки. Люди должны быть кросс-функциональны, т.е. иметь унифицированные компетенции (каждый должен уметь делать все).
• Scrum master – координирует команду. Специалист по Scrum, досконально знает этапы, церемонии, артефакты Scrum разработки.

Scrum события:

• Sprint – время, за которое создается инкремент продукта — готовый для конечного пользователя продукт.
• Планирование Sprint’а – участвует вся команда. На планировании Спринта решается, каким будет инкримент, и как организовать работу, чтобы успеть сделать все задачи. Выбираются задачи из бэклога продукта (формируется бэклог спринта).
• Ежедневные митинги (daily meeting) – на них обсуждается, что сделано за предыдущий день, что будет делаться сегодня, какие проблемы мешают достижению целей спринта.
• Sprint review meeting (обзор спринта) — подведение итогов спринта, демонстрация инкремента продукта для product owner или заказчика. Все члены команды участвуют в этом митинге.
• Ретроспектива – на нем высказываются о прошедшем спринте: что было сделано хорошо, то надо улучшить в следующем спринте.

Scrum артефакты:

• Бэклог продукта;
• Refinement — уточнение бэклога продукта (уточнение и упорядочение бэклога). Проводит product owner;
• Definition of ready — критерии подготовленности – фокус на требованиях к задачам в бэглоге до планирования итерации;
• Definition of done — критерии готовности – определяются на планировании спринта, сводится фокус на инкременте, который надо проверить на соответствие общей идеи продукта.
• Пользовательские истории (user stories) – задачи бэклога и спринта.
• Покер планирование (Planning poker) — оценка сложности user stories.
• Бэклог спринта — максимальное кол-во user stories в спринте
• Инкремент продукта.

Метрики:

• Velocity (скорость) – среднее кол-во задач, которое команда выполняет в спринт;
• Capacity (ёмкость) — доступное время команды;
• Диаграмма сгорания задач;
• Накопительная диаграмма потока;

Набор принципов, процесс разработки происходит в жесткие регламентированные отрезки. В конце каждого спринта должен быть работающий продукт с новым функционалом. Здесь используется итеративный инкрементальный подход. Особенность Scrum является возможность корректировать предыдущие этапы. Scrum разработку можно представить следующим процессом:

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

Среди преимуществ Scrum можно выделить:

• Возможность быстрого запуска проекта с наиболее приоритетными функциями и минимально возможным бюджетом;
• Ежедневный контроль над ходом работ, и более гибкий контроль над бюджетом проекта;
• Малую вероятность провала разработки из-за частых совещанием с заказчиком продукта;
• Возможность вносить коррективы в техническое задание по ходу реализации проекта;
• Контроль над процессом разработки;

К недостаткам Scrum относятся:

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

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

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

В завершение хочется обратить внимание, что для успешного применения гибких методологий в разработке, требуется сильная корпоративная культура и осознанная команда. Т.е., как и в системе TPS, на первое место выходит человек. Об этом не стоит забывать, внедряя современные технологичные ИТ решения в свой бизнес.

#scrum #agile #lean #kanban #toyota