Agile история: Как появился Agile. Часть 1. Предтечи — статья в блоге ScrumTrek

История создания Agile-манифеста — Дмитрий Блинов на vc.ru

11–13 февраля 2021 исполнилось 20 лет Манифесту Agile-разработки ПО. Давайте вспомним, какие подходы существовали до него, почему возникла потребность в таком манифесте, как он создавался, кто в этом участвовал, как появился термин «agile», и что думают авторы о полученном результате.

3053 просмотров

Что было до Agile-манифеста

Уже существовали итеративные подходы.

• Наример, был RUP. Кстати, он использует UML, настраивается под нужды и не требует использования всего-всего, что в нем описано.
• Был и Скрам, о котором Кен и Джефф рассказали в 1995 на конференции OOPSLA. А вот первая книга по Скраму «Agile Software Development with Scrum» вышла только в октябре 2001, а первая версия Scrum Guide только в 2010. При переводе книги «Agile project management with Scrum», с одной стороны, ее старались адаптировать к текущей версии Руководства по Скраму (тогда это была версия 2017 года), а с другой, не сильно отступать от оригинала, поэтому, читая ее, понимаешь, что в 2004 и Скрам был другим.
• Первый проект по XP стартовал в 1996, а оформился подход в 1999. Тогда же и TDD.
• Ещё были менее популярные сейчас Crystal c 1994 года и FDD c 1997.
  
• Уже давно существовал Lean manufacturing 1988-1996 (а TPS сильно раньше), а вот Lean software development появился позднее в 2003 в одноименной книге.

Встреча в 2000 в Орегоне

Весной 2000 Kent Beck (один из авторов eXtreme Programming и TDD) на встречу с названием «Extreme Programming Leadership Conference» в The Rogue River Lodge недалеко от города Медфорд в штате Орегон пригласил:

• активных практиков XP, включая (Uncle) Bob Martin, Ron Jeffries, Martin Fowler, Ken Auer,
• других заинтересованных, в частности, Alistair Cockburn, Jim Highsmith, «Pragmatic» Dave Thomas.

На встрече в числе других вопросов обсуждали:

• связь между XP и другими методами, которые в то время называли Lightweight Methods,
  
• и создание организации для их продвижения и поддержки.
  

Идея была холодно поддержана некоторыми участниками. Поэтому (Uncle) Bob Martin и Martin Fowler в перерыве договорились организовать встречу с представителями более широкого круга методов, включая Scrum и Crystal.

2. Встреча в 2001 в Юте

Организация встречи

Bob Martin и Martin Fowler составили предварительный список. Примерно в то же время Alistair Cockburn собирал похожую встречу. Два списка объединили, да и вообще постарались собрать всех активных, кому может быть интересно. Рабочим названием встречи стало «Lightweight Methods Summit», а в качестве цели в приглашении указали:

Создание манифеста, описывающего общие характеристики легковесных подходов.

Организацию логистики подхватил Alistair Cockburn. Он предложил встретиться недалеко от Солт-Лейк-Сити в штате Юта. Вместе с Jim Highsmith они организовали проживание, питание и активности.

Кто-то из ~20 приглашённых приехать не смог, например, Grady Booch (один из авторов языка UML) и «Big Dave» Thomas (тёзка другого Дейва — «Pragmatic Dave» Thomas, который приехать смог).

The Lodge at Snowbird

11–13 февраля 2001 года 17 «умников» экспертов-практиков разработки ПО собрались в кондоминиуме The Lodge горнолыжного курорта Snowbird в горах Уосатч в штате Юта — это в западной части континентальных США недалеко от Солт-Лейк Cити.

Каждый практиковал какую-то альтернативу тяжеловесным процессам, основанным на документации. Они собрались, чтобы поговорить, покататься на лыжах, отдохнуть и найти то общее, что объединяет их процессы/методы, которые в то время уже называли lightweight (легковесными).

Авторы Манифеста Agile-разработки ПО и их сферы интересов

• eXtreme Programming, TDD,
• Scrum,
• DSDM — Dynamic Systems Development Method,
• RAD — Rapid Application Development,
• Adaptive Software Development,
  
• Семейство Crystal, включая Clear,
  
• FDD — Feature-Driven Development,
  
• Pragmatic Programming, и другие.
  

Авторы Манифеста Agile-разработки ПО С просторов интернета

Сама встреча

