Считается, что Канбан – это не система управления проектами, но, когда вы перемещаете рабочие элементы по канбан-доске, это похоже на управление. Вы уверены, что это не система управления проектами?
Да, это вовсе не система управления проектами и не методология создания программного обеспечения. Канбан – это метод улучшения процесса.
Прежде чем вы сможете улучшить процесс, вы должны понимать это. Канбан-доска – прекрасный инструмент, помогающий создавать ПО, потому что это очень эффективный способ визуализации рабочего процесса.
Это также очень эффективный способ исправлять серьезные ошибки, которые часто встречаются в процессе улучшения: команда не всегда начинает работу, действительно хорошо понимая, как сегодня нужно разрабатывать программное обеспечение. Процесс усовершенствования начинается с того, что группа менеджеров и руководитель проекта собираются вместе и создают схемы или описания текущего процесса. Обычно они понимают, что для процесса усовершенствования необходима точка отсчета, поэтому занимаются рассылкой опросов, интервьюируют команды разработчиков и ищут другие способы, чтобы собрать информацию. Затем они объединяют все полученные сведения в документированный процесс и используют его в качестве отправной точки для совершенствования.
Проблема в том, что сбор такой информации – очень сложное дело. Он редко дает реальное представление о том, как на самом деле команды собирают создавать ПО. Представьте, что вы член команды, которого комитет старших руководителей спросил, как работает ваш проект. Вы будете указывать на неудачи? Или постараетесь нарисовать радужную картину? Даже если вы стремитесь быть максимально правдивым, вам не избежать обычной слабости, свойственной любому человеку: хорошо помнить успехи и забывать о проблемах.
Вот где лучше всего работает Канбан. Вначале команда визуализирует рабочий процесс на канбан-доске. Но не останавливается на достигнутом – по мере развития проекта она обновляет рабочие элементы на доске. Все члены команды понимают, что делают это не для управления проектом, а чтобы создать точную картину системы, которую используют для производства программного обеспечения. Это действительно реальная картина, потому что команда постоянно обновляет ее. И это очень полезно: когда программисты хотят выяснить, над какой пользовательской историей или функцией работать дальше, они четко видят, как работа протекает через систему. Но канбан-доску не используют для того, чтобы выяснить, какие задания следует выполнять. На ней присутствует информация об уровне рабочих элементов, но не задач. Если система включает доску задач, диаграмму Ганта или какой-то другой способ управления проектом, то они по-прежнему будут его применять.
Из-за того, что Канбан имеет такой эффективный способ визуализации рабочего процесса (канбан-доска) и измерения потока через систему (при помощи CFD), команда способна достичь наиболее эффективного улучшения. Но это не единственная причина, по которой команды, использующие Канбан, добиваются успеха в процессе совершенствования. Канбан позволяет получить отличные результаты, когда команда внедряет бережливое мышление. Как мы видели в примере со Scrum и XP, самый эффективный способ помочь команде принять бережливое мышление – использовать канбан-практики. Как только команда начинает визуализировать рабочий процесс и измерять поток, она понимает, где происходят потери в системе, и использует варианты мышления, чтобы создавать для себя новые возможности и учиться видеть работу системы в целом.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с вашей командой).
• Если бы вам предложили создать канбан-доску сегодня, то какие столбцы вы бы в нее включили? Если вы еще не создавали карты потока ценности, то сейчас подходящий случай сделать это – они помогут выяснить, как может выглядеть канбан-доска.
• Можно ли рассматривать один из этих столбцов в качестве удачного кандидата для WIP-лимита? Создайте стикеры с рабочими элементами только для этого столбца. Сколько из них задействовано прямо сейчас? Что было бы, если бы вы ввели WIP-лимит?
• Выясните, к кому вы можете обратиться, чтобы ввести WIP-лимит.
• Создайте простую канбан-доску и еженедельно отслеживайте проект. Постройте CFD на основе ваших данных. Стабилен ли ваш список незавершенных дел? А как насчет скорости поступления?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о канбан-методе в книге Дэвида Андерсона «Канбан. Альтернативный путь в Agile» (М.: Манн, Иванов и Фербер, 2017).
• Узнайте больше о системах мышления в книге Мэри и Тома Поппендик Lean Software Development: An Agile Toolkit (Addison-Wesley 2003).
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Канбан начинается с бережливого мышления, поэтому первым делом помогите вашей команде освоить это понятие. Вам помогут подсказки для коучей в главе 8.
• Самый большой барьер для команд, стремящихся использовать Канбан как средство усовершенствования их процесса, – понимание того, что этот метод – не система управления проектами. В качестве коуча вы подскажете, что это означает для некоторых систем управления проектами и как Канбан помогает командам лучше понять собственную систему, а не управлять проектами.
• Помогите команде научиться видеть преждевременность некоторых ее поступков, что становятся причиной потерь в проекте. Научите людей определять параметры и принимать решения в последний ответственный момент. Некоторые нервные менеджеры или менеджеры с магическим мышлением часто требуют, чтобы команды определились со сроками. Помогите команде научиться выполнять только те обязательства, которые необходимы для проекта.
• Канбан также нуждается в командной работе, чтобы принять системное мышление. Это важная часть Lean и одна из основных идей, которая делает Канбан работающим методом. Помощь команде в визуализации рабочего процесса при помощи канбан-доски – это зачастую удачный первый шаг на пути психологического освобождения людей от роли винтиков в механизме, выполняющем работу.
Глава 10. Agile-коуч
Вы уже познакомились со Scrum, XP, Lean и Канбаном, знаете, что у них общего, и понимаете, какие задачи они решают. Если вы работаете над разработкой программного обеспечения, то обратили внимание по крайней мере на несколько вещей (практики, идеи, изменения в отношениях), которые могут помочь вашей команде.
А теперь идите и сделайте это. Подтолкните вашу команду к Agile прямо сейчас!
Это кажется почти невыполнимой задачей, не так ли? Есть разница между чтением о ценностях, принципах, мировоззрении и практиках и их внедрением.
Некоторые команды, прочитав книги о Scrum или ХР, берут эти практики на вооружение и сразу получают отличные результаты. Все предыдущие девять глав посвящены тому, чтобы вы поняли, почему это возможно: такие команды уже обладают мышлением, совместимым с ценностями и принципами Agile-манифеста и методологией. Они с легкостью внедряют Agile, потому что им не приходится менять мировоззрение. Если дела в вашей команде обстоят точно так же, то вы имеете гораздо больше шансов на успех.
Но что если образ ваших мыслей несовместим со Scrum, ХР или другими гибкими методологиями? А атмосфера, в которой вы работаете, не позволяет добиться успеха в применении agile-ценностей? Как быть, если вклад каждого отдельного участника ценится выше командной работы, а за ошибки полагается суровое наказание? Что если среда душит инновации или ваша команда не имеет доступа к клиентам и другим людям, имеющим возможность помочь вам понять, какое программное обеспечение вы производите? Все это – барьеры на пути внедрения Agile.
Вот когда нужен agile-коуч – человек, который помогает команде внедрять Agile. Благодаря ему каждый член команды узнает о новом отношении, мировоззрении и преодолевает психологические, эмоциональные и технические преграды, мешающие внедрению Agile. Коучи работают с каждым членом команды, чтобы те смогли понять не только «как» применять новую практику, но и «почему» ее нужно использовать. Они помогают команде преодолевать естественную неприязнь и даже страх перед изменением, что происходит с теми, кого просят попробовать что-то новое в работе.
В этой книге есть множество примеров, когда люди получали результаты «лучше-чем-ничего»: команда внедряет практики agile-методологий, но ее члены получают лишь незначительные улучшения, потому что по-настоящему не меняют свои взгляды или отношение к командной работе над созданием программного обеспечения. Другими словами, команда нуждается в agile-мировоззрении, чтобы получить хорошие результаты от методологии Agile. Agile-ценности и принципы, описанные в манифесте, помогают команде приобрести правильное мировоззрение, и по этой же причине каждая методология предлагает свои ценности и принципы. Команда получает наилучшие результаты от внедрения Agile, когда мышление каждого ее участника совместимо с ценностями и принципами гибкой разработки и конкретной методологией, которую они внедряют.
Цель agile-коуча – дать возможность команде получить более гибкое мировоззрение. Хороший коуч помогает выбрать методологию, наиболее подходящую для уже существующего менталитета, и знакомит команду с ценностями, принципами и практиками методологии так, чтобы она работала на этих людей. Вместе с коучем команда начнет внедрять практики, а затем использовать их, чтобы учиться и усваивать ценности и принципы, постепенно менять свое отношение и приобретать правильное мировоззрение, что поможет не ограничиваться получением результата «лучше-чем-ничего».