Чистый Agile. Основы гибкости Мартин Роберт

Глава 8. Заключение

Вот такие дела. В этой книге — мои воспоминания, мнение, всякие разглагольствования и бредни об Agile. Надеюсь, вам было интересно, и вы почерпнули даже что-то полезное для себя.

Возможно, Agile — наиболее значительная и устойчивая революция в методах разработки ПО на нашей памяти. Такая значимость и устойчивость — свидетельство того, что те 17 ребят в феврале 2001 года в Сноуберде, что в Юте, спустили снежный ком вниз с очень высокого холма. Нестись на этом коме, наблюдая за тем, как он растет и набирает скорость, как сносит валуны и деревья, мне было очень весело.

Я написал эту книгу, потому что подумал, что наступило время, когда кто-то должен встать и сказать о том, каким Agile был и каким он должен быть и сейчас. Я посчитал, что настало время вернуться к основам.

Эти основы были, есть и будут теми самыми методами из круга жизненного цикла Рона Джеффриса. Эти основы представляют собой ценности, принципы и методы из книги Кента Бека Extreme Programming Explained[71]. Эти основы — также те самые устремления, техники и методы из книги Мартина Фаулера Refactoring[72]. Эти основы были изложены Бучем, Демарко, Йорданом, Константином, Пейдж-Джонсом и Листером.

О них кричали Дейкстра, Даль и Хоар. Вы слышали о них от Кнута, Мейера, Якобсена и Рамбо. Им вторили Коплин, Гамма, Хелм, Влиссидес и Джонсон. Если вы внимательно слушали, то услышали, как о них шептали Томпсон, Ричи, Керниган и Плаугер. И где-то улыбались Черч, фон Нейман и Тьюринг, когда эти эхо и шепот касались их ушей.

Эти основы старые, проверенные и правильные. Неважно, сколько пуха накинули по краям, эти основы никуда не исчезли, они до сих пор актуальны и до сих пор составляют ядро гибкой методологии разработки Agile.

Послесловие

Автор Эрик Кричлоу, 5 апреля 2019 года

Я могу легко вспомнить свою первую работу, где решили перейти на Agile. Был 2008 год. Нашу компанию приобрела крупная организация. Происходили значительные изменения в политике, делопроизводстве и штате сотрудников. Еще я могу вспомнить парочку других работ, где акцент ставился на методы Agile. Ритуалы соблюдались неукоснительно: планирование спринта, демонстрация, обзор спринта… В одной из этих компаний всех штатных разработчиков направили на двухдневные тренинги по Agile, где они получили сертификаты скрам-мастеров. Я был разработчиком мобильных приложений, и меня попросили написать мобильное приложение для игры в Agile-покер.

Но за 11 лет, с тех пор как я впервые познакомился с Agile, я работал в нескольких компаниях, где уже точно не помню, использовался Agile или нет. Возможно, потому что Agile стал настолько вездесущим, что его легко принять как данность и даже не думать о нем. Или, может быть, потому что до сих пор значительное количество организаций не перешло на него.

Когда я узнал об Agile, то не испытал особого восторга. У каскадной модели, возможно, есть свои проблемы, но в моей компании не тратили много времени на написание проектной документации. У меня, разработчика, в основном был такой порядок: мне в устной форме передавали, какой функционал нужен к следующему релизу, назначали дату выпуска релиза и отпускали на все четыре стороны колдовать. Это, конечно, могло приводить к лютому марафону на выживание, но зато я мог свободно выстраивать свои действия так, как хочу. Мне не нужно было часто давать отчеты и проводить анализ на ежедневных стендап-митингах, где пришлось бы объяснять, над чем я работал вчера и что я буду делать сегодня. Если я решал потратить неделю на изобретение колеса, мне в этом никто не мешал, никто не осуждал мой выбор, потому что все находились в блаженном неведении относительно того, чем я занимался.

Бывший директор по разработке, который шефствовал над нами тогда, называл нас «писаками». Нам просто нравилось лупить по клавиатуре на Диком Западе разработки ПО. Он был прав. И в какой-то мере методы Agile, будучи чем-то новым, царили у нас в голове, склоняя нас к инакомыслию.

Agile пришлось потрудиться, чтобы завоевать мое доверие.

Было бы самонадеянно полагать, что Agile — это стандарт де-факто в отрасли разработки ПО или что все разработчики принимают его с распростертыми объятиями. С другой стороны, было бы невежеством отрицать значимость Agile в мире разработки. Но что это вообще значит? В чем, собственно, его значимость?

Спросите разработчиков в какой-нибудь компании, работающей по Agile, что такое этот самый Agile. И ответ, скорее всего, будет совсем другим, чем ответ любого из тех, кто находится в должности выше менеджера. Возможно, именно здесь эта книга наиболее поучительна.

