Файл: Роберт мартин.pdf

Глава 6. Внедрение Agile
200
бойтесь сделать неправильно . Просто выполняйте свою работу наперекор возникающим проблемам и настойчиво ведите проект к лучшему .
ПРЕОБРАЗОВАНИЕ
Переход от других методологий и моделей к Agile ведет к изме- нению ценностей . Ценности при использовании Agile включают в себя принятие рисков, быструю обратную связь, а также глубокое и многостороннее взаимодействие между членами коллектива, которое стирает границы внутри команды, в том числе между начальниками и подчиненными . Они также нацелены на ясное и честное поведение, а не распределение ролей и поиски крайнего .
Эти ценности прямо противоположны ценностям крупных органи- заций, которые вкладывают значительные средства в менеджеров среднего звена, ценности которых — безопасность, преемствен- ность, административное управление и выполнение плана .
Разве возможно перевести такую организацию на Agile? Честно говоря, это не то, в чем я достигал больших успехов, у других я по- добных успехов также не наблюдал . Я видел, как затрачивалось много усилий и средств, но чтобы организация действительно осуществила переход, я видел редко . Уклад ценностей слишком отличается от тех, которых придерживаются менеджеры среднего звена, чтобы их принять .
То, что я видел, — это переход команд и отдельных специалистов, потому что команды и одиночные программисты часто следуют ценностям, которыми руководствуется Agile .
Как ни странно, руководители тоже часто разделяют ценности, присущие Agile, например: принятие рисков, ясность и взаимо-

Преобразование
201
действие . В том числе по этой причине они пытаются осуществить переход в своих организациях .
Дело как раз в менеджерах среднего звена . Этих ребят взяли на работу не для того, чтобы принимать риски или вносить ясность, но для того, чтобы передавать ответственность при минимальном взаимодействии . Эта проблема остро стоит во многих компаниях .
Руководство и работники в организациях разделяют мировоззре- ние, свойственное Agile, но среднее звено мыслит наоборот . Я ни разу не видел, чтобы менеджеры среднего звена стояли в основе изменений . И вправду, с чего бы? Сопротивление таким измене- ниям — это их работа .
Чтобы донести свою мысль, расскажу вам несколько историй .
Саботаж
Еще тогда, в 2000 году, я участвовал в переходе одной организации на Agile . Мы заручились поддержкой начальства и программистов .
Переход сулил большие надежды . Возникли сложности с техниче- скими руководителями и архитекторами . Эти ребята, неправильно оценив положение дел, подумали, что их значимостью стали пре- небрегать .
Значимость архитекторов, технических руководителей проектов и многих других в команде, работающей по Agile, отличается, но никак не преуменьшена . К сожалению, ребята не понимали этого, возможно, и по нашей вине . Может, мы не донесли до них то, на- сколько они были значимы для команды, или они просто не хотели учиться новым навыкам, которые бы им пригодились .
Как бы то ни было, они тайком строили план саботажа, чтобы не допустить перехода на Agile . Не буду вдаваться в подробности

Глава 6. Внедрение Agile
202
этого плана . Только скажу, что как-то раз их застукали за этим и немедленно выперли с работы .
Мне бы очень хотелось сказать вам о том, что после этого переход на Agile стал продвигаться семимильными шагами и закончился большим успехом . Но, увы, не могу .
Волчонок
У нас отлично получилось перевести на Agile одно из подразделе- ний компании куда крупнее . Оно переняло опыт экстремального программирования и проделало за эти годы такую работу, что удостоилось статьи в журнале Computer world . Собственно, за этот успех вице-президент по инженерно-техническому обеспечению, руководивший этим переходом, получил повышение .
Его заменил новый вице-президент . И, подобно возмужавшему волчонку, которому посчастливилось возглавить стаю, он занялся тем, что уничтожил все наследие своего предшественника . Это коснулось и Agile . Он полностью отказался от него и вернул коман- де старую модель разработки, которая отличалась не в лучшую сторону .
Это привело к тому, что многие члены команды стали искать новое место работы, чего, я полагаю, и добивался новый вице-президент .
Плакса
Последнюю историю мне рассказали . Я не присутствовал в самый важный момент . Мне рассказали мои сотрудники, работавшие в то время .

