Комментарии 37
Все недостатки показались странными:
Вне аджайла тоже не очень с прогнозированием.
Лучше взаимодействовать, чем закрыться в подвале и через полгода выкатить бесполезный продукт.
Все так, не выходит писать тз и перекидывать его через забор. Получается как во втором пункте.
Все равно лучше, чем наоборот: документации как у дурака махорки, а на проде только развернутый nginx.
Это не подход предполагает, что требования меняются. К сожалению, это наша реальность. Подход просто заточен под эту реальность.
Они не странные, они жизненные.
Методология разработки либо поощряет прогнозирование, либо нет. В случает Waterfall необходимо думать наперёд (то есть осуществлять стратегическое планирование), а в Agile - нет. Если нет стратегического планирования, то нет и продуманной архитектуры, а если нет продуманной архитектуры, то в конечном итоге программный продукт хорошим не станет. По крайней мере, более-менее сложный программный продукт
При работе по Waterfall тоже взаимодействуешь с заказчиком, просто нет так интенсивно как в Аgile
ТЗ формализует процесс разработки, оно необходимо
Не лучше. Я лично столкнулся именно с той ситуацией, что описана в этом пункте: пришел в стартап который работал над ПО, сорцы документированы не были, разобраться в них было очень трудно и приходилось дергать разработчиков что уже были "в теме". А это время. А сами сорцы, кстати, представляли жуткий пример техдолга. Но "работающий софт важнее исчерпывающей документации", несомненно; проблема в том что без документации а) перестаешь понимать как он работает, б) софт становится невозможно развивать дальше.
Реальность то, о чем договорились в контракте с заказчиком. А что он требования постоянно меняет, так пусть сначала определиться с тем, что хочет, потом заключает контракт
Методология разработки либо поощряет прогнозирование, либо нет. В случает Waterfall необходимо думать наперёд (то есть осуществлять стратегическое планирование), а в Agile - нет.
В случае с Waterfall спрогнозировать трудозатраты на новую разработку возможно только получения детального ТЗ. А время на подготовку ТЗ плохо прогнозируется для нового продукта.
Почему плохо прогнозируется? Можно начать с mvp. Описать текстом тупо фичи, которые хотим, интерфейс написовать, хотя бы "на квадратах". Вы рать стек для этого, описать базовую архитектуру mvp(которую потом сктати можно и переписать, если проект пойдет). И уже более менее понятно что надо сделать и сколько это займет времени. Главное сильно не менять требования, так как нужно сделать хотя бы первую версию продукта. Затем можно сделать какую то ретроспективу , посмотреть чего не хватает, куда двигаться дальше , да и вообще стоит ли двигаться, вдруг mvp версией пользуется 2 человека и оно тупо не надо
Не, вы давайте прогноз, точный, на полную разработку, от идеи до полноценного приложения. Чё это квадратики подсовываете?
Требования менять? Чего ради? Заказчик уверен в том, что ему надо. Он же вам на встрече рассказал, вы плохо слушали что-ли?
Так что давайте завтра присылайте ТКП с точной суммой и сроками.
Вы ведь профессионал?
В случае с Waterfall спрогнозировать трудозатраты на новую разработку возможно только получения детального ТЗ. А время на подготовку ТЗ плохо прогнозируется для нового продукта.
Как раз возможно и без детального ТЗ. Любой разработчик с опытом от 2 лет сможет сказать сколько приблизительно у него займет выполнение работы по ТЗ, даже если ТЗ и неполное. Оценка трудоемкости ТЗ -- одна из обязанностей разработчика, и если в компании разработчики не способны это сделать, то увы этой компании. Возможно она вообще не должна заниматься IT бизнесом.
Сможет. Правда, ошибётся не менее, чем в 2.5 раза в меньшую сторону. И то, только если задача знакомая.
Ну так пусть получит столько денег, на сколько оценил свою работу. В следующий раз не ошибется. Такое вот обучение с подкреплением.
Он-то, возможно, поумнеет. А заказчик, который рассчитывал по этой оценке на короткий срок, тем временем вылетит с рынка и разорится.
Ещё проблема есть - по старым задачам могут уточняться требования и поэтому их надо постоянно доделывать, наряду с новыми. Возникает ощущение бесконечности задач. Вроде ты сделал задачу, морально получил удовлетворение, что она закончена. А потом окажется, что не совсем закончена и надо доделывать снова и снова.
И каков конечный результат такой деятельности?
Отказывались в итоге от коротких спринтов, просто в бэклог задачи клали и делали по тихоньку)
А конечный продукт нормальный получился, без техдолга, в том или ином виде? Или его до сих пор не закончили?
Один продукт уже был до внедрения. Он есть и развивается. Просто отказались по сути от agile там. Там так сейчас - есть бизнес требование - задача в джире, примерные сроки, результат. Задачи копятся в беклоге и сортируются по приоритетам.
Второй продукт - стартап. Вот он фактически утонул в постоянно изменяющихся требованиях. Сейчас есть желание как раз добавить туда водопада) (описать фичи, сделать базовое ТЗ, выбрать стек) и попробовать заново с минимальными требованиями, чтобы хоть что то сделать )
Сейчас есть желание как раз добавить туда водопада) (описать фичи, сделать базовое ТЗ, выбрать стек) и попробовать заново с минимальными требованиями, чтобы хоть что то сделать )
Ну, разумно. В agile нет долгосрочного планирования, как результат нет и нормальной, расширяемой архитектуры. Вместо этого есть постоянное переделывание. Непонятно, зачем такой методологией вообще пользоваться.
Водопад порождает ТЗ, ТЗ порождает фичи, план, архитектуру, и спецификацию конечного продукта. По спецификации конечного продукта Вы будете судить, закончен ли продукт или нет, например просто проставляя галочки напротив каждой фичи/функционала.
Самое веселье начинается когда заказчик постоянно меняет требования, но отказывается платить так как не получает конечного продукта. Это приводит к банкротству компании и сокращению персонала, знаю из опыта.
- Если есть противоречия в ТЗ, по подрядчик облажался, приняв в работу такое ТЗ.
- Если же в ТЗ есть недосказанности и белые пятна, то по подрядчик вправе выбирать решение этой подзадачи "на свое усмотрение".
==Все просто, маэстро.
Заказчик не может предугадать хотелки клиентов.
Надо смотреть на все это как на туман войны в игре - у тебя есть хаос, и надо исследовать. Пока не сделаешь несколько мелких шагов не поймёшь что дальше
В гибких методолгиях есть место стратегии, просто не такая конкретная, и может меняться
Насчёт архитектуры - эта вещь динамическая, она меняется. Архитектура подстраивается под нужды, его можно менять в случае необходимости. Если архитектуру прибить гвоздями в начале развития продукта - ничего хорошего не выйдет.
Пятый пункт:
Мы же договорились, что НДС в системе будет 18%, чего это вдруг вы меняете требования и хотите 20?)
+500
Если Аджайл плохо работает, значит сами виноваты и у вас не правильный Аджайл.
Аджайл, это комбинация фундаментальной ошибка научного метода (если метод хорошо работает, то он должен хорошо работать всегда и везде) и системной ошибки выжившего (обоснование доказательства работы метода только по подтверждающим результатам и игнорирование отрицательных / противоположных фактов).
К сожалению, в Аджайл совсем не работатет Fix Time/Fix Price. Он поощряет продуктовый экстремизм со стороны заказчиков, поощряет тяп-ляп (низкое качество из-за ожидания частых изменений) и работает только для универсальных команд (без разделения общих ресурсов).
А вот большинство перечисленных в статье проблем к Аджайлу отношения не имеют и могут встречаться в любых проектах не зависимо от методологии.
Аджайл, это комбинация фундаментальной ошибка научного метода (если метод хорошо работает, то он должен хорошо работать всегда и везде) и системной ошибки выжившего (обоснование доказательства работы метода только по подтверждающим результатам и игнорирование отрицательных / противоположных фактов).
Это скорее к тем, кто его везде пихает.
Он поощряет продуктовый экстремизм со стороны заказчиков, поощряет тяп-ляп (низкое качество из-за ожидания частых изменений) и работает только для универсальных команд (без разделения общих ресурсов).
В точку. А теперь вопрос: а в каких компаниях распространены универсальные команды и почему? Может быть, универсальная команда -- признак "галеры", и их делают универсальными исходя из принципа "незаменимых людей быть не должно"? Как Вы считаете?
А вот большинство перечисленных в статье проблем к Аджайлу отношения не имеют и могут встречаться в любых проектах не зависимо от методологии.
С какими из них Вы встречались в Waterfall'е?
+500
Камон. Который раз одно и то же. Agile - это не та штука, которую надо выбирать. Если вы решаете, нужен он или нет, глядя на списки достоинств или недостатков - вы уже делаете что-то не так.
Всё гораздо проще. Agile работает, если у вас часто меняются требования. Более того, если требования меняются достаточно интенсивно - это единственный способ получить на выходе то, что им хоть как-то соответствует.
А динамика требований зависит прежде всего от рынка, на котором вы работаете. Если среда конкурентная и на арене есть пара шустрых игроков - выбора нет, придётся подстраиваться. Если вы в стартапе и важно нащупать то, что хотят пользователи, пока не проедены деньги - тоже выбора нет. Есть ещё тыщи примеров того, как требования могут быть очень динамичными - и не меньше того, как они могут быть спокойно зафиксированы на весь срок реализации.
Вот правильный ответ на вопрос, в первой вы группе или во второй, и скажет заодно, годится ли вам Agile.
Все равно нужно изначально сделать хоть какой то анализ продукта - что должно быть, сделать изначальное ТЗ хотя бы на 50% от всех фич, какой то обозримый mvp. Просто чтобы начав его делать - закончить! А не утонуть в постоянных изменениях требований к продукту по каждому чиху - а давайте это добавим и это. Так никогда и не закончишь mvp. Это морально выматывает, сам с таким столкнулся
А не утонуть в постоянных изменениях требований к продукту по каждому чиху - а давайте это добавим и это. Так никогда и не закончишь mvp. Это морально выматывает, сам с таким столкнулся
И я тоже. А автор статьи так и пишет: "It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one." (что я перевел как "У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.")
Бывает, что постоянные изменения объективны - вот как этим летом с QR-кодами для доступа в публичные места было: я их только в свой продукт включил, как тут свалилась их отмена. Но это действительно форс-мажор.
Обычно всё же изменения более редки и дают хотя бы какой-то осмысленный кусок работы сделать, будь то MVP или просто развитие продукта. Если это не так, если кто-то постоянно накидывает фичи - это как правило опять же признак того, что управление требованиями не кореллирует с потребностями рынка.
Фактически, Вы написали что его нельзя пихать везде и всюду, а у нас его именно везде и всюду и пихают. Поскольку почти вся инфраструктура сейчас зиждется на IT, лично я в этом вижу угрозу нашей национальной безопасности. Как пример, Вы согласитесь лететь на самолете, который проектировали и собирали по Agile?
С радостью. Я бы посоветовал вам прочесть книгу Мартина Роберта "Чистый Agile", там много говорится о тех вещах, которые вы описали в статье, там же объясняется, почему научный подход плохо применим к разработке, хотя автор и делает примечание о том, кому Agile не подойдёт.
Ну, Вы смелый человек. Лично я в такой самолет не сяду. С другой стороны Илон Маск ракеты в космос запускает, а в SpaceX по agile работают, если не знали: https://cliffberg.medium.com/spacexs-use-of-agile-methods-c63042178a33
Вроде как Илон известен тем, что просит чтобы подчинённые очень много работали. Если почитать на Glassdoor отзывы от работе в его компаниях, то люди пишут, что там плохо соблюдается баланс работы/личной жизни. То есть он требует максимальной вовлечённости в работу. Ну, при таком подходе, если его принимают люди , по какой методике не работай, все равно будет результат, так как даже после работы будешь думать все равно о ней)
Так потому и пихают, что опираются не на объективные потребности, которые вот, внутри, у них же перед глазами, а смотрят на статьи с абстрактными списками преимуществ и недостатков.
Огромные недостатки разработки программного обеспечения по Agile