Хабр, привет! Мы российская компания EvaTeam и мы создаем ПО для управления разработкой. Тема первого поста возникла из нашей деятельности, но вот в чем штука — нельзя так просто сделать пост о методологиях разработки и не скатиться в холивар. И хотя материалов о методологиях хватает, о том откуда они произошли — не особо и пишут (видимо потому, что мы бежим только вперед и оглядываться назад некогда). Но если мы хотим получить представление о том, что будет дальше, полезно иногда возвращаться к истокам. Под катом мы пройдемся по эволюции методологий разработки за более чем три десятилетия, по истокам «гибкой» разработки и поразмыслим о том, как новейшие знания приведут нас ко все более быстрым циклам разработки (но это не точно).

История «гибких методов» начинается не с Agile-манифеста, как вы сперва могли подумать — ее корни уходят гораздо глубже. Некоторые прослеживают путь agile-методологии вплоть до формулировки научного метода Фрэнсисом Бэконом в 1620 году. Более же разумной отправной точкой могут быть 1930-е годы, когда физик и статистик Уолтер Шухарт из Bell Labs начал применять циклы «план - дело - исследование - действие» (PDSA) для улучшения продуктов и процессов. 

Шухарт обучил этой итеративной и инкрементальной методологии развития своего подопечного Уильяма Эдвардса Деминга, который широко использовал ее в Японии в годы после Второй мировой войны. Возрождающаяся тогда компания Toyota наняла Деминга для обучения сотен менеджеров компании и в конечном итоге использовала его опыт для разработки знаменитой производственной системы Toyota — основного источника сегодняшнего «бережливого» мышления. Но вернемся от производства собственно к разработке ПО.

«Другая» инженерия

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

Другая часть проблемы заключается в том, что разработка программного обеспечения — это одновременно наука и искусство, с несовершенствами и связанными с ними человеческими ограничениями.

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

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

Предпосылки возникновения гибкости

Иногда встречается мнение, что «гибкие подходы» появились как своеобразный ответ на методологии, разработанные в 70-х и 80-х годах, которые в свою очередь были ответом хаотичным и незапланированным подходам, которые часто использовались на заре появления программного обеспечения. Но это мнение ошибочно.

На самом деле, в 70-90-е годы появились основополагающие теории и практики программной инженерии. Главная идея заключалась в том, чтобы приравнять программную инженерию к физической инженерии и позаимствовать как можно больше из проектирования и строительства.

Этот подход проявился в том, что стало известно как методология Waterfall. Она четко определяла основные фазы жизненного цикла разработки приложений, от требований до развертывания. А «водопадом» методология была названа, потому что команды полностью завершали один этап, прежде чем переходить к следующему. Требования должны быть завершены до перехода к функциональному проектированию, функциональное проектирование завершено до детального проектирования, и так далее по порядку. И как вода не течет вверх по склону, редко есть возможность вернуться на более раннюю стадию процесса.

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

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

Методология Waterfall, как она был задумана изначально, должна была учитывать изменения и пересмотр проектных решений. Предусматривалась возможность вернуться к предыдущему этапу и скорректировать некоторые решения и ожидания, и эти изменения могли изменить аспекты текущего этапа. Но на практике графики и бюджеты почти всегда делали это невозможным, заставляя команды придерживаться ранее принятых решений.

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

Разные взгляды на разработку

Не всем пришлись по душе новые веяния. Главное противодействие было со стороны крупнейшего в мире (на тот момент) разработчика ПО — правительства США. В частности, стандарты Минобороны (DoD) по разработке софта, до конца 90-х годов отдавали предпочтение Waterfall. 

В конце концов, Минобороны даже разработало свой собственный язык программирования: Ada, названный в честь Ады Лавлейс, которую часто называют первым программистом. Хорошо структурированный язык, он, казалось, требовал сложного процесса с большим количеством документации. Для эпохи «водопадного» процесса это было идеально. Он идеально подходил для эпохи высоко документированного и спланированного водопадного процесса.

