Презентация
серверов от Acer
До начала осталось:
Смотреть
{"id":2972,"title":"\u0412\u0435\u0431\u0438\u043d\u0430\u0440 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u0431\u0438\u0437\u043d\u0435\u0441\u0430 \u043e\u0442 Microsoft","url":"\/redirect?component=advertising&id=2972&url=https:\/\/vc.ru\/promo\/231217&hash=2af4649e2f1fb9d084608dab3d710d3891bb2460260cc7224d84dec68fae15c3"}
Карина Горбунова

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

Введение

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

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

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

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

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

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

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

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

Dao Toyota

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

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

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

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

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

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

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

Dao Toyota, Lean и Kanban

Помимо принципов ведения бизнеса, в 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 представлен ниже. В общем случае каждый столбик является отдельным этапом жизненного цикла разработки.

Доска Kanban Горбунова Карина

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

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

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

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

Модели разработки. Agile

Параллельно с внедрением различных методологий в производстве, развивается процесс разработки программного обеспечения. Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 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.

Scrum

Если 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 разработку можно представить следующим процессом:

Agile методология

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

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

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

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

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

Заключение

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

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

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

{ "author_name": "Карина Горбунова", "author_type": "self", "tags": ["toyota","scrum","lean","kanban","agile"], "comments": 14, "likes": 3, "favorites": 11, "is_advertisement": false, "subsite_label": "unknown", "id": 218436, "is_wide": true, "is_ugc": true, "date": "Tue, 09 Mar 2021 23:53:30 +0300", "is_special": false }
0
14 комментариев
Популярные
По порядку
Написать комментарий...
3

От названия статьи уже немного кровавые слёзки, страшно читать дальше

Это примерно "Борщ/морковь/еда/кола - виды салатной солёности"

Ответить
0

Андрей, т.к. статья теоретическая, то мне было интересно разобраться что из чего следует и почему. Сейчас со всех сторон тренеры по Agile советуют, как лучше запустить у себя гибкие методологии, а потом внедрить Kanban и "может быть вам нужен Scrum мастер?". Поэтому название символизирует для меня именно сборную солянку терминов, в которых среди моих знакомых досконально никто не разбирается. Статья была моей попыткой разобраться. Прочитала 10ки статей до того, как ее написать. Но если вы посоветуете что-то, где будет более структурировано все расставлено по полочкам, буду признательно

Ответить
1

Попробуйте почитать первоисточники:
https://resources.kanban.university/guide/
https://scrumguides.org/scrum-guide.html

Русскоязычный ресурс по Канбан методу:
https://kanbanguide.ru/

Ответить
1

Не знал про Тойоту, очень позновательно!

Ответить
1

Да, за Тойоту отдельное спасибо!

Ответить
1

Я так из статьи и не понял, каки образом реализуется принцип  «точно в срок» используя Канбан в ИТ, автор может пояснить по подробнее?

Ответить
0

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

Ответить
0

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

За счет чего?
Почему это принцип  «точно в срок»?
А не принцип  «когда вы мне все это сделаете»?
В чем разница? 

Ответить
1

Карина! Спасибо! Подписался по колокольчику)

Ответить
1

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

Например, в скрам-артефактах собрано все подряд, чего и нет в скрам-гайде: definition of ready, planning poker даже не упоминаются в гайде.
Скрам не появился в 1986. В 1986 вышла статья The New New Development game, где упоминается термин Scrum из регби. Только в 1993-1995 годах оформились первые идеи с виде фреймворка. 

Про Канбан-метод - ну совсем мимо кассы. 
Agile - это не методология, не управления и не проектами. И фраза "Lean, Kanban и другие методы управления проектами" убивает наповал. И т.д. 

Ответить
0

Было бы здорово услышать от автора пояснения про описанные в статье особенности Канбан метода. Особенно про ограничения.

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

Ответить
0

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

Ответить
0

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

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

Мы у себя применяем классы обслуживания. Например, они задаются SLA на сервисы, например на уровень критичности ошибок.
В таком случае критические ошибки с приоритетным SLA, берутся в работу без очереди. Чтобы это стало возможным с небольшим влиянием на "обычные" задачи, резервируется определенный % от ресурсов команды, который не используется под планирование "обычных" задач. Если "критических" ошибок не случилось за какой-то период, "обычные" задачи можно сделать быстрее.

И это только по одному ограничению. А что с остальными? Вы их тоже не рассматривали?

"Сложно отслеживать качество выполнения задачи и эффективность отдельного сотрудника."
Почему? В чем вы видите сложности? Почему их нет в сравниваемом Scrum (раз они не указаны в минусах)?

"Команда должна работать как единый механизм, если кто-то тормозит процесс, страдают все. В связи с этим метод плохо работает для команды более 5 человек." Почему вы так решили? Как быть с примерами, когда по процессу, построенному с помошью Канбан метода успешно работают команды в 10-20 человек? Вы не указали этот минус для Scrum - в нем нет такой проблемы? 

"Сложно совместить кросс-функциональные команды на одной доске." — в чем вы видите проблему сложности? 

"Не предназначен для долгосрочного планирования." — почему вы так решили?

Ответить

Комментарии

null