Kanban framework что это

Обновлено: 24.01.2025

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

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

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

Гибкие подходы

Agile — это гибкий структурированный итеративный подход к управлению проектами. Собственно, отсюда и название — Agile — «гибкий, проворный». На самом деле, это нечто большее. Это не отдельная методология, а целая система гибких подходов, в которую входят не только Scrum и Kanban.

Ценности Agile:

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

«Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева», — подчеркивается в Agile-манифесте.

Agile-манифест — основной документ эджайлистов, созданный в 2001 году, в котором описаны ценности и принципы гибкого подхода.

Принципы Agile

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

Мотивация — то, на чем держится проект. PM заинтересован в том, чтобы замотивировать команду и обеспечить поддержку владельцам бизнеса. Эффективнее всего это можно сделать на встречах, где передача информации происходит лично, в присутствии всех и вне переписок, чтобы избежать эффекта «испорченного телефона».

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

Так как команда в Agile самоорганизующаяся, то она самостоятельно анализирует свои действия и корректирует их. Постоянное внимание к техническому совершенству и качеству архитектуры способствует той самой гибкости, которая так важна в Agile.

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

Слышали, что «простота — лучшее качество человека»? Так вот, не только человека, еще и работы. Не делать того, что не прописано в требованиях, — искусство, так как часто хочется добавить «чего-нибудь эдакого». Нужно быть осторожным и вовремя остановиться, ведь добрые намерения могут сыграть злую шутку. Agile не приветствует того, что выходит за рамки, чего-то «сверх-». Поэтому не надо делать лишнего. Просто не надо.

Как в Agile отслеживается прогресс проекта? Работающим программным обеспечением. Этот пункт включает в себя все предыдущие. Без успешной реализации каждого предыдущего этапа и следования каждому из принципов, на которых базируется Agile, работающего ПО не выйдет.

Scrum

Возможно, когда кто-то слышит фразу «гибкий подход», в голове появляются яркие картинки хаоса, убегающих от дедлайнов разработчиков и рвущих на себе волосы PM-ов. Scrum, хоть и гибкий, но структурированный подход. Давайте будем как Scrum и разберёмся со всем по порядку.

Scrum-команда: можно ли накормить всех двумя пиццами

Некогда Джефф Безос, создатель Amazon, установил правило: каждая внутренняя команда должна включать в себя такое количество сотрудников, чтобы их можно было накормить двумя пиццами. Дело в том, что продуктивно работать и сотрудничать друг с другом можно, только если в команде будет немного людей. Скажем, 5-9.

Возможно, в те времена люди ели меньше или пиццы были больше по размеру, но суть этого правила Scrum перенял . Количество человек в команде не должно превышать 9. Если больше — это уже не скрам-команда.

В такой команде существует 3 роли:

product owner (владелец продукта), который по сути выступает в роли голоса заказчика;
scrum-мастер — мастер-джедай, который координирует работу в команде и является своеобразным мостом между продакт оунером и командой разработки;
команда разработки — самоорганизующаяся и кросс-функциональная .

Итерации: почему спринты, а не рабочие недели

Scrum — итеративный подход. Итерации называются «спринтами», их длительность определяется на старте проекта и фиксирована до конца. Обычно спринты длятся от двух до четырех недель (очень редко — одну неделю). Чем они короче, тем легче работать с изменениями. Когда спринт 1- или 2-недельный, легче вносить правки в продуктовый бэклог в случае необходимости, чем когда итерация длится 4 недели. Миллионы корректировок нежелательны во время спринта, но возможны. Если выясняется, что задача в работе не так уж важна для клиента и абсолютно нерелеванта для проекта в целом, то она однозначно убирается.

Зачем вообще нужны эти спринты, когда есть обычные человеческие недели? Чтобы лексикон разработчиков пополнился еще одним словом? Конечно нет, это мерило. За спринт команда должна сделать запланированный скоуп.

Скоуп (scope) — содержание проекта: что, каким образом и для кого должно быть сделано, чтобы проект считался реализованным.

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

Цель фреймворка — закончить спринт, в идеале выполнив все задачи. Самое главное — предоставить клиенту рабочую версию продукта на демо. Бывает, что какую-то из задач не успевают реализовать. Если для того, чтобы фича работала, эта задача не обязательна, не страшно : она перенесётся на следующий спринт.