Преобразование
203
В 2003 году моя компания переводила на Agile одну известную брокерскую фирму . Все шло замечательно . Велась подготовка руководителей высшего и среднего звена, а также разработчиков .
Они готовились вместе . Ничего не предвещало беды .
Потом пришла пора подвести итоги . Руководство и разработчики собрались в большой аудитории . Целью было оценить ход и успеш- ность перехода на Agile . Начальство задало вопрос: «Как обстоят дела?»
С разных сторон послышались ответы: «Все отлично!»
Потом повисло гробовое молчание, которое резко прервалось всхлипами, доносящимися сзади . Кто-то заплакал . И тогда эмоцио- нальный подъем обрушился, и аудитория погрузилась в уныние .
Вдохновения как не бывало . «Это так сложно, — донеслось до со- бравшихся . — Мы это просто не тянем» .
После этого начальство свернуло переход .
Мораль
Мораль всех этих историй: ожидайте любых странностей .
Притворяйтесь
Может ли команда, применяющая Agile, работать в организации, где есть сильное среднее звено, которое против этой методоло- гии? Я видел, как время от времени это происходило . Некото- рые команды разработчиков спокойно руководствуются Agile во время выполнения своей работы и в то же время выполняют строгие условия, навязанные менеджерами среднего звена . По-

Глава 6. Внедрение Agile
204
куда менеджеры среднего звена довольны соблюдением правил и нормативов, они оставляют разработчиков в покое, не вмеши- ваясь в их работу .
Это как раз то, о чем говорили Буч и Парнас: «Притворяйтесь!»
1
Команда работает по Agile, не объявляя об этом, и в то же время де- лает все для того, чтобы менеджеры среднего звена оставались до- вольными . Вместо того чтобы бороться с ветряными мельницами, такие команды используют Agile на низком уровне, преподнося его так, что для менеджеров среднего звена он выглядит безопасным и совместимым с их ценностями .
Например, менеджеры хотят получить документ об анализе, про- веденном на ранней стадии проекта . Команда, применяющая Agile, пишет большое количество первичного кода программы по всем канонам Agile, затем выпускает документ об анализе, запланировав череду историй по производству документации . Менеджеры полу- чают необходимый им документ .
В этом есть смысл, поскольку первые несколько итераций написа- ния кода в значительной мере ориентированы на анализ требова- ний . То, что анализ выполнен благодаря непосредственно написа- нию самого кода, менеджерам среднего звена знать необязательно .
Их не должно это волновать .
К сожалению, мне доводилось видеть компании, где такой дурдом, что если, не дай бог, среднее звено учует, что «что-то не так», оно прибегнет к различным уловкам, чтобы от Agile не осталось и сле- да . Это позор, потому что такие команды в действительности дают менеджерам все необходимое .
1
Booch G . Object-Oriented Analysis and Design with Applications . 2nd ed .
Reading, Massachusetts: Addison-Wesley, 1994 . Pp . 233–234 .

Преобразование
205
Успех в небольших организациях
Я видел, как некоторые средние по размеру компании перехо- дили на Agile . В таких компаниях тонкая прослойка менедже- ров среднего звена — это сотрудники, которые получили свои должности, поднимаясь с низов . У них сохранился образ мыш- ления людей, готовых к прямому взаимодействию и принятию рисков .
То, что мелкие компании полностью переходят на Agile, отнюдь не редкость . Там нет менеджеров среднего звена, а ценности боссов и разработчиков совпадают .
Успешный переход
отдельных специалистов
Наконец, в некоторых компаниях ценности Agile перенимают только отдельные сотрудники . Те, кто переходит на Agile индиви- дуально, чувствуют себя некомфортно в компании или команде, которые не собираются этого делать . Разница в ценностях обычно приводит к некоторому разделению . В лучшем случае люди, ко- торые осуществляют переход, объединятся, чтобы сформировать новые гибкие команды, которым удастся скрыться от менеджеров среднего звена . Если это не получается, они, скорее всего, будут искать (и найдут ведь!) работу в другой компании, которая раз- деляет их ценности .
За последние двадцать лет мы видели, как в отрасли меняются цен- ности . Образуются новые компании, которые принимают ценности
Agile, и программисты, которые хотят работать по методологии
Agile, группируются в таких компаниях .

Глава 6. Внедрение Agile
206
Создание Agile-организаций
Можно ли создать крупную организацию, где смогут успешно работать команды, использующие Agile? Несомненно! Только об- ратите внимание, я сказал «создать», а не «перевести» .
Когда IBM решила выпустить персональный компьютер, руко- водство компании понимало, что ценности организации не по- зволяют быстро внедрить нововведения и принять необходимые риски . Поэтому она создала организацию с другой системой ценностей
1
Было ли такое в мире разработки ПО? Было ли такое, что круп- ные организации создавали более мелкие, чтобы писать ПО с по- мощью Agile? На моей памяти были намеки на это, но не могу привести ни одного яркого примера .
Конечно, мы видели множество новых компаний, принимавших
Agile . Также можно вспомнить много компаний, консультировав- ших по Agile более крупные компании, которые не применяли
Agile в целом, но хотели выполнить отдельные проекты с боль- шей скоростью и надежностью .
А вот мой прогноз . В конечном итоге мы увидим, как крупные компании будут создавать новые подразделения, которые будут заниматься написанием программ с применением Agile . Также консалтинговые компании, занимающиеся Agile, будут все чаще оказывать услуги крупным организациям, которым не удалось перевести на Agile своих разработчиков .
1
The birth of the IBM PC . URL: https://www.ibm.com/ibm/history/exhibits/pc25/
pc25_birth.html.

