ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 346
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Похмелье от Аgile
245
подробно рассказывая о том, над чем они работают и когда эти работы закончат . Если владелец продукта думает, что разработчи- ки тратят слишком много времени на автоматизированные тесты, рефакторинг, парное программирование или что-то подобное, он просто команде запрещает это делать .
В их модели Agile нет никакой стратегическо-технической ра- боты . В ней нет требований к архитектуре или проектированию .
Порядок таков, что нужно просто сосредоточиться на какой-либо невыполненной работе из списка, которую нужно выполнить не- замедлительно и которой присвоили наивысший приоритет . И так одно задание с наивысшим приоритетом следует за другим . Такой подход приводит к длинной последовательности итеративных тактических работ и накоплению технического долга . Хрупкое программное обеспечение, знаменитые монолиты (или распреде- ленные монолиты, если говорить о командах, которые пробуют использовать микросервисную архитектуру) становятся в порядке вещей . Ошибки и неполадки оказываются излюбленной темой для обсуждения на ежедневном стендап-митинге и ретроспективах .
Релизы выходят не так часто, как ожидали клиенты . Тестирование вручную занимает целые дни, а то и недели . И надежда на то, что применение Agile убережет от всех напастей, бесследно уходит .
Менеджеры обвиняют разработчиков, что те слишком медленно работают . Разработчики обвиняют менеджеров, что те не дают им проводить необходимые стратегические и технические работы .
Владельцы продукта не считают себя частью команды, поэтому не берут на себя никакой ответственности за то, что дела пошли не так . Начинает преобладать порядок «свои против чужих» .
Это то, что мы называем похмельем от Agile . После долгих лет вло- жения средств в переход на Agile компании понимали, что у них до сих пор много тех же проблем, которые были до него . И конечно, во всем виноват Agile .
Глава 7. Мастерство высшего уровня
246
ОЖИДАНИЕ И РЕАЛЬНОСТЬ
Переход на Agile, который полностью сосредоточен на процессе, нельзя назвать полным переходом . В то время как коучи по Agile направляют менеджеров и команды поставщиков в работе по Agile, никто не помогает разработчикам изучать технические методы
Agile и инжиниринг . Предположение о том, что налаживание со- трудничества между людьми улучшит показатели по инжинирингу, в высшей мере ошибочно .
Слаженное сотрудничество убирает некоторые барьеры, кото-
рые мешают работать, но не обязательно добавляет мастер-
ства работникам.
С внедрением Agile появляются и большие надежды: команды разработчиков должны выпускать ПО, готовое к релизу в про- изводство, сразу как реализована какая-либо функция или, по крайней мере, в конце каждой итерации . Для большинства команд разработчиков это изменение значительно . Нет для них иного пути перехода на Agile, кроме изменения подхода к работе, а это означает, что нужно изучать и совершенствовать новые методы .
Но встает несколько вопросов . Как правило, во время перехода на
Agile на повышение квалификации разработчиков не выделяется бюджет . Клиенты не учитывают снижения темпов разработчиков при переходе на Agile . Большинство даже не знает, что разработчи- кам нужно изучить новые методы . Им сказали, что если они будут лучше сотрудничать, то разработчики будут работать быстрее .
Выпуск ПО в продакшен каждые две недели требует большой дис- циплины и развитых технических навыков, тех навыков, которых обычно не отыщешь в командах, выпускающих ПО несколько раз в год . Все становится намного хуже, когда предполагается, что не- сколько команд с внушительным числом разработчиков в каждой
Все дальше друг от друга
247
и работающих над одними и теми же системами, будут выпускать
ПО в продакшен сразу, как только реализуют какие-либо функции .
Уровень мастерства команд в технических практиках и инжини- ринге должен быть высоким, чтобы развертывать ПО в продакшен несколько раз в день, при этом не подрывая стабильность всей системы . Разработчики не могут просто выбрать что-то из списка невыполненных задач, начать писать код и думать, что все будет хорошо, когда релиз пойдет в производство . Им нужно стратеги- ческое мышление . Им нужно модульное проектирование с воз- можностью параллельной работы .
Им нужно постоянно принимать изменения и при этом обеспе- чивать постоянную возможность развернуть систему . Для этого им постоянно нужно создавать ПО — и гибкое, и надежное . Но сохранять равновесие между гибкостью, надежностью и необхо- димостью непрерывно развертывать ПО в продакшен в высшей мере тяжело, и такого равновесия нельзя достичь без необходимых навыков инжиниринга .
Нельзя думать, что команды смогут развить эти навыки просто благодаря комфортной и сплоченной обстановке . В обретении этих технических навыков командам нужна поддержка . Эту поддержку можно оказать сочетанием коучинга, тренингов, экспериментиро- вания и поощрения самообразования . Agile в бизнесе прямо связан с тем, как быстро компании могут выпускать ПО, а это означает эволюцию их навыков инжиниринга и технических методов .
ВСЕ ДАЛЬШЕ ДРУГ ОТ ДРУГА
Конечно, не каждый случай перехода на Agile сопровождается все- ми проблемами, описанными выше, или, по крайней мере, не в та-
1 ... 12 13 14 15 16 17 18 19 20
Глава 7. Мастерство высшего уровня
248
кой степени . С деловой точки зрения, честно сказать, большинство компаний, которые перешли на Agile хотя бы частично, сегодня находятся в лучшем положении . Они теперь работают короткими итерациями . Бизнес и технологии работают более слаженно, чем раньше . Проблемы и риски обнаруживаются преждевременно .
Предприятия чаще реагируют на новую информацию по мере ее поступления, по-настоящему выигрывая от итеративного подхода в разработке . Однако несмотря на то что компании действительно работают лучше, чем раньше, раскол между методами Agile и на- выками инжиниринга до сих пор наносит им вред . У большинства современных коучей недостаточно (если вообще есть) технических навыков для обучения разработчиков техническим методам, и они редко говорят об инжиниринге . На протяжении многих лет разра- ботчики стали считать Agile-коучей дополнительной прослойкой менеджмента: коучи говорят им, что делать, вместо того чтобы помочь развивать навыки .
Разработчики отдаляются от Agile или Agile отдаляется от
разработчиков?
Вероятно, ответ на этот вопрос будет таким: и разработчики, и Agile . Кажется, что Agile и разработчики отдаляются друг от дру- га . Во многих организациях Agile и Scrum стали принимать за одно и то же . Экстремальное программирование, если оно вообще при- сутствовало, было представлено лишь несколькими техническими методами вроде разработки через тестирование и непрерывной интеграции . От коучей ждут обучения разработчиков некоторым методам экстремального программирования, но они на самом деле никак не помогают и не вовлекаются в то, чем занимаются разра- ботчики . Многие владельцы продукта (или менеджеры проекта) до сих пор не ощущают себя частью команды и не чувствуют от- ветственности, когда что-то идет не по плану . Разработчикам до сих
Высшее мастерство разработки
249
пор приходится жестко настаивать в переговорах с представителя- ми бизнеса на проведении необходимых технических улучшений для продолжения разработки и сопровождения системы .
Компании до сих пор недостаточно созрели для понимания того,
что технические проблемы — на самом деле проблемы бизнеса.
Может ли Agile при снижении внимания на технических навыках значительно продвинуть выполнение проектов и обеспечить луч- ший результат, чем раньше? По-прежнему ли Agile сосредоточен на поиске эффективных способов разработки тем, ищет их и помо- гает в этом другим, как это написано в Манифесте Agile? Не могу уверенно сказать этого .
ВЫСШЕЕ МАСТЕРСТВО РАЗРАБОТКИ
Чтобы повысить планку профессиональных навыков разработки и восстановить некоторые изначальные цели Agile, группа разра- ботчиков собралась на встрече в Чикаго в ноябре 2008 года, чтобы создать новое движение — мастеров разработки ПО (Software
Craftsmanship) . Эта встреча напоминала саммит Agile, который прошел в 2001 году, на ней разработчики утвердили основной на- бор ценностей и создали новый манифест
1
на основе Манифеста
Agile:
Являясь устремленными к совершенству мастерами разработ-
ки ПО, мы повышаем уровень профессиональной разработки
ПО, делая это сами и помогая другим осваивать наше ремесло.
Занимаясь этой деятельностью, мы прежде всего научились
ценить:
1
https://manifesto.softwarecraftsmanship.org/#/ru-ru.
Глава 7. Мастерство высшего уровня
250
z
Не только работающий продукт, но также и искусно разрабо- танный продукт .
z
Не только готовность к изменениям, но также и постоянное увеличение ценности .
z
Не только людей и взаимодействие, но также и содружество профессионалов .
z
Не только сотрудничество с заказчиком, но также и плодотвор- ное партнерство .
Таким образом, в стремлении к тому, что слева, мы также счи-
таем непременным следовать и тому, что справа.
Манифест мастеров разработки ПО содержит идеологию, мента- литет . Он способствует профессионализму с разных точек зрения .
Искусно разработанный продукт означает хорошо спроектирован- ный и протестированный код . Это код, в который мы не боимся вносить изменения, и код, который позволяет бизнесу быстрее реагировать на изменения . Это код и гибкий, и надежный .
Постоянное увеличение ценности означает, что независимо от того, чем мы занимаемся, мы всегда должны стараться непрерывно по- вышать ценность для наших клиентов и работодателей .
Содружество профессионалов означает, что мы должны обмени- ваться знаниями и учиться друг у друга, повышая тем самым уро- вень всей отрасли . Мы ответственны за подготовку следующего поколения разработчиков .
Плодотворное партнерство означает следование профессиона- лизму в отношениях с клиентами и партнерами . Мы всегда будем, насколько возможно, проявлять этичность и уважительность в кон-
Идеология против методологии
251
сультировании и работе с нашими клиентами и работодателями .
Мы будем ожидать взаимного уважения и профессионализма, даже если нам придется взять на себя инициативу и показать пример .
Мы будем подходить к делу не как к чему-то, что просто нужно сде- лать по работе, а как к предоставлению профессиональных услуг .
Мы возьмем карьеру в свои руки, будем вкладывать наше время и деньги, чтобы совершенствоваться . Эти ценности не только про- фессиональные, но и личные .
Мастера стремятся выполнять свою работу как можно лучше не потому, что кто-то за это платит, а потому что они сами хотят хо- рошо работать .
Тысячи разработчиков по всему миру немедленно подписались под принципами и ценностями, которые признаются мастерами разработки ПО . Изначальное волнение, которое разработчики почувствовали в начале появления Agile, не только вернулось, но и усилилось . Мастера, как они стали себя называть, решили больше не позволять спекулировать на их движении . Это движение раз- работчиков .
Движение, которое вдохновляет разработчиков работать как мож- но лучше . Движение, которое вдохновляет разработчиков стано- виться и чувствовать себя профессионалами высокого уровня .
ИДЕОЛОГИЯ ПРОТИВ МЕТОДОЛОГИИ
Идеология — это система идей и идеалов . А методология — систе- ма методов и практик . Идеология определяет идеалы, на которые нужно держать курс . Можно использовать одну или несколь- ко методологий для достижения этих идеалов — они являются
Глава 7. Мастерство высшего уровня
252
средством достижения цели . Если посмотреть на Манифест Agile и его 12 принципов
1
, мы можем явно разглядеть идеологию в этих строках . Главная цель Agile — это обеспечить гибкость бизнеса и удовлетворить запросы клиентов, а достичь этого можно через тесное сотрудничество, итеративный процесс разработки, быструю обратную связь и техническое совершенство . Методологии вроде
Scrum, экстремального программирования (XP), метода разра- ботки динамических систем (DSDM), адаптивной разработки ПО
(ASD), методов Crystal, разработки, управляемой функциональ- ностью (FDD), а также другие методологии Agile служат одной и той же цели .
Методологии и методы — как дополнительное колесико в детском велосипеде: они хороши поначалу . Как и в случае с ребенком, который учится кататься на велосипеде, такие колесики помогут научиться безопасно и легко кататься . Когда ребенок становится увереннее, мы поднимаем колесики, чтобы он мог потренировать- ся держать равновесие . Потом убираем одно из дополнительных колесиков . А за ним и другое .
Теперь ребенок может кататься без посторонней помощи . Но если мы слишком сильно сосредоточимся на важности тренировочных колес и не будем их долго убирать, ребенок привыкнет к ним и не захочет без них кататься . Чрезмерное внимание к методологии или набору методов отвлекает команды и организации от их действи- тельных целей . Цель — научить ребенка ездить на велосипеде, а не внедрить тренировочные колеса .
Джим Хайсмит в своей книге Agile Project Management: Creating
Innovative Products пишет: «Принципы без методов — ноль без
1
https://agilemanifesto.org/iso/ru/principles.html.
Есть ли в мастерстве разработки методы?
253
палочки, в то время как методы без принципов, как правило, заучи- вают механически, без лишних раздумий . Принципы направляют методы . Методы воплощают принципы . Они идут рука об руку»
1
Хотя методологии и методы являются средством для достижения цели, мы не должны преуменьшать их важность . Профессионалов определяют по тому, как они работают . Мы не можем заявлять, что у нас есть какие-то принципы и ценности, если наши методы работы не согласуются с ними .
Хорошие специалисты могут точно сказать, как будут вести работу при тех или иных обстоятельствах . Они владеют широким набором методов и могут их применять в зависимости от потребностей .
ЕСТЬ ЛИ В МАСТЕРСТВЕ РАЗРАБОТКИ МЕТОДЫ?
В мастерстве разработки нет методов . Скорее оно способствует вечному поиску лучших методов и способов работы . Хорошие методы хороши до тех пор, пока мы не обнаружим новые, кото- рые придут им на замену . Закрепление определенных методов за мастерством разработки ПО ослабило бы это мастерство с по- явлением новых методов . Но это не значит, что международное сообщество мастеров разработки не советует применять никакие методы . Наоборот, со времени создания в 2008 году и по сей день сообщество признает экстремальное программирование лучшим набором методов Agile для разработки ПО .
Разработка через тестирование, рефакторинг, простота проекти- рования, непрерывная интеграция и парное программирование высоко ценятся в сообществе мастеров разработки ПО, но это
1
Highsmith J. Agile Project Management: Creating Innovative Products, 2nd ed .
Boston, Massachusetts: Addison-Wesley, 2009 . P . 85 .