Митинги: трата времени или важная стратегическая часть Scrum-а

Sprint planning meeting

На этом митинге решается судьба. Нет, не человечества — спринта. На нём присутствуют Scrum-мастер, Product Owner и команда разработки. Владелец продукта рассказывает, какой результат хочет видеть в конце спринта. Разработчики выясняют нужные моменты во избежание миллиона вопросов, которые могут появиться в процессе. Команда разбирается с нагрузкой. Исходя из всего этого определяется цель спринта. Так проходит первая часть митинга. Во второй части команда составляет спринт бэклог — задачи, которые нужно реализовать.

Длительность митинга зависит от длительности спринта. На собрание по планированию выделяется по 2 часа на каждую неделю в спринте. Если определяем, что спринты будут длиться 2 недели, то на планирование нужно выделить 4 часа. Если весь кофе выпит, спина заболела от долгого сидения на митинге, а длительность перевалила за 8 часов — что-то пошло не так. Задумайтесь: это случайность или есть тенденция затягивать собрания? В случае закономерности скорее всего ваш Scrum нужно масштабировать .

Daily Scrum Meeting

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

Так как Scrum-команда кросс-функциональна, все участники взаимосвязаны. Легче за какие-то 15-20 минут разобраться, кто и как связан в задачах, к кому идти и кто от кого что сегодня ждет, чем на протяжении дня пинговать всех на свете.

Вопросы, которые хоть и повторяются из митинга в митинг, но которые очень помогают понять текущую ситуацию по прогрессу:

Что было сделано?
Что запланировано?
Есть ли проблемы, и что может помочь?

Sprint review meeting

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

Время для ревью выделяется прямо пропорционально количеству недель в спринте: для недельного спринта — час, для трёхнедельного — три.

Sprint retrospective meeting

Скалолаз, который достиг вершины горы, оглядывается на проделанный путь, ловит какие-то инсайты, хвалит себя за то, чего добился. Делает пометки в голове наподобие «В следующий раз нужно купить более надежную экипировку». В Scrum-е это называется ретроспективой. Команда собирается, чтобы выяснить:

Что было хорошо?
Что было плохо?
Что можно улучшить?

Ретро проводится в последний день спринта. Не существует каких-то четких временный рамок. Обычно на этот митинг потребуется 45 минут, умноженные на количество недель в спринте.

Мы рассказали об артефактах, которые холят и лелеют в скраме. Если по какой-то причине у вас с ним не ладится, советуем прочитать статью, в которой скорее всего найдете решение проблемы.

Kanban

Если Scrum — структурный подход, то Kanban можно назвать подходом баланса. Визуальный метод, благодаря которому предельно ясно, за что нужно браться в первую очередь. Здесь целью являются выполнение задачи. Изменения и смещения по плану принимаются безболезненно. Никого пиццами кормить не нужно. В Kanban-е нет ограничения по количеству человек в команде и по длительности итераций, нет командных ролей и обязательных митингов. Что есть вместо этого? Обо всём по порядку.

Командные роли: есть кто живой

Scrum — не Scrum без Scrum-мастера и других ролей. В Kanban-е всё по-другому. Командных ролей нет, есть «команда». «И за всё, что мы делаем, отвечаем тоже вместе!» — слышали такое? Это девиз команды, работающей по Kanban-у, потому что за ход всего проекта отвечают все.

Из-за особенностей Kanban-а, о которых поговорим далее, команда может включать в себя несколько узкопрофильных подкоманд: дизайнеров, разработчиков, аналитиков. Не всегда их работа происходит параллельно, особенно на первых этапах разработки. Прежде, чем мастера кодов приступят к работе, дизайнерами уже должен быть разработан прототип, который основан на данных, которые в свою очередь должны быть собраны аналитиками.

Процесс: бездедлайновый хаос

В Kanban-е нет спринтов. Вся работа над проектом происходит непрерывно. Важные проектные события — планирования, релизы — происходят тогда, когда решит команда. Это может быть конкретный день недели, а может быть «делаем это после того, как сделаем это». Таким образом релизы не привязаны к концу итерации. Сделали существенно раньше, чем предполагалось? Отлично! Сделали позже? Бывает.

