е, профессии или каким-то увлечениям. И это вполне нормально. В разное время у нас разные потребности. Но походы на работу не должны быть кошмаром, когда у нас есть профессия. Это просто еще кое-что, что доставляет нам удовольствие и развивает как личность. Профессия наполняет нашу жизнь смыслом.
Влияние мастерства на отрасль разработки
С 2008 года по всему миру растет число сообществ мастеров разработки ПО, организуются конференции, которые привлекают десятки тысяч разработчиков. В то время как в сообществах Agile больше внимания уделяется взаимодействию между людьми и процессу создания программного обеспечения, в сообществах мастеров больше внимания уделяется технической стороне вопроса. Они всегда были главными сторонниками экстремального программирования и многих других технических методов, распространяя их среди большого числа разработчиков и компаний во всем мире. Именно благодаря сообществам мастеров разработки ПО многие разработчики стали изучать разработку через тестирование, непрерывную интеграцию, парное программирование, простоту проектирования, рефакторинг, принципы SOLID и чистого кода. Они также учатся создавать программы на основе микросервисной архитектуры, автоматизировать конвейеры развертывания и переносить программы в облако.
Они изучают новые языки и парадигмы программирования. Они изучают новые технологии и новые способы тестирования и сопровождения своих продуктов. Разработчики в сообществе мастеров создают безопасные и дружелюбные пространства, где могут встретиться с единомышленниками и поговорить о профессии.
В сообществах мастеров разработки ПО найдется место каждому. С самого начала одной из главных целей мастеров разработки было собрать самых разных разработчиков, для того чтобы они могли учиться друг у друга и повышать профессиональную планку.
В сообществах мастеров признаются участники любого уровня технического развития, на встречах приветствуется любой разработчик, независимо от его опыта. Сообщество преданно относится к подготовке нового поколения профессионалов, организует различные мероприятия, где люди, которые присоединяются к отрасли разработки, могут изучить основные методы искусного создания ПО.
Влияние мастерства на компании
Мастерство разработки ПО получает все большее признание. Многие компании, которые перешли на Agile, теперь смотрят в сторону сообщества мастеров разработки, чтобы улучшить свои технические возможности. Однако мастерство разработки ПО не так привлекательно для бизнеса, как Agile. Экстремальное программирование для многих менеджеров — это часто то, что они не понимают или что вызывает у них тревогу. Руководство понимает Scrum, итерации, демонстрации, ретроспективы, сотрудничество и быструю обратную связь. Но им не особо интересны техники, связанные с программированием. Для большинства из них экстремальное программирование относится к написанию кода, а не к Agile.
В отличие от Agile-коучей начала 2000-х, у которых была хорошая техническая подготовка, большинство современных коучей не могут научить методам экстремального программирования или разговаривать с представителями бизнеса об инженерной стороне вопроса. Они не могут сесть рядом с разработчиком и программировать с ним в паре. Они не могут ничего рассказать о простоте проектирования или помочь с настройкой конвейера непрерывной интеграции. Они ничем не помогут разработчикам в рефакторинге уже написанного кода. Они не могут обсуждать стратегии тестирования и сопровождение нескольких сервисов в продакшене. Они не могут объяснить представителям бизнеса преимущества определенных технических методов, не говоря уже о каких-то технических стратегиях.
Но компаниям нужны надежные системы — системы, которые позволят им реагировать быстрее, исходя из своих деловых потребностей. Компаниям также нужны целеустремленные и способные технические команды, которые могут хорошо создавать и сопровождать ПО. И это как раз те области, в которых мастера разработки выгодно отличаются.
Мышление мастера разработки ПО — источник вдохновения для многих разработчиков. Оно дает им чувство цели, гордости и пробуждает врожденное стремление к совершенству. Большинство разработчиков, как и вообще люди, любят учиться и выполнять работу на совесть, просто им нужна поддержка и благополучное окружение. Компании, которые приняли идеи мастерства разработки, видят, как процветают сообщества мастеров внутри них. Разработчики организуют свои сессии, на которых вместе пишут код, практикуют разработку через тестирование и совершенствуют навыки проектирования. Им становится интересно изучать новые технологии и модернизировать системы, над которыми они работают. Они обсуждают, как лучше усовершенствовать базу кода и сократить технический долг. Мастерство разработки ПО поощряет культуру обучения, что делает компании прогрессивными и чуткими к изменениям.
Высшее мастерство и Agile
Некоторые из факторов, побуждающих создание движения мастеров разработки ПО, были связаны с разочарованием многих разработчиков от пути развития Agile. Из-за этого некоторые считали, что движение мастеров и Agile противоречили друг другу. Участники движения мастеров разработки ПО, которые также участвовали в движении Agile, критиковали Agile за слишком большое внимание к процессу разработки и нехватку внимания к инжинирингу. Участники движения Agile критиковали движение мастеров за слишком узкий подход и пренебрежение реальными деловыми и человеческими проблемами.
Хотя обе стороны выказывали некоторое беспокойство, большая часть разногласий была связана с племенными инстинктами и, собственно, с принципиальным расхождением мнений. В сущности, стремления обоих движений очень схожи. Оба движения стремятся к удовлетворенности клиентов, ценят тесное сотрудничество и быструю обратную связь. Они стремятся к выпуску продукта высокого качества, полезности выполняемой работы и профессионализму. Чтобы достичь большой гибкости в бизнесе, компаниям требуются не только сотрудничество и итеративный процесс, но и хорошие навыки инжиниринга. Сочетание Agile и философии мастеров разработки ПО — прекрасный способ ее достичь.
Заключение
На встрече в Сноуберде в 2001 году Кент Бек выразил мысль, что одна из задач Agile — построить мост над пропастью, разделяющей бизнес и разработчиков. К сожалению, когда менеджеры проекта наводнили сообщество Agile, разработчики, которые в первую очередь создали сообщество, почувствовали себя обездоленными и недооцененными. Таким образом, они ушли, чтобы основать движение мастеров разработки ПО. Выходит, что старые терки никуда не делись.
И как бы то ни было, цели обоих сообществ — 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, то не испытал особого восторга. У каскадной модели, возможно, есть свои проблемы, но в моей компании не тратили много времени на написание проектной документации. У меня, разработчика, в основном был такой порядок: мне в устной форме передавали, какой функционал нужен к следующему релизу, назначали дату выпуска релиза и отпускали на все четыре стороны колдовать. Это, конечно, могло приводить к лютому марафону на выживание, но зато я мог свободно выстраивать свои действия так, как хочу. Мне не нужно было часто давать отчеты и проводить анализ на ежедневных стендап-митингах, где пришлось бы объяснять, над чем я работал вчера и что я буду делать сегодня. Если я решал потратить неделю на изобретение колеса, мне в этом никто не мешал, никто не осуждал мой выбор, потому что все находились в блаженном неведении относительно того, чем я занимался.