Искусство Agile-разработки. Теория и практика гибкой разработки ПО

Для команд, работающих в режиме личного общения, организация физического помещения может стать вашей самой дорогостоящей инвестицией. Вдобавок она является и наиболее ценной. Как обсуждается в разделе «Командная комната» главы 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 в конце каждого коммит-сообщения[13].

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

Если требования безопасности не допускают гибкости…

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

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

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

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

Руководство по устранению неполадок

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

Члены команды не пытаются применять новые практики

Команда не заинтересовалась Agile (см. «Заинтересуйте команду» главы 5); или

В команде нет коуча, который может научить ее практикам (см. раздел «Выберите Agile-коучей» текущей главы); или

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

Внутри команды слишком много конфликтов

Команды слишком часто переформируются (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Менеджеру команды приходится постоянно помогать улаживать конфликты (см. раздел «Измените стиль управления командой» текущей главы); или

Политики отдела кадров поощряют конкуренцию (см. раздел «Измените вредные кадровые политики» текущей главы).

Члены команды не сотрудничают друг с другом

Команда не заинтересовалась Agile (см. раздел «Заинтересуйте команду» главы 5); или

Члены команды не имеют возможности посвятить все свое время команде или не ладят друг с другом (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее сотрудничеству (см. раздел «Выберите Agile-коучей» текущей главы); или

Распределение или отслеживание задач требует индивидуальной работы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

Рабочее пространство не подходит команде (см. раздел «Организуйте рабочие помещения» текущей главы); или

Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Менеджер команды раздает индивидуальные задания (см. раздел «Измените стиль управления командой» текущей главы); или

HR-политики поощряют индивидуальную работу (см. раздел «Измените вредные кадровые политики» текущей главы).

Команда тратит слишком много времени на предварительную оценку, планирование и отслеживание работ

Команда вынуждена использовать корпоративную систему отслеживания задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

От команды требуют составления предварительных планов и детальных прогнозов (см. раздел «Смените водопадные подходы в управлении» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне фокусировки (см. часть II).

Программное обеспечение, созданное командой, не делает то, что нужно стейкхолдерам

У команды нет доступа к нужному представителю бизнеса, или ей нужны люди с большим опытом в сфере деятельности заказчика и пользователей (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее работе со стейкхолдерами (см. раздел «Выберите Agile-коучей» текущей главы); или

У команды нет доступа к стейкхолдерам (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

Команде тяжело привлекать внимание стейкхолдеров

Стейкхолдеры не поддержали инициативу с Agile (см. раздел «Заручитесь поддержкой стейкхолдеров» главы 5); или

У команды отсутствуют необходимые навыки в сфере деятельности заказчика (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

Стейкхолдеры не считают работу команды актуальной или значимой (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).

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

У команды нет доступа к нужному представителю бизнеса или опыта в бизнесе (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

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

Команде нужно развивать свободное владение навыками на уровне оптимизации (см. часть IV); или

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

Программное обеспечение, разрабатываемое командой, имеет очень долгие циклы выпуска версий, много багов или эксплуатационные проблемы

В команде нет людей, уверенно владеющих навыками на уровне поставки (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или

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

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

Разработка идет медленнее, чем ожидалось

Команда завершает предыдущие задачи, которые были до Agile, или все еще учится (см. раздел «Найдите время на обучение» текущей главы); или

Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей» текущей главы); или

Рабочее пространство не подходит командам (см. раздел «Организуйте рабочие помещения» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или

Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или

Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

Глава 5. Инвестируйте в изменения

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

Осознание изменений

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

Понять, как люди реагируют на изменения, можно с помощью модели изменений Вирджинии Сатир (рис. 5.1)[14]. Согласно рисунку, существует пять ступеней перемен. Они применимы к Agile следующим образом.

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

2. Сопротивление. Люди, желающие перемен, начинают получать поддержку, и какие-то изменения в направлении Agile становятся возможными. Это называется внешним элементом изменения. Люди начинают по-разному реагировать на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет необходимости, что вряд ли его внедрение будет успешным или что это пустая трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем больше сопротивления вы встречаете.

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

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

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

Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)

Такие реакции на изменения неизбежны. Попытки ускорить процесс только ухудшают ситуацию. Вот почему организациям следует отвести время на обучение (см. раздел «Найдите время на обучение» главы 4). Обратите внимание на параллели между моделью Сатир, представленной на рис. 5.1, и J-кривой, показанной на рис. 4.1 (см. выше).

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

Вы можете снизить (но не полностью устранить!) хаос, применив технику, которой я научился у Дианы Ларсен: поддержка, информация и структура (Support, Information, Structure – SIS)[15].