Kitobni o'qish: «Искусство Agile-разработки. Теория и практика гибкой разработки ПО», sahifa 5

Если вы не можете получить необходимые вам навыки разработчиков…

Скорее всего, вы не сможете достичь навыков в поставке, но практики поставки вам все же стоит изучать и использовать в работе.

Выберите Agile-коучей

Каждой команде нужен коуч, который поможет ей научиться быть эффективной Agile-командой. В подразделе «Навыки коучинга» главы 7 содержатся подробности. Краткое описание коуча представлено ниже.

• Каждой команде необходим тот, кто может помочь ей научиться быть эффективной и сплоченной.

• Командам фокусировки нужен тот, кто может научить практикам планирования, описанным в части II.

• Командам поставки нужен тот, кто может научить техническим практикам, изложенным в части III.

• Командам оптимизации нужен тот, кто сможет научить практикам развития бизнеса, описанным в части IV.

Некоторые коучи могут охватить сразу несколько категорий. Каждый коуч может работать с одной или двумя командами.

Если вы не можете нанять на работу нужных вам коучей…

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

Делегируйте полномочия и ответственность команде

Уважение к человеческим способностям лежит в центре философии Agile, и нигде это не очевидно настолько, как в подходе Agile к полномочиям и ответственности.

Секрет первоклассного выполнения работы заключается в правильном понимании деталей, а никто не понимает их лучше, чем непосредственные исполнители этой работы… Имея необходимую квалификацию и направляемые лидером, они будут принимать наилучшие технические решения и воплощать их лучше, чем кто-либо другой смог бы сделать за них [Poppendieck2003].

Мэри и Toм Поппендик

С точки зрения организационных инвестиций это означает следующее.

• Работа поручается командам, а не отдельным людям. Команды сами решают, как разбить весь объем работы на задачи и кто в команде будет их выполнять. Возможно, вам понадобится изменить процесс распределения задач и другие рабочие процессы в соответствии с этим подходом. Это приводит к определенным последствиям в системе оценки эффективности, о чем мы подробнее поговорим в разделе «Измените вредные кадровые политики» текущей главы.

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

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

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

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

Если работу нужно поручить отдельным людям…

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

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

Если корпоративные инструменты не поддерживают командную работу…

Если в вашей компании используется система распределения задач, которую невозможно заменить, то одним из вариантов краткосрочного решения проблемы может стать создание для каждой команды «фантомного» человека, чтобы он принимал командные задачи. Другой вариант – члены команды могут рассматривать получаемые индивидуальные задания как командные.

В долгосрочной перспективе лучше все же исправить корпоративную программу.

Если команды должны использовать корпоративный инструмент отслеживания…

Одна из главных причин эффективности Agile-команд – способность улучшать и упорядочивать свои рабочие процессы. Корпоративные системы отслеживания, включая так называемые инструменты управления жизненным циклом Agile (Agile Lifecycle Management), ограничивают возможности команд. Как и множество продуктов, борющихся за место в вагоне локомотива Agile, эти инструменты имеют тенденцию настолько упускать смысл самого подхода, что начинают снижать гибкость команд.

Принуждение Agile-команд к использованию корпоративных инструментов отслеживания в их повседневной деятельности снижает их производительность. Если у вас нет выбора в этом вопросе, то можно применять две отдельные системы отслеживания: одну для легковесного подхода Agile и основную корпоративную систему. Более подробная информация доступна в подразделе «Корпоративные системы отслеживания» главы 10.

Если у команды нет доступа к стейкхолдерам…

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

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

Если команда поставки не управляет своим процессом релиза…

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

Если команда оптимизации не управляет своими планами создания продукта и расходами…

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

Измените стиль управления командой

Когда команды сами определяют свои процессы, назначают себе задачи и координируют работу со стейкхолдерами, менеджеры командного уровня могут подумать, что им нет места в Agile. Но это далеко не так. Работа руководителя группы в Agile различается, но она не менее важна, чем в команде периода «до Agile». Больше информации об этом можно найти в разделе «Менеджмент» главы 10.

Поговорите с менеджерами об их новой роли и предложите им тренинг, если необходимо. Убедитесь, что их ожидания тоже соответственно изменились.

Если менеджеры не могут отпустить ситуацию…

Микроменеджмент раздражает, но в краткосрочной перспективе он не будет камнем преткновения. Однако он препятствует обучению, отбирая у команд возможность самостоятельно принимать решения. Микроменеджеры удлиняют сроки и повышают затраты, необходимые для достижения уровня свободного владения навыками¹².

Руководители часто занимаются микроменеджментом, когда не знают, чем еще им заниматься, или когда боятся, что им не найдется места в среде Agile. Заверьте их, что у них есть роль, показав, как она выглядит. Тренинг или хороший Agile-коуч могут в этом помочь.

Организуйте рабочие помещения

Команды Agile активно сотрудничают и постоянно общаются друг с другом. Чтобы это общение было эффективным, потребуется помещение, приспособленное под потребности команды. Оно может быть как физическим, так и виртуальным. В разделе «Командная комната» главы 7 содержится более подробная информация.

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

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

Так что это нормально – застраховать свои ставки на физическое рабочее пространство. Заложите на это средства в бюджете (в конце концов вам понадобится хорошее помещение для команды, если вы сработаетесь с Agile), но в краткосрочной перспективе вы можете реквизировать для каждой команды одну из больших комнат для собраний или часть открытого пространства офиса.

Что бы вы ни решили, начните работать над этим как можно раньше. Организация физического помещения занимает много времени.

Если команда удаленная…

Вы можете создать виртуальную командную комнату. В подразделе «Виртуальные командные помещения» главы 7 рассказывается, как это сделать.

Если вы не можете организовать физическое помещение для офисной команды…

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

Выберите команде подходящую для обучения задачу

У любой команды есть цель: ее место в общей стратегии организации. (См. раздел «Цель» главы 7.) Когда команда только начинает учиться Agile, важно выбрать цель, которая поможет в учебе. В практическом смысле это означает три вещи.

• Цель, имеющая ценность, но не срочная. Если команда будет сильно ограничена во времени, то ей будет трудно учиться. Члены команды по умолчанию вернутся к тому, что у них хорошо получалось в прошлом, чем будут тратить время на воплощение новых идей.

 Автономная цель. Чем сильнее команда зависит от других, тем с бо́льшими сложностями координации она, скорее всего, столкнется. Некоторых таких сложностей следует ожидать, но их переизбыток будет отвлекать команду от обучения.

• Совершенно новая кодовая база (green-field codebase). Команды, изучающие практики поставки, должны многому научиться, и это проще делать с нуля. В конце концов им придется научиться работать с существующим кодом. Команды, у которых есть опытный коуч в области поставки, могут игнорировать это требование, если тот согласится. Таким же образом могут поступить и те команды, которые изучают уровни, отличные от поставки.

Если есть важный дедлайн…

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

Если нет значимой работы с нуля…

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

Смените водопадные подходы в управлении

Руководство (Governance) – это процесс того, как работа согласовывается, отслеживается и управляется на высоком уровне. В большинстве организаций политики такого руководства предполагают водопадный подход в разработке. Часто это требует подготовки предварительной документации или четких переходов от фазы к фазе (phase gates). Все это означает предиктивный подход к планированию.

Для достижения лучших результатов нужно изменить политики руководства так, чтобы они стали соответствовать подходу Agile. Это значит удалить точки фазовых переходов и использовать адаптивный подход к планированию. Подробная информация доступна в подразделе «Agile-руководство» главы 10.

Если требуется водопадная модель управления…

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

Чаще всего руководство требует составления четких предварительных планов и бюджета. Простейший способ удовлетворить это требование – использовать сначала любой доступный вам подход, а затем, после того как вы пройдете через согласование проекта, начать Agile-часть процесса. В качестве альтернативы для команд, свободно владеющих навыками на уровне как фокусировки, так и поставки, вы можете заложить 4–8 недель на планирование, начать нормально работать и создать качественную дорожную карту (Roadmap). (См. раздел «Дорожные карты» главы 10.)

Как добиться успеха, используя водопадную модель

Agile подходит далеко не для каждой компании. И это нормально! Можно добиться успеха, используя водопадную модель. Если вы в компании, которой нужны предварительные планы или культура которой – «командуй и контролируй», то водопадная модель может быть более уместной.

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

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

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

Водопадный стиль управления несовместим со свободным владением навыками на уровне оптимизации, который основан на адаптивном планировании. Если от вас требуется соответствие водопадным политикам управления, ограничьтесь уровнями фокусировки и поставки.

Измените вредные HR-политики

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

Похожий случай – руководители, которые ценят только материальный результат. В Agile-команде есть много способов внести свой вклад в успех. Примером может служить человек, который непосредственно не пишет код, но проводит много времени, воспроизводя баги, или человек, который работает «за сценой» над улучшением коммуникации.

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

Такие особенности корпоративной культуры часто отражены в HR-политиках (Human Resources, HR) в части продвижения и поощрения. Если карьера людей зависит от внешней причины, независимо от их реального влияния на производительность команды, то у ваших команд, вероятно, будут трудности в совместной работе по Agile.

Вам не удастся изменить культуру вашей организации за одну ночь, но вы можете начать работать над изменением HR-политик, а руководители могут изменить способ своего обращения с командами. Это занимает много времени, так что начните как можно раньше. Вам наверняка понадобится поддержка высшего руководства.

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

Если HR-политики не подлежат изменению…

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

Если у вас много команд, то ограничьте пилотный Agile командами, имеющими опытных руководителей. Используйте их опыт, чтобы запустить необходимые вам изменения политик.

Решите проблемы, связанные с безопасностью

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

Проблема в том, что работающие очно команды, которые используют такие практики, как парное программирование и групповое програмирование (моб-программирование) (см. соответствующие разделы главы 12), работают вместе за одним компьютером. Это может беспокоить с точки зрения безопасности, поскольку человек, который вошел в систему, не всегда тот же, кто сейчас сидит за клавиатурой. Фактически человек, который авторизовался в системе, может ненадолго отойти, чтобы поговорить с кем-то или посетить уборную. Набирая код, люди часто меняются (буквально каждые несколько минут), поэтому выходить из системы каждый раз, когда вводить код должен другой человек, и затем снова входить нереально.

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

С этим связана проблема возможности отслеживания. Некоторые компании требуют, чтобы каждое внесенное изменение (commit) можно было отследить до его автора. Это требование можно выполнить, добавив инициалы или адрес электронной почты в коммит-комментарий команды. У Git есть соглашение о том, чтобы добавлять строку Co-authored-by в конце каждого коммит-сообщения¹³.

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