Ситуация. Архитектор, принимающий важные решения, не состоит в команде и не участвует в коллективной работе.
Последствия. Команда вынуждена соглашаться со всеми решениями. Она демотивирована и теряет способность проявлять инициативу.
Как сделать лучше? В Scrum-команде отсутствует роль архитектора. Agility на практике означает, что эксперт может подавать пример и пачкать руки, при этом он активно сотрудничает с другими участниками команды.
Ситуация. Начинающие Scrum-команды не завершают истории в течение спринта. Некоторые истории длятся спринтами!
Последствия. Участники команды должны возвращаться к коду, написанному в прошлом спринте.
Как сделать лучше? Такого рода проблема вызвана разделением ролей разработчика и тестировщика. Если тестировщик получает программное обеспечение для тестирования в самом конце спринта, в лучшем случае он обнаружит ошибки, которые уже не сможет исправить до завершения спринта. Скорее всего, он просто перенесет тесты на следующий спринт. Практики BDD и роение помогают избежать этой проблемы.
Ситуация. Все участники команды работают по одному.
Последствия. Все заканчивается тем, что задача или история не могут быть завершены, потому что кто-то из участников не справился.
Как сделать лучше? Лучшим решением этой проблемы будет предложение другому участнику работать в паре.
Это залог успеха компании Menlo, систематизировавшей практику парного программирования. [Шеридан, «Joy, Inc.»].
Ситуация. Те, кто разрабатывает ПО, иногда воспринимаются как исполнители. Их подталкивают к быстрому написанию кода в ущерб качеству.
Последствия. Накапливается технический долг.
Как сделать лучше? Постоянно развиваться в применении практик разработки.
Для этого следует рассматривать практики как один из важнейших элементов разработки, что не всегда соблюдается менеджерами или Владельцами продукта.
Движение Software Craftmanship зародилось с целью продвижения этой идеи, которая была сформулирована в Манифесте Software Craftsmanship [60].
Чтобы идти дальше
Книги
‣ Ричард Шеридан «Работа мечты. Как построить компанию, которую любят», МИФ, 2014
‣ Ален Саке, Mettre en œuvre DevOps, Dunod, 2018.
‣ Corey Haines, Understanding the Four Rules of Simple Design
Онлайн-ресурсы
‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/
‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum
20Kanban в дополнение к Scrum
Scrum кажется простым. Но вот уже двадцатую главу я стараюсь объяснить, как лучше его применить в работе. Kanban отчасти похож на него, и его столь же сложно описать. Он был создан Дэвидом Андерсоном несколько лет назад и с тех пор сильно изменился. Первоначально Kanban рассматривался как Agile-метод, основанный на концепции вытягивающей системы [61], которую впервые применила Toyota для разработки программного обеспечения. Сближение со Scrum дало гибридный термин ScrumBan, а также множество идей, изложенных в том числе в книге «Kanban & Scrum, Getting the best of both». В 2009 году я участвовал в переводе этой книги и докладывал эту тему на конференциях.
Kanban позиционировали как новый метод улучшения процесса разработки. В конце предисловия ко второму изданию книги Лорана Мориссо [Morisseau, «Kanban»] я резюмировал Kanban следующим образом:
Не просто еще один Agile-метод, но новый сервис-ориентированный метод улучшения процессов в соответствии с ценностями и принципами Agility, который способствует постепенному переходу и направлен за пределы проектов, на сами организации, пусть даже крупные, а то и за пределы ИТ.
Мое последнее предложение отразило миссию Kanban: быть методом управления, точнее, даже управления изменениями, и охватывать и другие области, помимо разработки программного обеспечения.
При написании этой главы я не преследовал цели предложить Kanban в качестве альтернативы Scrum. Я хотел бы показать, как в определенных ситуациях Kanban может дополнить, обогатить Scrum. Я начал это делать в предыдущих главах, предложив изображать рабочий процесс при помощи паттерна лотков, а также использовать паттерн роения – это все практики, появившиеся в Kanban. В самом начале я представил Scrum как поток событий – и в этом он похож на Kanban.
Scrum, очевидно, во многом вдохновлен Kanban-паттернами.
В этой главе я детальнее рассмотрю Kanban в качестве метода улучшения, применяемого к Scrum. Цель в том, чтобы при помощи других паттернов найти подход к проблемам, возникающим в определенных ситуациях, где применяется Scrum.
20.1 Зачем Kanban накладывать на Scrum?
Здесь я обратился к командам, уже внедрившим Scrum в свою работу. Провел опрос и узнал о наиболее частых проблемах. Представляю их ниже в виде карты (подробнее об инструменте impact mapping можно узнать в главе 15).
Рисунок 20.1 – Карта воздействия для улучшения
Цель опрошенных команд – гибко реагировать на изменения. Воздействия, относящиеся к тем или иным ролям, представляют собой ожидаемые ответы на возникшие проблемы.
Решения для достижения этих воздействий уже были представлены в предыдущих главах: роение, доработка и т. д. Жирным шрифтом на рисунке 20.1 выделены другие практики, или Kanban-паттерны, о которых мы узнаем в данной главе.
Речь в основном о ситуациях, когда команда сталкивается с высокой динамикой изменений (критерии контекстуализации в главе 14 «Контекстуализация Scrum»).
Kanban – это метод улучшения в виде постепенного и плавного изменения. Он заключается в следующих принципах:
✓ Начинать с того, что есть.
✓ Настроиться на постепенное изменение.
✓ Уважать текущий процесс, роли и обязанности.
В нашем подходе «Kanban в дополнение к Scrum» мы исходим из рамок Scrum с его спринтами, событиями, ролями и бэклогом.
Kanban предлагает шесть практик:
1. Визуализация рабочего процесса.
2. Ограничение незавершенной работы.
3. Измерение рабочего потока и управление им.
4. Четкая формулировка и прояснение правил управления процессом.
5. Имплементация циклов обратной связи.
6. Коллективное улучшение.
Порядок следования принципам соответствует степени, в которой Kanban применяется в работе.
Мы сфокусируемся на втором принципе и основной Kanban-практике: ограничение незавершенной работы.
Можно отметить, что остальных принципов мы хотя бы частично коснулись в предыдущих главах.
Ограничения используются, чтобы сделать поток более понятным и предсказуемым в системе. Цель в том, чтобы избежать перегрузки и обеспечить доступность.
Часто используется аналогия с дорожным движением: ограничение скорости позволяет уменьшить количество пробок и создать условия для беспрепятственного движения. Этот, казалось бы, парадокс еще больше сбивает с толку в мире работы, где совершенно непонятно, как замедление процесса может улучшить общую производительность.
Ограничения в Kanban – это практика ограничения незавершенной работы.
В частности, ограничение связано со столбцом доски (или лотком). Как только достигнут определенный предел элементов в столбце, новая запись невозможна, и перед командой встает вопрос, что делать дальше.
Это верхний предел, который помогает команде избежать захламления задач. По достижении этого предела участники обсуждают имеющиеся задачи, поощряется взаимопомощь.
Есть также другое, менее известное ограничение: нижний предел, который регулирует добавление новых записей. Это ограничение – в некотором роде альтернатива ритму Scrum.
Все, что здесь представлено, остается в Scrum-фреймворке, сохраняется структура и, в частности, спринты. Мы несколько изменили процесс планирования спринта, чтобы сделать его более гибким: в работу запускаются только начатые истории (см. главу 9).
Kanban-практика, которую мы накладываем на этот процесс, ограничивает работу. Давайте посмотрим, какие паттерны нам в этом помогут на уровне задач, историй и функциональностей.
20.2 Ограничение незавершенной работы
Начнем с введения верхнего предела для самого маленького элемента: задач.
На Scrum-доске спринта задачи разделены по трем колонкам: к выполнению, в процессе или к завершению, завершено. Добавить, под предлогом Kanban, еще один столбец в план спринта было бы очень плохой идеей: это создает очередь выполнения и многозадачность.
Очень часто в среднем столбце находится огромное количество элементов – те задачи, которые на данный момент в процессе выполнения. Их даже больше, чем людей в команде. Иногда на одного человека приходится по 5–6 задач, а то и больше! Конечно, некоторые задачи могут быть заблокированы препятствиями, надо сперва их устранить, чтобы вернуться к выполнению. Но зачастую в процессе находится непростительно много задач.
Ограничение текущих задач способствует обсуждению внутри команды и улучшает ситуацию. Это отправная точка для дальнейшего продвижения.