Постигая Agile Грин Дженнифер
Поставляйте как можно быстрее
Есть еще одна lean-ценность – поставляйте как можно быстрее.
Как вы это понимаете? Возможно, вам представляется, как грозный руководитель или менеджер проекта принуждает команду работать допоздна, чтобы поскорее выпустить готовый код. Означает ли решение «поставлять как можно быстрее» отказ от тестов, низкоприоритетных функций и всего остального, что считается «посторонним» или низкоприоритетным? А может быть, вы вспоминаете о героических разработчиках, засиживающихся в офисе до поздней ночи и в выходные или стремящихся пропихнуть свои «быстрые-и-грязные» костыли, чтобы получить важную функцию на выходе. Как раз все это рождается в умах большинства менеджеров, когда они слышат фразу «поставляйте как можно быстрее». Многие разработчики, тестировщики и другие инженеры думают то же самое.
Agile-команды знают, что подобные вещи заставят команду поставлять программные продукты медленнее, а не быстрее. Это идея о том, почему есть agile-принцип содействия устойчивому развитию («спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного срока» – один из принципов, о которых вы узнали в главе 3). Срезание пути и углов и сверхурочная работа требуют больше времени и денег, чем экономят. Команды выполняют работу лучше и быстрее, когда у них есть время, чтобы сделать все правильно.
Хотя это верно, но звучит абстрактно и несколько возвышенно. Принцип сосредоточенности из Scrum и XP-практики энергичной работы помогает сделать это правило более конкретным. Scrum и XP дали понимание того, как добиться оптимальных темпов для поставки с использованием итераций и потока. Lean развивает эту идею, предлагая три инструмента мышления, способные помочь командам поставлять как можно быстрее: систему вытягивания, теорию массового обслуживания и стоимость задержки.
Цель теории массового обслуживания – это необходимость убедиться, что люди не перегружены работой и у них есть время делать вещи правильно. Очередь представляет собой список задач, функций или элементов для группы либо индивидуального разработчика. Очереди имеют порядок. Это, как правило, «первый вошел, первый вышел». Согласно данному правилу, никто не может изменять очередность и элемент, который попал в очередь первым, прежде других вытягивается следующим участником и берется в работу. Теория массового обслуживания является математическим исследованием очередей, и одно из ее направлений включает в себя предсказание тех последствий, которые вызываются добавлением очередей на входе системы. Lean говорит, что если сделать очередь как поток командной работы публичной и центральным местом в процессе принятия решений, то это поможет командам поставлять результаты работы значительно быстрее.
Ключевые моментыКогда менеджеры считают, что команды могут сделать невозможное, и игнорируют реальные ограничения проекта, они используют магическое мышление.
Команды при помощи бережливого мышления ведут работу по ликвидации потерь, находя любые виды деятельности, которые напрямую не способствуют построению ценных продуктов, и устраняя их.
Любая деятельность, которая явно не добавляет ценности проекту, считается потерями. Lean-команды стремятся увидеть их и исключить из проектов, насколько это возможно.
Мэри и Том Поппендик зафиксировали семь потерь разработки программного обеспечения: частично проделанная работа, дополнительные процессы, лишние функции, переключение между задачами, ожидание, движение и дефекты.
Построение целостности – это lean-ценность, включающая в себя воспринимаемую целостность, или то, как хорошо продукт удовлетворяет потребности пользователей, и концептуальную целостность, или то, как слаженно работают функции продукта.
Бережливое мышление помогает командам увидеть ситуацию в целом или объективно понять то, как работает команда, в том числе ее недостатки. Измерение дает возможность сохранить объективное представление о проекте и команде.
Поставлять как можно быстрее значит избавиться от любых ненужных действий, приводящих к задержкам в работе и возникновению узких мест.
Как узнать, сможете ли вы поставить программный продукт максимально быстро?
Бережливое мышление предлагает использовать для этого измерения. Эффективный способ определить, как команда поставляет ценные продукты, – применение диаграммы незавершенных работ (work-in-progress, WIP-диаграмма). Это простая схема, которая показывает, как минимальные маркетинговые функции протекают через ваш поток создания ценности.
Если вы создали карту потока ценности, то можете построить WIP-диаграмму – плоскую диаграмму, показывающую, как объекты, продукты или другие меры величины потока ценности проходят через каждую часть потока создания ценности. Это работает нагляднее, если вы используете ММФ, поскольку они представляют собой минимально определенный размер того «куска» пользовательской ценности, который создается.
Рассмотрим карту потока ценности, которая показывает, как мастерская веб-разработки создает большую часть своих ММФ.
Рис. 8.3. Мы будем использовать карту потока ценности для построения WIP-диаграммы
Цель WIP-диаграммы состоит в том, чтобы показать полную историю прогресса работ и все те ценные характеристики, над которыми команда работает в настоящий момент. График демонстрирует, сколько ММФ находятся в работе в любой из дней и как они разбиваются на различные этапы потока создания ценности. Прогресс работ – это измерение, касающееся функционала, несущего ценность заказчику, а не технических задач. Другими словами, он показывает количество функционала или частей продукта, которые находятся в работе, а не конкретные задачи, выполняемые командой, чтобы произвести их. В Scrum мы называли их историями. Команда разбивала истории на задачи, которые перемещала на доске задач. Здесь, по аналогии, мы проводим измерение потока историй. Пользовательская история – хороший способ понять ММФ, потому что она представляет собой небольшой, самодостаточный кусок ценности, поставляемой клиенту. История могла бы появиться в WIP-диаграмме, но задачи, которые команда использует, чтобы реализовать историю, этого не могут.
Чтобы построить WIP-диаграмму, начните с оси X, показывающей дату, и оси Y, которая обозначает количество ММФ. Диаграмма содержит линию для каждого из элементов на карте потока ценности. Линии делят диаграмму на области для элементов карты потока ценности.
Нет прогресса никаких ММФ до начала проекта, так что есть только одна точка при Х = 0 в левой части диаграммы (день 0). Допустим, что при запуске проекта команда начинает работать с пользователями над девятью пользовательскими историями, и она применяет их как ММФ для своего проекта. Несколько дней спустя добавляются еще три истории. Вы сможете нарисовать точку на 9 в первый день, потом еще на 9 + 3 = 12, и, когда эти новые ММФ добавятся, вы сможете соединить точки линией.
Рис. 8.4. Начните строить WIP-графики, создавая линейную диаграмму ММФ (например, пользовательских историй) на первом этапе потока создания ценности, и затените область под ней
Несколько дней спустя программисты начинают работать над созданием дизайн-макетов для четырех историй, так что эти истории прогрессируют к следующему этапу потока создания ценности. Общее количество ММФ в системе – по-прежнему 12, но теперь они разделены на 8, еще находящихся в разработке (или ожидающих, поскольку карта потока ценности описывает и время работы, и время ожидания), – на первом этапе потока создания ценности, и 4 – на втором этапе. Так что вы можете добавлять точки на 4 и 12 ММФ, чтобы представить это.
Рис. 8.5. Когда работа прогрессирует к следующему этапу в потоке ценности, на WIP-диаграмме добавляется новая линия, разделяя ее на две зоны. Верхняя линия по-прежнему представляет общее количество ММФ в прогрессе, а пространство между ней и новой линией представляет количество ММФ, находящихся на первом этапе
Поскольку ММФ перемещаются по потоку создания ценности, общее количество задач растет и с течением времени WIP-диаграмма приобретает вид полосок, соответствующих каждому из этапов карты потока ценности. Что происходит, когда создание всех ММФ завершено? Если вы продолжаете показывать их на графике, то в конце концов количество ММФ в стадии «сделано» разрастается до таких размеров, что мешает воспринимать все остальные столбцы. Это делает активные ММФ похожими на ленту на вершине горы.
Это показывает рост, а не поток. Безусловно придавая больший вес вашему отчету и помогая произвести впечатление на старшего менеджера (поскольку демонстрирует, что команда проделала огромный объем работы), это не слишком-то полезно для управления потоком. Удаление с диаграммы работ со статусом «сделано» дает более четкую визуализацию того, как со временем изменяется протекание потока ценности.
Рис. 8.6. WIP-диаграмма показывает, как работа прогрессирует со временем
Рис. 8.7. Когда команда хочет показать руководителю, сколько работы выполнено, она оставляет задачи со статусом «сделано» на графике, потому что это выглядит впечатляюще. К сожалению, это делает его менее удобным для измерения прогресса работ
Рис. 8.8. Полезно удалять задачи со статусом «сделано» с графика и использовать разные оттенки для каждой полосы, чтобы было понятно, каким столбцам они соответствуют
Вот почему большинство WIP-диаграмм не включают в себя завершенные задачи. Таким образом, если проект стабилизируется с течением времени, то WIP-диаграмма также выглядит стабильной[80].
Когда ММФ переходит из одного этапа потока создания ценности в следующий, полоса старого этапа становится тоньше, а полоса нового – толще.
Это позволяет легко обнаруживать тенденции – как, например, когда много ММФ переходят из одного столбца в другой (или удаляются из потока ценности полностью) в одно и то же время.
Рис. 8.9. WIP-диаграмма помогает видеть, как работает поток создания ценности, а также легче обнаруживать задержки и другие потенциальные потери – например, те истории, которые слишком долго ожидают своего развертывания в производство
Есть важная идея, которую использует теория массового обслуживания. Это теория ограничений, созданная физиком и гуру менеджмента Элияху Голдраттом. Одна из главных идей этой теории заключается в том, что особое ограничение (например, работа, которая копится перегруженной командой) устанавливает предел общего объема работ, который можно пропустить через систему. Когда данное ограничение устранено, другое ограничение становится критическим. Теория ограничений утверждает: каждый перегруженный рабочий процесс имеет по крайней мере одно ограничение.
Когда ограничение накапливается в определенной точке рабочего процесса, люди часто называют это узким местом или бутылочным горлышком. Если убрать одно узкое место в системе (за счет изменения процесса или добавления людей), то можно добиться, чтобы работа протекала более гладко. Теория ограничений говорит нам, что обнаружится, однако же, какое-нибудь иное ограничение или узкое место где-то еще в системе. Между тем можно уменьшить общий объем потерь путем систематического отслеживания критических ограничений и их ликвидации.
Каково это – работать в команде, которая ежедневно имеет дело с одним из этих ограничений? Другими словами, как быть, если вы и ваша команда – это и есть узкое место?
Оказавшись узким местом в системе, всегда ожидаешь работы в многозадачном режиме с постоянным переключением между нормальной работой с полной занятостью и более редкими эпизодами разовых задач. Имейте в виду: множество команд, как правило, нагружены массой задач, возложенных на них в то же самое время, но не называйте это «многозадачностью». Люди обычно используют термин «многозадачность», чтобы замаскировать факт перегруженности команды. Разделение работы и подталкивание команды к многозадачному режиму часто удерживает вас от признания, что работы больше, чем времени, особенно если учесть дополнительное время и когнитивные усилия, необходимые для переключения между задачами.
Например, команда, которая 100 % своего времени посвящает разработке, может иметь руководителя с магическим мышлением, который просит ее потрудиться несколько часов в неделю в режиме многозадачности, в связи с чем люди уже не имеют ни поддержки, ни обучения, ни ремонта, ни совещаний, ни других дел. Им трудно однозначно определить, что работы оказалось больше, чем времени, особенно если лишние задачи добавляются понемногу, а не за один раз. Разработчики начинают чувствовать себя перегруженными, и, поскольку все это носит название «многозадачность», они не всегда догадываются, почему им так тяжело. Появится чувство, будто есть много работ на неполный рабочий день, за которыми невозможно угнаться. Можно помочь команде, применяя теорию массового обслуживания, чтобы разобраться в проблеме. Теперь мы знаем, что работа накапливается в узком месте где-то в рабочем процессе и растет взваленный на разработчиков ее объем.
И у меня есть философия, которой я живу. Все, кто работает со мной, знают об этом, вот она – на стене: «Если глупость входит в комнату, то у вас есть моральный долг застрелить ее независимо от того, кто ее сопровождает».
Кеоки Андрус. Beautiful Teams (глава 6)
Система вытягивания – способ выполнения проекта или процесса, который использует очереди или буферы для устранения ограничений. Это еще одна концепция из тех, что возникли в японской автомобильной промышленности, но впоследствии нашли свое место в области разработки программного обеспечения. Производители автомобилей, в частности Toyota, в 1950-х и 1960-х годах оценили свои склады комплектующих и попыталась найти способы уменьшить количество деталей, которые должны там лежать. После длительных экспериментов они обнаружили, что даже если в наличии почти все детали, необходимые для сборки автомобилей, то дефицит нескольких деталей может задержать всю линию. Потому что в итоге все монтажные бригады ждут поставки недостающих запчастей. Стоимость задержки становится важна: если деталь в дефиците, то задержка ее поставки на конвейер оказывается очень дорогой, а если часть имеется в изобилии, то стоимость задержки низкая.
Команды Toyota обнаружили, что можно сократить расходы и поставлять автомобили гораздо быстрее, если знать, какие запчасти нужны прямо сейчас, и поставлять на линию только их. Чтобы реализовать это, они придумали производственную систему Toyota (TPS). Это предшественница бережливого производства, которые Том и Мэри Поппендик адаптировали для создания бережливой разработки программного обеспечения.
В основе TPS лежит идея существования трех типов потерь, которые создают трудности в рабочем процессе и должны быть удалены.
Муда (), что означает «бесполезность, бесперспективность, праздность, избыточность, потери, расточительность».
Мура (), что означает «неравномерность, неритмичность, отсутствие единообразия, неоднородность, неравенство».
Мури (), что означает «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».
Любой, кто участвовал в плохо управляемых, буксующих проектах программного обеспечения – особенно тех, что используют неэффективный процесс, – не понаслышке знаком с идеями неравномерности, бесполезности и неразумности. Это верно для неэффективных водопадных процессов, но любой работавший, скажем, в команде с неправильным мышлением, способной достигать только результата «лучше-чем-ничего» (или еще худшего) с применением Scrum или XP-практики, также может распознать эти случаи.
Не кажутся ли вам знакомыми какие-либо из перечисленных ниже действий?
• Заставить всех подписать спецификацию занимает много времени, а разработчики между тем сидят и ждут старта проекта. Как только он начнется, они уже опоздали.
• Вечная забота менеджмента – обеспечить бюджет. К тому времени, когда проект получает зеленый свет, думать об этом уже поздно.
• На середине разработки группа признает, что важные элементы дизайна или архитектуры программного обеспечения должны быть изменены, но это вызовет большие проблемы, потому что зависят от них многие другие вещи.
• QA-команда (Quality Assurance) не начинает тестирования программного обеспечения, пока каждая функция не будет завершена. Позднее они найдут серьезную ошибку или проблемы с производительностью, и команде разработки придется отвлекатьсяот текущей работы, чтобы это исправить.
• Анализ и дизайн продолжаются так долго, что, когда кодирование все-таки начнется, каждый программист вынужден работать по ночам и выходным, чтобы уложиться в срок.
• Архитектор программного обеспечения проектирует большие красивые сложные системы, которые внедрять нецелесообразно.
• Даже мельчайшие изменения в спецификации, документе или плане проекта должны пройти трудоемкий процесс управления изменениями. Вместе с тем люди находят способы, чтобы обойти его, внося радикальные, крупномасштабные изменения в систему заявок на техподдержку или отслеживание ошибок.
• Проект не успевает завершиться в срок, поэтому руководитель добавляет людей в команду в последние несколько недель. Вместо ускорения выполнения проекта этот шаг создает путаницу и хаос[81].
Вспомните ваши собственные проекты, которые столкнулись с проблемами из-за заведомо глупых действий. Возможно, это правила, которые пришлось выполнять (или обходить), установленные вашим руководителем или являющиеся частью культуры компании. А может быть – ненужные дедлайны, произвольно назначенные, чтобы мотивировать вас.
Эти вещи неслучайны. Найдите время поразмыслить над определениями «муда», «мура» и «мури». Обдумайте список знакомых проблем проекта, а также тех, с которыми вы сталкивались сами. Сможете ли вы сопоставить каждую из них с одной из этих трех категорий. Были ли действия, которые пришлось выполнять, тщетными, бесполезными или лишними? Это муда – работа, которую вы должны делать, хотя она не добавляет ценности. Случалось ли вам сидеть, ожидая кого-то, чтобы получить работу? Это мура – неравномерность, или работа, происходящая урывками. А как насчет сверхурочных или работы по выходным, потому что вам надо было сделать больше, чем позволяют человеческие силы? Это мури – перегрузка, или ожидание необоснованных либо невозможных вещей.
Хотя есть много различий между разработкой программного обеспечения и производством автомобилей, Поппендик признали, что идеи бережливого производства имеют место в программных проектах. Поэтому логично предположить, что если команды разработки ПО сталкиваются с проблемами, похожими на те, что встречаются в промышленном производстве, то и решения, подходящие для производителей автомобилей, будут полезны и для команд программного обеспечения. В промышленности таким решением является вытягивающая система (также известная под названием «точно-в-срок»).
В 1950-е годы производственный коллектив Toyota возглавлял Тайити Оно. Он признавал, что трудно предугадать заранее, какие запчасти будут в дефиците, – часто оказывалось, что это самые разные детали. В этом заключалась первопричина потерь (муда, мура и мури). Поэтому они придумали систему, при которой на каждой сборочной линии специальные станции сигнализировали о готовности к большему количеству деталей группе, созданной для их поставки на основе этих сигналов. Каждая станция должна иметь небольшие очереди из запчастей, в которых нуждается производство. Вместо того склада, который выталкивал запчасти на линию, появилась линия, вытягивающая детали и бравшая их только тогда, когда запас в очереди сильно снижался.
Это называется вытягивающая система, потому что она состоит из отдельных независимых групп или членов команды, которые вытягивают лишь нужные им запчасти (вместо большого регулярно пополняемого запаса деталей, проталкиваемых к ним). Toyota и другие автопроизводители обнаружили, что процесс сборки стал значительно быстрее и дешевле, потому что избавился от огромных потерь и времени на ожидание. Действительно, каждый раз, когда определенный элемент потерь выявлялся, им удавалось сделать небольшое изменение в процессе с целью его ликвидации.
Системы вытягивания очень полезны для создания программного обеспечения – именно по той же причине, по которой они нужны на производстве. Вместо того чтобы пользователи, менеджеры либо владельцы продуктов проталкивали задачи, функции или запросы в направлении команды разработки, они добавляют их в очередь, из которой команда сама их вытягивает. Когда работа возвращается, вызывая неравномерность в середине проекта, они могут создать буфер, чтобы сгладить ее. Команда способна поддерживать несколько различных очередей и буферов в течение проекта. И как оказалось, это очень эффективный способ сокращения времени ожидания, удаления потерь и оказания помощи пользователям, менеджерам, владельцам продуктов и командам разработки в принятии решения о том, какое программное обеспечение уже готово.
Вот очень простой пример того, как система вытягивания может решить знакомую проблему: команде разработчиков ПО приходится ждать, пока каждая функция будет описана в большой спецификации, которая затем должна пройти через сложный процесс обзора и согласования. Может быть, этот процесс – способ получения всех перспективных мнений от каждого человека либо попытка спасти собственную шкуру, когда руководители и заинтересованные стороны боятся взять на себя ответственность. Это также может быть частью культуры компании, которая всегда так поступала, не думая о расточительности подобного поведения. Как бы выглядел этот процесс, если бы мы заменили его простой системой вытягивания?
Рис. 8.10. Эта карта потока ценности показывает потери, которые происходят, когда вся команда ждет большой спецификации, которая должна быть создана и утверждена
Это очень знакомая проблема, и в реальном мире многие команды нашли способы обойти ее. Например, дизайнеры и архитекторы могут сделать предпроект, основанный на раннем черновике спецификации и их лучших предположениях о том, что они будут создавать. Но время, которое команда тратит на поиск способов устранения потерь, она могла бы использовать гораздо продуктивнее. Она по-прежнему будет нести потери, часто и много, особенно если ее догадки окажутся неверными и ей придется отменить некоторые из предпроектных решений.
Система вытягивания – это лучший способ удалить неравномерности и предотвратить перегрузки.
Первым шагом в создании системы вытягивания должно стать разделение работы на маленькие вытягиваемые куски. Таким образом, вместо создания большой спецификации команда может разбить ее на минимальные маркетинговые функции – скажем, отдельные пользовательские истории и, возможно, небольшие фрагменты документации, сопровождающей каждую историю. Затем эти истории будут утверждены по отдельности. Как правило, когда процесс просмотра и согласования спецификации затягивается, причина в том, что люди имеют проблемы с некоторыми функциями. (Способны ли вы понять, как разделение работы на более мелкие ММФ дает команде больше возможностей? Это вариантное мышление.) Утверждение индивидуальных ММФ должно привести к быстрому получению одобрения как минимум для нескольких функций. Как только первая ММФ утверждена, команда может начать работать над ней. Теперь не нужно строить предположений. Вместо этого начинается реальное обсуждение той работы, которую требуется выполнить. Процесс утверждения может иметь под собой реальные основания (например, нормативное требование регулятора или подлинную необходимость узнать точку зрения каждого), теперь команда может получить реальный сигнал начать работу.
Вот так все принципы бережливого мышления – видение целого, выявление потерь и создание системы вытягивания для устранения неравномерности и чрезмерных нагрузок – могут собраться вместе, чтобы помочь команде усовершенствовать работу. Но это только начало. В следующей главе вы узнаете о том, как применить lean-мышление, чтобы улучшить способ, при помощи которого команда создает программное обеспечение.
Ключевые моментыМинимальная маркетинговая функция (ММФ) – самый маленький «кусок» ценности или функциональности, который команда способна поставить, например пользовательская история или запрос пользователя – то, что может закрыть пункт в бэклоге владельца продукта.
Карта потока ценности – это визуальный инструмент, помогающий lean-команде реально увидеть, как работает проект, показывая весь жизненный цикл ММФ, в том числе время работы и время ожидания на каждом этапе.
Понимание первопричин проблемы поможет вам увидеть ее в целом. Метод пяти «почему» – эффективный способ сделать это.
Полезный инструмент, помогающий команде поставлять как можно быстрее, – WIP-диаграмма, визуальный инструмент, который показывает, как ММФ следуют через поток создания ценности проекта.
Есть три важных вида потерь, которые ограничивают рабочий процесс: муда (потери), мура (неравномерность) и мури (необоснованность и невозможность).
Информация о том, как выполнять проекты, кажется полезной, но мне до сих пор трудно понять, как это влияет на мою повседневную работу. Как может Lean помочь в моей работе?
Обычно нам не нравится слушать теоретические рассуждения – когда говорят нечто подобное, это обычно признак того, что не видят здесь возможности немедленного практического применения. Однако во многом это на самом деле правда о Lean, так как Lean – это мышление. Оно не включает практик, которые ваша команда могла бы применять ежедневно, как Agile-манифест или Scrum и XP-ценности. Но, как и Agile-манифест, Scrum и XP-ценности, Lean является правильным мышлением, очень ценным для команды, если вы хотите лучше писать программное обеспечение.
В главе 2 мы ввели идею раздробленного видения. На протяжении всей книги вы видели много примеров, как это приводит к тому, что команда либо получает результат «лучше-чем-ничего», либо (в худшем случае) приходит к полному провалу проекта. Бережливое мышление помогает вам взглянуть с высоты птичьего полета не только на проект, но и на всю команду, компанию, ее правила, политику и культуру, которые вызывают у вас серьезные проектные проблемы.
Вернемся в начало этой главы и посмотрим на lean-ценности еще раз. Эти ценности помогут взглянуть на ту работу, которую вы делаете прямо сейчас.
Как только вы начинаете искать потери, вы замечаете их повсюду («устраняйте потери»). Вы перестаете видеть программу как набор отдельных задач и начинаете воспринимать ее как систему («видеть целое»). Вы будете использовать такие инструменты, как «пять “почему”», чтобы выйти за пределы фиксации отдельных проблем в работе, которую сделала команда, и распознать системные проблемы, влияющие на проект снова и снова («усиление обучения»). Каждая lean-ценность изменяет способ, которым вы смотрите на проект, команду и компанию. Это поможет вам увидеть более широкую перспективу.
В главе 9 вы узнаете, как обзавестись этой новой точкой зрения и использовать ее для реальных, постоянных изменений, чтобы улучшить создаваемое вами программное обеспечение.
Вы сказали, что «мури» может переводиться как «невозможно», но разве это не отрицание? Ведь считается, что все возможно при наличии мотивированной команды, верно?
Если бы только это было правдой. Проведем мысленный эксперимент, чтобы показать вам, что некоторые вещи действительно невозможны.
Представьте себе, что CEO вашего небольшого стартапа заходит в офис и говорит, что ваш самый крупный клиент зациклен на Бруклине. Руководитель кладет пакет зубочисток и палочек для мороженого на стол и сообщает: если ваша команда сможет сделать идеальный макет Бруклинского моста из зубочисток и палочек для мороженого к моменту появления клиента, то тот утроит бизнес компании и сделает вас богатыми. Если же работа не будет выполнена на отлично, то он уйдет к конкуренту, и тогда вашей компании конец.
Клиент будет здесь менее чем через час. Все за дело! Нет ничего невозможного! Вы сможете сохранить вашу компанию, верно?
Если вы не инженер-строитель, который к тому же виртуозно управляется с клеем, то вы потерпите неудачу. Некоторые задачи невозможно выполнить, несмотря ни на какую мотивацию.
Есть люди, умудряющиеся убедить свои команды, что мотивация – это все, что нужно для достижения цели. Управление такого типа (то, что мы называем магическим мышлением) опасно. Когда вы работаете в команде, которая действует так, словно вы и впрямь на многое способны, вы будете регулярно ожидать того, чего невозможно достичь. Часто это происходит из-за нереалистичных или неразумных сроков. Но иногда проблема в технической неосуществимости (или, по крайней мере, невозможности обойтись без очень большого объема работы – как в том случае, когда весь ваш код находится в ужасной форме и «с душком»).
Это мури. Еще раз прочтем определение, которое мы дали ранее: «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».
Бережливое мышление помогает определить мури и понять, что любое усилие, которое вы тратите, пытаясь сделать невозможное, – это потери. Самый эффективный способ устранить их – это в первую очередь исключить магическое мышление, которое побуждает стремиться к невозможному.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с вашей командой).
• Определите все ММФ в вашем проекте. Как они достигаются? Вы пишете истории пользователей на карточках или стикерах и помещаете их на доску задач? Есть ли у вас индивидуальные требования в спецификации? Найдите большую функцию или историю и решите, сможете ли вы разбить ее на более мелкие куски.
• Ищите потери в вашем проекте. Запишите примеры муда, мура и мури.
• Найдите любые ММФ, которые ваша команда уже завершила, и создайте карту потока ценности для них. Хорошо, если вы сможете собрать всю команду, чтобы сделать это вместе. Затем создайте карту потока ценности для другой ММФ. Каковы сходства и различия между двумя потоками ценности?
• Найдите узкое место, на которое ваша команда регулярно натыкается. (Карты потока ценности могут оказаться для этого очень полезными.) Организуйте дискуссию о том, как вы можете облегчить эту проблему в будущем.
• Посмотрите на даты, за которые вы и ваша команда сейчас отвечаете. Вы действительно взяли на себя те обязательства, про которые думаете, что вы их взяли? Есть ли варианты поставить что-то другое, одновременно выполнив эти обязательства?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о Lean, ценностях бережливого мышления и картах потока ценности в книге Мэри и Тома Поппендик Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003).
• Узнайте больше о Lean и картах потоков создания ценности в книге Алана Шэллоувея, Гая Бивера и Джеймса Тротта Lean-Agile Software Development: Achieving Enterprise Agility (Addison-Wesley, 2009).
• Вы сможете узнать больше о ММФ, о том, как разбить или разложить пользовательские истории, в книге Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (М.: Вильямс, 2012).
• Узнайте больше о возможностях вариантного мышления в романе об управлении рисками проекта Олава Маасена, Криса Матса и Криса Хипихапу Commitment (Hathaway te Brake Publications, 2013).
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Большинство людей, работающих в командах разработки программного обеспечения, никогда не сталкивались с мышлением, имеющим собственное название. Помогая им понять, что Lean – это мышление, а не методология, вы сделаете первый шаг к его принятию командой.
• Привычка говорить о потерях – одна из самых трудных частей бережливого мышления. В то время как большинство коучей соглашаются, что команды должны оставаться позитивными, «выяснение отношений» может оказаться полезным, когда дело доходит до помощи команде научиться определять потери (особенно когда речь идет о неразумности и невозможности).
• Вы можете вести дискуссию о потерях в положительном ключе, помогая найти примеры того, что можно считать потерями с точки зрения проекта, но не компании, для которой это жизненно важные вещи. Это поможет вести вашу дискуссию эмоционально верно, не говоря о потерях в негативном смысле.
• Часть вашей работы как коуча состоит в том, чтобы избегать трений между командой и компанией. Если имеются случаи, когда даже обсуждение проблем с топ-менеджерами может привести к серьезным последствиям для команды, то внедрение Agile способно вызвать более серьезные проблемы. Максимально аккуратно работайте с менеджерами, чтобы помочь им признать, что они используют магическое мышление.
• Еще один способ оставаться позитивным – это помогать обеим сторонам (и командам, и менеджерам) отделять процессы или системы от людей, работающих в них. Потери, неэффективность, обратная связь – это про то, что нужно сделать с процессом, а вовсе не суждения о людях, выполняющих свою работу.
Глава 9. Канбан, поток и постоянное совершенствование
Канбан – это не методология разработки программного обеспечения, прием описания жизненных циклов или подход к управлению проектами. Вам необходимо наличие какого-то базового процесса, к которому можно применить Канбан, для постепенного изменения и улучшения этого процесса.
Дэвид Андерсон. Канбан. Альтернативный путь в Agile[82]
Канбан – это метод улучшения процессов, используемых гибкими командами. Команды, применяющие его, начинают понимать, как они создают программное обеспечение, и постепенно улучшают его. Канбан, так же как Scrum и ХР, затрагивает образ мышления человека. В частности, он требует бережливого мышления. Мы уже узнали, что Lean – это образ мышления, ценности и принципы. Команды, использующие Канбан, начали с применения мировоззрения Lean. Это обеспечивает прочный фундамент, который в сочетании с Канбаном дает возможность улучшить процессы. Когда команды используют Канбан для усовершенствования, они сосредоточены на устранении потерь из процессов (в том числе муда, мура и мури – потери неровности, перегрузки и бесполезности, о которых мы узнали в главе 8).
Канбан – это технологический термин, адаптированный Дэвидом Андерсоном для разработки программного обеспечения. Вот как он описывает взаимоотношения с Lean в своей книге «Канбан. Альтернативный путь в Agile»: «Канбан-метод представляет собой сложную адаптивную систему, предназначенную для активации lean-решений в рамках организации». Есть команды, которые применяют Lean и бережливое мышление для разработки программ без использования Канбана, но на сегодняшний день это наиболее распространенный метод (и эффективный для многих agile-практиков) внедрения бережливого мышления в организацию.
Канбан отличается от гибких методологий, таких как Scrum и ХР. Scrum преимущественно ориентирован на управление проектами: объем работы, который должен быть проделан, чтобы эта работа была выполнена, и результат, необходимый пользователям и стейкхолдерам. ХР ориентирована на разработку программного обеспечения, ее ценности и практики строятся вокруг создания благоприятных условий для развития и формирования привычек, помогающих разработчику писать простой и легко изменяемый код.
Канбан помогает команде улучшить способы разработки программного обеспечения. Команда, использующая этот метод, имеет четкое представление о том, какие действия совершает при создании программного продукта, как взаимодействует с остальной компанией, как образуются потери, вызванные неэффективностью и неравномерностью, и каким образом со временем исправить ситуацию, устранив основную причину этих потерь. Когда команда улучшает способ создания ПО, это традиционно называется процессом усовершенствования. Канбан – хороший пример применения гибких идей (таких как последний ответственный момент) для создания метода усовершенствования процесса, который команды могут легко принять.
Практики Канбана позволяют стабилизировать и улучшить систему разработки программного обеспечения. Актуальный список основных практик можно найти в группе Kanban Yahoo!
Во-первых, следуйте основополагающим принципам:
• Начните с того, что вы делаете сейчас, уважайте имеющиеся роли, обязанности и должностные инструкции.
• Договоритесь об эволюционном развитии.
• Поощряйте лидерство на всех уровнях.
Затем принимайтесь за основные практики:
• визуализацию;
• ограничение числа задач в работе (WIP);
• управление потоком;
• сделайте правила явными;
• введите петли обратной связи;
• развивайтесь совместно и экспериментируйте (используя моделирование или научный подход).
На начальном этапе не требуется внедрять все шесть практик. Частичная реализация признается поверхностной и предполагает постепенное углубление, поскольку большинство практик принимаются и выполняются с большим потенциалом.
В этой главе вы узнаете о Канбане, его принципах, взаимоотношениях с Lean и практиках. Мы расскажем, как сосредоточение на потоке и теории массового обслуживания поможет вашей команде внедрить бережливое мышление в практику и создать культуру постоянного совершенствования.
Описание: команда, работающая над созданием приложения для камеры мобильного телефона в организации, купленной большой и многопрофильной интернет-компаниейКэтрин – первый разработчик
Тимати – второй разработчик
Дэн – их руководитель
Акт II. Игра в догонялки
Дэн раздражал Кэтрин и Тимати. Они понимали, что есть сроки и выполняемая работа важна. Они даже не возражали против давления, которое он оказывал. Но казалось, что каждый, даже самый маленький проект завершался «в режиме интенсивной терапии», как называл это Дэн, когда начинал заниматься микроменеджментом.
Текущий проект не отличался от остальных. Они работали над новой функцией приложения для камеры телефона, которая превращает лица друзей в старые плакаты «Разыскивается». Предполагалось, что это будет простой проект, который интегрирует их приложение с системой социальных сетей материнской компании.
Как обычно, во время тестирования обнаружилось множество ошибок, что заставило их пропустить дедлайн.
– Я уверен, что у нас не было бы проблем со сроками, если бы он не мешал нам работать, – сказал Тимати.
– Я знаю, что ты имеешь в виду, – добавила Кэтрин. – Это его вмешательство в каждую мелочь. Мы говорим о вмешательстве после семи вечера, когда на улице уже темнеет. Мы опаздываем на вечерний статус-митинг.
Это был «решающий момент», как называл это Дэн, имея в виду, что есть дедлайн, в который они не могут уложиться, но это означало, что аврал был всегда.
Кэтрин и Тимати вошли в кабинет Дэна и сели. Другие члены команды были уже там, и никто не выглядел счастливым. Дэн настроился на микроменеджмент.
– Итак, последние три проекта протекают в режиме «интенсивной терапии». Тим, Кэтрин, начнем с вас.
– Мы делаем успехи… – начала было Кэтрин.
Дэн прервал ее:
– У вас нет прогресса. Этот проект разваливается. Я дал вам достаточно времени для выбора собственного метода работы, а теперь мы должны действовать правильно.
Тимати возразил:
– Но там была ошибка, которую требовалось исправить.
– Вам всегда кажется, что есть ошибка. Просто вы, ребята, неспособны выполнить проект в срок. Мне придется погрузиться в процесс. Я подозреваю, что вы не понимаете всей его важности.
– Постойте! – воскликнула Кэтрин. – Ведь нет ничего удивительного в том, что в конце всегда возникают проблемы. В ходе работ накапливается много потерь.
– Что ты понимаешь под словом «потери»? – поинтересовался Дэн. – Это звучит негативно. Если мы хотим добиться успеха, то нужно оставаться позитивными. (Дэн всегда говорил о позитивном настрое, даже когда ругал своих сотрудников.)
– Ну, например, согласование любого изменения в пользовательском интерфейсе занимает недели. В середине обсуждения вы отдаете распоряжение приступить к разработке, и, похоже, мы тратим больше времени на изменение кода, чем на его написание.
– Правильно. И мы всегда удивляемся, когда команда тестировщиков находит ошибки. Почему-то это происходит постоянно, но мы никогда не находим времени, чтобы их исправить, – добавил Тимати.
Дэн начал злиться:
– Смотри, это такой стиль управления программными проектами. Перестань указывать пальцем на людей и обвинять их. Виноват я или команда тестировщиков.
– Слушай, Дэн! Хватит… – не сдержалась Кэтрин. Все удивленно взглянули на нее: она почти никогда не повышала голоса. – Мы никого не виним. Но есть проблемы, которые происходят снова и снова. Мы встречаемся два раза в день, и наши разговоры звучат как заезженная пластинка. Приходится бесконечно обсуждать одни и те же проблемы, которые почему-то всякий раз вызывают удивление.
Дэн немного опешил от такого напора. Он встал, посмотрел на Кэтрин, затем снова сел в свое кресло.
– Знаете, все это очень важно! Прямо сейчас найдем время и займемся этой проблемой. Это решающий момент.
Принципы Канбана
Давайте подробнее рассмотрим основополагающие принципы Канбана.
• Начните с того, что вы делаете сейчас, уважайте имеющиеся роли, обязанности и должностные инструкции.
• Договоритесь об эволюционном развитии.
• Поощряйте лидерство на всех уровнях.
Первый принцип – начните с того, что вы делаете сейчас, – отличается от всего того, о чем вы читали в этой книге.
Мы потратили много времени на сравнение гибких методологий с традиционными водопадными проектами. Например, Scrum дает полную систему для управления и реализации проектов. Если вы хотите внедрить Scrum, то нужно создавать новые роли (scrum-мастер и владелец продукта) и новые виды деятельности (планирование спринта, ежедневные scrum-митинги, доски задач). Это необходимо, поскольку система Scrum предназначена для управления проектами и поставки программного обеспечения.
Канбан не является системой управления проектами. Это метод улучшения процесса: шаги, которые команда принимает для создания и поставки ПО. Прежде чем вы сможете что-нибудь улучшить, нужна отправная точка, а для Канбана это как раз то, что вы делаете сегодня.
Привычное дело – думать о типичных проблемах.
Когда проектная команда делает то, что в итоге приведет к ошибкам и срыву сроков, это не похоже на ошибку. Позднее вы можете заняться анализом первопричин, ведь, столкнувшись с точно таким же выбором, команда, скорее всего, примет то же самое решение. Таковы люди.
Предположим, что команда всегда поставляет программное обеспечение клиентам только после многократных и непростых встреч с ними, во время которых пользователи таки и не могут найти обещанных функций. Конечно, не исключено, что эти разработчики невероятно рассеянны и всегда забывают об одной-двух функциях, которые обсуждали с клиентами. Но более вероятно, что их преследуют одни и те же проблемы в процессе выяснения требований пользователей.
Главная цель процесса улучшения состоит в поиске повторяющихся проблем, выяснении их общности и создании инструмента исправления.
Ключевая здесь вторая часть предложения: выявление того, что общего у этих проблем. Если вы предполагаете, что разработчик не может вспомнить все то, о чем просили пользователи, или они постоянно меняют свои требования, то вы придете к выводу, что эти проблемы невозможно решить. Но если предположить, что существует реальная и к тому же повторяющаяся причина, то есть шанс справиться с ситуацией.
Вот с чего начинается Канбан: взгляните на то, как вы работаете, и представьте свою текущую деятельность в виде совокупности заменяемых, повторяющихся действий. Канбан-команды называют правила, которым они всегда следуют, стратегией. По существу, это сводится к признанию привычек, тех шагов, которые делаются при создании программного обеспечения и их фиксации.
Иногда сложно записывать правила, которым следует команда, потому что легко попасть в ловушку, если судить о результатах проекта по команде в целом или отдельному ее участнику: если проект успешен, то все члены команды должны быть профессионалами, а если нет – то они явно некомпетентны. Это несправедливо, потому что предполагается, что в проекте все зависит от команды. Бережливое мышление помогает преодолеть это заблуждение, рассказывая, как увидеть картину в целом, что в данном случае означает увидеть большую систему целиком.
Стоит повторить, что каждая команда имеет производственную систему для создания программного обеспечения. Она бывает хаотичной и часто меняется. В основном она живет в головах членов команды, которые никогда не обсуждали, насколько она велика и что они придерживаются именно ее. Для тех, кто использует Scrum, система кодифицирована и понятна. Но многие команды следуют системе, существующей как некое «врожденное» знание: мы всегда начинаем проект беседой с представителями заказчика или составления графика, создания карт с пользовательскими историями либо сразу «погружаемся» в код после встречи с менеджером.
Именно с такой системой Канбан начинает работать. У команды уже есть способ запустить свой проект, а Канбан нужен, чтобы лучше понять систему. То есть начните с того, что вы делаете сейчас. Цель Канбана – сделать небольшие улучшения в этой системе. Вот что значит добиваться постепенных, эволюционных изменений. И именно поэтому Канбан имеет практики совместного улучшения и экспериментального развития. В бережливом мышлении необходимо видеть все целиком, чтобы понять, что требует измерений. А они составляют сердцевину эксперимента и научного подхода. Канбан-команда начнет с исследования того, как производится программное обеспечение, и получит объективное понимание ситуации. Затем она проведет определенные изменения как команда (в этой главе вы узнаете, как именно эти изменения работают) и проверит свои измерения на предмет соответствия желаемому эффекту.
Lean-ценность усиливает обучение и также является важной частью развивающейся системы, которую команда использует для сборки программного обеспечения. В этой книге вы узнали о петлях обратной связи. Когда вы сотрудничаете для измерения системы и экспериментального развития, петли обратной связи становятся очень важным инструментом сбора информации и подачи ее обратно в систему. Канбан-практика внедрения циклов обратной связи должна помочь вам увидеть тесную связь между Канбаном и Lean.
Ускоренное обучение – это также фактор канбан-принципа, который требует уважения текущих ролей и обязанностей участников. Предположим, что каждый проект начинается встречей руководителя проекта, бизнес-аналитика и программиста. Может быть, у них нет запротоколированных правил проведения таких бесед, но, скорее всего, эти правила легко понять, познакомившись с названиями должностей.
Канбан уважает текущие роли и обязанности, потому что все это важная часть системы.
Объединяет все эти принципы то, что Канбан работает только для тех команд, которые не жалеют времени, чтобы понять свою собственную систему сборки программного обеспечения.
Если бы существовал один правильный способ сборки ПО, то все бы просто использовали его. Но мы в главе 2 этой книги утверждали: серебряной пули нет – не существует набора «лучших» практик, гарантирующих сборку программы в каждом конкретном случае. Даже та команда, которая уже имеет опыт успешного применения практики в проекте, может с треском провалиться в следующем. Поэтому работа с Канбаном начинается с понимания настоящей системы запуска проекта: как только вы увидите систему целиком, Канбан предлагает соответствующую практику по ее улучшению.
Не подскажет[83]. Канбан предлагает начать с понимания того, как вы в настоящее время реализуете свои проекты. Это может быть Scrum, XP, «лучше-чем-ничего», эффективный водопадный процесс, неэффективный водопадный процесс или даже беспорядочный метод научного тыка или кодирования «с наскока». Как только вы выясните, каким образом ваша команда создает программное обеспечение, Канбан предложит практики для улучшения.
Если у вас уже есть процесс разработки программного обеспечения, то зачем вам Канбан?
Большинству команд удается что-нибудь поставлять. Вы знаете, сколько усилий тратит команда? Какой ценностью обладает результат их работы? Или он вызывает проблемы и затрудняет поставку ценного программного продукта?
Если есть система – неважно какая, – то большинству такие вопросы могут даже не приходить в голову. Даже если вы используете Scrum или XP, вы можете терять впустую много времени, не подозревая об этом. Привычные проблемы очень трудно обнаружить. Каждый может следовать правилам и делать все верно. Но так же как поведение формируется самой системой, потери складываются из совместной работы многих людей.
Такой пример приведен в главе 8: команда невольно увеличивает производственный цикл, даже если все активно трудятся и никто намеренно не затягивает работу. Но несмотря на это, заказчику кажется, что проект сильно задерживается. Хотя в команде даже не заметили этого, потому что делают все возможное, чтобы выполнить задачу как можно скорее.
Это и есть та проблема, которую решает Канбан.
Системное мышление воспринимает организацию как систему: анализирует то, как ее части взаимосвязаны и как организация работает в целом.
Том и Мэри Поппендик. Lean Software Development: An Agile Toolkit
Первый шаг к улучшению системы – признание того факта, что она существует. Идея видеть целое лежит в основе принципа Lean. Когда вы видите цельную картину, то перестаете думать о команде как об отдельном, разобщенном решении и начинаете воспринимать ее как единую систему. В Lean это называется системное мышление.
Каждая система принимает входные сигналы и превращает их в готовую продукцию. Как выглядят scrum-команды с точки зрения системного мышления? Вы можете думать, что Scrum – это система, которая берет задачи бэклога проекта на входе, а на выходе выпускает код. Многие scrum-команды имеют бэклог проекта, который состоит исключительно из историй. Такие команды считают себя «машинами», которые превращают истории в код.
Но очевидно, что они остаются командами, и мы предпочитаем рассматривать их участников как людей, а не роботов. Однако полезно думать о задаче, которую вы выполняете, как о части большой системы. Если применить системное мышление к scrum-команде, то становится ясно: выполняемая работа напрямую (или даже косвенно) способствует превращению историй в код. Признавая, что все в Scrum – система, вы поймете, как начать работать лучше и вносить усовершенствования. Такое мышление приводит к улучшениям, таким как дополнительные вопросы Джеффа Сазерленда для ежедневных scrum-митингов, о которых вы узнали в главе 5. Это хороший пример системного мышления, применяемого к Scrum, что приводит к эволюционному усовершенствованию.
Канбан призывает начать с понимания системы, которую использует ваша команда. И даже если вы не будете следовать какой-то определенной методологии, вы все равно сможете применять системное мышление в своей команде для выяснения способа работы.
Легко понять, что команда, исповедующая Scrum, использует систему. Но что если ваша команда не применяет подобные методы? Может быть, вы просто погружаетесь в работу над программным обеспечением? Выглядит все так, будто вы каждый раз запускаете проекты по-разному. Поэтому вы не имеете системы, правда?
Но самое забавное, что люди – особенно команды – всегда стремятся следовать правилам. Они могут быть не записаны, и мы нередко придумываем их, если они не существуют. Но правила существуют на интуитивном уровне, и если они засели в голове, то от них трудно избавиться. Даже когда вам кажется, что вы действуете спонтанно, появление нового человека в команде все расставит на свои места: вы очень быстро обнаружите, что он нарушает привычные для вас правила.
Lean предлагает инструмент, чтобы принять неписаные правила и превратить их в систему: систематизирование потока создания ценности.
Когда вы берете ММФ (минимальную маркетинговую функцию, о которой мы узнали в главе 8, – например, историю, требование или пользовательский запрос) и выявляете систематизированный поток ценности, ведущий к написанию кода, вы должны записать путь через вашу систему.
Если вы работаете в команде, которая придерживается неписаных правил, то вполне вероятно, что одна ММФ сильно отличается от другой. Но поскольку люди интуитивно следуют правилам, довольно вероятно, что вы можете наметить небольшое количество потоков создания ценности, охватывающих основные ММФ, которые ваша команда превращает в код. Если вам удастся сделать это, то вы сможете создать очень точное описание системы, которой следует ваша команда. Прежде всего система решает, какой поток создания ценности MMФ будет из нее вытекать.
Полезно иметь систему, которая работает одинаково для всех, даже если есть много различных путей для ММФ. Как только вы поймете, как работает система (то есть увидите целое), вы сможете принимать решения о том, какие пути расточительные, и заниматься постепенными изменениями подхода к разработке.
Одна из самых распространенных ошибок в начале изучения Канбана – это попытка использовать его как методологию для разработки программного обеспечения. Это неправильно. Канбан – это способ улучшения процессов. Он поможет вам понять методику, которую вы используете, и найти способы усовершенствовать ее.
Выделите немного времени и пролистайте книгу на несколько страниц вперед. Вы увидите рисунки, похожие на доски задач. Но на самом деле это канбан-доски. На них нет задач, зато есть рабочие элементы. Так называется самостоятельная единица работы, которую нужно отследить через всю систему. Как правило, она больше, чем ММФ, требования, пользовательские истории или подобный фрагмент общего пула работ.
Существует разница между доской задач и канбан-доской: в то время как задачи перемещаются по доске задач, рабочие элементы не являются задачами. Задачи – это то, что делают люди, чтобы переместить рабочие элементы в рамках системы, то есть это «винтики» механизма, который толкает рабочие элементы. Именно поэтому вы можете использовать системное мышление для понимания рабочего процесса при создании программного обеспечения, не унижая человеческое достоинство разработчиков мнением, будто они части некой машины. Задачи – это «винтики», а люди – уникальные личности с собственным характером, желаниями и мотивацией.
Столбцы на канбан-доске могут показаться похожими на этапы в потоке ценности. Однако многие канбан-эксперты разделяют понятия «систематизация потока ценности» и «канбан-доска». Они отражают на доске состояние рабочих элементов в рабочем процессе независимо от потока ценности и называют это картой жизненного цикла. Разница в том, что поток создания ценности – инструмент бережливого мышления, помогающий понять работу системы, а карта жизненного цикла – это то, как канбан-метод определяет конкретные этапы, которые проходит каждый рабочий элемент. (Дальше в этой главе вы узнаете, как построить канбан-доску.)
Вот пример того, как доска задач делает одно, а канбан-доска другое. Scrum помогает командам в самоорганизации и выполнении коллективных обязательств. К моменту начала использования доски задач команда уже выбрала элементы бэклога (рабочие элементы), которые включены в спринт, и разбила их на задачи. Так как текущие задачи перемещаются по доске задач, рабочие элементы начинают перемещаться из колонки «сделать» в колонку «сделано». Команда воспринимает это как прогресс.
Типичная канбан-доска показывает крупные рабочие элементы, а не отдельные задачи. И хотя на доске задач видны только рабочие элементы с разными статусами («сделать», «в процессе» или «сделано»), канбан-доска будет иметь широкую картину. Откуда берутся рабочие элементы? Как владелец продукта узнает, что рабочий элемент размещен в бэклоге проекта, и как расставляются приоритеты? После того как команда закрывает рабочий элемент, как она может отследить правильность его разворачивания? Рабочий элемент имеет большой жизненный цикл, выходящий за пределы создающей его команды. Канбан-доска будет иметь колонки для этапов, которые проходит рабочий элемент до того, как scrum-команда получит его, и после завершения работы над ним.
Более того, канбан-доска поможет показать проблемы, которые никогда не появляются на доске задач. Многие scrum-команды очень сильны в создании программного обеспечения, о котором их просят пользователи, но разочарованные клиенты все-таки остаются. Возможно, они создают рабочие элементы, не удовлетворяющие потребностям пользователей. Или между созданием рабочих элементов и процессом обзора результатов либо развертывания наблюдается слишком большой временной промежуток. Хотя эти проблемы вне контроля команды, часто обвиняют именно ее. Канбан-доска поможет решить этот вопрос.
Таким образом, хотя Канбан – это не система для управления проектами, он имеет очень важную связь со способом управления проектом, который применяет команда. Канбан направлен на улучшение и изменение процесса, используемого в проекте, и на то, как это может повлиять на управление им. Как правило, Канбан применяют для повышения предсказуемости потока, и это влияет на планирование и план проекта. Широкое использование Канбана и его показателей, скорее всего, окажет существенное воздействие на метод проектного управления[84].
Дальше вы узнаете о практиках Канбана и о том, как создавать и использовать канбан-доску, чтобы постепенно усовершенствовать систему в целом.
Совершенствование процесса с Канбаном
Мы уже знаем, что Канбан – это метод, который направлен на улучшение процесса, базируется на ценностях Lean и бережливого мышления. Он был разработан Дэвидом Андерсоном, который первым начал экспериментировать с идеями Lean во время работы в Microsoft и Corbis. Так же как Lean, название «канбан» связано с идеями разработки на автомобильных производствах в Японии. Но что делает Канбан гибким? Чем он отличается от традиционного процесса улучшения?
Читать бесплатно другие книги:
