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

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

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

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

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

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

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

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

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

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