В предыдущей части мы разобрали виды проектов по модели Киневин, в зависимости от которых выбирается стиль управления, один из которых - “Водопад”. В этой части мы поговорим о более новых, так называемых “гибких” подходах.
Содержание:
Сейчас Agile разрекламирован, и многими позиционируется чуть ли не как панацея от всего и вся, а точнее, как универсальный ответ на VUCA-мир (мир неопределенности). Так что же такое Agile?
Это подход к реализации проектов с помощью коротких отрезков - “спринтов” - по 1-4 недели и подготовки частей общего продукта - “инкрементов”.
Неопределенность может быть связана:
с разрабатываемым продуктом, требованиям к нему
с заказчиком/потребителем, с тем, чего же он хочет и что ему надо.
Еще одна отличительная черта Agile, особенно в продуктовом управлении - создание MVP.
MVP — тестовая версия товара, услуги или сервиса с минимальным набором функций, которая несет ценность для конечного потребителя. Подробнее о том что это такое и методах создания MVP по ссылке.
Главная цель этого подхода - протестировать предположение и как можно раньше выявить ошибку. Это нужно для того, чтобы дать клиенту тот продукт, который будет ценен для него и минимизировать стоимость игры в "угадайку".
Agile целесообразен, в основном, для запутанных систем модели Киневин или как элемент гибрида в сложных системах.
Парадокс в том, что agile очень трудно работает с планированием, требователен к системе контроля и уровню команды. При слабом менеджменте это приводит к огромным перерасходам и срывам сроков на проектах.
Поэтому сейчас встречается планирование обратное от классического.
Но чаще всего в жизни встречается 3 вариант:
Задаются требования к продукту и ограничения по ресурсам
Считаем и получаем, что либо денег мало, либо времени
Корректируем содержание и требования.
Но чтобы скорректировать требования к продукту проекта, нужно владеть инструментами управления продуктами (в частности CusDev-исследования) и бережливого производства
Упорядочивает же все главный документ - манифест гибкой разработки программного обеспечения, который выделяет четыре основные ценности:
1. Люди и взаимодействие важнее процессов и инструментов.
Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более инструмент не диктует, что людям делать. Они сами решают, как менять процессы/инструменты своей работы.
Чтобы ускорить процесс реализации, люди также должны взаимодействовать напрямую (без посредников в виде документов или других людей), активно общаться между собой лично, а не письменно. Правда, в современном бизнесе общение часто вынуждено переходить в онлайн. Но тогда это должна быть видеосвязь с интерактивными онлайн-досками, а не только письма и чаты.
2. Работающий продукт важнее исчерпывающей документации.
Чтобы клиенты были довольны, им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.
Чтобы укладываться в сжатые сроки с минимумом затрат, зачастую не стоит связывать себя документацией. Поддержка документации в адекватном продукту состоянии нередко замедляет разработку и требует неоправданно больших затрат.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
Чтобы на выходе получить продукт, действительно ценный для заказчика, стоит отказаться от излишних деталей в контракте между подрядчиком и заказчиком (равно как и в требованиях внутреннего заказчика к внутреннему разработчику продукта). Будучи жестко заданы на старте, детали контракта мешают учитывать новые данные и приоритеты, появляющиеся лишь во время разработки.
Чтобы бизнес-ценность продукта быстро росла, заказчик с разработчиком должны плотно общаться по ходу работы. В этом случае все возникающие изменения и проблемы оперативно обрабатываются обеими сторонами.
А чтобы такое сотрудничество исполнителя и заказчика стало возможным, нужно выстраивать их доверие друг к другу.
4. Готовность к изменениям важнее следования первоначальному плану.
Чтобы не откладывать риски проектов на последние стадии (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.
Чтобы в первую очередь делалось самое ценное, текущее видение бизнес-ценности и позиционирования продукта должно быть прозрачно для разработчиков, а процесс их работы должен позволять вносить существенные изменения в прежние планы. Разработчики должны быть готовы добавлять в продукт незапланированные новые возможности, если они стали ценными.
Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.
Не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Философию Agile также можно применять и при работе с персоналом:
Есть и принципы (есть хорошая статья о разнице между ценностями и принципами):
Удовлетворять клиентов, заблаговременно и постоянно поставляя продукт. Клиенты довольны, когда продукт поступает к ним регулярно и через одинаковые промежутки времени.
Изменять требования к конечному продукту в течение всего цикла его разработки.
Поставлять продукт как можно чаще (раз в неделю, в две недели, в месяц). Поддерживать сотрудничество между командой и заказчиком в течение всего цикла разработки.
Поддерживать и мотивировать всех, кто вовлечен в проект. Мотивированная команда намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны.
Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации).
Измерять прогресс только посредством рабочего продукта (клиенты должны получать только функциональное и рабочее программное обеспечение).
Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы).
Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением).
Стараться сделать рабочий процесс максимально простым, а ПО – понятным.
Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает).
Постоянно адаптироваться к меняющейся среде (благодаря этому конечный продукт будет более конкурентоспособным).
Из этих принципов рождается главный инструмент - Scrum, а также становится все более популярным Канбан.
Из принципов появились и признаки Agile-команды:
команда в Agile - профессионалы, с высоким уровнем экспертности в своем деле (программирование, услуги, производство и т.п.);
нет руководителей и старших (п.11 принципов), это полностью плоская команда. Нет даже неформальной структуры (лидеров мнений). Вместе с тем, ответственность за создание продукта делится равномерно между всеми участниками и лежит на команде в целом. В Agile не выделяют одного ответственного за результат;
состоит из 5-9 человек;
автономна и обладает достаточной смелостью, чтобы блокировать попытки вмешаться в ее работу и навязать срочные, но не приоритетные требования извне (помогает Scrum-мастер);
все члены взаимозаменяемы, команда кросс-функциональна. Любой участник может выполнять любую из задач, которые команда берет в работу. Но в сложных проектах это редко, и, как правило, есть «Т-компетенции»: когда участник глубоко разбирается в своей профильной деятельности (вертикальная черта в «Т») и средне в смежных областях (горизонтальная черта), может при необходимости помочь или заменить другого участника;
внутренне мотивирована на создание результата: она сама определяет, как выстроить работу над продуктом, все участники должны понимать цели, для которых создается продукт, каково его назначение, какие проблемы заказчика он должен решать;
размещается в одном помещении. Это помогает быстро общаться, быть в курсе общего состояния работы без формальных совещаний по статусу. При этом помещение для команды лучше выбирать изолированное от шума и присутствия других сотрудников: это поможет избавиться от информационного загрязнения и сфокусироваться на задаче.
Минусы и ограничения (наше мнение):
Agile не стоит применять в простых и сложных, по модели Киневин, проектах. В сложных проектах может быть в составе гибридного подхода: доработка типового продукта, внедрение в необычной инфраструктуре.
Высокая требовательность к уровню менеджмента, в том числе к работе с мотивацией, "осознанности" и компетенциями, как всей команды, так и руководителя/владельца. Во-первых тут применяется планирование, когда исполнитель сам оценивает необходимые сроки. Конечно, можно применять “покерное” планирование, но это лишние потери. А директивный подход приведет к текучке, что тоже не пойдет. В таких проектах важно учиться на исторических данных, чтобы понимать плюсы и минусы как каждого сотрудника, так и всей команды, каков на самом деле уровень производительности. Такие люди нуждаются в более "тонком управлении".
Далеко не каждый заказчик хочет и готов быть в диалоге, часто подключаться для оценки спринта и представленной части продукта. По опыту скажу, что зачастую заказчик хочет заплатить и получить результат. Он не хочет тратить свое время и отвлекаться, слушать аргументы и почему надо что-то менять.
Agile не любит ограничений по срокам и финансам, а оплата почасовая... Если слабый руководитель, высокая текучка, низкий уровень команды, то вы получите "черную" дыру ваших средств и непонятную перспективу получения результата.
У нас были как удачные проекты по Agile философии, так и нет.
В качестве удачного примера можно привести исследование для Томской области. Мы с заказчиком раз в неделю общались, обсуждали результаты, наше мнение слышали, и мы немного отступили от тех. задания. Как итог - получили неплохой продукт для целевой аудитории и на 17% раньше планового срока.
В качестве неудачного - проекты в Минэнерго. В силу определенных причин сроки по всем проектам постоянно сдвигались вправо, желания что-то делать уже не было. В итоге все скатилось к постоянным подготовкам обоснований.
Полезные ссылки:
Это подход/метод/фреймворк, в общем, инструмент, позволяющий небольшими ограничениями упорядочить процесс работы короткими отрезками, чтобы команда работала по принятому плану и постоянно училась, никто им не мешал, у ответственного была вся история разработки.
Как работает скрам:
Основные роли, которые предусмотрены:
Владелец продукта
Это человек, который отвечает за успех всего продукта / результата. Он ведет бэклог продукта. Это заказчик для команды разработки, который потом отвечает за коммерческий успех и востребованность у конечных потребителей. Это предприниматель внутри компании. Он должен иметь достаточно компетенций и полномочий, чтобы принимать решения по продукту от имени заказчика.
Команда
Исполнители, те кто создает продукт. Если мы говорим про разработку программ, то она состоит из тестировщиков, архитекторов, аналитиков, программистов и т. д. Нужен как можно больший охват компетенций, и, желательно, наличие у всех более 1-й компетенции, чтобы люди могли понимать, слышать друг друга. Размер команды 5-9 человек.
Scrum-мастер
Человек, который поддерживает работу команды, помогая освоиться с фреймворком и давая необходимые инструменты для успешного преодоления всех трудностей.
Он оберегает команду от вмешательства извне, когда идет работа над текущим инкрементом. Изменения должны поступать по итогам спринта, но не вовремя работ.
Он может использовать любые подходы: как практики Agile, так и, например, Kanban (доска Scrum, это по сути доска, на которой указаны все работы на текущий спринт), Lean Startup и миксовать разные подходы.
Кроме того есть "дополнительные" роли: Пользователи и Стейкхолдеры — лица, которые инициируют проект (бизнес-заказчики) и для кого проект SCRUM будет приносить выгоду. Они вовлечены в схватку только во время обзорного совещания по спринту (Sprint Review)
Основные процессы, которые помогают организовывать работу:
Планирование спринта
Проходит перед началом каждого отрезка. Цель – определить объем работ, который команда возьмет в ближайший спринт.
Команда выбирает из требований продукта самые приоритетные, детализирует их до уровня задач, оценивает трудоемкость и взаимосвязи между задачами.
Владелец продукта должен помнить, что он может лишь помочь команде осознать, что должно быть сделано за спринт, но не указывать и не выбирать за команду задачи, которые нужно включить в Бэклог (план работ) спринта. Команда, в свою очередь, берет на себя только тот объем работы, который действительно может выполнить. При этом нужно понимать, что решение команды – это не гарантия выполнения всех запланированных задач. Могут возникнуть непредвиденные сложности или новые внешние факторы.
Теперь мы видим, почему в Agile важна стабильность и уровень компетенций в команде.
Ежедневная летучка
Ежедневная планерка (Daily SCRUM), которая проводится в одно и то же время. Помните совещания на производствах? Этот инструмент вообще обязателен для всех. Он выстраивает точки контроля, позволяет лучше планировать день, повышает уровень дисциплины (я так полностью исключил опоздания на производстве).
На этой встрече команда обсуждает, что каждый из участников сделал за прошлый день, что планирует делать в следующий и в чем нужна помощь. Летучка длится не более 15 минут. Важно не отвлекаться на решение проблем в ходе встречи, а только обозначить их, и вернуться к решению после окончания, не отвлекая внимание других участников.
Владелец продукта постоянно посещает эти встречи. Он может поделиться с командой результатами и планами своей работы, однако не должен ставить задачи команде или каким-либо образом вмешиваться в комментарии по задачам.
Разработка
Работа. Основное правило – запрет на изменение состава спринта. В ходе спринта нельзя добавлять к работе команды новые требования или отказываться от уже включенных в Бэклог спринта. Остановить выполнение спринта можно лишь в одном случае: если Цель спринта теряет свою актуальность. В этом случае проводится Ретроспектива для анализа причин возникшей ситуации и заново запускается Планирование спринта.
Обзор спринта
Открытая встреча для демонстрации результатов спринта. По итогам Обзора спринта должна быть получена обратная связь от пользователей по представленным результатам. При необходимости можно обновить Бэклог продукта.
Обзор спринта дает возможность команде напрямую пообщаться с пользователями и заинтересованными сторонами, услышать их требования и комментарии по выполненной работе. Стоит помнить, что задача Обзора спринта – не показать инкремент продукта во всей красе, а предоставить возможность пользователям проанализировать работу, которая действительно была проведена, и обеспечить прозрачность хода проекта.
Ретроспектива
Закрытая встреча Команды, на которой оценивается прошедший спринт с точки зрения организации процессов. На Ретроспективе формулируются ответы на вопросы:
Что было сделано хорошо?
Как можно улучшить процесс?
Какие улучшения будем делать в следующем спринте?
Ретроспектива поможет разрядить обстановку после Обзора спринта, на котором заказчик отказался принять инкремент продукта (результат работы за 1-4 недели). Выявив причины сложившейся ситуации, команда может сделать вывод, что ей необходимо плотнее общаться с Владельцем продукта и помогать ему в работе с Бэклогом.
Я рекомендую следующую структуру проведения встречи:
Новости и актуальная информация для синхронизации команды.
Что сделано за неделю / спринт
Что планируется на следующую неделю /спринт
Риски: снялись, реализовались, возникли.
Основные артефакты/документы/вещи, которые рождаются в процессе работы:
Бэклог продукта
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Формируется и корректируется на всем протяжении проекта. Хорошо, когда к нему привлекается вся команда для сбора идей и предложений. Хотя в итоге отвечает за него именно владелец продукта.
Для оценки качества Бэклога применяется инструмент DEEP (detailed, estimated, emergent, prioritized): оценка содержания детализации, оценки трудозатрат, независимости и приоритезации элементов. Максимальную степень детализации должны иметь наиболее приоритетные элементы. Оценка элементов помогает спланировать, что мы запланируем на следующий спринт, а что сделать не успеем.
Для оценки элементов применяются относительные величины, которые показывают совокупную величину элемента по сложности, трудоемкости или размеру. Распространены техники оценки в стори-поинтах (от англ. «story points», очки, баллы) – 0, 1, 2, 3, 5, 8, 13 или 20 стори-поинтов, или в размерах футболок – S – маленький элемент, M – средний, L – большой..
Бэклог спринта
Набор элементов Бэклога продукта, который команда принимает в разработку на ближайший спринт. В Бэклоге спринта также формулируется Цель спринта (Зачем мы работаем в этом спринте? Чего хотим достичь именно за эту итерацию?) и план по достижению этой цели.
Цель нужна для объединения усилий команды в одном направлении, минимизации вариативности задач (ограничиваемся одной темой) и объяснения заинтересованным сторонам, над чем сейчас работает команда.
В Бэклог спринта должны попадать только такие элементы, которые удовлетворяют трем параметрам: они являются четкими, проверяемыми и осуществимыми. Четкость означает одинаковое понимание участниками команды сути задачи. Проверяемость означает наличие эффективного способа проверить, выполнена ли задача. Осуществимость означает возможность полностью выполнить эту задачу за один спринт.
Нежелателен разброс элементов спринта больше чем на порядок. То есть желательно, чтобы все оценки находились в пределах от 1 до 10.
Если участники команды по-разному оценивают размер задачи или элемента, эту проблему решают с помощью покерного планирования. Каждому из команды выдается набор карточек, которые содержат все возможные значения для оценок. Выбирается элемент для оценки, команда кратко обсуждает его содержание, и каждый участник кладет карту со своей оценкой на стол рубашкой вверх. Затем оценки открываются и авторы оценок, которые наиболее далеки друг от друга, аргументируют свою позицию. Все участники забирают каждый свою карточку и голосование повторяется заново до тех пор, пока все оценки не совпадут.
Инкремент продукта
Сумма завершенных во время спринта Элементов Бэклога продукта и всех инкрементов предыдущих спринтов. То есть это текущее состояние разрабатываемого продукта, включая доработки последнего спринта.
Диаграмма сгорания задач
Отдельно стоит упомянуть диаграмму сгорания (Burndown). Это диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта. Ее ведут ежедневно.
Ее цель - вести объективное и понятное планирование, понимать сроки завершения:
Зачастую ее выносят как отдельный артефакт, хотя, согласно гайду, это элемент бэклога продукта.
Она - не самый простой инструмент, но у Макса Дорофеева есть хороший цикл видео и примеров в Excel на тему прогнозирования сроков проектов (количественные методы и Excel). Ниже на него дана ссылка.
Полезные ссылки:
Видео:
Канбан - один из самых простых в применении и любимых мною инструментов.
Изначально это разработка Тойоты для производственной системы, основы бережливого производства. Бережливое производство (LEAN) сейчас применяется во всех крупных мировых компания.
Kanban предназначался для организации производства по принципу "точно в срок" и никак не был связан с проектной деятельностью.
Сейчас этот инструмент активно применяется в среде IT.
Его суть - визуализировать рабочий процесс и загрузку, чтобы увидеть узкие места и превентивно принимать меры, решая проблему на ранней стадии, и постоянно совершенствовать рабочий процесс.
Канбан очень гибок. Его можно интерпретировать достаточно свободно.
Одно из главных его условий - ограничение рабочих задач на каждой стадии (Work in progres - WiP).
Пример выше - не единственный метод визуализации рабочего процесса.
Ниже еще один пример организации работы. Такую концепцию мы применяли в Минэнерго в период перехода на удалёнку, и она себя очень хорошо зарекомендовала. Интуитивно понятна всем и актуальна, когда весь процесс в руках одного человека.
Основные принципы:
Опора на существующие методы работ
Канбан начинается с существующих методов работы и стимулирует в них дополнительные изменения.
Предварительная договорённость о проведении важных изменений.
Нужно учитывать, что постоянные изменения — это способ улучшить существующий процесс разработки, однако проведение глобальных перемен имеет большой риск. Канбан поощряет небольшие и эволюционные изменения. Собственно, в этом вся суть японской философии. Никаких серьезных революций.
Уважение к существующему порядку, ролям и обязанностям
Поощрение инициативы
Для "системного" улучшения рабочего процесса, Канбан предполагает использование шести шагов:
1. Визуализация
Нужно визуализировать текущую структуру процессов. Итоговый результат должен содержать признаки канбан-системы (WiP-лимиты, точки принятия обязательств и поставки), правила работы процесса «как есть». Канбан не предписывает, как должна выглядеть канбан-доска. Помимо столбцов вы можете включить в нее горизонтальные строки для различных типов задач (классы сервисов).
Как показано выше, можно работать минимум с 3-мя видами досок. А цифровые сервисы позволяют выставить сроки, чек-листы, добавить нужные документы к задаче, отслеживать все действия.
2. Ограничение количество незавершенной работы
Работа над новыми элементами начинается только по завершении (или выбрасывании) предыдущих задач. Много незавершенной работы экономически неэффективно, увеличивает время производства и не позволяет организации оперативно откликаться на потребности заказчиков.
Помимо экономики, это негативно сказывается и на психологии сотрудника, он теряет концентрацию и теряет приоритеты, снижает свою производительность.
3. Управление потоком
Поток задач в канбан-системе должен способствовать увеличению ценности, минимизировать время производства и повышать предсказуемость процесса. Необходимо постоянно контролировать процесс, выявлять узкие места (скопление задач на одном этапе или, как в примере Минэнерго, на одном человеке) и заблокированные задачи (выполнение которых блокируют внешние факторы, для этого, например, есть цветовые метки).
4. Делать правила явными
Канбан-система должна содержать правила распределения задач, критерии готовности и перехода с этапа на этап, критерии выбора новых задач и использование классов сервисов. Правила могут различаться для различных этапов процесса.
Прозрачность правил - основной вопрос. Об этом мы писали тут.
5. Внедрение циклов сбора обратной связи
Канбан предусматривает семь способов получения обратной связи (каденций). Каденции – регулярные совещания и проверки, приводящие к эволюционным изменениям и эффективному предоставлению сервисов. Важно выбрать оптимальную частоту каденций: слишком частые проверки могут привести к внесению изменений до того, как стал понятен эффект от предыдущих изменений. А если проверки проводятся слишком редко, низкие показатели будут сохраняться слишком долго.
Метод предлагает проводить следующие каденции (подробнее в «Канбан. Краткое руководство». Дэвида Андерсона и Энди Кармайкла):
ревью стратегии
операционное ревью
ревью рисков
ревью сервиса поставки
собрание по пополнению
канбан-митинг
собрание планирования поставки
6. Совместное улучшение, эволюция на основе экспериментов
Канбан не предписывает конкретных действий, которые необходимо выполнить для улучшения вашего процесса. По результатам работы выдвигайте гипотезы о том, что можно улучшить в процессе, проверяйте свои предположения на практике и делайте выводы.
Этот подход можно применять совместно со Scrum.
Полезные ссылки:
Разница Scrum и Kanban заключается в планировании и включении задач в работу. Scrum - это итерации длительностью 1-4 недели и фиксированный объем спринта. В Kanban задачи можно добавлять каждый день. Главное - визуализация и ограничение количества рабочих задач.
Еще аналогия: Scrum - автобус, Канбан - маршрутка.
Из желания совместить эти две философии и "мягко" научить команды основам бережливого производства появился Scrumban - более гибкий Scrum. Никакого формализованного документа на тему этого гибрида нет. По сути, это результат экспериментов разных компаний, когда все естественным путем приходят к одному и тому же.
От Scrum тут:
Спринты
Когда команда решит, над чем ей предстоит работать в течение спринта, участники уже не смогут получать новые задания до его окончания. Но по итогам спринта необязательно должен быть готов инкремент продукта. Ключевая задача спринта - точки контроля работы команды и пересмотра рабочих задач.
Ежедневные стендапы
Встречи продолжительностью не более 10 минут, где участники кратко отвечают на:
Какие задания мне удалось выполнить?
Над чем я работаю в сегодня?
Какие препятствия мне мешают?
Ретроспективы
В конце каждого спринта команда проводит собрание, чтобы оценить эффективность работы и список рабочих задач, приоритеты на следующий этап.
От Kanban тут:
Доска Kanban
Доска Kanban обычно содержит столбцы «К исполнению», «В работе» и «Готово», которые соответствуют этапам проекта.
Карточки
На доске перечислены задачи (карточки) проекта. Это привычный подход, поскольку раньше команды пользовались карточками для записей или стикерами, размещая их на магнитно-маркерных досках.
Ограничение выполняемой работы
Для достижения высокой эффективности команде необходимо знать, сколько задач ей под силу выполнить в течение определенного рабочего периода. Сколькими карточками может заниматься участник в течение дня? Это ограничение позволяет команде предотвратить переутомление (и эмоциональное выгорание) и при этом показать прогресс заинтересованным сторонам.
В итоге, если обобщить, то здесь активно используется доска для визуализации и ограничение на работу (WiP-лимиты) в процессе. Элементы из бэклога спринта выполняются последовательно, в колонку "В работе" не попадают сразу все карточки (и это не противоречит ScrumGuide). Поток работы выравнивается и мы избавляемся от неравномерности в производстве (очереди, увеличивающие время исполнения и количества дополнительных материалов, из-за чего начинается перегрузка, утомляющая людей и снижающая их эффективность, качество работы)
Ну а если детально, то:
устанавливается стандартный размер спринта для проекта;
планирование, планерки и ретроспективы не отменяются;
планирование ведётся для нескольких задач, но команда закладывается на то, что в задачах есть много подводных камней или прилетят другие задачи;
задачи получают приоритеты и разбиваются на части примерно одинакового размера;
перед тем, как задача берётся в разработку, она должна быть проработана и проанализирована;
у колонок проставлен WiP — есть ограничение на количество задач в процессе работы;
чёткие роли не указаны, они вводятся по необходимости;
в бэклог проекта попадают только те задачи, которые кем-то «заказаны», при этом отдельного бэклога нет, это колонка на доске всех задач;
не ведётся диаграмма сгорания, а спринты в первую очередь направлены на более частый анализ своей работы и более интенсивное усовершенствование рабочих процессов;
задачи не назначаются членам команды руководителем группы или менеджером проекта;
при приближении крайнего срока проекта менеджер замораживает набор функций. Можно работать только над функциями, которые команда уже имеет в списке, дополнительные функции добавлять нельзя;
после замораживания менеджер проводит сортировку - какие функции в разработке будут завершены, а какие останутся незавершенными. Это позволяет команде сфокусироваться и закончить важные задачи к сроку;
на ретроспективах команда, в первую очередь, работает над снижением времени цикла.
Преимущества Scrumban
Высокая гибкость
В Scrumban промежуточный продукт поставляется после каждого спринта. Такой подход позволяет вносить изменения в проект даже после его начала. При этом они не препятствуют прогрессу в реализации проекта.
Непрерывная поставка
Работа представлена на доске, а процесс непрерывен, что позволяет командам поставлять функции по мере их завершения, не дожидаясь окончания спринта.
Снижение нагрузки
Ограничение выполняемой работы в соответствии с возможностями команды позволяет продвигаться к цели без эмоционального выгорания.
Ускоренное решение задач
Размещение карточек на доске обеспечивает прозрачность, необходимую командам Scrumban для улучшения совместной работы и оперативного решения выявленных проблем.
Способность реализовывать крупные проекты.
Поскольку суть Scrum и Kanban заключается в постоянном и постепенном улучшении, Scrumban позволяет командам работать над самыми сложными проектами.
Ограничения Scrumban
Неоднозначность
Scrumban — относительно новый подход, поэтому сведений по его реализации не так много. В связи с этим могут возникнуть трудности с поиском рекомендаций или передовой практики.
Меньше контроля
Поскольку в Scrumban нет традиционных scrum-ролей, участники команды самостоятельно управляют спринтами. Отсутствие конкретного руководителя может привести к путанице в распределении обязанностей.
Сложность
Использование элементов двух методологий может сбить с толку участников команды, которые пользовались не Agile, а другой системой.
Также сравнение 3-х подходов: Scrum, Kanban, Scrumban
Scrum | Kanban | Srcumban | |
Методология |
|
|
|
|
|
|
|
Артефакты |
|
|
|
События |
|
|
|
Процесс |
|
|
|
В итоге имеем следующее сравнение
Кому больше всего подходит Scrumban:
Проекты по разработке ПО с меняющимися требованиями
Разработка программного обеспечения с расширением области проекта. Необходимый результат достигается с помощью спринтов и непрерывной разработки. Команды могут продолжать поставлять инкременты, даже если требования меняются.
Проекты с несколькими параллельными инициативам
В крупных компаниях зачастую идет работа над несколькими проектами одновременно. Иногда ими занимаются одни и те же команды. Благодаря своей гибкости Scrumban позволяет одновременно реализовывать разные инициативы, поэтому даже небольшие команды могут браться за несколько задач.
Стартапы или быстро меняющаяся среда
У стартапов часто меняются среда и проекты. В любой момент может возникнуть новая задача, а ресурсы бывают ограничены. Scrumban открывает небольшим командам новые возможности для достижения успеха
Полезные ссылки:
Видео:
Подход к управлению проектом выбирается под конкретный проект.
Главное внимание на подготовке к запуску проекта: инициации и планированию. Определите миссию и создаваемую ценность, сочетание со стратегией, цели, критерии успешности, заинтересованных лиц, риски. Чем раньше выявите ошибку, тем дешевле исправление;
По возможности выстраивайте неформальное общение с участниками и стейкхолдерами. Так удавалось вытаскивать даже "проблемные" проекты в новой отрасли. И подкрепляйте это письмами и протоколами.
Сейчас эпоха гибридов и поиска баланса "гибкость - эффективность - соблюдение бюджетов и сроков".
Актуальный тренд - ориентация на создание ценности для потребителя, создание комплексных продуктов.
Критичные факторы для проекта:
Определение критериев успеха, основные вехи и риск-менеджмент
Работа с персоналом на местах: обучение проектному управлению, принятию изменений и причинам сопротивления.
В цифровых проектах критична работа с данными:
структура НСИ;
оцифровка данных, модель данных и последующая аналитика;
уход от ручного ввода данных;
определение показателей, которые надо установить для принятия решений, и при запуске проекта, и после внедрения.
Также приведем сравнение различных стандартов от Михаила Софонова:
«Сравнение подходов к управлению проектами с животными:
PMBOK - Я бы сравнил PMBOK с бегемотом, потому что оба очень структурированы и содержат множество деталей. PMBOK описывает большое количество процессов и документов, а бегемот является крупнейшим наземным животным, имеющим массивную структуру тела.
PRINCE2 - Я бы сравнил PRINCE2 с орлом, потому что оба ориентированы на управление и лидерство. Орел является символом силы и власти, а PRINCE2 предоставляет набор принципов и методов для эффективного управления проектами.
P2M - Я бы сравнил P2M с дельфином, потому что оба могут быстро и гибко адаптироваться к изменениям и условиям среды. Дельфины могут легко переключаться между различными задачами и демонстрируют способность к творческому решению проблем. P2M, в свою очередь, предоставляет методики для эффективного управления проектами, которые могут быть легко адаптированы к различным сценариям.
SCRUM - Я бы сравнил SCRUM с муравьедом, потому что оба ориентированы на коллективную работу и эффективную коммуникацию. Муравьеды обычно работают в группах, чтобы обеспечить сбор пищи, а SCRUM-команды работают вместе, чтобы достигать целей проекта. SCRUM также известен своей гибкой методологией, что подчеркивает адаптивность и способность к изменениям в процессе работы над проектом.
KANBAN - Я бы сравнил KANBAN с муравьем, потому что оба обладают высокой степенью организации и дисциплины в работе. Муравьи являются искусными строителями и организаторами, которые могут работать в слаженной команде для достижения общих целей. KANBAN, в свою очередь, предоставляет систему управления проектами, которая позволяет управлять процессами и контролировать поток работы, что повышает эффективность и уменьшает риски»
Ну а в завершение хотим поделиться простой мыслью - вечно быть Agile нельзя.
Давайте будем честны, в большинстве под Agile скрывают банальный хаос. Agile не про отсутствие планирования. Кроме того, он очень чувствителен к выполнению определенных правил и стабильности команды, ее мотивации. То есть Вы не Agile в таком случае.
Но и само использование того же Scrum, Kanban или других подходов должно приводит к отпадению в необходимости реализации проектов по Agile.
Но почему? Для этого нужно вспомнить, а зачем появился Agile? Для работы и реализации проектов в ситуации высокой неопределенности.
Даже есть инструмент - модель Кеневин. Он помогает понять, в какой ситуации / системе вы находитесь, и какой подход нужно выбирать, на чем фокусироваться.
При этом в упорядоченных системах (простых или сложных) Agile наоборот противопоказан. Он увеличивает затраты на достижение результата. Что называется каждый раз придумывать велосипед заново. То есть Agile про результативность, когда надо сделать то, не знаю что. Но он не про эффективность.
А теперь давайте обратим внимание на ретроспективы. Все подходы внутри Agile предполагают регулярные ретроспективы, анализ своей работы, взаимодействия с клиентом / заказчиком / партнером. То есть сама логика этих инструментов в том, чтобы уйти от неопределенной ситуации и научиться прогнозировать их, становиться эффективнее.
Если вы постоянно (раз в полгода - год) меняете работу, или постоянно запускаете новые продукты, а не тиражируете определенные решения (что для бизнеса странно), то да, вам нужно быть Agile.
Но если у Вас есть сегмент и вы наработали с опытом и экспертизой "типовые" подходы / продукты, которые нужно корректировать и адаптировать в небольшой части, то рано или вы должны уйти от Agile. Вы должны прийти к упорядоченной системе, где нужны каскадные или гибридных подходы. Эти ретроспективы вас и должны привести к пониманию того, а чего хотят заказчики в 90% случаев и как работает организация / коллеги.
В итоге, если вы Agile на постоянной основе и везде, а не на период перестройки / запуска / адаптации, то это может говорить о:
несоблюдении инструментов Agile;
вы не нашли свой продукт и свою нишу или себя, не наработали нужную экспертизу;
у вас каждый раз уникальный продукт / проект (что должно отражаться на высокой цене ваших услуг);
организация "больна" изнутри, и вы таким образом маскируете высокую текучку, отсутствие работы над процессами и т.д.
Дополнительные материалы
1. Скрипт + пояснения
2. Видео
***
Мы разрабатываем собственное цифровое решение для ваших проектов. Ознакомиться с ним можно по ссылке: