Все о SCRUM. Изучение, разработка, интеграция

Kanban позиционировали как новый метод улучшения процесса разработки. В конце предисловия ко второму изданию книги Лорана Мориссо [Morisseau, «Kanban»] я резюмировал Kanban следующим образом:

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

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

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

Scrum, очевидно, во многом вдохновлен Kanban-паттернами.

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

20.1 Зачем Kanban накладывать на Scrum?

20.1.1 Проблемы, возникающие при использовании Scrum в определенных ситуациях

Здесь я обратился к командам, уже внедрившим Scrum в свою работу. Провел опрос и узнал о наиболее частых проблемах. Представляю их ниже в виде карты (подробнее об инструменте impact mapping можно узнать в главе 15).

Рисунок 20.1 – Карта воздействия для улучшения

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

Решения для достижения этих воздействий уже были представлены в предыдущих главах: роение, доработка и т. д. Жирным шрифтом на рисунке 20.1 выделены другие практики, или Kanban-паттерны, о которых мы узнаем в данной главе.

Речь в основном о ситуациях, когда команда сталкивается с высокой динамикой изменений (критерии контекстуализации в главе 14 «Контекстуализация Scrum»).

20.1.2 Краткое введение в Kanban

Kanban – это метод улучшения в виде постепенного и плавного изменения. Он заключается в следующих принципах:

✓ Начинать с того, что есть.

✓ Настроиться на постепенное изменение.

✓ Уважать текущий процесс, роли и обязанности.

В нашем подходе «Kanban в дополнение к Scrum» мы исходим из рамок Scrum с его спринтами, событиями, ролями и бэклогом.

Kanban предлагает шесть практик:

1. Визуализация рабочего процесса.

2. Ограничение незавершенной работы.

3. Измерение рабочего потока и управление им.

4. Четкая формулировка и прояснение правил управления процессом.

5. Имплементация циклов обратной связи.

6. Коллективное улучшение.

Порядок следования принципам соответствует степени, в которой Kanban применяется в работе.

Мы сфокусируемся на втором принципе и основной Kanban-практике: ограничение незавершенной работы.

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

20.1.3 Ограничения в Kanban

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

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

Ограничения в Kanban – это практика ограничения незавершенной работы.

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

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

Есть также другое, менее известное ограничение: нижний предел, который регулирует добавление новых записей. Это ограничение – в некотором роде альтернатива ритму Scrum.