Встречу начал Боб Мартин, поделившись своим взглядом на общие моменты в существующих легковесных процессах, и предложил цель — зафиксировать эти общие характеристики во благо всей отрасли для создания полезного ПО. Далее фасилитировать встречу стали Martin Fowler & Ward Cunningham. Кстати, знаменитую фотографию, выложенную на странице Манифеста, сделал именно Уорд.

The Lodge at Snowbird. Создание Agile Manifesto

Ожидания от встречи у всех были разными, но не завышенными.

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

Alistair Cockburn, Crystal family, Use cases

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

Однако мы быстро нашли много общего.

Martin Fowler, XP, UML, Patterns

«Дядя Боб» Мартин впоследствии охарактеризовал их так:

• Группа людей с набором близких ценностей, основанных на взаимном доверии и уважении;
• способствуют развитию организационных моделей, основанных на людях и сотрудничестве;
• выстраивают такие виды организационных сообществ, в которых хочется работать;
• создают хорошие продукты для клиентов в среде, где не просто говорят о «людях, как самом ценном ресурсе», но своим поведением показывают, что люди критически важны. И без слова «ресурс».

О чём договорились?

Договорились о многих аспектах разработки ПО, и поэтому решили оформить этот общий базис в виде боевого клича для всей отрасли. Хотели показать, что отстаивают и чему сопротивляются.

Вообще-то, это я и Мартин Фаулер, рисуя на доске во время обеда, сформулировали первые 3 сравнения. Группа расширила их до 5, а затем сократила до 4.

«PragDave» Thomas

The Lodge at Snowbird. Создание Agile Manifesto

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

Jim Highsmith, Adaptive software development

Группа оформила зафиксированные 4 ценности в виде «Манифеста Agile-разработки ПО».

Надеюсь, что Манифест прояснит, что является и не является agile.

Martin Fowler, XP, UML, Patterns

Почему именно «Манифест»? Почему именно «Agile»? Читайте в статье «Почему Agile так называется?»

Черновик 12 принципов группа записала во второй части встречи.

Заметки Анди Ханта на встрече в 2001 Andrew Hunt, AgileUprising

Группа назвала себя «The Agile Alliance».

После Юты

После встречи группа ещё пару месяцев дорабатывала формулировки 12 принципов. Ward Cunningham (изобретатель технологии wiki) позднее создал страницу AgileManifesto.org.

Почти все авторы снова встретились в октябре 2001 на конференции OOPSLA, где объявили, что не хотят какой-то выделенной роли в распространении ценностей и принципов Agile-разработки, и это могут делать не только они.

В конце 2001 они организовали НКО Agile Alliance для развития Agile-методов.

Итоговые впечатления

Я очень доволен результатом.

Martin Fowler, 2006

Думаю, я никогда не участвовал во встрече, на которой группа так сохраняла фокус и достигла целей с лёгкостью и минимумом конфликтов.

Uncle Bob Martin, 2007

Лично я в восторге от итоговой формулировки Манифеста.

Я был удивлён, что и другие так же довольны итоговыми фразами. Так что, мы всё же договорились о чём-то значительном.

Alistair Cockburn, 2001

Что сейчас

Были попытки докрутить манифест 2001 года, и есть несколько вариаций от других авторов, но сам оригинал остался неизменным.

Статистика применения Agile-подходов собирается по большей части с компаний, их использующих: «по результатам онлайн-опроса 100% россиян пользуются интернетом». Поэтому скажу из своего опыта работы с ИТ-компаниями. С каждым годом Манифест выглядит всё менее революционным:

• бизнес-участники работают рядом с техническими спецами,
• всё меньше кабинетов и больше open spaces,
  
• всё меньше проектных матриц и больше стабильных команд.

Участники тренингов, знакомясь с Манифестом, отвечают: «Ну, так это логично. У нас почти так и есть.» И это хорошо! Значит, движемся в хорошем направлении: от формализма и бюрократии к людям и крутым продуктам!

Все причастные к этому движению,

с 20-летием Agile-манифеста вас!

Если интересно, то ещё можете прочитать:

• Как правильно произносить: эджАйл или Эджл? И как переводится?
  
• Почему Agile так называется? Были другие варианты? (Спойлер: да, были. )
  
• Что привело к необходимости появления «Манифеста Agile-разработки ПО»?
• Что такое Agile? И вообще, корректен ли такой вопрос?
• Ответы на вопрос «Что такое Agile?» в разных источника Сети

Использованные источники:

1. Видео-лекция 2016 Robert «Uncle Bob» Martin с хронологией развития программирования «The Future of Programming».
2. Заметки 2001 Jim Highsmith сразу после встречи на курорте Snowbird — важная страница на сайте AgileManifesto.org.
   
3. Заметки 2001–2006 Martin Fowler о создании Манифеста «Writing The Agile Manifesto».
   
4. Заметки 2007 Роберта «Дяди Боба» Мартина «The Founding of the Agile Alliance».
   

30 лет гибкой разработки — краткая история и к чему нас это ведет / Хабр

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

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

Уолтер ШухартУильям Эдвардс Деминг

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

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

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

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

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

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

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

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

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

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

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

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

Методология 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-х годов. Сложные аппаратные и программные системы часто проектировались, разрабатывались и внедрялись в течение десятилетий.

Еще один пример — широко используемый сейчас лайнер Boening 747, был разработан 60(!) лет назад.

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

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

Рождение Agile

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

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

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

17 авторов манифеста

Само название «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 лет.

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

Краткая история гибкой методологии

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

Исаак Саколик

пишущий редактор, Информационный мир |

Thinkstock Содержание

• До Agile: методология водопада
• Поворот к гибким методам
• Почему гибкая разработка обеспечивает лучшее программное обеспечение

Показать больше

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

Но что такое agile и как разработчики и организации внедряют agile-методологии? Эта статья представляет собой краткую историю гибкой разработки и того, чем она отличается от классической методологии водопада. Я расскажу о различиях между гибкими и каскадными методами на практике и объясню, почему agile гораздо лучше подходит для того, как на самом деле работают разработчики и команды, особенно в современных средах разработки.

До Agile: методология водопада

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

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

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

Методология водопада на практике

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

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

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

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

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

Плюсы и минусы водопадной методологии

Изобретенная в 1970 году, водопадная методология была революционной, поскольку привносила дисциплину в разработку программного обеспечения и обеспечивала наличие четкой спецификации, которой нужно следовать. Он был основан на методе производства водопада, заимствованном из 19-го века Генри Форда. 13 инноваций сборочной линии, которые обеспечили уверенность в каждом шаге производственного процесса. Метод водопада был предназначен для обеспечения того, чтобы конечный продукт соответствовал тому, что было указано в первую очередь.

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

Переход к гибким методам

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

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

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

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

В 2001 году группа опытных разработчиков программного обеспечения осознала, что они коллективно практикуют разработку программного обеспечения, отличную от классической методологии водопада. Не все из них были в стартапах. Эта группа, в которую входили светила технологий Кент Бек, Мартин Фаулер, Рон Джеффрис, Кен Швабер и Джефф Сазерленд, разработала Agile-манифест, в котором задокументированы их общие взгляды на то, как должен работать современный процесс разработки программного обеспечения. Они делали акцент на сотрудничестве, а не на документации, на самоорганизации, а не на жестких методах управления, и на способности управлять постоянными изменениями, а не на жестком водопадном процессе разработки.

Из этих принципов родилась гибкая методология разработки программного обеспечения.

Почему гибкая разработка обеспечивает более качественное программное обеспечение

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

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

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

Гибкая разработка также способствует постоянному совершенствованию. Представьте, если бы Microsoft прекратила разработку Windows после версии 3.1 или Google прекратила улучшать свои поисковые алгоритмы в 2002 году. Программное обеспечение постоянно нуждается в обновлении, поддержке и улучшении; гибкая методология устанавливает как мышление, так и процесс для этого постоянного улучшения.

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

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

Связанный:

• Разработка программного обеспечения
• Гибкая разработка

Copyright © 2022 IDG Communications, Inc.

Как выбрать платформу разработки с низким кодом

История Agile | Планирование LeanKit

Содержание

Содержание

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

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

Но как мы сюда попали? Что влечет за собой история Agile? И как знание истории Agile может помочь нам лучше понять методологию и ее положительное влияние на сегодняшний мир разработки? Давайте взглянем.

Усиление и расширение Agile Team Success

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

Прочитать технический документ • Усилить и расширить успех Agile-команды

Бесплатная пробная версия AgilePlace: программное обеспечение AgilePlace Online Kanban

Подпишитесь на 30-дневную бесплатную пробную версию, и вы и ваша команда сможете начать создавать онлайн-доски Kanban уже сегодня. Убедитесь сами, как AgilePlace поддерживает инициативы непрерывной доставки, устраняет потери и улучшает процессы и скорость доставки вашей команды.

Начните бесплатную пробную версию • Бесплатная пробная версия AgilePlace

