Здравствуйте, Pauel, Вы писали:

S>>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика

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

Мое впечатление от Agile (по крайней мере от SCRUM и Kanban, т.к. по ним информации больше, тогда как Crystal зверь более редкий и малоизученный) заключается в том, что Agile это отличный компромисс по защите интересов и тех, и других:

— проектная команда защищается от внезапных вбросов от заказчика. Типа "мы же согласовали скоуп спринта, если у вас что-то появилось или что-то отвалилось, то все это учтем на будущий спринт, а пока подождите и дайте нам завершить текущий спринт". Сейчас это звучит дико, наверное, но еще лет 10-12 назад отшить заказчика, который внезапно примчался с криками "бросаем все, мне вот это нужно уже прям вчера", было сложно и требовало железных яиц у ключевых людей на стороне проектной команды (в том числе и у владельцев конторы, в которой проектная команда трудится, если заказчик внешний). Теперь же есть принятые многими правила игры: мол, все согласились, что работаем по SCRUM-у, поэтому никто в уже согласованный скоуп спринта ничего насильно не впихивает. Как я понимаю, ограничение на длину спринта и рекомендация иметь небольшие спринты (две недели) как раз отсюда и происходит: до разумных пределов сокращается лаг по реакции на изменяющиеся условия;

— заказчик защищается от того, что проектная команда занимается какой-то неведомой деятельностью, последствия которой не очевидны и непонятно на что же тратятся кровные деньги заказчика. Нет такого, что команда ушла в подполье на 2 месяца для сбора и анализа требований, по истечению которого получается какой-то фолиант на 100500 страниц с описаниями всякого разного, что нужно вкуривать еще несколько недель. После чего команда опять исчезает на написание пояснительной записки к проекту, результатом чего будет еще один фолиант на 100500 страниц. А при необходимости среагировать на какие-то входящие изменения (типа новой фичи в продукте основного конкурента или изменениями в требованиях от регулятора) приходится переписывать часть этих фолиантов. И т.д., и т.п. Вместо этого идет итерационный процесс выдачи конкретных результатов заказчику, сперва от примитивных и минималистичных PoC и MVP, до постепенного превращения PoC/MVP в полноценный продукт за счет инкрементального наращивания возможностей. Т.е. благодаря относительно коротким итерациям заказчик постоянно видит на что уходят его деньги.

При этом (с моей колокольни глядя) Agile отлично работает в проектах, когда общий скоуп более-менее понятен изначально и есть постоянный поток хотелок, которые можно резать на небольшие кусочки, дабы эти кусочки были реализуемы в рамках спринтов. Отличную демонстрацию этого желающие могут сейчас наблюдать в процессе эволюции сервиса deepl.com: за пару лет на моих глазах он превращается из примитивной демки по возможностям новой разработки в области машинного перевода в полноценный сервис, который конкурирует и с Google.Translate, и с Grammarly. Постепенно в него добавляются и новые фичи (переводы документов, выбор из разных вариантов перевода, и нативные приложения, чтобы Web-интерфейсом не пользоваться), и новый подход к работе с пользователями (подписки с разными планами и прием платежей). Вот все это, имхо, отлично ложится на SCRUM/Kanban.

Еще один (потенциально возможный) пример: разработка компилятора для языка программирования по спецификации языка. Вот тот же C++ если взять: есть зафиксированный стандарт (C++20, к примеру), к нему должен появится компилятор. Вполне себе понятный скоуп работ, который можно оценить и разрезать на отдельные шаги (спринты). Возможно, по каким-то направлениям нужно провести исследования (скажем, как можно минимизировать динамические аллокации при создании короутин). Но это будут исследования на предмет "как лучше", а не "можно ли вообще что-то хорошее получить".

Тогда как в рамках приведенных выше примеров есть задачи, которые на SCRUM/Kanban (а может и вообще на Agile) ложатся не очень хорошо.

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

Или стандарт языка C++. Он же формируется из предложений, а предложение кому-то нужно родить. Потом довести до ума. Потом пройти через согласования. Возможно, выдержать несколько ревизий. Чтобы потом быть отвергнутым. Как это было с большим куском работы над концептами в рамках C++11, которые были выброшены, а вошли концепты, в видоизмененном состоянии в C++20. Или как это было с контрактами, которые хотели включить в C++20, но которые (емнип) не попали даже в C++23. Или как это происходит с Concurrency TS и Networking TS.

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

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

Отсюда и интерес к теме использования SCRUM в исследовательских проектах. Но, сложилось у меня ощущение, что отметившиеся здесь евангелисты SCRUM сами над исследовательскими проектами по SCRUM и не работали. Либо подразумевали под "исследовательскими проектами" что-то свое.