Но даже в 80-х и 90-х годах, когда Waterfall был распространен, ему пытались противостоять лидеры отрасли и академические мыслители. Как например Джеймс Мартин со своей быстрой разработкой приложений, или RAD. Целью RAD было сократить стадию подготовки и быстро приступить к разработке, чтобы бизнес мог сразу начать сотрудничать с командой разработчиков, увидев работающий прототип всего за несколько дней или недель. Также наблюдался переход к так называемой итеративной разработке, которая своими корнями уходит в 60-е годы и работы  

Уильяма Эдвардса Деминга (о котором писалось выше).

В 80-х годах появилось несколько книг и статей о методах итеративной разработки. Например автор книги «Мифический человеко-месяц», Фред Брукс в 1986 году написал статью «Нет серебряной пули - сущность и случайность в разработке программного обеспечения», в которой он отмечает, что не существует какой-либо единой техники или процесса, который обеспечит значительное повышение производительности разработки софта.

Вероятно, самой известной работой 80-х годов по итеративной разработке была работа Барри Боэма «Спиральная модель разработки и совершенствования программного обеспечения». Спиральная модель представляла собой специфическую итеративную технику, при которой проект начинается с малого и постепенно растет по мере того, как в него встраивается все больше функций и возможностей. 

Нужно больше итераций

В то же время разрабатывались и более конкретные итеративные методологии. Например, в начале 90-х годов, Джефф Сазерленд и Кен Швабер придумали процесс Scrum. Этот термин пришел из регби и обозначал команду, работающую над достижением общей цели. Они кодифицировали scrum в 1995 году, чтобы представить его на объектно-ориентированной конференции в Остине, штат Техас. Затем он был опубликован в виде документа под названием «Процесс разработки программного обеспечения SCRUM». Первоисточниками методологии Scrum послужила все та же производственная система компании Toyota.

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

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

Примерно в то же время Кент Бек (один из 17 авторов Agile-манифеста) был нанят в качестве консультанта в экспериментальный проект по разработке ПО в компании Chrysler. Со временем его назначили руководителем проекта, и в стремлении добиться успеха он решил довести лучшие практики до экстремального уровня, дав название методологии XP. Хотя проект был в конечном счете отменен после приобретения Chrysler, Бек опубликовал книгу под названием «Объяснение экстремального программирования», а его имя стало синонимом одной из ведущих альтернативных методологий. 

Кризис разработки приложений

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

Проблема заключалась в том, что даже 30 лет назад бизнес развивался быстро. В течение трех лет могли измениться требования, системы и даже весь бизнес. Это означало, что многие проекты отменялись на полпути, а многие из тех, что были завершены, не отвечали всем текущим потребностям бизнеса, даже если первоначальные цели проекта были достигнуты.

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

В качестве крайнего, но отнюдь не необычного примера можно привести программу Space Shuttle, запуск которой состоялся в 1982 году, в которой использовались информационные и вычислительные технологии 60-х годов. Сложные аппаратные и программные системы часто проектировались, разрабатывались и внедрялись в течение десятилетий.

Важно отметить, что в то время, программное обеспечение часто оставалось на втором плане, потому что его разработка не начиналась до тех пор, пока не был создан собственно сам проект аппаратного обеспечения (например те же телефонные коммутаторы, автомобили или самолеты).

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

Рождение Agile

Возможно, различные гибкие и итеративные методики все еще оставались бы в оппозиции Waterfall, если бы не встреча группы из 17 инженеров в 2001 года на горнолыжном курорте The Lodge at Snowbird. Назвав себя «Аджайл Альянс», эта группа согласилась с Манифестом гибкой разработки программного обеспечения, который потом стали называть просто Agile-манифестом. 

Неизвестный факт: еще до встречи в Snowbird, в 2000 году, «легкие» методологии обсуждались в Rogue River Lodge в Орегоне, куда Кент Бек пригласил адептов экстремального программирования. После этого мероприятия вышло несколько статей, в которых упоминалась категория «легких» или «легковесных» процессов, хотя никто из участников не был особенно удовлетворен таким описанием. И только после этого, появилась идея собраться на двухдневную пьянку(зачеркнуто) встречу, для более полного обсуждения этих процессов.

В эту группу входил вышеупомянутый Джон Керн, пионеры экстремального программирования Кент Бек и Уорд Каннингем, Ари ван Беннекум, Алистер Кокберн и еще двенадцать человек, хорошо известных сегодня в сообществе Agile. 

Само название «agile» предложил Майк Бидл. Вероятно, потому что ему нравилась книга «Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer» 1994. Ну а остальные согласились, что это название отражает адаптивность и готовность к изменениями, которые участники считали очень важными для их подхода.

Эти идейные лидеры искали способы быстро создать работающее ПО и передать его в руки конечных пользователей. Такой подход к быстрой доставке обеспечивал два весомых бонуса:

• Пользователи бы быстрее получали преимущества новых версий;

• А команда разработки в свою очередь получала бы быструю обратную связь о сфере применения и направлении развития ПО.

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

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

Основной инструмент гибкости

Отдельно хочется пройтись по софту для управления проектами, который является неотъемлемой частью «гибкой» разработки. За последние 10 лет такого софта появилось (и продолжает появляться) ну очень много. Можно сходу насчитать более 20 решений, каждое из которых обладает уникальным набором функций и преимуществ, которые могут вам подойти, в зависимости от того, какая у вас оргструктура в команде и над каким продуктом вы работаете.

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

Их связку Jira + Confluence можно сколько угодно ругать за тормознутость, неудобство и не особо дружелюбный интерфейс, но факт есть факт — эти продукты используются буквально везде и этим они хороши. К тому же их функционал подстраивается под самые популярные существующие методологии, что тоже неплохо. 

Печаль в том, что Atlassian, в этом году объявила о приостановке лицензий некоторых компаний и отмене их подписки, с без возможности восстановления. В таких условиях российские компании обращают внимание на альтернативные продукты со схожим функционалом. Сейчас таких решений несколько: Yandex Tracker, YouTrack, а совсем недавно их число пополнился и нашими продуктами, EvaProject как российский аналог jira, и EvaWiki как российский аналог Confluence, которые обеспечивают автоматическую миграцию всех данных из Jira и Confluence, с замещением всех функций и нашими фирменными улучшениями. О том, что нам пришлось пережить в процессе разработки — расскажем в следующих постах, а сейчас вернемся к теме поста.

Agile-эволюция

Первые последователи Agile-движения были в основном небольшими командами, которые были готовы идти вперед методом проб и ошибок. По мере того, как их подходы совершенствовались, а «гибкие» методы все больше использовались сообществом программистов, понятие «масштаб» вышло на первый план. Да, теперь разработчики могли создавать работающий код за короткие итерации, но когда дело доходило до тестирования и развертывания (не говоря уж о выпуске), фрагментированные процессы убивали всю идею гибкости — вылечить разрыв между бизнесом и программированием.

Постепенно появилась идея рассматривать весь жизненный цикл ПО как единый процесс, который можно автоматизировать, и тут появившийся в 2009 DevOps и его практики непрерывной интеграции (CI) и непрерывной доставки (CD) смогли предложить компаниям нечто большее чем изначальный Agile — способ по-настоящему реализовать цели, изложенные в Agile-манифесте, обеспечивая  за счет автоматизации на всех этапах, от сборки до тестирования и развертывания, систематический, воспроизводимый и более частый выпуск качественного софта для конечных пользователей. Вот тут, можно почитать про CI/CD подробнее.

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

Вполне вероятно, тогда «релиз» программного обеспечения со всеми его улучшениями перестанет быть событием, которое необходимо планировать, а станет просто ежечасным или ежеминутным явлением, как дыхание. Посмотрим. Во всяком случае кажется, что разработка ПО все более начинает походить на работу на «заводе», где производство не останавливается ни на секунду, а продукт пользователь получает моментально. Так что дедовское: «лучше бы ты погромист делом занялся и на завод пошел» имеет все шансы сбыться. А вы как думаете?