Решение серьезной проблемы: внутри ранней истории Agile

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

Представьте, если бы вам пришлось годами ждать решения ключевых проблем, с которыми сталкивается ваш бизнес. Менее 30 лет назад такое время ожидания было нормой. И мы можем проследить самые ранние корни в истории Agile до этой проблемы.

До появления Agile команды разработчиков (особенно в области программного обеспечения, производства, аэрокосмической и оборонной промышленности) выявляли проблемы и планировали решение. Затем они будут разрабатывать это решение и полностью выводить его на рынок. В частности, большинство команд использовали каскадный подход, методологию разработки, которая следует заданному пути, по которому команды:

• Устанавливают проектные требования и объем работ
• Разрабатывают продукт на основе этих заранее определенных требований
• Создать продукт
• Протестировать продукт
• Устранить все проблемы, обнаруженные во время тестирования
• Запустить готовый продукт

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

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

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

Изменения происходят: история Agile обретает форму

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

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

Наконец, в начале 2000-х история Agile и будущее разработки изменились навсегда.

Все началось весной 2000 года, когда группа из 17 разработчиков программного обеспечения, включая Мартина Фаулера, Джима Хайсмита, Джона Керна, Джеффа Сазерленда, Кена Швабера и Боба Мартина, встретилась в Орегоне, чтобы обсудить, как они могут ускорить время разработки. для того, чтобы быстрее вывести новое программное обеспечение на рынок. Они признали две ключевые возможности, которые сделают возможным достижение этой цели:

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

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

Рождение манифеста: Agile становится в центре внимания

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

В течение трех дней группа подготовила «Манифест гибкой разработки программного обеспечения» (более известный как Agile-манифест). Настоящий поворотный момент в истории Agile, этот манифест изложил четыре ключевые ценности:

1. Люди и взаимодействие важнее процессов и инструментов
2. Рабочее программное обеспечение важнее исчерпывающей документации
3. Сотрудничество с клиентами важнее переговоров по контракту
4. Реагирование на изменения важнее следования плану

Эти четыре основных принципа составляют Манифест Agile.

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

• Удовлетворение клиентов за счет ранней и непрерывной поставки ценного программного обеспечения
• Приветствие меняющихся требований в любой момент цикла поставки
• Частое предоставление программного обеспечения за счет более коротких сроков разработки
• Использование работающего программного обеспечения в качестве основного показателя прогресса
• Использование регулярных моментов саморефлексии для выявления возможностей для улучшения

Эти четыре ценности и 12 принципов продолжают определять методологию Agile, используемую командами сегодня.

Представляем миру новый метод: следующая глава в истории Agile

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

Agile становится мейнстримом

Чтобы помочь распространить информацию о Agile Manifesto, отцы-основатели в истории Agile решили создать более постоянную организацию, и так родился Agile Alliance. Agile Alliance — это некоммерческая организация, которая существует до сих пор. Цель организации — делиться информацией об Agile, предоставлять ресурсы командам, желающим внедрить методологию Agile, и продолжать развивать подход для удовлетворения меняющихся потребностей.

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

По мере того, как Agile набирала обороты, роль Agile Alliance росла. В 2003 году ставший уже официальным Agile Alliance вернулся в Юту на первую ежегодную конференцию по Agile — важную веху в истории Agile. Группа описала это мероприятие как «посвященное продвижению принципов Agile и созданию площадки для процветания людей и идей». Эта ежегодная конференция под названием Agile 20XX продолжается и по сей день.

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

Agile набирает обороты

В то время как Agile набирает обороты в начале 2000-х, мы увидели, что Agile Manifesto набирает обороты в 2010-х.

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

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

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

Что будет дальше в Agile? Подготовка к 2020-м годам

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

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

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

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

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

Это свидетельство тех первых встреч группы из 17 разработчиков программного обеспечения в 2000 и 2001 годах, которые сформировали историю Agile, что почти два десятилетия спустя все виды команд разработчиков (а теперь и тестировщиков) продолжают придерживаться основных принципов Agile. Agile-манифест. Со временем Agile развивался, чтобы соответствовать меняющимся потребностям, но по-прежнему остается верным первоначальному манифесту. Конечно, мы не ожидали бы ничего меньшего от манифеста, основанного на идее, что командам нужна возможность развивать свой подход в любое время, чтобы лучше соответствовать меняющимся потребностям.

Мы еще не готовы закрыть книгу по истории Agile

Что ждет методологию Agile в следующем десятилетии и далее?

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