Comments 41
Имхо, сейчас теоретики от IT уподобляются средневековым схоластам, ведущим дискуссии о количестве ангелов, умещающихся на острие иглы.
Методики, ценности, блаблабла.
Возьмем, например, строительство дома.
Для того чтобы он не развалился - нужен фундамент (да хоть 4 камня - это тоже фундамент!), для того чтобы построить правильный фундамент - нужно понимание как хотя бы примерно будет выглядеть этот дом в итоге, из чего он будет построен, каков порядок бюджета на строительство, и примерный желаемый срок.
А вон та картинка, про "хороший Agile" с самокатом - велосипедом - машиной прямо-таки наводит на мысль, что сначала надо построить хотя бы конуру, потом расширить ее до сарайчика, а потом доработать его до дома. И вкрячить сверху башню.
Так это не работает!
Чтобы построить башню - нужно закладывать такие бюджеты, ресурсы и сроки, что если у вас их нет - лучше ограничьтесь домиком, сразу, на этапе "я хочу".
И сразу же - делайте фундамент под дом, а не под собакину конуру: ПОТОМ переделывать выйдет дольше и дороже.
Почему люди думают, что в IT не так?
Потому что в IT действительно не так. Любая аналогия, как и приведённая Вами, подобна котёнку с дверцей.
Когда строится дом, уже на старте есть готовый план. И если в государстве есть нормальный надзор над строительной отраслью, никто в здравом уме не будет пытаться "добавить ещё пару этажей" или "а давайте вместо бетона попробуем использовать пластик" когда половина дома уже построена.
Когда реализуется IT проект, ситуация прямо противоположна. Начали пилить стартап, сделали наполовину бэкенд и на три четверти мобильное приложение - и тут выясняется, что приняли новый закон / конкуренты выкатили своё приложение / менеджеру пришла гениальная идея / подставьте свой вариант. Конечно, можно упереться и сказать "у нас есть утверждённое ТЗ, нам всё по барабану, продолжаем делать как планировали" - но в этом случае просто конкуренты (те из них кто был готов меняться на ходу) выиграют, а проект рискует провалиться.
Вообще, если и сравнивать проекты в IT со строительной отраслью, возможно лучше сравнивать не со строительством, а с проектированием. И вполне можно представить, что в ходе проектирования здания, когда большая часть проекта уже готово, заказчик вдруг выдвигает новые требования: да, возможно часть работы придётся выкинуть и переписать с нуля.
Это называется хаос, анархия, плохая организация и т.д. в зависимости от конкретики :)
Бетон есть бетон, фундамент есть фундамент, дом есть дом. Без первого не сделать второе, без второго третьего. А уж какой там конкретно бетон и от какого производителя, какие строители, размеры и вид фундамента, какой дом... Ну, вы поняли — определят архитектора, проектировщики и прочие важные, причём сразу либо будут переделывать.
P.s. По картинке в начале статьи: она отбивает всякое желание работать с Agile, ведь судя по ней, тот требует поиска, изобретения и проектирования для каждого этапа по отдельности и с нарастающей сложностью (помимо реализации!). Согласитесь, проще спроектировать лишь автомобиль, чем скейтборд, самокат, мотоцикл и т.д., когда нужен лишь автомобиль. Да и не факт, что сможешь — там значительная разница в знаниях, технологиях и подходах ;)
Картинка действительно не очень удачная, потому что иллюстрирует реалии разработки софта на примере создания материальных продуктов, причём достаточно сложных. Для полноты аналогии следовало бы уточнить, что когда мы на первом шаге отдаём пользователю наспех сделанный самокат, есть шанс услышать "ой не, нам же нужно чтобы он держался на воде" или "а мы же хотели на нём летать". И в условиях неопределённости, сделать самокат и выкинуть его на второй итерации - всё же дешевле, чем полгода строить машину, только для того чтобы осознать что заказчик хотел совсем другое.
Бетон есть бетон, фундамент есть фундамент, дом есть дом
Так никто не спорит, что при строительстве настоящего дома, есть вполне устоявшиеся практики, и обычно ещё до начала строительства есть план, который не теряет актуальности в течение всего этого строительства (пусть и с некоторыми корректировками). Мой комментарий был как раз в том, что эта аналогия никак не подходит для IT проектов.
Это называется хаос, анархия, плохая организация и т.д. в зависимости от конкретики :)
Ну что ж, проекты разные бывают, в том числе и в IT. От крупных многолетних проектов со стабильными требованиями до стартапов, где концепция может меняться очень резко. Для Вас - "хаос, анархия ", для кого-то - свобода. Изменчивость требований - необязательно плохая организация (хотя иногда это так), это может быть просто спецификой конкретной отрасли.
Это только так кажется )
Проектирование:
- для собачьей конуры достаточно пешей доступности - но уже надо учитывать инсоляцию (нагрев на солнце конуры) и ветра (чтобы не замерзла)
- для курятника - уже нужна транспортная (тачка с комбикормом должна проехать)
- для дома - коммуникации, водопровод, водоотведение
- для многоэтажки - парковочные площади, выезд на дороги со двора
И если заказчку выкатить проект "курятник на обрыве у реки", а он такой "мне понравилось, давайте переделаем под торговый центр!" - то будет нехорошо в итоге.
Мозг человека вырабатывает дофамин при достижении целей или получении информации. В век смартфонов когда ты бездумно листаешь ленту - ты просто стал дофаминовым наркоманом, и теперь неспособен получить (дождаться) удовольствия от реализации длительного проекта. Ну если бумеры еще помнят тот катарсис от качественно сделанного монолита, то зумеры теряют интерес и эффективность - им никак без декомпозиции и MVP. Был такой фантастический рассказ классика - в будущем люди перестали ценить длинные музыкальные композиции и писали только джинглы, 5-10 секундные, типа для рекламы. Их напевали, под них танцевали. Туда и движемся.
Основная мысль почему в IT не так, заключается в сравнении стоимости проектирования и создания итогового продукта.
В строительстве из-за высокой материалоемкости, создание готового продукта гораздо выше стоимости проекта. Поэтому дешевле сначала подготовить нормальный проект, а потом по нему строить. Но это не значит, что нет примеров, когда сначала построили конуру, а потом уже пристраивают к ней дом побольше.
В программной разработке стоимость проектирования будет не ниже, чем сама разработка, а в некоторых случаях без какого-то прототипа очень сложно определиться с проектом дальнейшего развития. В итоге это и выливается в то, что мы видим сейчас.
Хороший пример про эджайл и строительство : https://nbabaeva.medium.com/как-объяснить-дедушке-эджайл-и-скрам-за-5-минут-без-картинок-и-самому-лучше-понять-139ba51b5230
Эджайл скорее не про заложить фундамент под бытовку, а потом передумать и построить три этажа. Скорее так: построить бытовку под самую большую потребность, осмотреться, строить дальше по комнатам по мере того, как выявляются новые задачи. Если комнату пристроили, а оказалась не нужна - демонтировать или перестраивать. Да, итог будет не оптимальный с точки зрения архитектуры (а значит и удобства и надежности и масштабируемости). Но первые жильцы заедут максимально быстро. И построены будут только те комнаты, которые реально нужны (а в частных домах часто проектируют и строят неиспользуемые вещи типа балконов, бильярдных и тд).
Опять выдуманный теоретический пример, как тот сферический конь в вакууме )
Практика строительства немного отличается ..
По ссылке у меня ничего не загрузилось.
Но в целом, в деревнях и пригородах домов, которые достраивали и перестраивали, много.
Особенно это заметно в частном секторе в черте города.
Ну да, а потом изба стоит на ленте, кухня пристроена к ней и стоит на кирпичах, зимой-летом это всё гуляет, рвет обои и дует в щели, просто хозяева уже приноровились и внимания не обращают.
Вот и с программами так же: иногда бывает кто-то начинает ругаться, что сайт кривой или там приложение работает хз как - а я смотрю и понимаю почему так получилось: связали А и Б вместе изолентой, поэтому когда нажимаешь на кнопку здесь - падает там, нужно просто привыкнуть и не нажимать...
В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Я свой первый эджайл проект делал для SwissRe: второй по величине в мире перестраховочной компании. Регулирования у них там никак не меньше, чем у банков. Очень даже возможно, ничто не мешает к моменту сертификации у регулятора подходить мелкими итерациями с непрерывной обратной связью от заказчика.
Agile же не про итерации. А про документирование, согласования и соответствие конечного результата ожиданиям. Везде, где есть регуляторы и сертификации, будет много формализма и документации, поэтому чистый agile, когда все на личных договоренностях и на работающем продукте неприменим.
Agile же не про итерации
🤦♂️ Серьёзно? И Вы пытаетесь учить других, что такое эджайл?
я не учу других Agile, я консультант в другой сфере.
Про итерации как раз поясняю тут в статье, потому что люди часто путают итеративные подходы к разработке с Agile, потому что слышали про скрам, который основан на итеративном подходе и аджайл.
Между тем сам по себе итеративный подход может существовать и без аджайла:
PDCA. RUP, спиральная модель, тест драйвен и т.д.
Ну и в каскадной модели тоже может быть аджайл, если у нас нет жестких требований по документации процесса проектирования, разработки, нет необходимости стэкать несколько разных команд и продумывать интеграции и т.п.
я не учу других Agile, я консультант в другой сфере.
С удовольствием почитал бы Вашу статью, касающуюся Вашей сферы компетенции. Про эджайл не нужно – я только на один момент указал, но на самом деле в статье спорных (как минимум) утверждений полно.
Да, Agile Manifesto – не методология. Как и устав компании – не правила внутреннего распорядка. Это идеологическое обоснование итеративной модели разработки – как альтернативы повсеместно использовавшемуся на тот момент waterfall. SCRUM, кстати, появился сильно позже, и не нужно всё время ссылаться именно на него, как синоним Agile.
Ну так итеративные системы вполне есть и без аджайла, я же про это.
Разработчикам лучше, когда мы можем объединить оба подхода. Но не всегда это возможно.
Статью про свою сферу ещё пишу.
Ну так итеративные системы вполне есть и без аджайла, я же про это.
Вы путаете вывеску с содержанием. В наше время эджайл – общепринятое обозначение методологий, основанных на коротких итеративных циклах. Даже если сама методология была разработана до появления этого понятия. Термин прижился именно в разработке ПО, в других сферах не встречал – хотя похожие подходы используются не только в программировании.
Agile Manifesto появился в 2001 году, а сам термин Scrum для итеративной модели разработки был предложен ещё в 1991 году. Да и сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Так что повсеместность использования каскадной модели до появления Agile и The Scrum Guide как минимум спорна.
термин Scrum для итеративной модели разработки был предложен ещё в 1991 году
Спасибо, не знал. Повидимому, всё, как обычно: мало произвести хороший продукт, надо его ещё и хорошо продать. В этом смысле именно Манифест явился поворотным пунктом, сумев привлечь внимание широких кругов. До него единичные попытки были, но таки повсеместно использовался именно waterfall.
Как не про итерации? А быстрая обратная связь откуда берется?
Итерации подразумевают некий законченный цикл. Смотрите например PDCA, RUP.
Если в цикл включили обратную связь, то хорошо и логично, но это не обязательно будет аджайл подход. Представьте, что для обратной связи вам нужно заполнить три формуляра и передать разработчику. А разработчик далее делает опять изменения проекте, рабочей документации, выказывает план разработки на месяц, выделяя отдельно исправления, доработки, новые функции.
Вот как бы и итерации есть, обратная связь, а аджайл отсутствует.
В то же время, и каскадную разработку можно вести с периодической демонстрацией разработанных функции и сбором обратной связи. Сам по себе классический подход не запрещает же демонстрации промежуточных результатов, общение с заказчиком, изменения в проекте. Просто идёт концентрация внимания на результатах, без конкретизации процесса, вот и всё.
классический подход не запрещает же демонстрации промежуточных результатов,
когда? результат сбора требований и проектирования можно и нужно продемонстрировать, а на этапе кодирования что демонстрировать?
общение с заказчиком, изменения в проекте
конечно не запрещает, в PMBoK'е такого запрета нет :) Только при изменениях нужно откатываться на начало, которое было уже давно, и много работы пойдет в корзину
каскадную разработку можно вести с периодической демонстрацией разработанных функции и сбором обратной связи
не нужно называть получение обратной связи словом итерация
а на этапе кодирования что демонстрировать?
хотел бы пошутить, что демонстрировать можно код, но не буду.
На самом деле сейчас никакая разработка не заключается в том, чтобы кодить кодить пару месяцев, а потом откомпилировать и задеплоить. Уже давно есть инструменты и для быстрой компиляции и быстрого тестирования без необходимости ждать двое суток.
Только при изменениях нужно откатываться на начало, которое было уже давно, и много работы пойдет в корзину
это крайность, которая декларируется в PMBoK, на на практике так никто наверно не делает. Все почему-то вносят правки и максимум сдвигают сроки сдачи.
не нужно называть получение обратной связи словом итерация
ну да, об этом и говорю.
Как вы надоели уже с аджайлом в проектной работе, вот честно. Как и надоели доказывать, что он не отстой. Да и был бы не отстой, в доказательствах бы не нуждался.
Картинка прикольная, но обманчива. Вопервых да - пока ватерфол строит базу, аджайл уже на скейте. Но вот финал у аджайла будет далеко не одновременно с ватерфолом, а существенно позднее, причем у их авто колеса будут разного размера. Из плюсов только модный цвет, в соответствии с тенденциями рынка, но руль управляет только левым колесом, а запаска не от этой модели авто.
Как учит нас PMBoK, перед тем как войти в проект необходимо на старте определится с методологией управления проектом на которую влияет объем проекта, зрелость команды, ограничения, предъявляемые требования.
В больших проектах, с горизонтом 5-10 лет методология Waterfall является базой на которой строится весть проект. На больших горизонтах по мере реализации меняются условия, люди, страна, заказчики. Руководителю проекта или его последователям очень важно сохранить видение того куда идет проект, что бы банально не забыть самому и что мы все делаем и в какой стадии находится проект в Agile это просто невозможно.
По мере реализации большого проекта всегда меняются составляющие требования к оборудованию, требования к ПО, требования к безопасности, именно в эти моменты перестает работать Waterfall и в моменте требуется более гибкий подход Agile организовать тестирование походящего под требования ПО или железа, перестроить подход в реализации этапа Waterfall.
Как итог, в больших проектах проверенно работают Waterfall как горизонт планирования, Agile как реакция на изменения внешних факторов, протоколы позволяющие создать общее понимание о чем договорись, приказы финализирующие вехи проекта и позволяющие двигаться дальше.
Каскад можно сделать вполне "гибким" даже по понятиям аджайла, если вшить в процесс управления производством ADM-цикл. При этом, на практике, как вы верно отметили, внедрятели гибких подходов в основном вообще забывают про процесс управления требованиями. Спасибо за статью.
Никогда не испытывал "чувства противоречия": база и стратегия (цель, бюджет) - это Waterfall. Часто заходит в тактический уровень. Тактический и, особенно, операционный - принципы Agile. Всё очень просто.
Мифы и реальность: есть ли основание противопоставлять Agile и Waterfall?