Есть ли какие-то преимущества в гибких методах, помимо работающей сборки между спринтами?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третье преимущество заключается в том, что Agile проекты имеют тенденцию быть более мотивирующими. Людям очень тяжело иметь какое-то чувство драйва в годичном проекте. Крайний срок кажется таким далеким, и это отсутствие непосредственности означает, что люди склонны откладывать, чрезмерно полировать замыслы и в противном случае просто не работают очень продуктивно. Это особенно верно, потому что первые месяцы тратятся на то, что людям не нравится делать, например на специальные документы. Поскольку Agile всегда имеет очень непосредственные, конкретные сроки в ближайшем будущем, люди, как правило, более мотивированы. Гораздо сложнее откладывать с конкретным сроком для фиксированного набора задач на следующей неделе.

В ответ на цитату из вопроса, который является фундаментальным заблуждением анти-проворных противников

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

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

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

То же самое с YouTube, Twitter и множеством других компаний.

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

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

Скрам сам по себе не предписывает никаких технических приемов, потому что это общая структура.

Гибкая разработка программного обеспечения требует от команды технического совершенства. Это вытекает из следующих технических приемов из XP (экстремальное программирование). Например, вы должны узнать о рефакторинге, tdd, всей команде, парном программировании, инкрементальном дизайне, ci, совместной работе и т. Д.

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

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

Для меня главное преимущество agile - это снижение рисков в проекте.

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

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

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

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

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

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

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

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