Доска Kanban

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

Движение задач на доске происходит слева направо: от статуса To Do, где собраны все задачи для реализации, до Done, где задачи достигают своеобразного дзена. Когда все задачи перейдут в колонку Done, считается, что проект готов.

Задачи на доске визуализированы благодаря карточкам, на которых указан приоритет, нужный для понимания очередности выполнения задач. Для того, чтобы мозг не закипел, а команда не работала над задачами 24 часа в сутки, задачи в каждом из статусов ограничены по их общему весу. Вес — мера, которая показывает, сколько времени «весит» задача. Команда сама определяет на начальном этапе, как долго нужно просидеть над задачей, и ставит каждой задаче свой вес. Если в колонке «Testing» ограничение в 3, то общий вес задач в этом статусе может быть 3.

Статусы Kanban

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

Исходя из потребностей команда может добавить и другие колонки. Например, Blocked — когда задача уже сделана, протестирована, но из-за каких-то ошибок не может быть перенесена в колонку Done как готовая и без багов.

Что лучше: Agile, Scrum или Kanban

Agile, Scrum и Kanban объединяет мысль о том, что люди — ключевое звено проекта. Помимо взаимоотношений всегда будут принципы, которые будут важны одной команде и абсолютно безразличны другой. Это и отличает их друг от друга.

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

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

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

Ира Демченко

Копирайтер в IAMPM. Любит котиков, настолки и сложноподчиненные предложения. Пишет, потому что по-другому просто не может.

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

Что же такое Agile?

Вся работа над проектом разделяется на короткие циклы (итерации) и ведется поэтапно;
В конце каждой итерации заказчик получает готовый минимально работающий продукт или его часть, которую уже можно использовать;
В течение всего рабочего процесса команда сотрудничает с заказчиком;
Любые изменения в проекте приветствуются и быстро интегрируются в работу.

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

Так выглядят аджайл спринты

Scrum

Термин Scrum пришел из регби. Он означает особую фигуру, в которую собираются игроки перед началом матча, и выглядит это примерно так:

Фигура Scrum в регби

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

Kanban

Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски.

Визуализация задач в канбане

Пример утреннего митапа

Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды.

Наши авторы

Профессионалы, работающие с Sony, NASA, Сбербанк, МТС, Nokia и многими другими компаниями. Спикеры на конференциях, авторы статьей

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

Стандартный фреймворк для управления проектами можно разбить на три большие части:

Жизненный цикл проекта. Ключевое различие между методологиями Waterfall и Agile заключается в том, что эти фреймворки включают в себя разные жизненные циклы. Например, фреймворк Waterfall состоит из пяти стандартных фаз:
Подготовительный этап
Планирование
Исполнение
Контроль
Завершение

Фреймворк Agile скорее всего будет использовать модифицированный жизненный цикл, лучше отражающий гибкую и итеративную природу Agile-методологии.

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

Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.

В чем разница между методологией и фреймворком?

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

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

Б. Что общего у Agile-фреймоворков?

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

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

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

В. Фреймворк Scrum

Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.

Как и в случае других Agile-фреймворков, Scrum использует итеративный подход к управлению проектами. Методология Scrum предписывает разбить проект на спринты длительностью от одной до четырех недель. Каждый спринт заканчивается созданием работоспособной версии черновика продукта.

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

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

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

Прозрачность. Необходимо использовать общий язык и стандартные определения.
Инспекция. Артефакты и продукты должны регулярно и тщательно проверяться для обеспечения качества.
Адаптация. Если инспекция выявит качество ниже стандартного уровня, команда обязана как можно быстрее внести корректировки или исправления.

Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:

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

Scrum также имеет собственную уникальную терминологию. Далее приведены важнейшие термины, часто используемые при работе с фреймворком Scrum:

Бэклог продукта. Бэклог — это список задач и требований, которые должны быть выполнены применительно к конечному продукту. За создание бэклога и управление им отвечает владелец продукта.
Спринт. Спринт — это период времени для выполнения набора задач из бэклога. Длительность спринтов должна быть одинаковой. Обычно это две недели, хотя спринт может длиться от одной до четырех недель в зависимости от потребностей команды и проекта.
Планирование бэклога. Планирование бэклога (иногда его еще называют планированием спринта) — это определение задач в бэклоге, которые нужно включить в каждый из спринтов.
Бэклог спринта. Часть бэклога, назначенная текущему спринту.
Ежедневный Scrum. Проектная группа встречается каждый день, чтобы обсудить ход работ за последние сутки, ожидаемый прогресс за следующие сутки и возникающие проблемы. Обычно такие встречи называются ежедневный Scrum или стендап и длятся около 15 минут.
Ретроспектива. Каждый спринт должен заканчиваться обзорным совещанием, которое называется ретроспектива. Команда рассматривает свои достижения и обсуждает возможности что-то улучшить в ходе следующего спринта.
Scrum-доска. Scrum-доска помогает участникам команды видеть бэклог спринта и управлять им. Доска может быть настоящей или виртуальным инструментом в системе управления проектами. Обычно на доске есть три столбца: «К исполнению», «В работе» и «Выполнено». По мере выполнения объектов из бэклога они перемещаются по доске из одного столбца в другой. Поэтому все видят, что им нужно делать в следующем спринте и как продвигается работа.
Артефакт. Бэклог продукта, бэклог спринта и инкремент продукта — это три артефакта Scrum в проекте. Бэклог продукта и бэклог спринта отражают работу, которую нужно сделать, а инкремент продукта — это часть продукта, которую команда создала в ходе текущего спринта.

Г. Другие популярные Agile-методики управления проектами

Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:

1. Kanban

Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.

Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.

Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.

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

Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.

Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:

Игра в планирование
Частые небольшие релизы
Приемочное тестирование клиентом
Простота проектирования
Парное программирование
Разработка через тестирование
Рефакторинг
Непрерывная интеграция
Коллективное владение кодом
Стандарт оформления кода
Метафора системы
40-часовая рабочая неделя для программистов

3. Функционально-ориентированная разработка (FDD)

Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.

Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:

Разработка общей модели
Составление списка необходимых функций системы
Планирование работы над каждой функцией
Проектирование функции
Реализация функции

4. Метод разработки динамических систем (DSDM)

Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.

Этот фреймворк основан на восьми основных принципах:

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

5. Crystal

Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.

Является ли бережливое управление проектами (Lean) Agile-фреймворком?

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

Устранение потерь
Повышение качества
Создание знаний
Отсроченные обязательства
Быстрая поставка
Уважение к людям
Полная оптимизация

Д. Определение эпика Agile

В Agile-методологии управления проектами эпики — это «крупные истории пользователей».

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

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

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

Еще один важный термин — это «тема». Тема — это набор историй пользователей, которые связаны между собой или могут быть отнесены к одной категории. Например, если вы планируете строить дом, то можете сгруппировать все электротехнические требования в одной теме, а требования к качеству строительных конструкций в другой.

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

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

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

Вы можете отслеживать крупные, нечетко определенные идеи в своем бэклоге. Можно записать требование как эпик, а затем изменить его по мере выполнения проекта.
Вы можете установить иерархию для элементов вашего бэклога. Эпик остается в бэклоге в виде оригинальной идеи или требования. Связанные с ним истории пользователей отслеживают аспекты продукта, которые позволят это требование удовлетворить.

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

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

Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.

Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка

Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?

Ни один фреймворк не является универсальным, так что очень важно оценить отдельные проекты и потребности команды.

Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).

Оцените объемы проекта. Большой длительный проект может быть трудно разбить на двухнедельные спринты. Но если его размах трудно определить и он может расти, то Agile, скорее всего, лучше подойдет, чем более традиционный фреймворк.
Определите движущие факторы проекта. Очень важно знать экономическое обоснование проекта и его ценность для организации. Какие преимущества он даст вашей компании?
Составьте представление о ключевых целях клиента, ожидаемых результатах и приоритетах проекта.
Выявите все факторы, цели, результаты и приоритеты проекта, на которые могут повлиять различные методологии. Например, если ваша цель — максимальная экономичность, возможно, вам подойдет бережливая методология Lean. Если клиент рассчитывает получить подробную документацию, правильным выбором может стать FDD.
Составьте список возможных методологий, подходящих для вашего проекта, и расставьте их по порядку на основе критериев, выявленных на прошлом этапе.
Выбирайте фреймворк, подходящий для большинства факторов, целей, результатов и приоритетов. Если какие-то результаты важнее остальных, можете расставить приоритеты, чтобы не упустить самое важное. Вам нужно выбрать фреймворк, который даст наилучший результат с наименьшим риском.
Выбрав фреймворк, отслеживайте его эффективность. Суть всех Agile-методологий заключается в гибкости и адаптивности. Если выбранная вами методология не дает желаемого результата, следует модифицировать или даже заменить ваш фреймворк.

