Книга: Постигая Agile

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

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

Давайте подробнее рассмотрим основополагающие принципы Канбана.

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

• Договоритесь об эволюционном развитии.

• Поощряйте лидерство на всех уровнях.

Первый принцип – начните с того, что вы делаете сейчас, – отличается от всего того, о чем вы читали в этой книге.

Мы потратили много времени на сравнение гибких методологий с традиционными водопадными проектами. Например, Scrum дает полную систему для управления и реализации проектов. Если вы хотите внедрить Scrum, то нужно создавать новые роли (scrum-мастер и владелец продукта) и новые виды деятельности (планирование спринта, ежедневные scrum-митинги, доски задач). Это необходимо, поскольку система Scrum предназначена для управления проектами и поставки программного обеспечения.

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

Привычное дело – думать о типичных проблемах.

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

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

Главная цель процесса улучшения состоит в поиске повторяющихся проблем, выяснении их общности и создании инструмента исправления.

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

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

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

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

Именно с такой системой Канбан начинает работать. У команды уже есть способ запустить свой проект, а Канбан нужен, чтобы лучше понять систему. То есть начните с того, что вы делаете сейчас. Цель Канбана – сделать небольшие улучшения в этой системе. Вот что значит добиваться постепенных, эволюционных изменений. И именно поэтому Канбан имеет практики совместного улучшения и экспериментального развития. В бережливом мышлении необходимо видеть все целиком, чтобы понять, что требует измерений. А они составляют сердцевину эксперимента и научного подхода. Канбан-команда начнет с исследования того, как производится программное обеспечение, и получит объективное понимание ситуации. Затем она проведет определенные изменения как команда (в этой главе вы узнаете, как именно эти изменения работают) и проверит свои измерения на предмет соответствия желаемому эффекту.

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

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

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

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

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

Не подскажет[83]. Канбан предлагает начать с понимания того, как вы в настоящее время реализуете свои проекты. Это может быть Scrum, XP, «лучше-чем-ничего», эффективный водопадный процесс, неэффективный водопадный процесс или даже беспорядочный метод научного тыка или кодирования «с наскока». Как только вы выясните, каким образом ваша команда создает программное обеспечение, Канбан предложит практики для улучшения.

Если у вас уже есть процесс разработки программного обеспечения, то зачем вам Канбан?

Большинству команд удается что-нибудь поставлять. Вы знаете, сколько усилий тратит команда? Какой ценностью обладает результат их работы? Или он вызывает проблемы и затрудняет поставку ценного программного продукта?

Если есть система – неважно какая, – то большинству такие вопросы могут даже не приходить в голову. Даже если вы используете Scrum или XP, вы можете терять впустую много времени, не подозревая об этом. Привычные проблемы очень трудно обнаружить. Каждый может следовать правилам и делать все верно. Но так же как поведение формируется самой системой, потери складываются из совместной работы многих людей.

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

Это и есть та проблема, которую решает Канбан.

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

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

Но очевидно, что они остаются командами, и мы предпочитаем рассматривать их участников как людей, а не роботов. Однако полезно думать о задаче, которую вы выполняете, как о части большой системы. Если применить системное мышление к scrum-команде, то становится ясно: выполняемая работа напрямую (или даже косвенно) способствует превращению историй в код. Признавая, что все в Scrum – система, вы поймете, как начать работать лучше и вносить усовершенствования. Такое мышление приводит к улучшениям, таким как дополнительные вопросы Джеффа Сазерленда для ежедневных scrum-митингов, о которых вы узнали в главе 5. Это хороший пример системного мышления, применяемого к Scrum, что приводит к эволюционному усовершенствованию.

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

Легко понять, что команда, исповедующая Scrum, использует систему. Но что если ваша команда не применяет подобные методы? Может быть, вы просто погружаетесь в работу над программным обеспечением? Выглядит все так, будто вы каждый раз запускаете проекты по-разному. Поэтому вы не имеете системы, правда?

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

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

Когда вы берете ММФ (минимальную маркетинговую функцию, о которой мы узнали в главе 8, – например, историю, требование или пользовательский запрос) и выявляете систематизированный поток ценности, ведущий к написанию кода, вы должны записать путь через вашу систему.

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

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

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

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

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

Столбцы на канбан-доске могут показаться похожими на этапы в потоке ценности. Однако многие канбан-эксперты разделяют понятия «систематизация потока ценности» и «канбан-доска». Они отражают на доске состояние рабочих элементов в рабочем процессе независимо от потока ценности и называют это картой жизненного цикла. Разница в том, что поток создания ценности – инструмент бережливого мышления, помогающий понять работу системы, а карта жизненного цикла – это то, как канбан-метод определяет конкретные этапы, которые проходит каждый рабочий элемент. (Дальше в этой главе вы узнаете, как построить канбан-доску.)

Вот пример того, как доска задач делает одно, а канбан-доска другое. Scrum помогает командам в самоорганизации и выполнении коллективных обязательств. К моменту начала использования доски задач команда уже выбрала элементы бэклога (рабочие элементы), которые включены в спринт, и разбила их на задачи. Так как текущие задачи перемещаются по доске задач, рабочие элементы начинают перемещаться из колонки «сделать» в колонку «сделано». Команда воспринимает это как прогресс.

Типичная канбан-доска показывает крупные рабочие элементы, а не отдельные задачи. И хотя на доске задач видны только рабочие элементы с разными статусами («сделать», «в процессе» или «сделано»), канбан-доска будет иметь широкую картину. Откуда берутся рабочие элементы? Как владелец продукта узнает, что рабочий элемент размещен в бэклоге проекта, и как расставляются приоритеты? После того как команда закрывает рабочий элемент, как она может отследить правильность его разворачивания? Рабочий элемент имеет большой жизненный цикл, выходящий за пределы создающей его команды. Канбан-доска будет иметь колонки для этапов, которые проходит рабочий элемент до того, как scrum-команда получит его, и после завершения работы над ним.

Более того, канбан-доска поможет показать проблемы, которые никогда не появляются на доске задач. Многие scrum-команды очень сильны в создании программного обеспечения, о котором их просят пользователи, но разочарованные клиенты все-таки остаются. Возможно, они создают рабочие элементы, не удовлетворяющие потребностям пользователей. Или между созданием рабочих элементов и процессом обзора результатов либо развертывания наблюдается слишком большой временной промежуток. Хотя эти проблемы вне контроля команды, часто обвиняют именно ее. Канбан-доска поможет решить этот вопрос.

Таким образом, хотя Канбан – это не система для управления проектами, он имеет очень важную связь со способом управления проектом, который применяет команда. Канбан направлен на улучшение и изменение процесса, используемого в проекте, и на то, как это может повлиять на управление им. Как правило, Канбан применяют для повышения предсказуемости потока, и это влияет на планирование и план проекта. Широкое использование Канбана и его показателей, скорее всего, окажет существенное воздействие на метод проектного управления[84].

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

Оглавление книги