У всего хорошего есть и плохое. Почему разработка программного обеспечения по методике Agile не решит все ваши проблемы.
Перевод статьи "The Massive Downside of Agile Software Development", источник тут и тут (полная версия).
Disclaimer
Данной статьей автор начинает цикл статей о недостатках Agile и почему его следует ограничить в применении.
Когда дело доходит до разработки программного обеспечения, все ищут беспроигрышную методологию как для поставщиков, так и для клиентов. В конце концов, в ближайшее время разработка программного обеспечения никуда не исчезнет. Разработка программного обеспечения по методологии Agile - это новейшая методология создания качественного, кастомизированного программного обеспечения за меньшее время. Хотя она и делает проект менее громоздким и более прозрачным, у нее имеются серьезные недостатки.
Чем является разработка программного обеспечения по Agile?
Эта методология была впервые представлена в 2001 году, когда 17 человек собрались на горнолыжном курорте Snowbird в штате Юта и создали с «Agile Манифест». В нем изложены 12 важнейших принципов разработки ПО. Они включают в себя общение, сотрудничество, открытость, гибкость и важность программного обеспечения. Аgile - это разновидность постепенной разработки программного обеспечения, которая проходит быстрыми циклами - во многом как бег на короткую дистанцию.
Результатом являются небольшие выпуски программного продукта, каждый из которых основан на предыдущем продукте. В идеале команды совершают больше выполненной работы за меньшее время. Оказалось, что этот метод лучше всего подходит для критичных по времени выполнения приложений, причем заказчик является доступным и готов общаться на протяжении всего жизненного цикла разработки. Для этого метода нужна приспосабливающаяся команда, готовая реагировать и вносить изменения на основе тестов и обзоров продуктов.
Преимущества Agile
Плюсы разработки по agile убедительны. Вот несколько причин, по которым многие применяют эти принципы:
Увеличение доходов компании за счет выпуска в производство некоторых преимуществ поэтапно, а вы тем временем продолжаете разрабатывать продукт.
Продукты поступают на рынок быстрее, выпускаются раньше и регулярно, и клиенты быстрее возвращают свои инвестиции.
Гарантия качества с интегрированным тестированием и регулярными проверками работающего продукта на протяжении всей разработки.
Лучшая прозрачность для основных заинтересованных сторон, поскольку гибкая разработка программного обеспечения поощряет участие пользователей в совместных усилиях.
Снижение риска, поскольку команда выявляет и исправляет любые проблемы на раннем этапе.
Компромиссы Agile
С преимуществами гибкой разработки программного обеспечения приходят и ряд недостатков. С гибкой разработке программного обеспечения легко потерять чувство равновесия. Брайан Лоули, генеральный директор 280 Group так говорит об Agile:
В разработке программного обеспечения не существует панацеи или бесплатного обеда. Если вы хотите применять гибкие принципы, вы должны быть уверены, что руководство продукта и команда проекта все понимают требования. Они также должны осознавать как потребности могут быстро превратиться в огромные подводные камни.
Требования и недостатки гибких методологий.
Вот 5 главных недостатков гибкой разработки программного обеспечения:
1. Меньшая предсказуемость.
Для некоторых программных продуктов разработчики не могут количественно оценить полный объем необходимых усилий. Это особенно верно в начале жизненного цикла разработки крупных продуктов. Команды, для готорых гибкая методология является новой, опасаются этих неизвестных. Этот страх вызывает разочарование, плохие практики и зачастую ведёт к неправильным решениям. Более систематизированный каскадный процесс (waterfall) упрощает количественную оценку усилий, времени и затрат на поставку конечного продукта.
2. Больше времени и обязательств.
Тестировщики, заказчики и разработчики должны постоянно взаимодействовать друг с другом. Это включает в себя многочисленные личные беседы, поскольку они являются лучшей формой общения. Все участники проекта должны тесно сотрудничать. Ежедневные пользователи должны быть доступны для незамедлительного тестирования и подписания на каждом этапе, чтобы разработчики могли отметить его как завершенный, прежде чем переходить к следующей функции. Такой подход может гарантировать что продукт соответствует ожиданиям пользователей; однако он является обременительным и требует много времени.
3. Повышенные требования к разработчикам и заказчикам.
Принципы Agile требуют тесного сотрудничества и активной вовлеченности пользователей. Несмотря на то, что Agile это увлекательная и полезная система, она требует больших обязательств для достижения успеха в рамках всего проекта. Клиенты должны пройти обучение, чтобы помочь в разработке продукта. Любое отсутствие участия клиента повлияет на качество и успех программного обеспечения. Это также плохо отражается на компании-разработчике.
4. Отсутствие необходимой документации.
Поскольку требования к программному обеспечению уточняются как раз к моменту разработки, документация становится менее подробной. Это означает, что когда новые участники присоединяются к команде, они не знают подробностей об определенных функциях или о том, как им нужно работать. Это создает недопонимание и трудности.
5. Проект легко сбивается с пути
Этот метод требует очень небольшого планирования для начала работы и предполагает что потребности потребителя постоянно меняются. Со столь небольшими требованиями для продолжения, легко видеть как это может ограничить agile модель. Далее, если пользователь не совсем ясен в своих отзывах или сообщениях, разработчик может сосредоточиться на неправильных областях разработки. У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.
Самые распространенные ошибки новых команд Agile-разработки
Гибкая разработка также имеет тенденцию открывать ворота для большего количества ошибок. Вот некоторые из наиболее распространенных:
Плохая структура команды
Недостаток полномочий команды
Плохое планирование
Неэффективное тестирование
Игнорирование отзывов клиентов
Не обращается внимание на сопротивление пользователей
Когда гибких методологий следует избегать
Многие команды путают гибкую разработку программного обеспечения со способом более быстрой поставки ПО. Гибкая разработка программного обеспечения имитирует повседневные действия, разбивая работу на спринты и составляя пользовательские истории. Однако им (командам) не удается полностью посвятить себя гибкой разработке. Поэтому, хотя они говорят, что они «делают по Agile», по факту они придерживаются традиционной ментальности, которая работала в прошлом.
Этот метод невыгоден, когда клиент должен работать по определенному бюджету или графику. Вы также должны избегать Agile, когда клиенты не могут изменить масштаб проекта после его запуска.
Комментарии (33)
rsashka
27.09.2021 18:57Если Аджайл плохо работает, значит сами виноваты и у вас не правильный Аджайл.
Аджайл, это комбинация фундаментальной ошибка научного метода (если метод хорошо работает, то он должен хорошо работать всегда и везде) и системной ошибки выжившего (обоснование доказательства работы метода только по подтверждающим результатам и игнорирование отрицательных / противоположных фактов).
К сожалению, в Аджайл совсем не работатет Fix Time/Fix Price. Он поощряет продуктовый экстремизм со стороны заказчиков, поощряет тяп-ляп (низкое качество из-за ожидания частых изменений) и работает только для универсальных команд (без разделения общих ресурсов).
А вот большинство перечисленных в статье проблем к Аджайлу отношения не имеют и могут встречаться в любых проектах не зависимо от методологии.
kantocoder Автор
27.09.2021 21:27+1Аджайл, это комбинация фундаментальной ошибка научного метода (если метод хорошо работает, то он должен хорошо работать всегда и везде) и системной ошибки выжившего (обоснование доказательства работы метода только по подтверждающим результатам и игнорирование отрицательных / противоположных фактов).
Это скорее к тем, кто его везде пихает.
Он поощряет продуктовый экстремизм со стороны заказчиков, поощряет тяп-ляп (низкое качество из-за ожидания частых изменений) и работает только для универсальных команд (без разделения общих ресурсов).
В точку. А теперь вопрос: а в каких компаниях распространены универсальные команды и почему? Может быть, универсальная команда -- признак "галеры", и их делают универсальными исходя из принципа "незаменимых людей быть не должно"? Как Вы считаете?
А вот большинство перечисленных в статье проблем к Аджайлу отношения не имеют и могут встречаться в любых проектах не зависимо от методологии.
С какими из них Вы встречались в Waterfall'е?
K0styan
27.09.2021 19:10+4Камон. Который раз одно и то же. Agile - это не та штука, которую надо выбирать. Если вы решаете, нужен он или нет, глядя на списки достоинств или недостатков - вы уже делаете что-то не так.
Всё гораздо проще. Agile работает, если у вас часто меняются требования. Более того, если требования меняются достаточно интенсивно - это единственный способ получить на выходе то, что им хоть как-то соответствует.
А динамика требований зависит прежде всего от рынка, на котором вы работаете. Если среда конкурентная и на арене есть пара шустрых игроков - выбора нет, придётся подстраиваться. Если вы в стартапе и важно нащупать то, что хотят пользователи, пока не проедены деньги - тоже выбора нет. Есть ещё тыщи примеров того, как требования могут быть очень динамичными - и не меньше того, как они могут быть спокойно зафиксированы на весь срок реализации.
Вот правильный ответ на вопрос, в первой вы группе или во второй, и скажет заодно, годится ли вам Agile.
themen2
27.09.2021 21:13Все равно нужно изначально сделать хоть какой то анализ продукта - что должно быть, сделать изначальное ТЗ хотя бы на 50% от всех фич, какой то обозримый mvp. Просто чтобы начав его делать - закончить! А не утонуть в постоянных изменениях требований к продукту по каждому чиху - а давайте это добавим и это. Так никогда и не закончишь mvp. Это морально выматывает, сам с таким столкнулся
kantocoder Автор
27.09.2021 21:32+1А не утонуть в постоянных изменениях требований к продукту по каждому чиху - а давайте это добавим и это. Так никогда и не закончишь mvp. Это морально выматывает, сам с таким столкнулся
И я тоже. А автор статьи так и пишет: "It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one." (что я перевел как "У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.")
K0styan
28.09.2021 11:29Бывает, что постоянные изменения объективны - вот как этим летом с QR-кодами для доступа в публичные места было: я их только в свой продукт включил, как тут свалилась их отмена. Но это действительно форс-мажор.
Обычно всё же изменения более редки и дают хотя бы какой-то осмысленный кусок работы сделать, будь то MVP или просто развитие продукта. Если это не так, если кто-то постоянно накидывает фичи - это как правило опять же признак того, что управление требованиями не кореллирует с потребностями рынка.
kantocoder Автор
27.09.2021 21:36-1Фактически, Вы написали что его нельзя пихать везде и всюду, а у нас его именно везде и всюду и пихают. Поскольку почти вся инфраструктура сейчас зиждется на IT, лично я в этом вижу угрозу нашей национальной безопасности. Как пример, Вы согласитесь лететь на самолете, который проектировали и собирали по Agile?
Debosher
27.09.2021 21:53С радостью. Я бы посоветовал вам прочесть книгу Мартина Роберта "Чистый Agile", там много говорится о тех вещах, которые вы описали в статье, там же объясняется, почему научный подход плохо применим к разработке, хотя автор и делает примечание о том, кому Agile не подойдёт.
kantocoder Автор
27.09.2021 21:55+2Ну, Вы смелый человек. Лично я в такой самолет не сяду. С другой стороны Илон Маск ракеты в космос запускает, а в SpaceX по agile работают, если не знали: https://cliffberg.medium.com/spacexs-use-of-agile-methods-c63042178a33
themen2
27.09.2021 22:18Вроде как Илон известен тем, что просит чтобы подчинённые очень много работали. Если почитать на Glassdoor отзывы от работе в его компаниях, то люди пишут, что там плохо соблюдается баланс работы/личной жизни. То есть он требует максимальной вовлечённости в работу. Ну, при таком подходе, если его принимают люди , по какой методике не работай, все равно будет результат, так как даже после работы будешь думать все равно о ней)
kantocoder Автор
27.09.2021 22:33+1Ну, закономерно: результат ничто, процесс -- всё! Типично для agile.
ignat99
28.09.2021 02:44Этот принцип повсеместно в Азии встречается. Этот принцип первое что меня удивило в корейском отделении Самсунг Электроникс в Гуми в 2004 году.
Вторая удивительная традиция - спать на клавиатуре после игры в компьютерную стратегию на рабочем месте.
K0styan
28.09.2021 11:25Так потому и пихают, что опираются не на объективные потребности, которые вот, внутри, у них же перед глазами, а смотрят на статьи с абстрактными списками преимуществ и недостатков.
GraDea
Все недостатки показались странными:
Вне аджайла тоже не очень с прогнозированием.
Лучше взаимодействовать, чем закрыться в подвале и через полгода выкатить бесполезный продукт.
Все так, не выходит писать тз и перекидывать его через забор. Получается как во втором пункте.
Все равно лучше, чем наоборот: документации как у дурака махорки, а на проде только развернутый nginx.
Это не подход предполагает, что требования меняются. К сожалению, это наша реальность. Подход просто заточен под эту реальность.
kantocoder Автор
Они не странные, они жизненные.
Методология разработки либо поощряет прогнозирование, либо нет. В случает Waterfall необходимо думать наперёд (то есть осуществлять стратегическое планирование), а в Agile - нет. Если нет стратегического планирования, то нет и продуманной архитектуры, а если нет продуманной архитектуры, то в конечном итоге программный продукт хорошим не станет. По крайней мере, более-менее сложный программный продукт
При работе по Waterfall тоже взаимодействуешь с заказчиком, просто нет так интенсивно как в Аgile
ТЗ формализует процесс разработки, оно необходимо
Не лучше. Я лично столкнулся именно с той ситуацией, что описана в этом пункте: пришел в стартап который работал над ПО, сорцы документированы не были, разобраться в них было очень трудно и приходилось дергать разработчиков что уже были "в теме". А это время. А сами сорцы, кстати, представляли жуткий пример техдолга. Но "работающий софт важнее исчерпывающей документации", несомненно; проблема в том что без документации а) перестаешь понимать как он работает, б) софт становится невозможно развивать дальше.
Реальность то, о чем договорились в контракте с заказчиком. А что он требования постоянно меняет, так пусть сначала определиться с тем, что хочет, потом заключает контракт
sshmakov
В случае с Waterfall спрогнозировать трудозатраты на новую разработку возможно только получения детального ТЗ. А время на подготовку ТЗ плохо прогнозируется для нового продукта.
themen2
Почему плохо прогнозируется? Можно начать с mvp. Описать текстом тупо фичи, которые хотим, интерфейс написовать, хотя бы "на квадратах". Вы рать стек для этого, описать базовую архитектуру mvp(которую потом сктати можно и переписать, если проект пойдет). И уже более менее понятно что надо сделать и сколько это займет времени. Главное сильно не менять требования, так как нужно сделать хотя бы первую версию продукта. Затем можно сделать какую то ретроспективу , посмотреть чего не хватает, куда двигаться дальше , да и вообще стоит ли двигаться, вдруг mvp версией пользуется 2 человека и оно тупо не надо
sshmakov
Не, вы давайте прогноз, точный, на полную разработку, от идеи до полноценного приложения. Чё это квадратики подсовываете?
Требования менять? Чего ради? Заказчик уверен в том, что ему надо. Он же вам на встрече рассказал, вы плохо слушали что-ли?
Так что давайте завтра присылайте ТКП с точной суммой и сроками.
Вы ведь профессионал?
kantocoder Автор
Как раз возможно и без детального ТЗ. Любой разработчик с опытом от 2 лет сможет сказать сколько приблизительно у него займет выполнение работы по ТЗ, даже если ТЗ и неполное. Оценка трудоемкости ТЗ -- одна из обязанностей разработчика, и если в компании разработчики не способны это сделать, то увы этой компании. Возможно она вообще не должна заниматься IT бизнесом.
sshmakov
Сможет. Правда, ошибётся не менее, чем в 2.5 раза в меньшую сторону. И то, только если задача знакомая.
kantocoder Автор
Ну так пусть получит столько денег, на сколько оценил свою работу. В следующий раз не ошибется. Такое вот обучение с подкреплением.
sshmakov
Он-то, возможно, поумнеет. А заказчик, который рассчитывал по этой оценке на короткий срок, тем временем вылетит с рынка и разорится.
kantocoder Автор
Ну если заказчик не умеет правильно оценивать риски, может ему и не место в IT? Кроме того, заказчик может заложить в контракте с исполнителем неустойку, что переложит риски на плечи исполнителя.
sshmakov
Заказчик и не в IT. А риски, которые несёт заказчик, несоразмерны с затратами на разработку, поэтому ни одна фирма-разработчик их принимать на себя не будет.
themen2
Ещё проблема есть - по старым задачам могут уточняться требования и поэтому их надо постоянно доделывать, наряду с новыми. Возникает ощущение бесконечности задач. Вроде ты сделал задачу, морально получил удовлетворение, что она закончена. А потом окажется, что не совсем закончена и надо доделывать снова и снова.
kantocoder Автор
И каков конечный результат такой деятельности?
themen2
Отказывались в итоге от коротких спринтов, просто в бэклог задачи клали и делали по тихоньку)
kantocoder Автор
А конечный продукт нормальный получился, без техдолга, в том или ином виде? Или его до сих пор не закончили?
themen2
Один продукт уже был до внедрения. Он есть и развивается. Просто отказались по сути от agile там. Там так сейчас - есть бизнес требование - задача в джире, примерные сроки, результат. Задачи копятся в беклоге и сортируются по приоритетам.
Второй продукт - стартап. Вот он фактически утонул в постоянно изменяющихся требованиях. Сейчас есть желание как раз добавить туда водопада) (описать фичи, сделать базовое ТЗ, выбрать стек) и попробовать заново с минимальными требованиями, чтобы хоть что то сделать )
kantocoder Автор
Ну, разумно. В agile нет долгосрочного планирования, как результат нет и нормальной, расширяемой архитектуры. Вместо этого есть постоянное переделывание. Непонятно, зачем такой методологией вообще пользоваться.
Водопад порождает ТЗ, ТЗ порождает фичи, план, архитектуру, и спецификацию конечного продукта. По спецификации конечного продукта Вы будете судить, закончен ли продукт или нет, например просто проставляя галочки напротив каждой фичи/функционала.
kantocoder Автор
Самое веселье начинается когда заказчик постоянно меняет требования, но отказывается платить так как не получает конечного продукта. Это приводит к банкротству компании и сокращению персонала, знаю из опыта.
ilnuribat
Заказчик не может предугадать хотелки клиентов.
Надо смотреть на все это как на туман войны в игре - у тебя есть хаос, и надо исследовать. Пока не сделаешь несколько мелких шагов не поймёшь что дальше
В гибких методолгиях есть место стратегии, просто не такая конкретная, и может меняться
Насчёт архитектуры - эта вещь динамическая, она меняется. Архитектура подстраивается под нужды, его можно менять в случае необходимости. Если архитектуру прибить гвоздями в начале развития продукта - ничего хорошего не выйдет.
GraDea
Пятый пункт:
Мы же договорились, что НДС в системе будет 18%, чего это вдруг вы меняете требования и хотите 20?)