Ж. Бесплатные инструменты для управления Agile-проектами

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

Своим появлением термин «канбан» обязан компании Toyota Motor Corporation, разработавшей и внедрившей на своих автомобилестроительных заводах принцип производства и снабжения, обеспечивающий реализацию системы «точно в срок». При этом немногие знают, что именно послужило источником появления этой методологии, которая сейчас широко используется в финансах, бизнесе и ИТ-секторе.

Growth Hacking — механизмы или действия, помогающие продукту и бизнесу быстро расти. Важные элементы процесса — непрерывное экспериментирование, проверка гипотез и извлечение выводов из ошибок.

Принципы канбана

Канбан берет начало в сервисной парадигме, где все существует в виде экосистемы сервисов. В ее основе лежат четыре принципа:

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

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

канбан-доска;
каденции времени;
буферы задач;
лимиты по WIP (work in progress) — ограничение числа выполняемой в моменте работы;
классификация входной очереди и специальная приоритизация;
«плавательные дорожки» задач;
SLA (соглашения об уровне обслуживания);
карточки задач и их специальная анатомия;
стендап-совещания;
совещания по пополнению очереди;
правила и механизмы незамедлительной эскалации проблем. В данном случае, эскалация означает процедуру привлечения внимания к отдельному запросу.

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

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

Применение канбана

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

Производственный «канбан» подходит для оптимизации процессов на различных предприятиях, а также в рамках lean manufacturing (бережливого производства). Например, применительно к компании «Газпром нефть» метод зарекомендовал себя как инструмент, который повышает эффективность снабжения месторождений, где компания ведет или планирует вести добычу.

Существует также распространенное суждение, что метод часто применяют в ИТ, но это не совсем так. Например, в разработке он используется редко, поскольку разработчикам нужно более строгое планирование задач, разделение на спринты в одну или две недели, возможность оценить промежуточные результаты и скорректировать последующие планы.

Канбан-доска

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

Это работает так: столбики представляют собой разные этапы, на которые разбивают рабочий процесс. Карточки в столбцах — это конкретные задачи-шаги. За каждый этап несет ответственность отдел/сотрудник. Карточки перемещаются по столбцам в соответствии со своим статусом.

При этом принцип формирования каждого столбца должен быть один. Например, это могут быть этапы производственного процесса («прототипирование», «дизайн», «разработка», «тестирование») или статусы выполнения задач («предстоит сделать», «в работе», «на проверке», «завершено»). По каждой колонке должно быть определено ограничение объема незавершенной работы — это позволяет предупредить перегрузы и простои. Этот принцип берет свое начало в законе американского ученого Джона Литтла, согласно которому при увеличении количества одновременно выполняемых задач, снижается скорость выполнения каждой из них. Поэтому команды постоянно балансируют между ограничением на невыполненную работу и скоростью пропускной системы. Лучшие практики ведения канбан-доски основаны на простых компонентах — обсуждение, баланс и взаимодействие.

Уведомление о том, что в колонке «в ожидании» скопилось уже четыре карточки при лимите в три

Ключевые правила работы с канбан-доской:

Не забывайте перемещать карточки на доске в соответствии с движением задачи.
Все задачи должны быть на доске и иметь приоритет по выполнению.
Используйте оптимальное количество статусов на доске.
У каждой команды должны быть своя доска.
Определите оптимальное количество задач в каждом статусе (если будет 100 карточек на доске, она потеряет свою наглядность и простоту).

Ошибки в применении канбана

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

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

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

Ошибка 3. Не фиксировать срочные задачи на канбан-доске. В результате происходят перекосы рабочего процесса.

Ошибка 4. Не считаться с ограничениями WIP (количеством незавершенной работы), а это базовая практика для погружения сотрудников в текущую работу. Игнорируя WIP, вы упускаете возможность выявить узкие места рабочего процесса.