Разработчики понимают Agile как методологию для оптимизации процесса разработки и для того, чтобы сделать разработку более предсказуемой, практичной и управляемой. Вполне логично, что мы смотрим на него с этой точки зрения, потому что это та точка зрения, которая самым непосредственным образом влияет на нас.

По своему опыту могу сказать, что многие разработчики понятия не имеют о том, что менеджеры используют метрики и данные, полученные при работе по методам Agile. В некоторых компаниях команда разработчиков принимает участие во встречах, когда эти метрики обсуждаются. Однако во многих других компаниях разработчики остаются в неведении, что такие обсуждения вообще есть. Более того, возможно, в каких-то компаниях таких обсуждений не проводят в принципе.

Хотя я уже давно знал об этой особенности Agile, я все еще видел пользу в том, чтобы понять изначальный замысел и ход мышления основателей методологии, о которой рассказывается в этой книге. Было бы здорово и увидеть основателей Agile просто как людей. Они были не какими-то суперархитекторами разработки, не были рукоположены магистром Ордена инженерной мысли или избраны широкими народными массами разработчиков, чтобы передать каноны. Это были разработчики, наделенные опытом, обладавшие идеями, как облегчить себе жизнь и работу и избежать стрессов. Им надоело работать в командах, чья работа обречена на провал, поэтому им хотелось создать условия, способствующие благополучию.

Так можно сказать про большинство разработчиков, которых я встречал в каждой компании, где работал.

Если бы встреча в Сноуберде прошла на 15 лет позже, могло быть и так, что я бы сам организовал эту встречу и изложил бы те самые идеи, и на встрече было бы много разработчиков, с которыми я работал лично. Но будучи лишь еще одной группой опытных разработчиков, они были склонны к полетам фантазии, которые не всегда приживались в корпоративной реальности. Может быть, все это работает, как задумано, в мире высококлассных консультантов, наделенных властью выставлять требования и подчинять организации и руководство своим убеждениям, но большинство из нас — пехота, винтики в механизме фабрик по созданию программ. Нас можно заменить, у нас мало рычагов влияния. Поэтому когда дело доходит до таких штуковин, как «Билль о правах», мы понимаем, что это идеал, но не то, что большинство из нас встречает в действительности.

Сегодня из сообществ в соцсетях я с радостью узнаю, что многие новые разработчики выходят за привычные рамки бакалавриата computer science и графика работы с девяти до пяти, что они сотрудничают с другими разработчиками по всему миру, учатся, применяют свои знания и опыт, чтобы обучать и вдохновлять новоиспеченных программистов.

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

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

Теперь, когда вы прочитали эту книгу, у вас есть пища для размышлений. Рассмотрим Agile с тех сторон, о которых вы, возможно, знали, но о которых не особо задумывались. Подумайте о нем с точки зрения бизнес-аналитика, менеджера проекта или любого другого менеджера, непосредственно не связанного с разработкой, ответственного за планирование релизов или создание дорожных карт развития продукта. Подумайте над тем, какую пользу им приносит вклад разработчиков в методы Agile. Поймите, каким образом ваш вклад в работу влияет не только на вашу рабочую нагрузку в течение следующих двух недель. Затем вернитесь и снова просмотрите книгу. Если вы подойдете к ней с более широкой перспективы, думаю, вы по крупицам соберете еще больше полезных идей.

Как только вы это сделаете, попросите другого разработчика из компании прочитать эту книгу и провести такой же анализ. Можете дать почитать эту книгу даже кому-то… кто и вовсе не разработчик. Дайте ее кому-нибудь из тех, кто представляет вашу компанию на уровне бизнеса. Я почти гарантирую, что «Билль о правах» — это что-то из области того, о чем они никогда и не думали. Жить станет намного приятнее, если вы сможете до них донести, что эти права так же неотъемлемы для Agile, как и метрики, которые они получают при его использовании.

Можно сказать, что Agile стал чем-то вроде религии в области разработки. Многие из нас считают его лучшей практикой. Почему? Для многих — потому что так сказали. Это стало традицией: так надо. В понимании нового поколения корпоративных разработчиков просто так заведено. Они, и даже многие «старички», вообще не знают суть Agile — какие у него изначальные цели, задачи и методы. Можно что угодно говорить о религии, но истинные приверженцы — это те, кто старается понять то, во что они верят, помимо веры в то, о чем им говорят. Как и в случае с религией, нет единой общепринятой версии, которая подходит каждому.

Представьте, насколько большое значение имеет интерес к истокам своей религии, понимание событий и идей, которые образовали то, что впоследствии признали каноном. Когда речь заходит о профессиональной жизни, получается в точности то же самое. Делайте так же везде, где это того стоит: проповедуйте такой подход там, где имеете вес, восстановите первоначальную цель, цель, о которой вы и практически все, с кем вы когда-либо работали, мечтали, говорили и, вероятно, от которой в итоге отказались. Сделать достижимым успех в разработке программного обеспечения. Сделать достижимыми цели организации. Сделать процесс создания продукта лучше.