Постигая Agile Грин Дженнифер
Поначалу участникам ярмарки это казалось излишеством: зачем отдавать деньги одному человеку, брать у него чек, а затем передавать его кому-то другому? Но теперь все вынуждены согласиться с необходимостью этого дополнительного этапа: чек – это канбан-карточка, и поставщик кукурузы гриль создает WIP-лимит и вытягивающую систему.
Люди, готовящие кукурузу во втором окне, знают, сколько чеков выбито, и будут отправлять в первое окно только нужное количество чеков, поэтому очередь ожидающих небольшая. Это позволяет регулировать количество готовящейся кукурузы. Поэтому в периоды замедления спроса они не держат кукурузу на гриле так долго, что она превращается в уголь, а в пиковые моменты увеличивают объемы, чтобы свести очередь к минимуму. Это также означает, что они могут нанять дополнительных людей для трудоемких действий и жарить кукурузу, не отвлекаясь на денежные расчеты. В тех редких случаях, когда количество людей, желающих купить кукурузу, превышает возможности людей внутри киоска, образуется очередь в первом окне. Те, кто готовит кукурузу, защищены от хаоса, связанного с покупателями, пытающимися всучить им деньги. Они могут полностью сконцентрироваться на процессе жарки, что позволяет очереди двигаться быстрее или не появляться вовсе.
Благодаря тому, что их работа течет плавно, процесс приготовления может стать ритмичным и позволяет сотрудникам чувствовать себя более комфортно и хорошо выполнять свою работу.
Регулирование WIP-лимита предоставляет поставщику кукурузы гриль свободу действий. Увеличение чеков приводит к росту количества жарящейся кукурузы в периоды с пиковой нагрузкой (например, после окончания больших шоу на ближайших трибунах). Они могут быстро и плавно нарастить производство, а затем так же плавно его уменьшить после спада спроса. Знают ли продавцы кукурузы, что они применяют закон Литтла? Ограничивая число прибывающих в систему людей, они могут уменьшить время обработки заказа, чтобы клиенты, заплатившие за кукурузу, не ожидали ее. (Вы можете представить, как выглядит кумулятивная диаграмма потока?)
Этот пример помогает проиллюстрировать разницу между выталкивающими и вытягивающими системами. Производители жареных оливок используют выталкивающую систему – длинную очередь. Люди «проталкивают» ее, потому что она привлекает покупателей и создает спрос. Поставщики оливок не имеют контроля над спросом, они могут продавать оливки только следующему человеку из очереди. Продавцы кукурузы гриль «втягивают» очередь, потому что выдают чеки заплатившему клиенту. Они используют их для притягивания людей к своему стенду и могут ограничить количество покупателей, если оно достигает лимита. Так они устанавливают WIP-лимит, позволяющий им уравновешивать производственные возможности и спрос. Регулирование WIP-лимита дает возможность мгновенно приспосабливаться к меняющейся ситуации.
У меня нет обилия деталей для сборки автомобиля или кукурузы, которую нужно обжарить на гриле. Я создаю программное обеспечение, поэтому постоянно решаю различные проблемы. Какое отношение ко мне имеют эти примеры?
Канбан имеет к вам самое прямое отношение, потому что это система, позволяющая мгновенно реагировать на изменения в проекте. Вводя лимит на выполнение незавершенных работ и контролируя размер очереди, вы уменьшаете вариабельность. Выделяя источники задержек и применяя такие методы, как кластеризация блокеров (или анализ коренных причин блокировок и усовершенствования, направленные на снижение вероятности и влияния блокеров), мы сокращаем вариабельность. Атака на ее источники, негативно влияющие на экономический результат системы, является одной из основных техник Канбана[88].
Командам разработчиков нужно этим заниматься – и много. Можно утверждать, что разработчики гораздо чаще имеют дело с изменчивостью, чем производители автомобилей или поставщики кукурузы. Программное обеспечение отличается от любого другого инжинирингового продукта тем, что оно изменчиво. Так как ПО не является физическим объектом, программисты имеют гораздо больше возможностей, чем другие инженеры, изменять его и на более поздних этапах проекта. Но каждое изменение несет риск. И если ваш проект бросало из стороны в сторону вследствие изменившихся требований, то появляются неравномерности (мура), потому что эти изменения могут стать очень разрушительными.
Так что же вы можете сделать, чтобы убедиться, что эти неравномерности не сорвут проект?
Большинство водопадных команд мыслят традиционно, считая, что работа выполняется через процесс управления изменениями. Изменения контролируются, замедляются, и, если возможно, их избегают. Изменения в плане должны быть предложены, рассмотрены командой, проанализированы с точки зрения их влияния на проект, а затем согласованы со всеми сторонами, прежде чем они будут реализованы. Это эффективный способ защиты проекта от изменчивости, уменьшающий его риски, – но при этом он гарантирует, что ваша команда создает именно запланированное изначально независимо от того, на самом ли деле это ценно для пользователей.
Мир традиционного управления проектами выглядит не таким мрачным, как это может показаться. В главе 6 и главе 7 мы видели, что команда имеет больше возможностей для разработки легко изменяемого программного обеспечения, если ей предоставить спокойную обстановку, в которой удается работать разумное количество часов, и такую эмоциональную атмосферу, чтобы было проще сосредоточиться на решении проблем. Хорошие руководители проектов признают это. Поэтому они будут добавлять временной запас в график работы, так же как в ХР-командах. А управление процессами изменений означает, что они не имеют ХР-возможности добавлять задачи с низким приоритетом, которые команда может сместить на более поздние итерации, потому что это потребует изменения плана, а значит, его рассмотрения и утверждения. Вместо этого они будут добавлять буферы, или дополнительные задачи, не имеющие реальной значимости, просто заполняющие график, часто используя формулы для определения того, сколько еще можно втиснуть таких «пустых» задач. Теперь они могут следовать первоначальному плану и дать команде достаточно времени для работы – и в то же время избавляются от дополнительной изменчивости, поэтому проект завершается вовремя.
Другими словами, когда команда испытывает трудности с традиционным проектным управлением, в ответ она обычно добавляет в график работ «пустые» задачи – независимо от того, что является причиной проблемы.
Канбан-команды не создают буферы и «пустые» задачи в графике, потому что это скрывает изменчивость от тех, кто старается создавать правильные решения. Ценности бережливого мышления в том, что они позволяют видеть картину целиком и препятствуют сокрытию информации. Кроме того, бережливое мышление говорит нам, что, когда есть потери, вызванные неравномерностью, мы должны найти причину проблемы и устранить ее. Вместо того чтобы скрывать потери за «пустыми» элементами, канбан-команды показывают их, визуализируя рабочий процесс, вводя WIP-лимиты и другие стратегии, чтобы их исправить. Они делают изменчивость и ее основные причины явными.
Что делать, если мой руководитель не согласен с введением лимитов на выполнение незавершенных работ?
Тогда вы будете иметь проблемы с внедрением Канбана. Когда вы читаете о том, как действует Канбан, кажется, что создание очередей и ограничение потока поможет существенно улучшить работу команды. Но все начинается с введения WIP-лимитов, которые нужны, чтобы ваше руководство согласилось не добавлять дополнительную работу, когда команда достигает WIP-лимита.
Это может стать ахиллесовой пятой при попытке совершенствования, особенно когда руководитель убежден, что мышление приравнивается к действию. Допустим, вы потратили несколько недель или даже месяцев, помогая команде разобраться с Канбаном, работая вместе над визуализацией рабочего процесса, создавая канбан-доску и проводя тщательные измерения для определения WIP-лимита. Теперь вы вместе с другими менеджерами с гордостью приносите свое предложение. Ваш руководитель понимает, что это заслуживает внимания. Он говорит: «Мне нравится канбан-доска, я думаю, что эти измерения замечательны, и полностью вас поддерживаю. Но мне нужно сделать всего одно небольшое изменение. Стереть этот номер в верхней части столбца на доске».
Ему кажется, что это абсолютно несущественно – стереть один маленький номер. Но WIP-лимит – это ноу-хау Канбана. Без него команда не имеет возможности ограничить поток и Канбан не работает.
На интуитивном уровне не всегда понятно, что сокращение работы всего на один шаг позволяет ускорить весь проект. И даже если вы визуализируете рабочий процесс, проводите измерения и выявляете потери, вызванные неравномерной работой, перегрузками и необоснованной или невозможной работой, это может оказаться недостаточно убедительным для руководителя. Когда это не так, он будет ориентироваться на WIP-лимит и видеть в нем компромисс. Может быть, он чувствует, что, удалив его, команда сможет оптимизировать свою работу и предотвратить неполную занятость. Или он считает, что WIP-лимит дает команде временной запас, и боится, что она будет злоупотреблять им, замедляя темпы работы и устраивая себе отпуск. Либо эта идея просто кажется ему неудачной. А возможно, он чересчур рационален и совершенно лишен магического мышления, поэтому считает так: поставка по готовности приведет к тому, что функция будет переходить из одного релиза в другой и пользователи, увидев это, одуреют и начнут настаивать на увольнении разработчиков и выгонять людей. Но независимо от того, что он думает, удаление WIP-лимита выбивает опору из-под всех действий в стиле Канбана.
Так что же делать, если вы не можете получить согласия руководителей на введение WIP-лимита?
Это отличная возможность, чтобы попробовать Scrum, в котором есть предсказуемые временные ограничения и заранее оговоренный объем, а также руководство со стороны специально выделенного для этого владельца продукта.
Причина, по которой Scrum эффективен, когда менеджеры сталкиваются с ограничениями, в том, что бэклог находится внутри проекта. Scrum-команды полагаются на владельца продукта, имеющего полномочия принимать решения, какие рабочие задачи следует добавлять в бэклог и включать в каждый спринт, и вводят его в состав команды. Теперь команда контролирует объем, а руководители и пользователи могут работать с владельцем продукта, чтобы вносить любые изменения, в том числе и в объем работы. Это дает гораздо больше гибкости, чем традиционный процесс управления изменениями, но все равно ограничивает изменчивость, которой подвержена компания. Команда даже использует доску для визуализации рабочего процесса – но это доска задач, а не канбан-доска, потому что содержит задачи, а не рабочие элементы и в ней нет WIP-лимитов или других явных стратегий.
В то же время Канбан имеет очереди и буфера – внешние объекты по отношению к проекту.
Соглашаясь с WIP-лимитом, клиенты (руководители, пользователи, владельцы продукта и т. д.) решают, что помещать в очередь. Они должны согласовывать WIP-лимиты и не защищаться от изменчивости, но взамен получают гораздо больше контроля над тем, какие функции создаются и в каком порядке. Используя производственные термины, мы называем это поставкой «точно в срок», потому что команда сама решает, какая задача выполняется следующей, основываясь на рабочих элементах, ожидающих на различных этапах рабочего процесса (стикеры в столбцах на канбан-доске), и эти решения могут приниматься очень поздно – даже за минуту до начала работы над рабочим элементом.
Если попытка освоить Канбан заканчивается внедрением Scrum – это очень хороший результат. Как только команда заработает последовательно внутри стабильной системы, вы поможете ей узнать, что такое процесс усовершенствования. Обнаружив, что команда получает результат «лучше-чем-ничего», считайте это шагом в правильном направлении. Теперь вы можете продолжать двигаться вперед. Использование Канбана улучшает работу команды, создающей программное обеспечение, и является прекрасным способом для прогресса.
Считается, что Канбан – это не система управления проектами, но, когда вы перемещаете рабочие элементы по канбан-доске, это похоже на управление. Вы уверены, что это не система управления проектами?
Да, это вовсе не система управления проектами и не методология создания программного обеспечения. Канбан – это метод улучшения процесса.
Прежде чем вы сможете улучшить процесс, вы должны понимать это. Канбан-доска – прекрасный инструмент, помогающий создавать ПО, потому что это очень эффективный способ визуализации рабочего процесса.
Это также очень эффективный способ исправлять серьезные ошибки, которые часто встречаются в процессе улучшения: команда не всегда начинает работу, действительно хорошо понимая, как сегодня нужно разрабатывать программное обеспечение. Процесс усовершенствования начинается с того, что группа менеджеров и руководитель проекта собираются вместе и создают схемы или описания текущего процесса. Обычно они понимают, что для процесса усовершенствования необходима точка отсчета, поэтому занимаются рассылкой опросов, интервьюируют команды разработчиков и ищут другие способы, чтобы собрать информацию. Затем они объединяют все полученные сведения в документированный процесс и используют его в качестве отправной точки для совершенствования.
Проблема в том, что сбор такой информации – очень сложное дело. Он редко дает реальное представление о том, как на самом деле команды собирают создавать ПО. Представьте, что вы член команды, которого комитет старших руководителей спросил, как работает ваш проект. Вы будете указывать на неудачи? Или постараетесь нарисовать радужную картину? Даже если вы стремитесь быть максимально правдивым, вам не избежать обычной слабости, свойственной любому человеку: хорошо помнить успехи и забывать о проблемах.
Вот где лучше всего работает Канбан. Вначале команда визуализирует рабочий процесс на канбан-доске. Но не останавливается на достигнутом – по мере развития проекта она обновляет рабочие элементы на доске. Все члены команды понимают, что делают это не для управления проектом, а чтобы создать точную картину системы, которую используют для производства программного обеспечения. Это действительно реальная картина, потому что команда постоянно обновляет ее. И это очень полезно: когда программисты хотят выяснить, над какой пользовательской историей или функцией работать дальше, они четко видят, как работа протекает через систему. Но канбан-доску не используют для того, чтобы выяснить, какие задания следует выполнять. На ней присутствует информация об уровне рабочих элементов, но не задач. Если система включает доску задач, диаграмму Ганта или какой-то другой способ управления проектом, то они по-прежнему будут его применять.
Из-за того, что Канбан имеет такой эффективный способ визуализации рабочего процесса (канбан-доска) и измерения потока через систему (при помощи 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-коуча – дать возможность команде получить более гибкое мировоззрение. Хороший коуч помогает выбрать методологию, наиболее подходящую для уже существующего менталитета, и знакомит команду с ценностями, принципами и практиками методологии так, чтобы она работала на этих людей. Вместе с коучем команда начнет внедрять практики, а затем использовать их, чтобы учиться и усваивать ценности и принципы, постепенно менять свое отношение и приобретать правильное мировоззрение, что поможет не ограничиваться получением результата «лучше-чем-ничего».
В этой главе вы узнаете об agile-коучинге: как команды учатся, а agile-коучи помогают им изменить мировоззрение, чтобы было легче внедрить методологию Agile, и как коуч может сделать вашу команду более гибкой.
Описание: команда, работающая над созданием приложения для камеры мобильного телефона в организации, купленной большой и многопрофильной интернет-компаниейКэтрин – первый разработчик
Тимати – второй разработчик
Дэн – их руководитель
Акт III. И вот еще что (опять?!)…
– Кэти, у тебя есть минутка? У меня отличные новости.
Кэтрин поморщилась, услышав, что Дэн зовет ее в свой кабинет. Она подумала: «Я никогда не привыкну к этому». Но все-таки зашла, села в кресло и приготовилась слышать «отличные новости».
– Вы проделали замечательную работу, используя гибкие методологии. Просто фантастическую.
Кэтрин припомнила все те восемь месяцев, которые они с Тимати потратили, чтобы при помощи Канбана улучшить процесс работы.
Она выявила несколько узких мест в процессе (одно особенно серьезное), заключавшихся в том, что Дэн и другие менеджеры практически наугад спускали вниз задания на разработку новых функций.
После того как она установила очередь на выполнение работ, произошла удивительная вещь: менеджеры начали соперничать за место в очереди и постепенно перестали требовать от нее и Тима выполнения непосильного объема заданий.
Впервые за месяц Дэн вызвал ее, чтобы поделиться действительно «отличной новостью».
Раньше это словосочетание обычно означало, что в последний момент он решил внести изменения, которые пускали под откос весь проект.
– Я рада слышать, что ты счастлив, Дэн, – с усмешкой сказала Кэтрин.
Дэн продолжал:
– В головной компании тоже заметили наше продвижение. Они уже читали про Agile и теперь, когда у нас есть кое-какие успехи, хотят, чтобы мы научили этому другие команды.
– Подожди. Так ты просишь, чтобы я… стала их коучем? – воскликнула Кэтрин.
– Точно, – сказал Дэн.
– Я понятия не имею, как это делается, – ответила Кэтрин.
Дэн посмотрел ей в глаза.
– Это не обсуждается, Кэти. Встряхнись – и за дело.
Коучи понимают, почему люди не всегда хотят меняться
Большинство людей в вашей компании стараются хорошо выполнять свою работу. Они хотят, чтобы их коллеги и руководители видели, что они хорошо выполняют возложенные на них задачи. Когда кто-то достигает определенного уровня комфорта в работе и знает ее досконально, последнее, чего бы он или она хотели, – это чтобы кто-то пришел и заставил их работать по-другому.
Эндрю Стеллман и Дженнифер Грин. Applied Software Project Management
Большую часть своего времени agile-коучи тратят на то, чтобы помочь людям изменить способ их работы. Это непростая задача, потому что только коуч видит всю картину целиком. Люди, которых просят работать по новым правилам, могут не понимать, зачем им это.
Существует много способов такого внедрения практики, когда команда, имеющая самые благие намерения, умудряется сделать так, что практика не работает. Например, в главе 5 описано, что команды часто превращают ежедневный scrum-митинг в статус-митинг. Важная задача scrum-митинга – замена командно-административной формы управления на самоорганизующуюся. Три вопроса, которые каждый задает в ходе встречи, позволяют команде самостоятельно контролировать план проекта. Но многие команды, пытающиеся внедрить Scrum, в итоге используют его как простое ежедневное совещание, где члены команды озвучивают состояние своей работы. Scrum-мастер фактически выступает на нем в роли руководителя проекта и распределяет задания между сотрудниками.
Точно так же некоторые команды добавляют пользовательские истории в документированные бизнес-требования, но рассматривают их как обычные спецификации, характерные для каскадной модели разработки.
Эти команды по-прежнему создают громоздкие спецификации до начала разработки продукта (BRUF, big requirements up front development) и просто добавляют к ним пользовательские истории. А вместо того, чтобы использовать разработку через тестирование, некоторые при попытке внедрить ХР просто хотят убедиться, что их код полностью покрыт тестами, которые они разрабатывают после сборки кода, что означает, что тесты никаким образом не влияют на архитектуру, потому что она полностью завершена к моменту, когда пишутся тесты.
Во всех этих случаях люди искренне пытаются внедрять Agile. Но они не понимают, как эти практики вписываются в более широкую систему методологии. Поэтому вместо того, чтобы попытаться изменить способ работы, они сосредоточиваются на той части практики, которая кажется им знакомой. Так стоит ли ожидать каких-то отличий? Команда, знакомая только с командно-административным способом управления, не имеет опыта самоорганизации, в ней не сформирована среда, стимулирующая глубже изучать суть Scrum.
Так давайте воздадим должное командам, когда это необходимо. Большинство команд внедряют Agile уже в ходе разработки программного обеспечения и добиваются некоторого успеха. (Совершенно недееспособные команды редко имеют менеджера, мировоззрение которого позволило бы им первым делом попробовать Agile.) Поэтому они ищут возможность вносить незначительные изменения, потому что не хотят ломать то, что реально работает.
Это ведет к одному из основных препятствий для внедрения Agile – убеждению каждого члена команды наподобие «я знаком с Agile, внедрил практики, которые мне понятны и близки, моя команда работает лучше, чем раньше, и мне этого достаточно». Такой результат называется «лучше-чем-ничего», и именно это заставляет многих людей отказаться от целостного внедрения Agile, сведя роль методологии к конкретным, несущественным улучшениям и, в итоге, к разочарованию после первоначальной эйфории.
Почему члены команды так часто настаивают на принятии только таких практик, которые кажутся им знакомыми, и отвергают любые другие, не известные им на данный момент?
Потому что каждая новая практика – это изменение, и всегда есть риск ошибиться. А в подобных случаях людей нередко увольняют.
Это то, о чем каждый agile-коуч должен постоянно помнить. Задача коучинга – помочь командам измениться, а это, в свою очередь, может стать причиной нестандартного (но вполне разумного) эмоционального отклика людей, которых принуждают меняться. Почему? Потому что они держатся за свои рабочие места, чтобы жить и кормить семью.
Вспомните: когда нас просят выполнить незнакомые задачи, мы ощущаем эмоциональный стресс, если не уверены, что сможем легко овладеть новыми навыками. Глубоко в нашем подсознании сидит охотник-собиратель, который рассуждает так: «Вчера я не сомневался, что выполню свою работу и принесу домой еду для всей семьи, но сегодня я в этом уже не уверен». Это важная причина, объясняющая беспокойство сотрудников, когда от них ждут изучения чего-то нового, и их, казалось бы, иррациональную реакцию на изменения (которая на самом деле вполне ожидаема).
Другая причина, почему люди отвергают перемены и тяготеют к тому, в чем хорошо разбираются, заключается в том, что они чувствуют недостаток времени, не позволяющий им спокойно обдумать все приводимые доводы. Например, обычно команды внедряют Agile после опробования ее на пилотном проекте. Часто это начинается с чтения книги об Agile. После этого человек пытается внедрить какую-либо методологию в команде, одновременно занимаясь дедлайнами, ошибками, конфликтами, изменениями требований и прочими проблемами, которые присущи любому проекту. Все это не самая идеальная атмосфера для внедрения совершенно нового способа думать о работе. Люди будут стараться изо всех сил, но если столкнутся с чем-нибудь непонятным, скрывающимся за общей вывеской Agile, названиями методологий и практик, то фактически в их работе мало что изменится. Контрольные точки в плане проекта теперь будут называться «спринты», или кто-нибудь решит использовать доску задач, которая не повлияет на выполнение работы. В конце концов команда вернется к прежнему стилю работы, потому что она так привыкла и к тому же существуют дедлайны.
Когда команда использует названия известных agile-практик, но не меняет при этом способа работы, нетрудно понять, почему люди разочаровываются в новых идеях. Они приходят к выводу, что Agile – это просто другое название того, чем они давно занимаются. Думая, что внедрили Agile, они не изменили способа работы и продолжают получать прежние результаты.
Такая команда решит, что Agile не работает, даже не понимая, что в действительности и близко не подошла к настоящей методологии. Подобная реакция – следствие того, что людей просят изменить способ работы, но они не понимают зачем. И рядом нет никого, кто помог бы им пройти через эти изменения без ущерба для целостности новых практик и идей.
Именно поэтому командам необходимы agile-коучи. Их важнейшая задача – определить момент, когда люди сталкиваются с чем-то новым, и помочь им принять эти изменения. Коуч должен объяснить каждому члену команды суть изменения, чтобы тот понимал «зачем» (а не только «что» конкретно нужно). Это поможет команде изменить способ работы, а не просто взять название какой-нибудь гибкой методологии и присвоить его привычной практике.
Хороший коуч старается максимально понятно объяснить, как ежедневные scrum-митинги помогают самоорганизоваться, а разработка через тестирование – мыслить функционально и двигаться в сторону инкрементального проектирования. Как пользовательские истории дают возможность каждому члену команды понять позицию людей, применяющих программное обеспечение. Коуч помогает выйти за рамки простого принятия новых правил, и люди начинают видеть правильное направление движения и то, что оно способно им дать.
Если вы обучаете много команд, то слышите одинаковые мнения от разных людей. Приведем несколько высказываний членов команды, которые могут свидетельствовать об их дискомфорте в связи с изменением, а также о том, что можно предпринять в такой ситуации. На все это полезно взглянуть с точки зрения коуча, даже если вы им не являетесь.
«Мы и так успешно разрабатываем программное обеспечение. Почему ты призываешь меня делать что-то по-другому?»
Трудно спорить с успехом. Если вы работаете с командой, которая имеет свою историю разработки ПО для клиентов, то у нее есть право знать, почему нужно меняться. Недостаточно просто сказать, что это решение руководства, – такое заявление ослабит моральный дух. Как коуч вы должны позитивно относиться к работе, которую проделала команда. Но не нужно стесняться указывать на недостатки. Практики в каждой методологии Agile направлены на решение проблем команды. Если вы сможете помочь понять, почему эти проблемы возникают, и предложить команде решения, то шансы, что они будут одобрены, возрастают.
«Это слишком рискованно».
Это очень распространенная реакция на Agile, особенно среди тех, кто привык к командно-административному стилю управления проектом. Где все эти буферы, реестр рисков, лишняя бюрократия, которая тормозит проект и дает возможность в случае чего спасти свою шкуру? План проекта может быть непрозрачным, что порой удобно для команды: им не нужно делиться деталями, кроме как при завершении отдельных этапов; они могут вставлять буферы в промежутках, чтобы уменьшить и даже ликвидировать неопределенность. При использовании отчетов о статусе в качестве основного показателя прогресса разработки вам удается контролировать информацию, которая поступает к пользователям и клиентам. Команды, работающие по таким принципам, чувствуют в Agile угрозу. В главе 3 упомянут agile-принцип, в котором говорится, что работающее программное обеспечение – основной показатель прогресса проекта. Если в agile-команде что-то идет не так, то все об этом знают. Задача agile-коуча – помочь менеджерам, пользователям и клиентам освоиться с этими неприкрашенными критериями достигнутого прогресса и предоставить команде безопасную среду, в которой она получит возможность ошибиться, чтобы впоследствии иметь возможность учиться на собственном опыте. Но если пока это нереально, то ваша задача подсказать всем, а особенно руководителю, какую поставить перед собой цель и как изменить климат и настрой команды в будущем.
«Парное программирование (разработка через тестирование или другие практики) не подходят мне».
Программист, привыкший работать в одиночку, может интуитивно чувствовать, что парное программирование будет тормозить его работу. Особенно понятна такая позиция, когда человек работает в атмосфере, не принимающей ошибок. Вполне объяснимо, что он чувствует себя неуютно в присутствии другого человека, наблюдающего за тем, как он пишет код. И каждому, кто когда-либо обучал юного новичка водить автомобиль, знакомо неприятное чувство, которое испытывает старший член команды, передавая клавиатуру неопытному сотруднику при работе в паре. Существует много причин, по которым люди чувствуют себя некомфортно при использовании этих практик, особенно когда мировоззрение команды им не соответствует. Хороший agile-коуч сначала поможет команде выбрать практики, совместимые с ее мышлением. И в процессе их применения члены команды увидят преимущества и поймут, как и почему эти практики работают. Под руководством коуча все начинают активнее воспринимать гибкое мышление.
«Agile не подходит для нашего бизнеса».
Часто люди говорят так, потому что привыкли создавать подробные планы или описания проектов, прежде чем начать реальную работу. Они не могут представить процесс иным. Руководители проектов и те, кто привык к командно-административному стилю мышления, чувствуют себя комфортнее, имея оформленные в виде бумажных документов описания задач, требования и план проекта до начала любых работ. Точно так же архитекторы и разработчики успокаиваются, когда весь дизайн системы отражен на бумаге до того, как написана первая строка кода. И вдруг их просят доверить команде принятие решений – вплоть до последнего ответственного момента, а это означает потерю контроля. Поэтому они будут повторять: «У нас очень сложный бизнес. Люди в других компаниях, может быть, и в состоянии с ходу включиться в проект, но из-за нашей специфики необходимо планировать и проектировать все заранее». Действительно, любой бизнес сложный и каждый проект требует анализа и планирования. Agile-коуч поможет менеджерам, представителям бизнес-подразделений и руководителям разработки понять, что команды намного лучше справляются с этими сложностями, если позволить им разделить проект на более мелкие части. И у них должна быть возможность принимать решения в последний ответственный момент.
«Именно это мы и делаем, только называется по-другому».
Это одна из наиболее распространенных причин, по которым люди отвергают методологии Agile. Они будут искать способы продолжать работать в привычном стиле, используя при этом новые названия гибких практик, о которых читали или слышали. В таком случае Agile станет выглядеть обыденной – и даже неправильной, – если они решат присвоить это имя своей неудавшейся практике.
Попробуйте ввести в строку поиска «Agile – ерунда» (Agile sucks), и обнаружите высказывания людей, которые сделали именно это. Они называют Agile «очковтирательством», считая, что это просто практики каскадной модели, но под новыми названиями. Agile даже будут называть способом «запутать» принципы разработки программного обеспечения, диктуемые здравым смыслом.
Как коуч вы должны признать, что это делается не по злому умыслу. Это естественная реакция человека, который никогда не видел, что такое настоящая Agile (но думает, что видел). Задача коуча – помочь команде понять, что Agile действительно отличается от всего того, что они до сих пор делали, а вовсе не «ерунда».
Коучи понимают, как люди учатся
Хорошая модель освоения чего-либо (если освоение в принципе возможно) пришла из боевых искусств. Ученик боевых искусств проходит через три этапа мастерства, которые называются «сю», «ха» и «ри». «Сю» означает «следуй правилу». «Ха» – «ломай правила». «Ри» – «будь правилом».
Лисса Адкинс. Coaching Agile Teams: A Companion for ScrumMasters
Кент Бек, автор книги Extreme Programming Explained, описывал применение экстремального программирования (ХР), используя аналогичные уровни. Когда его спросили об ХР и пяти уровнях «модели зрелости возможностей», разработанных Институтом программной инженерии, он ответил, что ХР имеет три уровня зрелости:
1. Делайте все, как написано.
2. После того как работа выполнена, экспериментируйте с вариациями в правилах.
3. В итоге не беспокойтесь о том, соответствуете вы ХР или нет.
Алистер Кокберн. «Быстрая разработка программного обеспечения».
Вернемся к главе 2, в которой мы узнали, как по-разному люди воспринимают Agile. Так же как слепой, встретивший слона, каждый человек по-своему ответит на вопрос «что такое Agile?».
Разработчик, знающий о таких ХР-практиках программирования, как разработка через тестирование и инкрементальный дизайн, решит, что Agile – это о разработке ПО, его проектировании и архитектуре. Менеджер проекта, прочитав о scrum-спринтах, планировании, бэклоге и ретроспективах, подумает, что Agile – это об улучшении практик управления проектами.
Чтобы объяснить суть Scrum, ХР, Lean и Канбана, потребовались сотни страниц. Мы говорили о мировоззрении, ценностях, принципах и практиках. И показали вам, как использовать их все вместе, чтобы помочь команде поставлять большую ценность для клиентов. Мы объяснили, что вы можете сделать сегодня, чтобы помочь команде. Мы предложили инструменты (например, неоднократное повторение вопроса «считаете ли вы это нормальным?»), чтобы помочь вашей команде изменить мировоззрение и для изучения Agile, понимания Scrum, XP, Lean и Канбана.
Это не тот способ, которым большинство людей внедряют Agile.
Как было бы хорошо, если бы все разработчики мира купили и прочли нашу книгу. Но, к сожалению, большинство людей изучают Agile не при помощи книг. Они учатся на практике. И проще всего выполнять задачу, если она разбита на небольшие части.
Другими словами, когда люди пытаются освоить Agile, они хотят получить список простых правил, который поможет им быстрее и качественнее создавать программное обеспечение.
Если вы новичок в agile-коучинге, то это может вызвать у вас разочарование. Представьте, что вы пытаетесь научить команду внедрять Scrum. Из главы 5 вам известно, что если кто-то не понимает принципа самоорганизации и коллективной ответственности, то у него не получится Scrum. Поэтому вы тратите время, объясняя такие scrum-ценности, как мужество, приверженность, уважение, сосредоточенность и открытость, и то, как работает самоорганизация. Но команда разочарована, потому что это очень абстрактные понятия. Люди хотят поговорить о доске задач и пользовательских историях. Вы стремитесь научить их Scrum, а они, по всей видимости, полны решимости удовлетвориться результатом «лучше-чем-ничего». И ничего с этим не поделаешь. Так что же происходит?
Есть старая поговорка об учениках: встречайте их там, где они находятся, а не там, где бы вы хотели, чтобы они вас ждали. Хороший agile-коуч понимает, как происходит процесс обучения, и предлагает людям информацию, поддержку и примеры, помогающие подняться на следующую ступень знаний. Коучи знают, что люди не меняются в одночасье.
В уже упоминавшейся книге «Быстрая разработка программного обеспечения» Алистер Кокберн рассказывает об основной идее обучения, которая называется «сюхари». Это очень ценный инструмент коуча, старающегося понять, где команда находится в текущий момент. «Сюхари» взята из боевых искусств, но это хороший способ подумать о том, как вообще происходит процесс обучения.
В «сюхари» различают три этапа обучения. Первый этап, «сю» (, «повиновение» или «наблюдение»), описывает мышление человека, впервые сталкивающегося с новой идеей или методикой. Ученик хочет получить простые правила, которым может следовать. Именно поэтому люди чаще всего держатся за практики: команда может создать правило внедрения спринтов, заниматься парным программированием, использовать доску задач и т. д. И каждый может сказать, соблюдается или нет правило, о котором идет речь.
Правила особенно важны для взрослых, потому что, в отличие от детей, они не привыкли постоянно познавать новое. Предлагая тому, кто изучает новую систему – например, Agile, – простые правила, вы даете возможность начать их применять. Несложные практики, являющиеся частью таких методологий, как Agile, Scrum, XP и Канбан, хорошо подходят тем, кто находится на этапе «сю», потому что благодаря своей простоте дают возможность людям сосредоточиться на оттачивании мастерства. Установив для команды правило (например, «ежедневно в 10:30 проходит scrum-митинг, где каждый отвечает на три вопроса»), вы можете направить ее по верному пути для изучения принципа («мы используем принцип самоорганизации для постоянного анализа и коррекции плана»).
Цель коуча – не в навязывании слепой веры в чудо Agile. Фанатик Agile – это тот, кто решил, что каждая команда имеет только один способ применения этой методологии. И он назойливо навязывает его всем и каждому. Адепты Agile, как правило, сосредоточиваются только на тех правилах, которые поняли, и останавливаются на уровне «сю». Они считают, что все проблемы можно решить при помощи усвоенного и проповедуемого ими правила. Из agile-фанатиков не получается хороших коучей, потому что они не тратят время на попытки понять, где находятся люди, которых они обучают.
Чтобы привести нас к этапу «сюхари» – «ха», agile-коуч должен подняться выше понимания простых правил (, «обособление» или «перелом»). Это этап, где люди уже овладели правилами и могут усваивать принципы, которые управляют ими. На протяжении всей книги мы повторяли, насколько эффективно для изменения мировоззрения команды внедрение практик и как через них (и многочисленные командные обсуждения) приходит понимание ценностей и принципов методологии. Когда команда достигает уровня «ха», она начинает двигаться от результата «лучше-чем-ничего» к реальному приросту производительности. А он возможен, когда все разработчики действительно приняли мировоззрение Agile.
Мы еще ничего не сказали об этапе «ри» (, «освобождение от правил»). Когда вы достигаете этого уровня обучения, вы в совершенстве владеете идеями, ценностями и принципами и меньше заботитесь о методологии, потому что продвинулись гораздо дальше. Если появляется проблема, которую можно решить при помощи определенной практики, то команда просто выполняет ее. Вас действительно не волнует, Scrum ли это, XP, Канбан или каскадная модель. Потому что ваш процесс не нуждается в имени. Но это не тот хаос, который характерен для команд, где никогда не пытались использовать Agile. Команда, в которой каждый достиг этапа «ри», – это отлаженная, хорошо функционирующая производственная единица, где каждый делает то, что ему положено.
Кокберн отмечает, насколько «удручающим дзеном» это может прозвучать. В книге «Быстрая разработка программного обеспечения» он рассказывает, как люди в стадии обучения «ри» говорят то, что трудно понять ученикам, находящимся на этапе «сю»:
«Делайте все, что работает».
«Когда вы действительно делаете это, вы не отдаете себе отчет, что вы это делаете».
«Используйте методологию до тех пор, пока она приносит хороший результат».
Для того, кто находится на уровне освобождения от правил, это полностью верно. А тех, кто еще только пытается разобраться, это сбивает с толку. Тем же, кто ищет порядка, это не принесет пользы.
Хороший коуч первым делом выясняет у каждого члена команды, каков текущий этап обучения. Если люди находятся на уровне «ри», то с ними легко работать, потому что каждый член команды знает, как учиться, и готов адаптироваться к новым практикам.
И наоборот, на уровне «сю» все хотят иметь однозначные правила. Вы используете стикеры или карточки на доске задач? Как коучу вам известно, что на самом деле это не имеет значения. Но тот, кто никогда не использовал доску задач, понятия не имеет, важно это или нет. Поэтому ваша цель – дать ему правило. Позже с вашей помощью он поймет, почему вы выбрали стикеры, и узнает, что карточки также подойдут. Просто они немного разные – например, на карточке можно писать с обеих сторон, а на стикере только с одной. И вы будете использовать сходства и различия, чтобы члены команды разобрались, как стикеры и карточки реализуют одни и те же принципы.
Вновь обратимся к ситуации, когда разочарованный коуч старается «внедрить» Scrum. «Сюхари» поможет понять, почему команда разочаровывается, пытаясь осознать ценности, и почему хочет говорить только о наиболее значимых практиках: досках задач и пользовательских историях. Доску задач или пользоательскую историю нетрудно представить в качестве этапа «сю» данной концепции: простое правило, которое можно начать применять прямо сегодня. Scrum полон подобных правил («встречайтесь каждый день и отвечайте на три вопроса»). В этом причина, что команды успешно внедряют scrum-практики.
Такие ценности, как открытость и приверженность, – это уже идеи уровня «ха»: абстрактные понятия, управляющие тем, как вы используете правила в системе. Самоорганизация и коллективные обязательства возможны только тогда, когда каждый член команды действительно понял и усвоил эти ценности. «Сюхари» помогает понять, почему команда должна пройти через применение практик, прежде чем сможет отказаться от них и осознать, что на самом деле понимается под открытостью и приверженностью.
Именно поэтому внедрение практик Scrum – очень эффективный первый шаг в оказании помощи команде, пытающейся постичь ценности этой методологии. Хороший коуч терпелив и во время каждого спринта ждет подходящего момента, чтобы рассказать команде о ценностях. Часто такая возможность возникает тогда, когда два человека имеют разные точки зрения на аспекты «слона» Scrum.
Предположим, разработчик обнаруживает в середине спринта, что функциональность не будет закончена. На ближайшем scrum-митинге он просит владельца продукта перенести ее разработку на следующий спринт. Владелец продукта рассержена. Она боится гнева клиента или менеджера по этому поводу и требует, чтобы разработчик «сделал все возможное» для реализации функционала – даже за счет «срезания углов» и отсутствия законченного кода. На эту проблему есть ответ на уровне «сю»: правила Scrum диктуют, что команда должна демонстрировать только полностью готовый программный продукт, а незаконченная версия передвигается в следующий спринт. Agile-коуч знает правила Scrum и может использовать их для разрешения конфликта.
Кроме того, agile-коуч также видит, что есть возможность для обучения уровню «ха». Признав существование раздробленного видения (об этом мы говорили в главе 2), которое может стать целостным, коуч поможет владельцу продукта взглянуть на проблему с точки зрения разработчика: некачественное выполнение работы увеличит технический долг, а это приведет к сложностям в поддержании всей кодовой базы. Технический долг, в свою очередь, станет причиной удлинения спринтов. Таким образом, хотя владелец продукта и может быстрее поставить функционал клиенту, игнорируя правила Scrum, в итоге команда окажется в худшем положении, потому что дальнейшая разработка будет протекать более медленно. Это важный урок, который поможет владельцу продукта узнать больше о такой scrum-ценности, как сосредоточенность, и о том, как команда, сфокусировавшая свое внимание на завершении работы, быстрее получит более качественный продукт.
Коуч также может помочь разработчику понять, насколько важна эта функциональность и как она обеспечивает ценность для клиентов. Кроме того, команда узнает, как в дальнейшем лучшее понимание ценности поможет ей установить более тесный контакт с владельцем продукта, чтобы найти способ разбить функционал на мелкие части и поставлять клиентам больше ценности максимально быстро. Этот важный урок даст возможность разработчику подробнее узнать о такой scrum-ценности, как обязательство, а также о том, как команда становится эффективнее, если понимает, что действительно важно для клиентов.
Это пример того, как коуч с глубоким пониманием методологии выполняет важную роль в команде. Он помогает ей понять и принять методы и правила методологии. И через них может помочь каждому члену команды усвоить ценности Agile. А используя эти ценности, он поможет каждому человеку и команде в целом развить в себе гибкое мировоззрение.
Коучи понимают, что делает методологию работающей
Конфликты и проблемы возникают в проектах ежедневно. Хороший scrum-мастер, например, посвящает большую часть своего времени их разрешению. Но далеко не все эти проблемы можно использовать в качестве обучающих примеров при изучении Scrum.
В частности, как коуч смог в конкретной конфликтной ситуации, о которой мы рассказали выше, увидеть возможность объяснить команде о таких scrum-ценностях, как сосредоточенность и обязательство? Относились ли эти ценности к данной конкретной проблеме?
Все дело в том, что коуч понимает не только как scrum-команды используют итерации, но и зачем они это делают. Он знает, что ограниченные по времени итерации могут быть полностью неэффективными, если команде разрешается поставлять не выполненную до конца работу. При таком развитии событий итерации превращаются в простые этапы проекта: объем каждой из них становится все более изменчивым, и команда уже не обязана поставлять работающее программное обеспечение в конце каждой итерации.
Это противоречит нескольким важным ценностям и принципам, благодаря которым Agile работает. Например, коуч знает, что работающее программное обеспечение – это основной показатель прогресса, а поставка неготового функционала в конце спринта дает клиентам ложное представление о достигнутом прогрессе. Коучу также известно: agile-команды ценят сотрудничество с пользователями, но это вовсе не означает, что клиент всегда прав. Иными словами, если команда видит реальную проблему с планом, она готова взаимодействовать с заказчиком, чтобы вместе придумать решение, обеспечивающее наибольшую ценность. Коуч понимает: если клиент и владелец продукта могут оказывать давление на разработчиков, чтобы включить не до конца собранное ПО в обзор спринта, то реальный прогресс команды будет преувеличен и сотрудничество с пользователями превратится в переговоры по контракту между командой и заказчиком.
Все это известно коучу, потому что он понимает ценности и принципы Agile и Scrum и знает, как они управляют практиками, а также то, из-за чего эти методологии могут стать формальными. Scrum-коуч хорошо знаком с понятиями «коллективная ответственность» и «самоорганизация». ХР-коуч отлично понимает, что такое приветствие изменений и инкрементальная архитектура. Канбан-коуч знает, как улучшить командные процессы при помощи введения WIP-лимитов, и использует их для контроля рабочего потока – и когда кто-то пытается нарушить выставленные лимиты и включить в список как можно больше задач, то вся методология разваливается.
В своей книге Coaching Agile Teams Лисса Адкинс советует коучам, как правильно подходить к проблемам, связанным с командой. Об этом мы уже упоминали в главе 5, но стоит повторить.
Позвольте команде неудачу. Конечно, это не значит хладнокровно наблюдать, как команда приближается к краю пропасти. Но используйте десятки возможностей, которые возникают в каждом спринте, чтобы позволить команде провалить одно из заданий. Команды, попадавшие в трудные ситуации и выходившие из них благодаря в том числе сплоченности, становятся крепче и работают быстрее по сравнению с теми, кого оберегали от неудач. Такая команда может удивить вас. То, что должно было причинить ей вред, сделало ее сильнее. Наблюдайте и ждите.
Это превосходный совет для любого agile-коуча, особенно того, кто склонен к командно-административному стилю управления или считает необходимым контролировать каждый аспект обучения и прогресса команды. Хороший коуч понимает: есть моменты, когда команда может и должна потерпеть неудачу, потому что это самый действенный и эффективный путь к успеху.
Это тот случай, когда ретроспективы приобретают чрезвычайную ценность. Мы узнали о том, как scrum– и XP-команды используют ретроспективы, чтобы в ходе проекта провести ретроспективный анализ и найти пути для улучшения. Для agile-коуча это отличная возможность помочь команде извлечь урок из провала, именно для этого его и позволяют. Если команда ошибается, потому что недостаточно точно применяет практику, то коуч поможет понять, какие из текущих навыков требуют улучшения. Но иногда сбой происходит из-за устаревшего образа мыслей. Зная принципы работы методологий и практик, agile-коуч использует провал, чтобы помочь команде узнать больше о конкретной ценности или принципе. Благодаря этому она примет правильное решение и избежит неудачи. Благодаря этому команды прогрессируют.
Но хороший тренер отлично знает, когда провал недопустим. Как и любая сложная конструкция, каждая методология имеет свои «несущие балки», которые нельзя трогать, чтобы не нарушить целостность проекта. Коучу нужен уровень «ха» понимания методологии: он глубоко изучил ее как систему и знает, почему она работает.
В главе 8 мы прочли о руководителе, который непреднамеренно «подрезает крылья» всем канбан-усилиям, когда просит команду убрать WIP-лимит. Кто-то с уровнем понимания «сю» может позволить изменить WIP-лимит, полагая, что сможет получить пользу, оставив хотя бы часть Канбана. Хороший канбан-коуч осознает, что некоторые вещи (например, конкретные столбцы на канбан-доске) могут быть изменены, но WIP-лимит должен оставаться без изменений, потому что это стержень, на котором держится методология Канбан.
Одна из наиболее трудных задач коуча – понять, какую именно информацию необходимо объяснить команде, какую – руководителю, а какую – клиентам. Разъяснения правил методологии на уровне «сю» достаточно, чтобы работа была выполнена, но мало, если нужно помочь команде получить правильное мышление и достичь результата «лучше-чем-ничего».
Иногда команде хватает элементарного набора правил, а порой она чувствует, что просто подменяет случайный набор правил каскадной модели столь же случайным набором agile-правил. Уровень «ха» помогает увидеть, почему следование этим правилам позволит создавать лучшее программное обеспечение. Но это также может звучать как «удручающий дзен», как выразился Кокберн. Agile-коуч нужен, чтобы помочь команде двигаться вперед на уровень понимания «ха» в таком темпе, при котором можно справляться с работой без чрезмерно абстрактных объяснений, которые ей не помогают.
Принципы коучинга
Основная идея, которую мы продвигаем на протяжении всей книги, – это понимание того факта, что для внедрения Agile необходимо правильное мировоззрение и команда получает его через ценности и принципы.
Вот почему каждая методология Agile имеет свой набор ценностей. И команда приближается к ее реальному потенциалу только тогда, когда усваивает их.
Поэтому неудивительно, что коучинг имеет свой собственный набор ценностей. Джон Вуден, тренер мужской баскетбольной команды Калифорнийского университета в 1960–1970-х годах, считался одним из величайших тренеров в истории спорта. В своей книге «Современный баскетбол»[89] он выделяет пять основных принципов коучинга: трудолюбие, энтузиазм, состояние, основные принципы и развитие командного духа. В agile-коучинге эти принципы значат так же много, как и в баскетболе.
Трудолюбие
Изменение стиля разработки программного обеспечения командой означает интенсивную работу над тем, чем она никогда раньше не занималась. Разработчики должны думать о планировании и тестировании, а не просто писать код. Владельцы продукта должны понимать, что делает команда, а не закидывать ее новыми функциональными требованиями. Scrum-мастера должны научиться передавать управление команде, оставаясь по-прежнему в проекте. Все эти навыки новые для команды и требуют работы над ними.
Энтузиазм
Когда вы полностью принадлежите работе и открывающиеся новые возможности вас вдохновляют, все остальное не имеет значения. У вас действительно множество причин быть в восторге: вы решаете проблемы, которые в прошлом вызывали головную боль. Когда каждый с энтузиазмом воспринимает Agile, вы получаете нечто большее, чем отличное ПО, – у вас формируется команда, любой участник которой более склонен к инновациям, счастлив и воодушевлен совместной работой.
Состояние
Agile работает тогда, когда каждый член команды хорош на своем месте. Известно, что каждый человек гордится своим мастерством. Если люди стараются разработать более качественное программное обеспечение, трудятся, чтобы добиться в этом успеха, то тогда они испытывают гордость за свое дело и максимально мотивированы. Вот почему члены agile-команды продолжают усердно работать над совершенствованием своих навыков, чтобы привнести в проект только самое лучшее.
Основные принципы
Вуден пишет: «Самая лучшая система не может преодолеть некачественного исполнения основных принципов. Коуч должен быть уверен, что никогда не позволит себе увлечься сложной системой». И это особенно актуально для agile-коучей. Agile работает, потому что ценности этой методологии просты и понятны и она содержит несложные практики. Это основы Agile, и хороший коуч стремится, чтобы команда сосредоточилась на них, и помогает ей поддерживать простоту в работе.
Развитие командного духа
Мы уже говорили о самоорганизации, целостности команды, энергичной работе и расширении прав и возможностей команды – это способы, при помощи которых agile-команды помогают развитию друг друга и совместно создают среду сотрудничества и инноваций. Одновременно с этим agile-коуч должен вести наблюдение за теми членами команды, которые в первую очередь ориентированы на собственную производительность, карьеру, результат или получают повышение по службе, и помочь им изменить свое отношение к приоритетам. Вуден точно знает, что делать в таких случаях: «Коуч должен использовать каждую частицу психологии в управлении и все доступные методы, чтобы развить командный дух. При любой возможности следует поощрять коллективную работу и бескорыстие, и каждый [член команды] должен быть готов, а не просто желать пожертвовать личной славой ради благополучия команды. Эгоизм, зависть, самовлюбленность и критика друг друга могут разрушить командный дух и потенциал любой команды. Коуч должен знать это и быть постоянно начеку, чтобы не дать проблеме развиться».
Эти пять принципов – прочный фундамент мировоззрения agile-коуча. Чтобы стать хорошим коучем, необходимо усвоить и применять их точно так же, как вы используете ценности Аgile-манифеста и другие гибкие методологии.
Ключевые моментыAgile-коуч – это тот, кто помогает команде внедрить Agile, а каждому отдельному ее члену – освоить новое мышление.
Эффективные agile-коучи помогают командам преодолеть сложности, связанные с внедрением новой практики, сосредоточив внимание на той ее части, которая им близка.
Коучи распознают предупреждающие сигналы о том, что команда испытывает дискомфорт в связи с изменениями.
Изучая новые системы или осваивая новые принципы мышления, люди проходят через три этапа, которые называются «сюхари».
Тот, кто впервые сталкивается с этой идеей, находится на этапе «сю», когда изучает правила и зачастую лучше реагирует на конкретные указания.
На этапе «ха» обучающиеся начинают принимать во внимание более крупные системы и адаптировать свое мировоззрение, чтобы соответствовать им.
На стадии «ри» люди владеют идеями системы уверенно и свободно – например, они знают, когда можно не следовать правилам.
Эффективный agile-коуч знает, почему система работает и зачем нужны правила.
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше об agile-коучинге в книге Лиссы Адкинс Coaching Agile Teams (Addison-Wesley 2010).
• Узнайте больше о концепции «сюхари» и о том, как люди учатся и адаптируются к новым системам, в книге Алистера Кокберна «Быстрая разработка программного обеспечения» (М.: Лори, 2013).
• Можно узнать больше об основах коучинга в книге Джона Вудена «Современный баскетбол» (М.: Физкультура и спорт, 1987).
• Вы можете узнать больше о том, почему команды сопротивляются переменам и как помочь им преодолеть это сопротивление, в книге Эндрю Стеллмана и Дженнифер Грин Applied Software Project Management (O’Reilly, 2005).
Об авторах
Эндрю Стеллман – разработчик, архитектор, лектор, agile-коуч, руководитель проектов, эксперт в разработке лучшего программного обеспечения. Имеет более чем двадцатилетний опыт профессионального создания программного обеспечения, в его активе – проектирование крупномасштабных серверных систем в режиме реального времени, руководство большими международными командами разработчиков, работа вице-президентом крупного инвестиционного банка, а также консультирование компаний, школ и корпораций, включая Microsoft, National Bureau of Economic Research, Bank of America, Notre Dame и MIT. За это время ему посчастливилось поработать с рядом замечательных программистов и узнать от них много нового.
Дженнифер Грин – agile-коуч, менеджер по развитию, бизнес-аналитик, менеджер проекта, тестировщик, лектор, имеет большой авторитет в области практик и принципов программной инженерии. Уже более двадцати лет занимается разработкой программного обеспечения в различных областях, включая СМИ, финансы и ИТ-консалтинг. Работала с замечательными командами разработчиков и тестировщиков над решением сложных технических вопросов и целенаправленно занималась поиском и преодолением возникающих на этом пути традиционных проблем с организацией процессов.
Несколько слов об обложке
Животное на обложке книги «Постигая Agile» – это гёльдиевая мармозетка, или гёльдиевая обезьянка (Callimico goeldii).
Это единственный вид рода Callimico, таких приматов также называют «каллимико». Иногда их классифицируют отдельно от мармозеток из-за таких характеристик, как третий ряд коренных зубов, вынашивание одного детеныша и наличия когтей вместо ногтей.
Названа в честь швейцарского натуралиста Эмиля Августа Гёльди, который открыл этот вид в начале XX века.
Эти обезьянки обитают в верхнем бассейне Амазонки, Бразилии, Колумбии, Перу, Боливии и Эквадоре. Как правило, они живут в лесу с подлеском или в низкорослых зарослях рядом с лесом, расположенных вблизи ручьев, и в бамбуковых зарослях. Предпочитают питаться насекомыми, грибами (в сухой сезон) и фруктами (в сезон дождей). Живут небольшими стаями по шесть особей и поддерживают связь друг с другом, издавая пронзительные крики. Перемещаются сквозь заросли по стволам деревьев, но большую часть времени спят в гуще листвы.
Их тело всего около 20–23 сантиметров в длину, это немного больше белки, но хвост может достигать 30 сантиметров. Мордочка темного цвета, шерсть черная или темно-коричневая, часто с более светлыми бликами. Самки достигают половой зрелости в 8,5 месяца, а самцы в 16,5. Численность самок превосходит численность самцов, самки могут рожать два раза в год. Примерно через три недели после рождения главными воспитателями детенышей становятся самцы.
Продолжительность жизни гёльдиевых обезьянок – около 20 лет, даже в неволе. Природоохранный статус – «уязвимые», однако в меньшей степени, чем мармозетки в целом. Деятельность человека и другие изменения среды обитания угрожают их существованию. Их трудно поймать и сложно наблюдать за ними в дикой природе.
Многие животные, изображенные на обложках книг издательства O’Reilly, находятся под угрозой исчезновения. Все они важны для сохранения окружающего нас мира. Чтобы узнать больше о том, как вы можете им помочь, зайдите на сайт www.animals.oreilly.com.
Эту книгу хорошо дополняют:
Scrum. Революционный метод управления проектами
Джефф Сазерленд
Роман Пихлер
Дэвид Андерсон
Читать бесплатно другие книги:
