Здравствуйте, so5team, Вы писали:
S>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика
То есть, когда у нас есть некоторая свобода в требованиях, они меняются, но реализацию можно или растянуть во времени, или переформулировать требования.
То есть, минимальная неопределенность. Максимум, что мы себе можем позволить — нагуглить либу, написать poc на фичу, посчитать вычислительную сложность итд. Вроде бы тоже ресёрч, но ооочень маленький.
Здравствуйте, 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 и не работали. Либо подразумевали под "исследовательскими проектами" что-то свое.
S>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика,
Не для этого нужна гибкость. Точнее, хотелки тоже меняются, но гибкость в разработке ПО необходима в первую очередь потому, что планы меняются в процессе разработки. Таски, выполненные в текущем спринте, могут убрать необходимость в тасках, работать над которыми планировалось потом, или заменить их другими.
Это то, где погорает стандартный вотерфол.
Здравствуйте, Pauel, Вы писали:
P>А вы видели исследование в котором анализа результатов нет? Анализ это обработка данных, интепретация результатов, итд. Это часть исследования.
Вот именно. Часть исследования. Ты же говорил об исследовании в целом. Причем, в разрезе того, что, в отличие от разработки софта, исследования не содержат ничего определённого, а сам на вопрос, что же такое исследование (research) привёл пример донельзя регламентированного и известного вдоль и поперёк анализа.
Вот эти вот противоречия в твоих собственных словах и заставляют меня сомневаться.
P>Здесь нет никакого словоблудия: P>1. каждый эксперимент в исследовании может выделяться в конкретный проект со вполне достижимой целью. Например — создать броневую плиту на основе xxx. P>2. проект может содержать в себе исследование, например — выяснить оптимальные условия отжига.
Это именно, что словоблудие, которое ведёт к полнейшему бардаку в голове и, как следствие, в организации в целом. И в итоге у тебя пытаются прототип заставить работать как релизную версию, а пользователи начинают работать с системой с первого спринта.
Проекты точно так же могут разбиваться над подпроекты и в практически любом проекте есть что-то, что требует прояснения для дальнейших корректировок планов. Обычно это называется общим словом "риски". Ты не привёл никаких отличий исследований от других типов проектов.
_AB>>А что случится, если в ответ на что такое ресёрч тебе приведут пример анализа? P>Раз вы запутались, я вам помогу: P>Research is the process of finding information, while analysis is the process of evaluating and interpreting that information to make informed decisions
Извини, но это не я в ответ на что такое ресёрч привел пример анализа, так что запутался не я, а ты.
Здравствуйте, so5team, Вы писали:
S>Мы же не про минимальное планирование говорим, а про скрам. Скрам -- это формализованный метод разработки продуктов с жесткими ритуалами и (емнип) запретом на игнорирование этих самых ритуалов (т.к. тогда уже не скрам получается).
Скрам — это точно не формализованный метод разработки продуктов.
Скрам, скорее, это, прежде всего, идеология командной работы над достижением какой-либо цели. На основе этой идеологии выстроена методология (причём, слабоформализованная), описывающая минимально необходимый (с точки зрения авторов ) набор методов (а не жёстких ритуалов), необходимых для достижения этих целей.
Что касается оговорки про то, что выкинете что-нибудь — это будет не скрам, то во-первых, не надо забывать, что скрам — это ещё и коммерческий продукт над ним в виде сертификаций и прочего, что требует хотя бы минимальной стандартизации. А во-вторых, это взгляд авторов методологии на минимально необходимый набор инструментов. Если выкинуть что-то из минимально необходимого, то цели достичь задуманным авторами путём не получится и это будет не их методология с этой точки зрения.
Что касается жёсткости "ритуалов", то из всей "жесткости" там лишь список минимально необходимых событий и артефактов, у которых есть ограничения по длительности и которые должны преследовать определённые цели, согласно заложенной идеологии. С этой точки зрения (с точки зрения идеологии), методологию можно назвать очень жёсткой, но ирония в том, что именно про все эти цели и забывает примерно этак 80%+ всех, применяющих скрам, что и приводит к ритуализации и формализации практической реализации этого фреймворка.
Немного в сторону, но, ИМХО, авторы скрама сами себе в ногу выстрелили, когда в первых версиях применяли околорелигиозные термины типа "ритуалов" и прочего и навязывали больше ограничений, не делая достаточного акцента на том, зачем это делается. Текущая версия куда более приближена к реальному миру и куда более работоспособная, с моей точки зрения.
S>Минимальное планирование может выглядеть как: S>"1. Ввязываемся в драку. S>2. Разбираемся по обстоятельствам"
ИМХО, это не планирование. Минимальное планирование определяет хотя бы цель ввязывания в драку и общие намётки того, в какую сторону будут пытаться эту драку двигать.
S>и для некоторых это работает.
Только, если все участники понимают цель и общий замысел, даже если формально его не озвучили.
S>Только вот к скраму это не имеет отношения.
Это и к планированию отношения не имеет.
S>Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение.
Я могу ошибаться, но такими поисками занимаются одиночки, а не команды. И только когда одиночка нашёл что-то перспективное, вот тогда на основе имеющихся результатов может быть создана команда для практического применения найденного. Да, одиночки не работают в вакууме, получают данные извне и используют ранее открытое, но я не назову вот так навскидку чего-то фундаментального, открытого командой из нескольких людей, которым поставили цель это фундаментальное открыть. ЕМНИП, всегда был сначала один, нашедший идею, а дальше её могли развивать уже и командой. А одиночки не имеют отношения ни к проектной ни к операционной деятельности и им ни канбан, ни скрам, ни водопад не нужны.
Мы же ведём разговор именно о работе в команде, не так-ли?
Здравствуйте, _ABC_, Вы писали:
_AB>Что касается оговорки про то, что выкинете что-нибудь — это будет не скрам, то во-первых, не надо забывать, что скрам — это ещё и коммерческий продукт над ним в виде сертификаций и прочего, что требует хотя бы минимальной стандартизации. А во-вторых, это взгляд авторов методологии на минимально необходимый набор инструментов. Если выкинуть что-то из минимально необходимого, то цели достичь задуманным авторами путём не получится и это будет не их методология с этой точки зрения.
Не вижу противоречий с тем, что я говорил ранее.
S>>Минимальное планирование может выглядеть как: S>>"1. Ввязываемся в драку. S>>2. Разбираемся по обстоятельствам" _AB>ИМХО, это не планирование.
Тем не менее, это именно оно и именно в таком виде оно наблюдалось в прошлом (не только мной, достаточно вспомнить сделку между Microsoft и IBM в начале 1980-х).
Кроме того, это именно те планы, над которыми боженька смеется не так часто и не так сильно
_AB>Минимальное планирование определяет хотя бы цель ввязывания в драку
Я наивно полагал, что планирование -- это следующая стадия после целеполагания. Т.е. сперва определяет цель, потом уже начинается планирование по ее достижению. Например, кто-то хочет стать поставщиком решений для крупной компании (типа Сбера или Газпрома). Это цель. И минимальный план для ее достижения: ввязываемся в ближайший тендер, а там разберемся.
_AB>общие намётки того, в какую сторону будут пытаться эту драку двигать.
А это уже по ходу уточняется. В планировании тоже итерационный подход работает
S>>Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение. _AB>Я могу ошибаться, но такими поисками занимаются одиночки, а не команды.
Возможности одиночки сильно ограничены. Если такое и происходит, то либо на маленьких проектах, либо на самых ранних стадиях, когда какой-нибудь условный Грейдон Хоар в свободное от работы время вынашивает идею Rust-а (или условный Герб Саттер вынашивает идею Cppfront).
Но история того же Go показывает, что там с самого начала была командная работа, т.к. даже список требований к новому языку Роб Пайк не в одиночку составлял. Да и когда Грейдон Хоар получил поддержку от Mozilla для своих разработок, то там образовалась команда из, емнип, четырех человек, которая и занималась Rust-ом в течении нескольких лет (+ помощь от сочувствующих с разных концов света).
Так что более правильно было бы говорить о небольших командах (3-5 человек). И это еще один фактор, почему какой-нибудь условный SCRUM (как "патентованный" процесс) не столь актуален: в таких небольших командах координация и кооперация намного проще и эффективнее самоорганизуется без необходимости в жестких ритуальных действиях.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы. K>Это всё херня на самом деле. Когда надо что-тио делать приходится просто садиться и делать вне зависимости то того девопс ты или нет.
Здравствуйте, _ABC_, Вы писали:
P>>А вы видели исследование в котором анализа результатов нет? Анализ это обработка данных, интепретация результатов, итд. Это часть исследования. _AB>Вот именно. Часть исследования. Ты же говорил об исследовании в целом. Причем, в разрезе того, что, в отличие от разработки софта, исследования не содержат ничего определённого, а сам на вопрос, что же такое исследование (research) привёл пример донельзя регламентированного и известного вдоль и поперёк анализа.
Вы пытаетесь играть в слова. Исследование неопределенного спроса на 90% состоит из сбора сведений. Вы же почему то видите здесь исключительно 10% анализа.
P>>2. проект может содержать в себе исследование, например — выяснить оптимальные условия отжига. _AB>Это именно, что словоблудие, которое ведёт к полнейшему бардаку в голове и, как следствие, в организации в целом.
Похоже, вам ктото запретил посмотреть разницу между проектом и исследованием.
_AB>Проекты точно так же могут разбиваться над подпроекты и в практически любом проекте есть что-то, что требует прояснения для дальнейших корректировок планов. Обычно это называется общим словом "риски". Ты не привёл никаких отличий исследований от других типов проектов.
Наоборот, привел то самое ключевое — исследование дает нам качественный результат в виде нового знания, и планируется в основном последовательно. Например, пока вы сведения не собрали, вам нечего анализировать. Более того — у вас все шаги могут быть известы заранее.
И этот самый сбор сведений в чистом виде операционная деятельность — вы тупо сидите и регистрируете поступающие детали.
_AB>Извини, но это не я в ответ на что такое ресёрч привел пример анализа, так что запутался не я, а ты.
Пока вы сведения не соберете(1), вам нечего анализировать(2). Исследование это сначала 1, потом 2. Вы попутали арбуз и косточку от арбуза.
Здравствуйте, so5team, Вы писали:
S>Мотивацию этого подхода тоже можно понять: вот выбросил я, например, Daily Scrum, утратил один из инструментов контроля за происходящим, проект завершился неудачно. Почему бы мне не начать говорить, что SCRUM сработал плохо? А нельзя, т.к. у меня был не SCRUM, и это правда.
Что значит правда? Все хотят получить какую-то универсальную инструкцию -- делай раз, делай два и думают, что она
приведет их к успеху. Поэтому сам факт был ли скрам или не было особого смысла не имеет. Это равносильно
тому, чтобы все делать по инструкции, которой, к слову, просто не существует. Точнее она, инструкция, для каждого
случая индивидуальна. Ну может для какие-то задач и проектов действительно лучше подходит, например,
классический скрам, а для других -- уже нет.
S>Ну а так-то да, под команду можно настроить процесс, понадергав полезного из разных подходов (SCRUM, Kanban, Crystal и пр.). Главное, чтобы работало. Вопрос в том, можно ли к сформированному процессу конкретный ярлык прилепить (по аналогии с тем, что не всякое вино в определенных юрисдикциях может "Шампанским" называться).
А так ли нужен этот ярлык? Ну работает это ассабляж, так пусть работает. Можно просто говорить "работаем
по agile" и это будет правдой.
Здравствуйте, Kernan, Вы писали:
SD>>Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться. K>Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