Пример установки ограничения числа незавершенных карточек

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

Ошибка 6. Не актуализировать статус задачи (например, задача выполнена, а на доске она еще в процессе работы). Это может создать неправильное представление о загрузке команды и статусе проекта.

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

Ошибка 8. Перегружать команды: если в одной колонке больше 15 карточек, то ее уже сложно воспринимать комплексно в контексте других задач, создается локальный «захлеб». Решение — добавлять более крупные задачи и дробить их внутри на подзадачи (например, используя чек-листы).

Ошибка 9. Не давать обратную связь в команде: улучшения невозможны без анализа текущего состояния.

Ошибка 10. Отсутствие вовлеченности команды. Канбан визуализирует процессы и задачи, объединяет людей, чтобы они вместе искали возможности для оптимизации. Непонимание командой сути использования метода может приводить в лучшем случае к ситуациям, когда все начинается и так и заканчивается доской, в худшем — к сбоям в работе.

Ошибка 11. Отсутствие приоритетов и ответственных за исполнение задач.

Сервисы для ведения канбан-досок

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

Trello — самый популярный и интуитивно понятный сервис, подходящий для проектов из разных сфер. Здесь можно создавать любое количество досок с разным составом команды (в бесплатной версии есть ограничение на количество досок). К карточкам можно добавлять разноцветные метки, прикреплять вложения и оставлять комментарии. Число колонок не ограничено. Однако по мере эволюции процесса, когда компания будет применять разные практики, инструментов этого сервиса может стать недостаточно, возникнет потребность расширить функционал. Именно поэтому Trello купила компания Atlassian, чтобы аудитория органически перетекала в схожий, но платный и более сложный инструмент — JIRA, откуда пользователь уже сможет перейти на еще более широкий пакет софта в облаке, если ему нужно, например, хранить документацию по проекту, или обсуждать задачи более удобный образом.

JIRA — больше подходит для ИТ, а также для технических команд и процессов, находящихся вне системы Agile. Этот сервис используют крупные компании, у которых численность штата специалистов больше, чем в малом бизнесе. Помимо возможности создавать проекты и отслеживать прогресс, в Jira есть функции отслеживания багов и интеграции со сторонними сервисами.

Kanbanize — англоязычная программа, которая поддерживает большую часть необходимых инструментов канбана, но пока не распространена в России.

Kaiten — российский сервис, максимально адаптированный к применению всех инструментов канбана и позволяющий собирать большой объем аналитики.

В целом сервисов для применения канбана довольно много: Сonceptboard, Taskify, Targetprocess, Favro, Higger, Smartsheet, TargetProcess, SwiftKanban, LeanKit, Miro, Blossom, ZenHub, MeisterTask, Kanbanchi, Breeze, ProofHub, Битрикс24, YouTrack, Asana, Kanbanery.

Как не «похоронить» проект в канбане

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

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

Нужно четко осознавать, что Trello (или любой другой сервис) — это всего лишь инструмент, который позволяет визуализировать активности, рассчитывать метрики. Не нужно полагаться только на инструменты при применении любого подхода, нужно сначала изучить основы и принципы, понять, зачем все это нужно, а потом уже подстраивать инструменты под свои нужды, и тогда успех обеспечен.

В создании материала также участвовали:

Даниил Ростовцев, программист, технический директор компании ТМТ;
Андрей Тихонов, менеджер по масштабированию гибких методологий Yota;
Валентин Попов, ведущий разработчик компании «РашенСофт»;
Илхом Назаров, исполнительный директор студии разработки мобильных экосистем Heads and Hands;
Максим Мул, основатель компании Work Solutions;
Александр Сазанович, профессор, руководитель программы «МВА — Стратегический менеджмент. Управление организацией» школы бизнеса МИРБИС;
Лилия Горбачик, ИТ-эксперт;
Виктория Храмцова, Agile Coach Accenture в России;
Дмитрий Голубовский, CEO и основат Tagesjump.

В Telegram-канале «Списать не получится» мы еще больше рассказываем о трендах в образовании и о том, как учиться в течение всей жизни и делать это с удовольствием. Подписывайтесь!

Читайте также: