Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

Есть два подхода к описанию уровней профессионального мастерства. Система гильдий, распространенная в средневековой Европе, предусматривала три уровня: ученик, подмастерье и мастер . Практически ничем не отличается японская система сюхари, в которой выделяются три уровня владения боевыми искусствами: сю, ха и ри . И в той и в другой системе люди, находящиеся на первом уровне, изучают основные техники; на втором уровне акцент делается на исключениях и рефлексии; а на третьем уровне думать уже не надо, все дается легко и естественно.

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

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

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

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

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

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

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

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