Коучинг
207
КОУЧИНГ
Нужен ли команде, работающей по Agile, коуч? Вообще — нет . Но если хорошо подумать, то иногда нужен .
Прежде всего, следует видеть грань между тренером и коучем .
Agile-тренер обучает команду, как организовать себя, применяя
Agile .
Часто они не работают в самой компании или работают в ней, но сами не являются членами команды . Их цель — прививать цен- ности Agile и обучать дисциплинам Agile . Их работа не должна длиться долго . Команде, состоящей из десятка разработчиков, по- надобится одна-две недели тренингов .
Agile-тренер может говорить и делать что угодно, но всему осталь- ному, чему нужно, разработчики научатся сами .
В начале перехода команды на Agile тренер может временно вы- ступать в роли коуча, но продолжительность такого коучинга не- велика . Это бремя должен на себя взять кто-то из членов команды, и чем скорее, тем лучше .
Как правило, коучи и тренеры — разные люди . Коучи — это члены команды, чья задача — обеспечивать соблюдение методологии внутри команды . Когда разработка кипит, у программистов может возникнуть соблазн сойти с колеи . Они ненароком могут пере- стать работать в паре, выполнять рефакторинг кода или обращать внимание на сбои, возникающие при непрерывной сборке . Коуч наблюдает за тем, чтобы такого не было, и при случае указывает команде на их огрехи . Коуч выступает в качестве совести команды, постоянно ей напоминая о данных себе обещаниях и о ценностях, которые те согласились соблюдать .

Глава 6. Внедрение Agile
208
Эта роль по мере необходимости обычно переходит от одного члена команды к другому согласно неофициальному графику .
Команда, уже стабильно сработавшаяся, не нуждается в коуче .
С другой стороны, команда в напряженной обстановке, будь то из-за графика работ, проблем во взаимодействии с клиентами или внутри команды, может принять решение назначить кого-либо коучем на время .
Коуч не менеджер . Он не отвечает за распределение средств или график работ . Коуч не руководит командой и не представляет интересы команды перед менеджерами . Коуч также не является посредником между клиентами и разработчиками . Коуч выпол- няет свои функции исключительно внутри команды . Никто из менеджеров или клиентов не знает, кто является коучем и есть ли он вообще .
Скрам-мастер
В Scrum такой коуч называется мастером . Изобретение этого понятия и череда событий, последовавших за ним, были одно- временно и лучшим, и худшим, что когда-либо случалось в со- обществе Agile . Программы сертификации привлекли большое количество менеджеров проекта . Такой приток поспособствовал распространению Agile в самом начале, но в итоге он привел к тому, что функции коуча приравняли к тому, чем занимается менеджер проекта .
В наше время слишком часто происходит так, что скрам-мастера никакие не коучи, а обычные менеджеры проекта, которые выпол- няют соответствующую работу . К несчастью, название должности и наличие сертификата способствуют их непомерному влиянию на команду, применяющую Agile .

Сертификация
209
СЕРТИФИКАЦИЯ
Вся существующая сертификация по Agile смехотворна и нелепа .
Нельзя относиться к такой «сертификации» всерьез . Обучение во время программ сертификации часто полезно, однако оно не должно сводиться к определенной роли и должно быть рассчитано на всех членов команды .
Например, от «сертификата» скрам-мастера никакого толка нет .
Сертификаты значат не больше, чем то, что кому-то некуда было девать деньги и он в лучшем случае прошел двухдневные курсы .
Лицо, выдающее сертификат, не гарантирует, что новоиспечен- ный мастер будет хорош в роли коуча . Бессмысленность наличия такого сертификата в том, что он наделяет «сертифицированного скрам-мастера» чем-то особенным, а это не имеет ничего общего с коучингом в команде . Чтобы стать коучем в команде, не нужно никаких обучений .
Нет ничего плохого в прохождении самого обучения, необходимого для сертификации . Просто обучать только одного человека отдель- ной роли в команде глупо . Каждый член команды, применяющей
Agile, должен понимать ценности и методы Agile . И если один член команды подготовлен, значит, нужно подготовить и всех .
Настоящая сертификация
А как на самом должна выглядеть программа сертификации по
Agile? Это должен быть семестровый курс, который сочетал бы обучение работе по Agile и небольшой учебный проект по гибкой методологии разработки . На этих курсах будет система оценок и высокие планки прохождения заданий . Тот, кто выдает сертифи- каты, должен гарантировать, что ученики усвоили ценности Agile