О докладчике и теме доклада
Одна из тех вещей, которыми мне приходится заниматься в профессиональном плане – помощь командам в настройке и внедрении Agile.
В частности, у меня есть опыт внедрения и развития Канбана в командах, занимающихся 1С-проектами.
Этим опытом я и хочу с вами поделиться – расскажу о том, как добавить в проекты гибкости при помощи Канбана.
Немного статистики
Почему именно Канбан? Здесь выдержка из отчета по Agile в России в 2020 году. Видно, что из компаний, которые работают по Agile, в 2018 году по Канбан работало 10%, в 2019 году – 15%, а в 2020 году – уже 23%. Канбан стремительно растет, и есть основания предполагать, что этот рост продолжится.
Инструменты и преимущества Канбан
Когда мы говорим про Канбан, понимаем под ним три вещи.
-
Первое – это доска, универсальный инструмент.
-
Второе – система, которая использует этот инструмент.
-
Третье – метод, когда мы организуем работу, используя эту систему и этот инструмент.
Давайте уточним эти понятия, чтобы говорить на одном языке.
С Канбан-доской все наиболее просто. Ее в своей работе используют очень многие.
Канбан-доска в тренде. На слайде приведена выдержка из отчета по ситуации Agile в мире за 2019 год. Мы видим, что Канбан-доска – это лидер среди всех инструментов, применяемых для управления проектами. 76% говорят, что применяют Канбан-доску, 10% – что собираются применять. Очевидно, что 76% – это очень много.
Главное преимущество Канбан-доски – она позволяет избежать эффекта «дырявого стека», который описал Максим Дорофеев в своей книге «Джедайские техники». В список задач постоянно добавляются более срочные и важные, и в конце концов мы оказываемся в ситуации, когда первая задача вываливается из нашего стека, и мы ее больше не найдем.
Канбан-доски бывают разные: Jira, Trello, Redmine, Pyris, Битрикс24… Но эксперты рекомендуют начинать всегда с физической доски: она более наглядна, ее проще настроить, как вам надо. Изменить шаблон трудно, а дорисовать столбец и добавить по горизонтали плавательную дорожку всегда проще.
Любители наглядных досок во время эпидемии ковида довольно сильно обломались, потому что команды перешли на удаленку. У многих команд изначально не было возможности работать на физической доске. Например, в Инфостарте команда 1С-ников полностью распределенная: от Калининграда до Хабаровска.
Если команда работает на удаленке, в качестве физической доски можно использовать доску для совместной работы (SharedBoard). Не уверена, что можно так работать постоянно, но если хочется обсудить структуру доски и правильно настроить ее на будущее, это вполне удобный способ.
Например, мне нравится доска Miro: берем специальный шаблон либо рисуем прямоугольники и по ним двигаем стикеры. Настраиваем это все на стендап-совещаниях и постепенно переходим на более совершенный инструмент.
С Канбан-доской разобрались, разберемся, что такое Канбан-система.
Вытягивающая система и WIP-лимиты в Канбан
Если мы на Канбан-доску добавим ограничение по числу задач, то превратим выталкивающую систему в вытягивающую. Это уже будет называться Канбан-система.
Выталкивающая система – это когда на нас наваливается столько задач, сколько хотят навалить. А вытягивающая система – это когда мы берем столько задач, сколько можем сделать.
В моем опыте практически всегда на отдел 1С сыпется слишком много задач, много хотелок от пользователей, реализуются конфликтующие проекты, людей не хватает. Задачи приходят в отдел, но когда они выйдут – неизвестно.
Канбан-система позволяет честно это признать: даже если мы сейчас возьмем в работу все 500 задач, которые нам ставят, мы всё равно не сделаем их. Поэтому давайте объявим, что между бэклогом и очередью у нас есть точка взятия обязательств. Мы не будем брать 500 задач, возьмем 5, но сделаем их за неделю.
В конечном итоге все заинтересованы в том, чтобы работало именно так. Производительность становится более предсказуемой. Если задачи взяты в работу – их точно сделают.
На этом этапе появляется понятие WIP-лимитов: work in progress limits, ограничение по количеству задач.
Например, на слайде мы видим, что разработчики закончили работать, но не могут передать задачу в тестирование, потому что тестировщики загружены.
Задачу из разработки мы сможем передвинуть только когда тестировщики передадут свою задачу в продакшн.
На Канбан-доске мы видим, где у нас простои и бутылочные горлышки. Тот факт, что тестировщики перегружены, мешает работать разработчикам – сложности на определенном участке работы сразу обращают на себя внимание, и вся команда заинтересована в том, чтобы задачи быстрее завершить.
Иногда возникает вопрос: когда мы добавляем WIP-лимиты, мы не оптимально используем ресурсы, они начинают простаивать. Но бояться этого не нужно. Мне нравится аналогия, когда Канбан сравнивают с автобаном. Если рассматривать дорожное полотно как ресурс, когда на автомагистрали ресурс используется максимально? В глухой пробке, поскольку в этот момент все ресурсы максимально заняты. К эффективности работы и скорости поставки это не имеет отношения.
У нас может быть история, когда все очень заняты и имитируют бурную деятельность, но работа продвигается медленно, не доходит до результата. Канбан-система эту ситуацию исключает.
Кроме этого, мы уходим от многозадачности, сотрудники не теряют время на переключение.
Если мы на основе Канбан-системы организуем взаимодействие в компании, это будет называться Канбан-метод. В нем выделяют принципы изменений, принципы поставки и практики.
Канбан – это Agile?
Сторонники Agile считают, что Канбан – это гибкий метод, который относится к Agile, а сторонники Канбана считают, что это отдельное направление.
Для меня было откровением, что самая известная книга по Канбан Дэвида Андерсона, которая в русском переводе звучит как «Канбан – альтернативный путь в Agile», в оригинале называется «Kanban – The Alternative Path to Agility». Т.е. про гибкость мы говорим, а про Agile – нет.
Почему же Канбан – отдельное направление?
-
Самый очевидный ответ, что автора Канбан Дэвида Андерсона не взяли на курорт Snowbird Ski, где 17 идеологов придумали Agile manifesto.
-
А если серьезно, то Канбан подходит не только для проектов, но и для операционной деятельности. Поддержку прекрасно можно вести по Канбан. Мы пробовали, подтверждаю.
-
Суть Agile в том, что у нас есть небольшие, независимые, кроссфункциональные команды, которые выдают результат: быстро делают поставки и собирают обратную связь. В Канбан это все необязательно, команда может быть частью большой команды, может не быть коротких релизов, но работать по этому методу можно все равно.
Важно то, что Канбан внедрить просто.
Есть общая идея: мы начинаем с того, что уже есть и двигаемся эволюционно – именно этот факт является одной из причин, почему Канбан так популярен у руководителей проектов 1С.
Почему 1С-ники предпочитают Канбан Скраму
Я веду курсы по управлению проектами на Инфостарте. В качестве одного из заданий мы пробуем применить методики Скрам и Канбан в организации, где работают слушатели.
На слайде я привела срез по результатам опроса учеников последнего потока (прим. ред. май 2021): всего в опросе участвовало 86 выпускников потока, из них две трети считают, что Канбан – лучше подходит для их организации, чем Скрам. 21% выступили за гибридные методы, 10% – за Скрам.
Конечно, это не самая репрезентативная выборка, если я сама больше склоняюсь к тому, что Канбан больше подходит к 1С, возможно, я как-то неосознанно транслирую это своим слушателям. Но показательно.
Почему так происходит? У меня несколько предположений:
-
Во-первых, у нас чаще всего специалисты 1С работают не по правилу «одна команда – один продукт». Как правило, на них лежат обязанности по поддержке и разработка на нескольких проектах внедрения одновременно.
-
Во-вторых, Скрам хорошо подходит для ситуаций, когда мы на входе получили требования от заказчиков, что-то разработали и выдали результат. Когда мы говорим о внедрении и кастомизации продукта под пользователей, у нас много тесного взаимодействия с заказчиками. Нет такого, что мы что-то делаем независимо, у нас все время много совместной работы с пользователями.
-
В-третьих, трудно предсказать трудоемкость, чтобы спланировать спринт, многие задачи выскакивают неожиданно. У нас произошло изменение законодательства, бухгалтерия не может сдать отчетность, если мы не обновимся. Цикличное планирование не очень хорошо работает.
-
Для управления командой 1С-разработчиков более привычна роль руководителя проекта, чем Скрам-мастера (лидера-слуги по версии предыдущих версий Scrum Guide). Команда пока не готова к ситуативному лидерству, а Скрам-мастер меньше руководит, чем классический РП.
-
Вообще, в силу некой консервативности мира 1С эволюционный метод проще внедрить, чем революционный.
На слайде ярко выделено, что нужно сделать, чтобы начать работать по Скраму и по Канбану.
-
Скрам предполагает, что мы сильно меняем наш формат работы. В книге Джеффа Сазерленда так и написано: «Порвите ваши визитки, у вас теперь только одна роль – член команды, и других ролей нет».
-
Канбан, наоборот, предлагает начать с того, что мы имеем. Достаточно разобраться, как работает Канбан, и завести доску. Все остальное – это уже развитие, не бывает правильного и неправильного Канбана, бывают разные этапы.
Канбан хорошо отражает современный тренд ITSM – ИТ как услуга, когда внимание фокусируется на потребностях пользователей. Мы анализируем, что им надо на самом деле, и в связи с этим корректируем свои планы.
При этом Канбан – это непрерывное развитие, когда мы стараемся развиваться по некоему пути, растем от хаоса к идеалу. Это стремление отражено в модели зрелости Канбан.
Модель зрелости Канбан немного напоминает модель зрелости организации CMMI – когда на разных этапах мы получаем разные преимущества Канбан.
Главная идея Канбан в постепенном внедрении основных практик:
-
мы постепенно делаем задачи наглядными,
-
постепенно вместе улучшаем процесс работы
-
постепенно внедряем каденции – регулярные встречи для получения обратной связи.
Практика работы по Канбан
Поделюсь нашим опытом движения по этапам.
На нулевом, персональном, уровне, у каждого сотрудника есть личная доска, и человек учится с этой доской работать.
Здесь речь идет не о процессе, а о личном героизме. Если человек организован – у него все хорошо.
На следующем уровне появляется фокус на командной работе.
Вместо индивидуальных досок появляется общая доска с командными WIP-лимитами – по аватаркам видно, кто за что отвечает, и становится понятно, кто чем занят.
На практике работать над задачами командой не всегда бывает просто. Хочу показать вам пару слайдов из серии комиксов Comic Agile на эту тему.
Приходит Скрам-мастер и говорит: «Давайте введем WIP-лимиты, чтобы у нас не было слишком много задач, а то мы все не успеваем».
Кто-то из команды робко поднимает руку и говорит, что у команды вряд ли получится работать над одними и теми же задачами совместно. Но Скрам-мастер успокаивает его, что это не проблема.
И на последней картинке видно, что один человек работает над задачей, а остальные отдыхают.
Это напоминание о том, что WIP-лимиты нужно настраивать гибко.
На следующий уровень мы переходим, когда командная работа уже настроена – мы начинаем ориентироваться на пользователя.
-
Мы выстраиваем разные процессы по-разному.
-
У разных задач может быть разная цветовая маркировка.
-
Процесс у нас налажен, но в результате мы пока не очень уверены.
На третьем уровне мы уже уверены в достижении цели:
-
мы выходим на уровень организации,
-
измеряем нашу работу при помощи метрик (например, на слайде видно, сколько задач у наших разработчиков одновременно в работе)
-
собираем обратную связь – например, мы недавно проводили в компании опрос, насколько люди довольны работой ИТ.
-
на этом уровне у команды уже все хорошо, но не всегда получается работать рентабельно.
На четвертом уровне мы уже уверены в рентабельном бизнес-результате и готовы работать с рисками.
-
Мы уже уверенно применяем метрики и петли обратной связи
-
Уверены, что у нас разные классы услуг
-
За счет четкой организации процесса у нас конкурентные преимущества для бизнеса.
На четвертом этапе важно, что мы выходим на уровень организации. Если раньше мы собирали совещания на уровне команды – устраивали встречи по пополнению очереди и взятию обязательств, ежедневные стендап-совещания, планирование поставки, то теперь выходим на уровень организации: делаем обзор стратегии, работ, которые ведутся в компании, и рисков.
Как работать с рисками
По обзору рисков поделюсь своей любимой техникой: PreMortem (от латинского слова Mort – смерть). Представьте себе, что мы встречаемся через год, и тот проект, над которым вы работаете, с треском провалился. Почему это могло случится?
Эта техника – продолжение техники, когда мы учимся на ошибках – после провала проекта мы собираем извлеченные уроки и анализируем причины провала.
В случае с PreMortem мы пытаемся проскочить первые этапы, представить, что может пойти не так, увидеть препятствия заранее и избежать этих рисков в дальнейшем.
Как развивать Канбан-систему
Ключевой вопрос: как переходить с уровня на уровень?
Метод, который мы используем и рекомендуем – это применение системного системного мышления в знакомстве с Канбан.
Мы периодически анализируем, что происходит:
-
в чем проблемы;
-
с какими запросами к нам обращаются;
-
сколько мы успеваем делать;
-
как у нас выглядит процесс работы, какие у него этапы – нужно ли добавить в него код-ревью, разделить функциональное и техническое тестирование и т.д.;
-
какие классы обслуживания у нас есть.
На основании этого мы проектируем, как мы работаем – какие доски, какие каденции, как сделать.
Есть специальный шаблон Static А3 – он доступен по лицензии Creative Commons, можно его найти и использовать.
А3 – это формат бумаги. Мы кладем этот лист на стол и стараемся в него уместиться, чтобы не растекаться по древу и точно описать все процессы.
Мы используем онлайн-шаблон. Вносим в него, какие у нас запросы, неудовлетворенности, красным цветом отмечены болевые точки.
И на основании обсуждения анализируем, как изменить доску.
На слайде я привожу примеры разных решений, которые принимали команды по итогам встреч и заполненных форм STATIK.
Казалось бы, зачем нам проводить для этого статики? И так понятно, что нужно встречаться с заказчиками и разрабатывать документацию.
Но не все так просто. Только команда понимает, что именно ей нужно на самом деле. Чтобы она использовала на практике те или иные инструменты, важно, чтобы люди приняли это решение совместно.
Если решение о совещаниях принимается только на уровне руководства, люди на совещания забьют, не поймут их важности.
Если команда собралась сама и поняла, что есть проблемы – люди отнесутся к этому по-другому.
Понравилась статья? Хотите глубже погрузиться в методологии управления проектами, расширить управленческие компетенции и наладить процессы в собственных проектах? Записывайтесь на курсы Марии Темчиной, набор продолжается, успейте и вы.
