Разнообразие правил

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

Хорошо ли, когда люди следуют собственным правилам?

Да. Скорее нет. Может быть. Все зависит от ситуации…

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

В то же время часто нет никакой необходимости синхронизировать методы работы с исходным кодом. Как члена команды меня не беспокоит, что у людей свои правила откладывания и фиксации кода или свои правила комментирования – при условии, что код, внесенный в ствол, полностью протестирован. И для меня не имеет значения, какими средствами люди пользуются при дизайне. Меня гораздо больше интересует, чтобы члены команды были мотивированы. Мне также небезразлично, мотивирован ли я сам, поэтому я не буду заниматься парным программированием, если у меня нет настроения (что бывает часто). Я хочу, чтобы оценивали ценность сделанного мной, а не способ, которым я это делаю. Если я могу писать код высочайшего качества, сидя в переговорной комнате голым и с трусами, надетыми на голову, то кому какое дело? (Это просто пример. Я пробовал – это не работает.)

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

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

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