В этом есть смысл, поскольку первые несколько итераций написания кода в значительной мере ориентированы на анализ требований. То, что анализ выполнен благодаря непосредственно написанию самого кода, менеджерам среднего звена знать необязательно. Их не должно это волновать.
К сожалению, мне доводилось видеть компании, где такой дурдом, что если, не дай бог, среднее звено учует, что «что-то не так», оно прибегнет к различным уловкам, чтобы от Agile не осталось и следа. Это позор, потому что такие команды в действительности дают менеджерам все необходимое.
Успех в небольших организациях
Я видел, как некоторые средние по размеру компании переходили на Agile. В таких компаниях тонкая прослойка менеджеров среднего звена — это сотрудники, которые получили свои должности, поднимаясь с низов. У них сохранился образ мышления людей, готовых к прямому взаимодействию и принятию рисков.
То, что мелкие компании полностью переходят на Agile, отнюдь не редкость. Там нет менеджеров среднего звена, а ценности боссов и разработчиков совпадают.
Успешный переход отдельных специалистов
Наконец, в некоторых компаниях ценности Agile перенимают только отдельные сотрудники. Те, кто переходит на Agile индивидуально, чувствуют себя некомфортно в компании или команде, которые не собираются этого делать. Разница в ценностях обычно приводит к некоторому разделению. В лучшем случае люди, которые осуществляют переход, объединятся, чтобы сформировать новые гибкие команды, которым удастся скрыться от менеджеров среднего звена. Если это не получается, они, скорее всего, будут искать (и найдут ведь!) работу в другой компании, которая разделяет их ценности.
За последние двадцать лет мы видели, как в отрасли меняются ценности. Образуются новые компании, которые принимают ценности Agile, и программисты, которые хотят работать по методологии Agile, группируются в таких компаниях.
Создание Agile-организаций
Можно ли создать крупную организацию, где смогут успешно работать команды, использующие Agile? Несомненно! Только обратите внимание, я сказал «создать», а не «перевести».
Когда IBM решила выпустить персональный компьютер, руководство компании понимало, что ценности организации не позволяют быстро внедрить нововведения и принять необходимые риски. Поэтому она создала организацию с другой системой ценностей[58].
Было ли такое в мире разработки ПО? Было ли такое, что крупные организации создавали более мелкие, чтобы писать ПО с помощью Agile? На моей памяти были намеки на это, но не могу привести ни одного яркого примера.
Конечно, мы видели множество новых компаний, принимавших Agile. Также можно вспомнить много компаний, консультировавших по Agile более крупные компании, которые не применяли Agile в целом, но хотели выполнить отдельные проекты с большей скоростью и надежностью.
А вот мой прогноз. В конечном итоге мы увидим, как крупные компании будут создавать новые подразделения, которые будут заниматься написанием программ с применением Agile. Также консалтинговые компании, занимающиеся Agile, будут все чаще оказывать услуги крупным организациям, которым не удалось перевести на Agile своих разработчиков.
Коучинг
Нужен ли команде, работающей по Agile, коуч? Вообще — нет. Но если хорошо подумать, то иногда нужен.
Прежде всего, следует видеть грань между тренером и коучем. Agile-тренер обучает команду, как организовать себя, применяя Agile.
Часто они не работают в самой компании или работают в ней, но сами не являются членами команды. Их цель — прививать ценности Agile и обучать дисциплинам Agile. Их работа не должна длиться долго. Команде, состоящей из десятка разработчиков, понадобится одна-две недели тренингов.
Agile-тренер может говорить и делать что угодно, но всему остальному, чему нужно, разработчики научатся сами.
В начале перехода команды на Agile тренер может временно выступать в роли коуча, но продолжительность такого коучинга невелика. Это бремя должен на себя взять кто-то из членов команды, и чем скорее, тем лучше.
Как правило, коучи и тренеры — разные люди. Коучи — это члены команды, чья задача — обеспечивать соблюдение методологии внутри команды. Когда разработка кипит, у программистов может возникнуть соблазн сойти с колеи. Они ненароком могут перестать работать в паре, выполнять рефакторинг кода или обращать внимание на сбои, возникающие при непрерывной сборке. Коуч наблюдает за тем, чтобы такого не было, и при случае указывает команде на их огрехи. Коуч выступает в качестве совести команды, постоянно ей напоминая о данных себе обещаниях и о ценностях, которые те согласились соблюдать.
Эта роль по мере необходимости обычно переходит от одного члена команды к другому согласно неофициальному графику. Команда, уже стабильно сработавшаяся, не нуждается в коуче. С другой стороны, команда в напряженной обстановке, будь то из-за графика работ, проблем во взаимодействии с клиентами или внутри команды, может принять решение назначить кого-либо коучем на время.
Коуч не менеджер. Он не отвечает за распределение средств или график работ. Коуч не руководит командой и не представляет интересы команды перед менеджерами. Коуч также не является посредником между клиентами и разработчиками. Коуч выполняет свои функции исключительно внутри команды. Никто из менеджеров или клиентов не знает, кто является коучем и есть ли он вообще.
Скрам-мастер
В Scrum такой коуч называется мастером. Изобретение этого понятия и череда событий, последовавших за ним, были одновременно и лучшим, и худшим, что когда-либо случалось в сообществе Agile. Программы сертификации привлекли большое количество менеджеров проекта. Такой приток поспособствовал распространению Agile в самом начале, но в итоге он привел к тому, что функции коуча приравняли к тому, чем занимается менеджер проекта.
В наше время слишком часто происходит так, что скрам-мастера никакие не коучи, а обычные менеджеры проекта, которые выполняют соответствующую работу. К несчастью, название должности и наличие сертификата способствуют их непомерному влиянию на команду, применяющую Agile.
Сертификация
Вся существующая сертификация по Agile смехотворна и нелепа. Нельзя относиться к такой «сертификации» всерьез. Обучение во время программ сертификации часто полезно, однако оно не должно сводиться к определенной роли и должно быть рассчитано на всех членов команды.
Например, от «сертификата» скрам-мастера никакого толка нет. Сертификаты значат не больше, чем то, что кому-то некуда было девать деньги и он в лучшем случае прошел двухдневные курсы. Лицо, выдающее сертификат, не гарантирует, что новоиспеченный мастер будет хорош в роли коуча. Бессмысленность наличия такого сертификата в том, что он наделяет «сертифицированного скрам-мастера» чем-то особенным, а это не имеет ничего общего с коучингом в команде. Чтобы стать коучем в команде, не нужно никаких обучений.
Нет ничего плохого в прохождении самого обучения, необходимого для сертификации. Просто обучать только одного человека отдельной роли в команде глупо. Каждый член команды, применяющей Agile, должен понимать ценности и методы Agile. И если один член команды подготовлен, значит, нужно подготовить и всех.
Настоящая сертификация
А как на самом должна выглядеть программа сертификации по Agile? Это должен быть семестровый курс, который сочетал бы обучение работе по Agile и небольшой учебный проект по гибкой методологии разработки. На этих курсах будет система оценок и высокие планки прохождения заданий. Тот, кто выдает сертификаты, должен гарантировать, что ученики усвоили ценности Agile и показали высокий уровень мастерства в применении методов Agile.
Agile в крупных масштабах
Движение Agile появилось в конце 1980-х. Его быстро признали способом организовать небольшую команду, размером от 4 до 12 разработчиков. Эти числа были нестрогими и редко озвучивались, однако все понимали, что Agile (или как мы его там называли до 2001-го) не подходит для гигантских команд из тысяч разработчиков. Это не та задача, над решением которой мы бились. Тем не менее вопрос подняли почти сразу. А что насчет больших команд? Что, если применить Agile в крупном масштабе?
Долгие годы люди искали ответ на этот вопрос. В самом начале авторы Scrum предложили метод Scrum-of-Scrums. Позже мы стали наблюдать появление некоторых фирменных подходов вроде SAFe[59] и LeSS[60]. На эту тему написано несколько книг.
Я уверен, что в этих подходах нет ничего плохого. Я уверен, что эти книги замечательны. Но я не пробовал этих методов и не читал книг. Вы можете подумать, что я какой-то пустомеля, что высказываюсь на тему, которую не изучил. Может, вы и правы. Однако у меня есть своя точка зрения.
Agile создан для малых и средних команд. Точка. Он хорошо работает для таких команд. Agile никогда не предназначался для больших команд.
Почему мы не пробовали решить проблему больших команд? Да потому что проблема больших команд решается огромным количеством специалистов вот уже больше пяти тысяч лет. Эта проблема больших команд — проблема культур и цивилизаций. И если в какой-то мере судить о нашей нынешней цивилизации, эту проблему решили достаточно неплохо.
Как построили пирамиды в Египте? Надо было решить проблему больших команд. Как получилось победить во Второй мировой войне? Надо было решить проблему больших команд. Как удалось отправить человека в космос и благополучно вернуть его на Землю? Надо было решить проблему больших команд.
Но такие большие проекты — не единственные достижения больших команд, не правда ли? Как получилось развернуть телефонную сеть, построить автомагистраль, создать интернет, произвести мобильные телефоны или автомобили? Это все сотворили большие команды.