Pull to refresh

Comments 290

У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач - наводит на определенные мысли об авторе.

Декомпозиция - ключевой инженерный навык. Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции. Иначе все быстро скатывается в задачи без конца и края. Над ними сначала месяц сидит и охреневает разработчик. Потом месяц сидят и охреневают ревьюеры, что им нужно вникнуть в 5000+ новых строк. Потом еще месяц задача ходит по кругу In Progress - In Testing, потому что QA охреневает от количества ассертов. В итоге 3 месяца - и полный ноль результата. Спасибо, лучше буду дробить.

Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения

Разрабатываем трейдинговую платформу по скраму. Неизвестного и нового довольно дофига, скопипастить особо неоткуда. Как раз все отлично ложится в процесс, когда заказчик приходит с хотелкой, а команда накидывается, делает дорожную карту фичи и распределяет задачи по исполнителям. Опять же есть подозрения, что в тексте имеет место экстраполяция "я не умею - значит никто не умеет".

Разрабатываем трейдинговую платформу по скраму. 

Это у вас в вебе все так легко и прозрачно.

А теперь зайдите в геймдев где при разработке чего-то реально нового, каждая задача тянет на полноценный рисерч в рамках которого задача может быть выполнена без всякой декомпозиции, либо наоборот потребовать еще рисерчей. Кроме того познания в графике/физике итд требуют годы опыта и задачи требующие глубоких познаний банально некому оценивать так как людей с такими познаниями просто мало, не то что в компании а в целом на рынке. Собственно на таких реально больших и сложных задачах скрам умирает. И не редко в геймдеве есть задачи с неизвестным исходом рисерч которых может длится месяцы, а если это что то уникальное (например тысячи интерактивных крыс в игре A Plague Tale: Requiem) то разработка и доработки будут длится годами.

А теперь зайдите в геймдев

А зачем мне заходить в геймдев? Это пусть автор пишет границы применимости его теории. А то получается странный разговор:

Автор: Пингвинов не существует!!!

Хабр: Да почему же? Антарктида, Тасмания, Южная Америка - там водятся пингвины.

Автор: А вы зайдите в пустыню Гоби - там пингвинов нет!!!

при чем же здесь пустыни? вы написали:

Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции.

То есть вы написали, что не только в геймдеве, а вообще в любой промышленности - даже где компьютеров нет вообще - скрам работает. А если скрам не работает, то причина - как вы пишете - в том, что все работнгики - низкоквалифицированные джуны, которых никто не учил ГЛАВНОМУ.

В общем-то вы проиллюстрировали тезис про "элегантный коммунизм". Который в рекламе работает везде, а после продажи - почти нигде.

То есть вы написали, что не только в геймдеве, а вообще в любой
промышленности - даже где компьютеров нет вообще - скрам работает

Серьезно? Прям так и написал? А мне казалось, что:

Декомпозиция - ключевой инженерный навык. Вообще, вне всяких методологий. Даже вне разработки ПО

У вас декомпозиция == скрам? В следующий раз попросите помощи ЧятикаГПТ, если настолько тяжело написанное воспринимать.

У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач

Вы сказали, что единственная причина по которой пинают скрам, это когда пинающие не умеют в декомпозицию, и поэтому не могут заранее просчитать сложность задачи.

Других причин, кроме неумения в декомпозицию, для недовольства скрамом нет, согласно вашему тезису.

Вы сказали, что единственная причина по которой пинают скрам

Неа, не говорил, лол. Продолжаю самоцитирование

У скрама много недостатков, но то, что автор раз за разом пинает именно
разбиение задач - наводит на определенные мысли об авторе

Где что-то про "единственную причину"? Я говорю конкретно про автора, что есть вероятность, что навык декомпозиции у него не наработан. А если он не наработан, то жить в целом становится тяжелее.

Насчет ЧятикаГПТ я серьезно. Говорят, умеет разжевывать написанное.

Я говорю конкретно про автора, что есть вероятность, что навык декомпозиции у него не наработан.

То есть вы больше обсуждаете автора и его бэкграунд нежели саму по себе проблему.

Вы учитываете, что ИТ в принципе крайне молодая индустрия и в ней всё ещё большинство это самоучки и как и описано автором ИТ-шники это исследователи и RnD-специалисты по умолчанию или стремящиеся к этому? Если вы слышали интерес сферического ИТ-шника в вакууме, то он обычно сводится к задачам разработки "чего-то нового", а не клепанию одинаковых колош на ИТ-фабрике, то есть дословно в движении к исследовательской/RnD деятельности.

Конечно, в крупных компаниях у бизнеса уже давно пришло желание видеть вместо огромного RnD отдела с непонятым выхлопом на инвестицию - ИТ-фабрику с понятным потоком производства ценности для бизнеса.

Да, этот процесс старается структурировать Scrum и SAFe и прочие метОды. Но давайте говорить честно, по имеющимся методологиям нет научных исследований. Чтобы на базе статистических данных подтверждали эффективность того или иного подхода с учётом контрольных групп, точного учёта всех параметров, исключения большого количества внешних влияний.

Ни к одной из применяемых методологий не были приложены чёткие гипотезы, исследования и фактические подтверждения того, что эти гипотезы подтверждаются. Фактически эти методологии - просто заявления людей о том как они считают и как им бы хотелось работать и взаимодействовать, дословно = манифесты, коим и является Agile

Может быть, дело в том, что у Вас некоторые процессы идут в не в том ключе, как у других? Как я понимаю, Вашей команде заказчикв выделил бюджет на конечный продукт ( трейдинговую платформу ), а как Вы распределите бюджет на задачи, его не волнует.
Я тоже работаю в веб, но у меня ситуация иная. Приходит менеджер, далее диалог: менеджер: заказчик хочет вот такую фичу, сколько это часов?
я: не знаю, мы такого не делали. Мы можем сделать вот такой кусочек за N часов, и понять, что делать дальше.
менеджер: а какая часть задачи это будет? Половина? Четверть?
я: говорю же, не знаю. Мы такого не делали.
менеджер: нет, меня это не устраивает, мне надо сначала продать задачу заказчику.

Та самая RnD задача, о которой писал автор статьи.
При этом на другом проекте, где заказчик просто хочет получить результат (где-то в будущем), такой проблемы нет.

Ну так а причём здесь скрам или не скрам? Неважно как вы у себя устроите процессы, но у вас всё равно остаются две проблемы: вы всё ещё не знаете сколько будет стоить решение задачи, а менеджеру всё ещё надо её сначала продать.

То есть вам в любом случае надо сначала продать клиенту ваш R&D. Или взять на себя риски и назвать ему какую-то конкретную цену за эту задачу.

так тут проблема не самого скрама, а попытка применить его к RnD задачам... у меня от такого тоже болит... и да, скрам тут не работает. нужно смотреть как решать RnD задачи и донести до менеджеров, что этот процесс не укладывается в дейлики и закрытию какой-то таски каждый день

В чем проблема взять задачу-плейсхолдер на весь спринт (спайк, POC, RnD, называйте как хотите). В конце спринта, через условные 10 рабочих дней (в случае 2-недельного спринта) у разработчика появится примерное понимание сколько дней (стори-поинтов) _примерно_ еще потребуется. Далее создаете еще таких же задач в следующие спринты.

Если же вообще понимания не появилось (делаем что-то суперсложное, "тысячи активных крыс в Plague Tale") - ну созадавайте опять плейсхолдер на 1 инженера на следующий спринт и все.

Всем участникам процесса надо быть гибче просто, не надо все воспринимать всё "в лоб".

Задачу на весь спринт, ага. Хорошо если максимальный срок по задаче 3 дня, а если один день? Как будете отчитываться о ходе выполнения задачи, как же цели спринта. Скрум-мастер быстро объяснит в чем вы не правы)

В чем проблема взять задачу-плейсхолдер на весь спринт (спайк, POC, RnD, называйте как хотите). В конце спринта, через условные 10 рабочих дней 

А зачем ? что эта задача дает кроме пересоздания задач каждые 10 дней и переназначение на нее все того же единого разработчика. Какая фактическая польза кроме того что скрам мастер сможет накормить своих детей ведь у него еще осталась работа.

Автор говорит про "неизвестное неизвестное". Эта задача-плейсхолдер снимает первый уровень неизвестности. Ты целый спринт на законных основаниях занимаешься вскрытием проблем и рисков, поиском решения. В результате спринта от тебя ожидают ответа в виде "невозможно никак", "надо так, оценка - 3 месяца", "надо вообще по-другому", "можно обойтись без этого" и подобных. Если через спринт бизнес узнает, что нужно влупить в эту хотелку все деньги мира, наверняка задача резко потеряет приоритет. А в водопаде будут делать до тех пор, пока деньги не закончатся, а потом еще и в кредит, потому что "уже потрачено"

Ты целый спринт на законных основаниях занимаешься вскрытием проблем и рисков, поиском решения. 

Это если можно срок задачи установить в 2 недели. А у фанатичных адептов так делать нельзя, надо декомпозировать, как их не волнует.

Для "(спайк, POC, RnD, называйте как хотите)" допускается планировать хоть целый спринт. Даже если в итоге выяснится, что решалась задача за 5 минут. Адепты, как правило, понимают, что лучше ограничить период неопределенности, чем иметь неопределенную неопределенность. За фанатичных не ручаюсь.

То, о чем мы говорим, это же вопрос культуры и коммуникаций. Если скрам-команда не имеет возможности вернуть обратную связь заказчику и работает по принципу "мы люди маленькие, нам задачу дали, мы будем её пилить пока не сделаем, либо пока не устанем", то, конечно же, никакого спайка, никакой декомпозиции и никакой ответственности не дождешься. Если же команда имеет голос и может в процессе принятия задачи в работу сказать "нет, стоп, нам непонятно, мы не подписываемся", тогда просто задача в работу не идёт. Ну и кто в проигрыше от этого?

В результате спринта от тебя ожидают ответа в виде "невозможно никак", "надо так, оценка - 3 месяца",

А кто сказал что спринта хватит на оценку ? Спринты у кого то неделя а у других 2 месяца. Кроме того кто сказал что эти оцененные 3 месяца хватит ? А если задачу сделают в рамках рисерча ведь рисерч без mvp по таске считай бесполезен, а этот mvp уже зачастую закрывает таску.

В итоге скрам ради скрама а задача была выполнена as is, про разработчика забыли на X времени без рамок спринтов, и он все сделал. И никаких подзадач и оценок ему для этого не надо.

 Если через спринт бизнес узнает, что нужно влупить в эту хотелку все деньги мира, наверняка задача резко потеряет приоритет

На самом деле если команда с опытом то сразу после озвучивания задачи идет оценка типа "изи" или "мы на этом встрянем очень надолго" из которой бизнес уже прекрасно понимает надо ему это или нет.

Hidden text

В итоге скрам полезен для менеджеров и руководства как метод слежения за производительностью сотрудников. Но чисто для работы это действительно ощущается как рак отнимающий время вникуда. банальный канбан с задачами уже покрывает 99% задач. Тут в пример хочется привести Apple / Google которые всухую слились в AI гонке на данный момент, и тот же openAI где по сути стартап мусорка без аджайла и скрама существовала годами, и только такой подход без мозгоделия позволил им реально делать работу а не красивые задачки для руководства.

Еще пример в виде разработки игр в крупных компаниях типа Rockstar и найтидог, мега крупняк с кучей людей, скрамом и аджайлом, а переработок миллион, баги в играх вылазят постоянно, все фиксят в последний момент, куча кранчей. Наверное оценивают задачи плохо, и разработчики плохие, надо наказать их.

А кто сказал что спринта хватит на оценку ?

я живу в мире, где работа над какой-либо задачей продвигает меня в её решении. сами по себе они, почему-то, не решаются :(

может и не хватить, но явно будет лучше, чем на старте.

А если задачу сделают в рамках рисерча ведь рисерч без mvp по таске считай бесполезен, а этот mvp уже зачастую закрывает таску.

идеальный случай. большей частью потому, что решена задача была в рамках установленного ограничения по времени. Х, в данном случае, не "когда нибудь", а вполне себе "через две (подставьте свое число) недели"

На самом деле если команда с опытом

когда команд > 1, то начинается ручное управление:

– эти знают лучше, давайте дадим им!
– но у них уже есть другая задача аналогичного приоритета!
– пусть вспотеют посильнее!

в то время, как рядом сидит менее опытная команда, но которая может немного закосячить с оценкой. даже если они ошибутся на 50%, в рамках спринта это половина. если дать задачу опытной команде, то, по-хорошему, они сделают её в следующем спринте. результат ручного управления - задача сделана на полспринта позже, зато опытной командой. вопросы качества не затрагиваю, в этом диалоге слишком много неизвестных.

Как минимум – такой подход заставит тебя раз в этот самый спринт подытожить, а что же ты выяснил, и какая новая информация появилась.

Потому у тебя будет планирование, где ты подумаешь: а надо ли вообще эту задачу сейчас брать? Может быть ты потратил три спринта, команда поняла что неопределённость особо не сокращается, и за такие деньги нафиг эти тысячи активных крыс продукту не нужны.

Согласись, намного удобнее, чем разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь", а в конце говорит "ну, не получилось"

Как минимум – такой подход заставит тебя раз в этот самый спринт подытожить, а что же ты выяснил, и какая новая информация появилась.

А что мне мешает подытожить это без скрама, без заведения задачек и спринтов ?

Если из вашего же сообщения взять " разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь"" то ему явно нечего еще сказать под конец двухнедельного спринта раз он разбирается в задаче которой требуется "ушёл куда-то на полгода", и тут хоть есть задачка и хоть нет, он работает. А если ему есть что сказать то он и без эстимейта и задач вам это расскажет без проблем.

В той же веб разработке все как в китайской потогонке, все рассчитано и уже готово, только клепай на конвейере. А в сложной разработке с неизвестными алгоритмами и результатами, как у художников, нужна тишина, покой, студя с хорошим светом, вдохновение итд =) Иначе будет как у Microsoft на последней презентации. Показали 5 игр а они все дженерик мусор, не игры с душей и именем а game_1, game_2, game_3, так как все выштампованно из готовых ассетов по скраму с оценками времени, и там небыло времени на полет души и эксперименты.

Так ничего не мешает :)

SCRUM – явно не единственный способ работать работу.

Но фреймворк, при правильном использовании, заставляет тебя задуматься о том, как сделать свою процесс более управляемым.

Разработчику может и хотелось бы сказать "ой, ну я ничего не узнал", но фрейморк пушит тебя завершить работу, зафиксировать результат, и запланировать новую работу (опять же, сформулировав ожидания – что именно ты пойдёшь исследовать, и что расскажешь через две недели)

Разработчику может и хотелось бы сказать "ой, ну я ничего не узнал", но фрейморк пушит тебя завершить работу, 

Что мешает писать заметки по результатам изучения, и делать это без скрама с задачами оценками и переносом задач каждые 2 недели на следующий спринт ?

Я не говорю что скрам не нужен, но я привел пример где он как рак для человека, вы пытаетесь убедить меня в обратном именно в рамках этой ситуации, то вы заведомо проиграли.

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

Так ничего не мешает:)

SCRUM — явно не единственный способ работать работу.

Ты просто в какую сторону воюешь то? Я не говорю, что scrum – единственный способ жить.

Я говорю, что scrum может помочь структурировать в том числе RND. Мы абсолютно друг другу не противоречим)

Структурировать RnD помогает ведение журналов и системное мышление.
Все эти ваши методологии обеспечивают лишь примитивную визуализацию для бесконечно далеких от того, чем вообще занимается команда, людей.

То, что вы описали, можно назвать Скрамбаном. То есть это эдакий канбан поперек скрама. Может тогда сразу уже перейти на канбан?

В чем проблема взять задачу-плейсхолдер 

Я бы так не делал, так как тогда - о чем все. Ну смотрите. Есть человек, он "копает" что-то неведомое. Тут не важно, неведомое вообще, для команды или только для него (хотя эта опция явно требует другого решения).

Но в любом случае у него есть идеи, что он делат. К примеру:

  • ищет варианты решения

  • пробует конкретный вариант

  • формулирует требования

  • ...

И это уже формализуется и легко вносится в спринт

И это уже формализуется и легко вносится в спринт

чтобы внести в спринт нужно оценить.
как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него

чтобы внести в спринт нужно оценить.как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него

Ну смотрите. Если мы примем, что требования к решению есть либо описана проблема, которую надо решить, то очевидно декомпозируются либо требования, либо сама проблема

К примеру, очень сложный пример. Мы хотим долететь до Марса и высадить там Марсоход и вы ищете решение. Очевидно, что начинать надо с декомпозиции задачи, которую повторять многократно. Первый уровень может быть разбиение на:

  • Ракета носитель для выхода на орбиту Земли

  • Ракета для того, чтобы долететь до Марса и выйти на его орбиту

  • Корабль, чтобы приземлить на Марсе

  • Сам марсоход

И дальше разбиваете до требуемого уровня детализации

Если простой пример, медленный отклик приложения. Разбиваем и ищем

------------

Тогда ваша первая задача - сделать декомпозицию. Вот и все

Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу

как оценивать "ищу варианты решения" и уложиться в дедлайн?

Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу

Это и есть ответ :) Не знаешь как делать - бей на части. Либо требования, либо проблему, либо архитектуру решение.

И так часть или части, которая будет разбита до элементов, о которых можно сказать "знаю" - будет оценена и внесена в спринт/план.

Или исполнитель не обладает требуемой квалификацией для занимаемой позиции

-------------

Мне даже грустно писать этот ответ, если честно

Так знаешь как делать.

  1. Набрейнштормить варианты решения - 2 дня с разгребанием, в спринт укладываемся

  2. Копать наиболее перспективный вариант либо до точки отказа либо до получения ясности - мы не можем внести в спринт, так как до брейншторма мы не знаем, что это за вариант, какие ресурсы потребует, какой будет признак отказа

  3. Довести наиболее перспективный вариант до решения или начать копать следующий по перспективности вариант или провести новый брейншторм с учетом полученных на п.2 данных - да, для третьего пункта мы не знаем не только ресурсов, но и что это будет за задача. Вносить в спринт нечего. А за один спринт по 2 дня на гипотезу мы можем и до 5 пункта дойти. А уже здесь вносить нечего.

Ну видите, мы начинаем сходиться. Уже есть первая таска на борде. Как будут варианты - еще раз собираемся и либо декомпозируем дальше, либо оценивает и делаем :)

Главное помнить, что не мы для процедур, а процедуры для нас и нет проблем добавить таску по ходу :)

И дальше разбиваете до требуемого уровня детализации

То, что нужны ракета, марсоход и т.д. — это очевидно, здесь декомпозицию сделать достаточно легко. А вот дальше уже сложнее. Например, в марсоходе нам нужен некий двигатель и некие колёса, ну или что-то вместо них, а их нельзя проектировать совершенно отдельно, потому что от мощности двигателя зависит вес марсохода и, значит, характеристики колёс, которые должны всё это везти, а, в свою очередь, увеличивая колёса увеличиваем общую массу, изменяем габариты, меняются размеры корпуса и передаточного механизма, то есть, это снова может повлиять на требуемую мощность двигателя, а увеличенные размеры нового двигателя возможно повлияют на расположение центра тяжести, что для марсохода может быть критично, и т.д. Нельзя просто взять и разделить конструкцию на отдельные элементы и их отдельно спроектировать. Тем более, если нужно минимизировать размеры и массу конструкции (чтобы легче было доставлять её на Марс).

Конечно, но я специально взял граничный кейс с мега задачей. Если мы остаемся в плоскости планирования, а не как это сделать технически (я тут не претендую на экспертность по очевидным причинам), но именно декомпозиция, которую вы продолжили позволяет в конечном итоге прийти к измеряемым задачам

В нашем варианте это может быть задача определить направления, определить состав групп проекта и т.д.

Суть в том, что камрад спросил - как делать и планировать то, что еще не знаешь как сделать. Ответ прост, декомпозировать то, что знаешь. Либо принять, что ты не соответствуешь позиции :)

-------------------

На самом деле на старте любого проекта возникает такая ситуация, когда ты еще на знаешь, но уже есть конкретные задачи, исполнители и сроки :)

Поэому вообще вопрос вызывает, как минимум, чуток недоумения

В чем проблема взять задачу-плейсхолдер на весь спринт

Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.

В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!

Скрам ритуалы требуют даже по такой задаче плана эксперимента и отчета о результатах - та самая демка "которую можно в прод".
Тем самым механически не дает нырнуть на полгода в свободное плавание переходящее в броуновское движение с одной укладывающейся в WIP задачей канбана в InProgress.
Да можно избегать этого и без скрама. И возможно 100%RnD процесс эффективнее вести не по скраму. Но если вы уже работаете по скраму 90% задач, то и оставшиеся 10% RND логично оставить в том же процессе, если их делают те же люди.

скрам смещает фокус с того что надо делать на вот эти все формальные пляски с декомпозицией и примерно всегда неверными оценками. Нормальные разрабы не уходят на пол года делать непонятно что чтобы потом сказать "не получилось", все равно апдейты даешь команде, но я хочу чтобы это я выбирал когда апдейтить или когда ещё поработать, в идеале, вообще не приходя на дейлик. А не чтобы кто-то мне задавал один и тот же тупой вопрос каждое утро суть которого "дай репорт по задаче", репортить что-либо вообще раздражает.

Так скрам и не просит репортить и конкретно говорит этого не делать как раз. Задача идет - сказать нечего, все ок. Есть блокеры - озвучиваешь. Что-то пошло совсем не так - озвучиваешь, чтобы команда могла скорректировать планы. Вот для этого дейлик и более ни для чего.

втыкаемся в эту проблему.

  1. заказчик захотел

  2. пм с дизайнером нарисовали макет

  3. макет приносят команде на оценку по срокам

  4. разработчику ставят задачу на оценку. эта задача выполняется в течение спринта рядом с обычными

  5. разработчик оценивает

  6. к оценке добавляется x запаса

  7. если не отказались от идеи, увидев оценку - задачу ставят на разработчика, дедлайн = оценка

это тоже ломается об r&d

  1. как оценивать решение задачи неизвестным образом - неизвестно. можно было бы закладывать время на "попробовать варианты абв и выбрать", но для этого нужно комплексно продумать каждый

  2. оценку надо успеть выдать к следующему диалогу ПМа с заказчиком, чтобы они договорились о приоритетах

  3. во время работы по задаче можно придумать лучшее решение, чем то что заложено в оценке. лучшее не значит более быстрое, а значит что в будущем поможет с другими задачами, емли заложиться в нее сейчас

  4. на одной неделе тебе дают задачу x, а через еще две - x'. для решения задачи x не вводили новых сервисов/слоев, а для x' уже не получится. можно было сразу делать инфраструктуру для x', чтобы потом быстро закрыть обе задачи, но не вышло. теперь тебе нужно переносить x на x'. системно не решаемо, тк ПМ не может обобщить

при разработке чего-то реально нового,

Хз в чем тут особенность геймдева, но это работает в любой сфере, если нужно что-то новое сделать, то нужен ресерч

Исследование (рисёч) всегда с неизвестным исходом, в этом его смысл. Но вообще говоря, мысль о том, что исследование нельзя спланировать и декомпозировать, это большое преувеличение.

В начале исследования программист вполне может сформулировать, как он планирует исследовать:
- ознакомиться с такими-то материалами
- если узнает то-то, то проверить такую-то гипотезу
- если это работает, написать прототип
- если нет, то поставить более конкретные задачи на другие исследования
Это уже декомпозиция, которую можно оценивать. Хоть целиком, хоть по отдельности.
Если человек говорит что он хочет "просто посмотреть такую-то тему" без понимания, что и как он будет исследовать, это уже плохой звоночек.

И если этого не делать, человек может месяцами даже не замечать, что занимается ненужной фигнёй. А декомпозиция и оценка (если остальные не понимают в теме - ну ок, не будут ставить оценку, но даже блин кошке полезно объяснить, что ты собираешься делать) спасёт его же самого от непродуктивной траты времени.

Вот эти самые несколько слов, которые толком ничего не значат: "если узнает то-то" и содержат ошибку. Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. Так и выходит, что планирование возможно только ближайшего шага, или просто полагаясь на интуицию и известные величины(вроде известных частей прототипа).

Только исследование, как правило, включает в себя десятки гипотез, до исчерпания идей. По сути, каждая новая гипотеза - новое исследование. Какие именно будут гипотезы невозможно узнать, пока не дойдёшь до них.

Проработка для оценки гипотез почти = проверке гипотезы во множестве случаев, т.е. дешевле сразу код писать. Фактически это то же программирование, но без собственно кода, что ещё сложнее и подвержено большому кол-ву ошибок.

Кстати, если делать по скраму, то "поставить более конкретные задачи на другие исследования" = новому спринту, что = полной потере гибкости. Если делать иначе - это уже не скрам. Цепочка гипотез растянется на годы работы, вместо дня

 Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. 

Да, но это не отмазка ничего не писать в описание задачи :) Никто ж не просит описать все, просто внесите в задачу

Так и выходит, что планирование возможно только ближайшего шага

И все. Дальше напишете результаты и создадите таски для следующих задач

Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке

Мне кажется, вы сознательно себя "загоняете в угол", выполняя буквально правила, которые, по большому счету не нужны

Ну смотрите, идет нормальный проект написания софта. Что делает аналитик/дизайнер? Очевидно копают вперед. Они знают наперед, как будет реализована фича? НЕТ. Не знают. Даже заказчик не знает, так как может оказаться, что "люди с полей" принесут новую инфу.

Но никто не страдает, так как в спринте таска "проработать определенное нанравление".

--------------

Вы ж не на доску работаете, а на результат.

В Вашем примере - а зачем столько деталей? Надо time tracking? Делайте по факту, чтобы заказчик видел? Не надо time tracking - вообще перестаньте себя мучать бухгалтерией. Ну или пусть по факту ПМ ее сводит, раз ему надо.

-------------

Если вернуться к Scrum (What is Scrum? | Scrum.org ), возможно стоит перечитать и посмотреть, а точно ли вы работаете по нему

Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)

Что делает аналитик/дизайнер? Очевидно копают вперед.

Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.

Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы)
-----
В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.

Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта.
Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер.
-----
Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.

Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)

Давайте на примере. Ну честно, когда за плечами 20+ лет, можно промазнуться со сроками, но говорить о не "типовом" проекте ... либо по странному стечению обстоятельств условно архитектра из финтеха засунули в гейм дев и теперь смотрят, как он выгребет :)

Понятно, такая ситуация маловероятна

В остальном ... сорян, я не уловил. Я предполагаю, у вас есть какой-то обширный контекст, но я его не знаю и понять вашу мысль не могу :(

-------------

Если вы столкнулись с тем, что уже надо на кого-то списать "факап" - это безусловно плохо, но вряд ли имеет отношение к общей теме

Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии

Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач

Вопрос в том, понимается ли он. Как его задумали? Возможно имеет место бьіть банальное исполнение каких-то процедур, которые имеют далекое отношение к тому, что написано в исходной методологии

Лично я совершенно не перевариваю идею кросс-функциональности, а также роль скрам мастера, которая породила по сути кучу дармоедов. Остальное выглядит довольно таки рационально и понятно

Также я могу по опыту сказать, что народ вообще забывает, что цель итерации - это в первую очередь, а что делать - во-вторую, из-за чего планинги часто просто превращаются в накидывание пока не закончится капаситет, а потом оно вместе не собирается

Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии

Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.

а потом оно вместе не собирается

Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.

когда за плечами 20+ лет, можно промазнуться со сроками

Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?

Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.

А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.

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

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

Смешались в кучу кони и люди.

Вам говорят, что декомпозиция это отличный навык.

Вы говорите, что декомпозиия не подходит для каких-то задач RnD, потому скрам это плохо.

Простите, возможно в момент написания вы не поняли этого, но надеюсь сейчас до вас дойдёт, что:

  1. Декомпозиция это хороший инструмент.

  2. Нет универсальных инструментов для всего. Для разных задач лучше подходят разные инструменты и это навык инженера - уметь их применять.

  3. Неприменимость инструмента к задаче не делает инструмент плохим.

Ну и отдельно - честно говоря, ваши примеры скорее больше говорят не о том, что в вебе всё просто, а у вас сложно, а о том, что в вебе порядка больше, чем в геймдеве, притом в первую очередь в головах.

Всегда было интересно про геймдев. Со стороны кажется что там кранч на кранче и костыль на костыле и происходит это потому что игру нужно выпускать асап в определенное окно, но при этом большой список хотелок и релиз в духе "все или ничего".

А как это выглядит изнутри индустрии?

Геймдев разработчики всегда игры позиционируют как что-то из ряда вон выходящее. Про "окно" согласен. Но почему игру надо выпускать "асап", а не когда она доведена до ума? Потому что так решил менеджмент и инвесторы ждут (если они есть). Чем это отличается принципиально от релиза в каком-нибудь retail крупном? Там зависимостей от окружающей среды не меньше: топ менеджмент ставит сроки и ждёт их соблюдения, в горячий сезон релизить нельзя из-за рисков все сломать и упустить прибылью. Конкуренты толже могут поджимать.

А так - и в геймдеве бывают нормальные релизы, почти без багов и коанчей (Baldurs Gate 3), а бывает забагованное дерьмо с лопаты и кранчи. Все от комнды и менеджмента зависит, а не от того что это "геймдев".

Да вот поэтому интересно в чем такая особая специфика геймдева, что оттуда историй про кранчи, багованные баги и костыли в виде поездов-шапок больше, чем в других отраслях.

это безболезнено и смешно. никак не сравнить с реальным миром, как баг (и костыль MCAS) у боинга, когда самолёт не может взлететь из-за одного неправильного датчика. или у атомного реактора, но хорошо, хоть защита сработала. пара багов в реальном мире - и самолётам запретили летать. А в это время в геймдеве - набираем предзаказы на новые костыли и баги, кто быстрее заплатит, то будет главным тестировщиком багов!

Я думаю тут дело в том, что даже посредственная и багованная игра, как правило окупается, поэтому менеджеров устраивает что выйдет говно - главное побыстрее выпустить и продать.

Нифига не как правило. Откуда вы это взяли? Да, может посредственная и багованная окупиться, может шедевральная и отполированная провалиться. Но шансы одинаково низкие для этого, и они тем ниже, чем известнее и богаче студия.

Игры с дисков переехали в онлайн сервисы, баги стало возможно фиксить после релиза, а маркетологи с бюджетами геймдева, могут продать что угодно. Единого клиента который платит всю сумму и не примает работу с багами у них нет. Пока окупается можно лить говно в прод.

И повышенная сложность геймдева миф. Большая часть бюджета это 3д модели, заставки киношного уровня и маркетинг. А 2 десятка механик делается за месяц несколькими разрабами. Гемдизайнеры это потом просто как конструктор собирают. В общем самое дорогое в играх это контент который мало связан с разработкой.

Там зависимостей от окружающей среды не меньше: топ менеджмент ставит сроки и ждёт их соблюдения, в горячий сезон релизить нельзя из-за рисков все сломать и упустить прибылью. Конкуренты толже могут поджимать.

Приведите пример, что это за ритейл крупный?

Мне вот про геймдев как раз всё понятно.

Из своего опыта.
Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.

1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд.
2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую.
3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание)
4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.

Если задача длится 2 месяца, нету никаких этапов и рубежей, чтоб оценить прогресс, то это не проблема геймдева, а проблема декомпозиции и оценки задач.

Так вы разбиваете задачу на исследовательские, которые влезают в спринт и в каждой новой указываете направление исследования, на основе того, что наисследовали в прошлый раз. А если получилось в прошлый раз не только наисследовать, но и понять, что надо делать, ставите задачу на выполнение.

Это же тоже никак не связано со скрамом. Независимо от того, как вы работаете, вы каждый день выходите на смену и что-то делаете, и получаете какой-то результат, который примените в будущем. А если вы не можете сформулировать результат после выполнения работы, то и работа выполнена не была.

Краткий ответ - декомпозиция очень важный инженерный навык, с этим спорить было бы глупо.
Однако разбивать RnD задачи на мелкие атомарные части часто не получается, или получается плохо, так как скоуп задачи заранее неизвестен, и часто может измениться на несколько порядков от оценки.

Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".

Но если мало кто умеет его готовить, может не в поваре дело?

Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной. Вернее, есть, и это называется грантовая система. Но это не про разработку ПО.

Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?

У нас RnD задачи тоже есть и тоже встречают сопротивление менеджмента. Но их не так много и для этих целей самых скилловых просто на время освобождают от спринтов. Да, команда разработки должна иметь кахонас, чтобы иногда проталкивать свою повестку.

RnD задачи, по идее - стандартная задача поддержки(которую почему-то уж слишком сильно разделяют с разработкой). "Произошло нечто. Нам кажется, что это не правильно и хочется, чтобы не происходило". И тут может быть так, что причина/исправление за 5 минут ищется, а может - что очень долго нужно разбираться, а как и почему оно вообще произошло.

У меня другое понимание RnD. Вот, например, сидим мы на одном инстансе, который еще с MVP остался, а хотим хайлоад, отказоустойчивость, мультиинстанс, доступность 99999. Вот как этот скачок совершить, продолжая работать в проде, - это как раз задача RnD.

Ну а баги расследовать - такое себе RnD. Опять же, если постоянно возникают баги, которые расследуются неделями, то точно скрам виноват?

ну саппорту разобраться в спагетти-коде доставшемся от разработки - это целый RnD

Это больше на детектив тянет

Повезло, что не на хоррор

Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?

Банальный highload например. Когда стандартные архитектурные паттерны перестают работать. И на привычные инструменты (СУБД, библиотеки, фреймворки) уже нельзя положиться. Когда не понимаешь, где "горлышко бутылки", даже обложившись метриками сверху до низу. Когда не готов дать внятного теоретического обоснования возникающим проблемам. И всё, что ты можешь - генерировать гипотезы и проверять их экспериментально. И когда внезапно выстреливает самая безумная и неперспективная гипотеза, проверить которую решились от отчаяния. Вот какой тут нахрен скрам?

  • подготовка материала по best practice решения RnD задач - менеджеру нужно объяснить, что "это другое"

  • брайншторм гипотез, взвешивание каждой - 1 день

  • задача на исследование каждой гипотезы - покрытие метриками - фиксирование результат(не важно удачного или нет) - 1-2 дня на каждую гипотезу

  • груминг фикса

  • а тут уже дальше технические задачи

что-то такое я предоставлял менеджеру.. )

Ну, генерируйте и проверяйте. Но вообще-то в хайлоаде вполне себе часто видны бутылочные горлышки.

Я прочитал ветку и у меня впечатления, что люди, жалующиеся на скрам и приводящие примеры, чаще не видят, что проблема не в скраме, а в их подходах и, возможно, уровне компетенций. Как следствие идёт перекладывание ответственности на "внешнего врага".

Опять же, даже если мы берём за константу, что вы правы и всё так и есть и даже если скрам вам вообще не подходит, это не делает его хуже и уж тем более раком. Он всё ещё просто не подходит вам.

В самом скраме ничего плохого нет. Раком его делают люди, которые по умолчанию пихают его куда можно, и куда нельзя. И религиозные фанатики, доводящие рекомендации скрама до абсурда.

PS

В нескольких своих проектах я сам лично вводил разработку по скраму. И ничуть об этом не жалею. Просто там он был по делу.

Именно так! Если команда берет задачу и 2 месяца даже не знает как начать решать - зачем брала то?

Если задача не имеет решения для конкретной команды - не поможет никакой скрам. Но, возможно, скрам поможет выявить этот факт побыстрее.

Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной.

Никогда не работал в чистом R&D, поэтому возможно предположу что-то совершенно неправильное. Поправьте меня тогда, пожалуйста, но мне кажется, что Канбан зайдет в R&D на ура. У вас имеются некие задачи. Срок выполнения этих задач очень размытый, и не факт, что каждая вообще может быть выполнена на 100% В то же время имеется ограниченное количество ресурсов (ученых, доступного времени на лабораторных установках и т.д.), поэтому нельзя допустить, чтобы в работе было одновременно 100500 задач, т.к. это будет крайне неэффективно. Соответственно, мы имеем доску задач с колонками:

  • Общий список задач, над которыми еще не начинали работать, но возможно будут взяты в работу. Количество задач нелимитированно.

  • Список задач которые решено взять в работу, но работа над ними еще не начата. Количество от нелимитированного, до некоего предела, чтобы не получилось очень большого списка.

  • Список задач, над которыми ведется работа. Количество жестко лимитировано. Нельзя взять в работу новые задачи, пока не решены предыдущие

Время решения каждой задачи неограниченно. Или ограничено неким приемлемым для всех логическим пределом (нельзя решать одну задачу год, или 10 лет и т.д.) Такая организация не подходит для R&D?

Да - Канбан это наиболее подходящий для R&D инструмент.

Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?

Можно много чего - статический или динамический анализ кода, компиляторы (например для нового языка), формальные доказательства корректности программ, профайлеры, линтеры и все такое. Например в статическом анализе кода (нормальном), используется, так называемое символьное выполнение (не путать с обычным), так вот, полностью его, на реальной программе выполнить невозможно (экспоненциальный рост сложности), поэтому приходится постоянно искать приближение к идеалу, и это - terra incognita

Ну вот честно говоря, у меня почти все задачи RnD полностью или с элементами. И, кмк, элементы встречаются всегда в работе программиста.
Для начинающих это любая задача с вопросом "как?", коих... все. Потом становится всё лучше, но появляются сторонние проблемы. Баги IDE, системы, фреймворков и т.д. Чем дальше, тем больше таких проблем. И решает эти проблемы тот у кого опыта больше вырулить на опыте и общих знаниях, т.к. другие просто не справятся за адекватные сроки. Я одинаковых задач то знал буквально по пальцам руки. Даже если называются одинаково, то делались принципиально по разному через год.

PS: сам я в геймдеве больше работал. Может в других сферах и иначе, но что-то сомневаюсь, что там простая перегонка json-чиков для кодеров.

Но если мало кто умеет его готовить, может не в поваре дело?

Когда я занимался джедайскими техниками, то заметил один удивительный факт. Люди думали, что навык планирования зависит от инструмента.

Пример: У меня проблемы с планированием, а я вижу как хорошо у Васи получается планировать с помощью Jira (или Notion, или Singularity). И начинаю думать, что я научусь планировать так же хорошо как Вася как только начну применять его инструмент.

Только это так не работает. Я не стану хорошим фотографом от того, что куплю себе крутой фотик. Для этого нужно что-то ещё, кроме инструмента, а именно умение увидеть и поймать хороший кадр. И от перехода в Jira у меня не появятся навыки планирования.

Сдается мне, что с декомпозицией та же история. Любой процесс разработки будет идти сложно (хоть ватерфол, хоть скрам), если вы не умеете декомпозировать. Однако я предполагаю, что в скраме проблема с декомпозицией будет лучше видна.

Но многие продолжают думать, что переход на скрам автоматически научит людей декпомозировать/планировать/делать то, что они раньше не умели делать.

И в этом проблема. В ложной связке "я купил пианино - и теперь я классный пианист". Или "Стоит мне перейти на скрам - я сразу стану таким же крутым разрабом как тот чувак"

В целом это основная причина плохой готовки скрама. Что кроме скрама надо знать и уметь много чего, о чем не говорят в силу того, что это сложно и неочевидно. А среднестатистический тренер находится в ложной связке "сейчас введем процедуры дейли, демо и ретро, и тогда научимся всему тому, чего раньше не умели". При этом этот же тренер даже не осознает, что среди навыков, которым надо научиться, может быть умение декомпозировать. И не знает как научить декомпозиции. Но надеется, что на ретро все такие моменты подсветит команда. И та же команда придумает как научить декомпозиции.

RnD задачи разбиваются не полностью на мелкие атомарные части, а только выделяются те части, которые можно взять в ближайший спринт. Перед следующим спринтом задача целиком пересматривается и делается следующее выделение. Зачастую то, что вы делали в предыдущем спринте, полностью выбрасывается, и это нормально, поскольку в этот момент вы лучше понимаете, что надо делать, чтобы вывести фичу.

Собственно, это и есть суть Скрама.

А не нормально и не по скрамовски в этом, что ты можешь выделить атомарную часть на 2 дня при 10 дневном спринте. В итоге или 8 дней стоим 2 работаем, скорость в 5 раз меньше чем могла бы быть. Или пофиг скрам, фигачим новые задачи в текущий спринт.

По скрамовски - это поднять этот вопрос на ретро. Где один из вариантов - уменьшить длину спринта.

Не по скрамовски - забить.

Но если покопаться, то в типичном Scrum-like проекте атомарной задачей на 2 дня делают типа добавить кнопку на фронте, после чего фронтендер отдыхает, пока бэкендер доделает свою часть, девопс поставит релиз, а тестировщик протестирует. Ах да, кнопке на фронте предшествует еще правка макета и требований, пока их не будет, фронтендер не начнет работу.

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

Чаще всего проблема не с методологиями, а с людьми, которые эти методологии применяют. Поработал разок с каким-нибудь упоротым менеджером, а потом ходишь рассказываешь про ужасный скрам. Ну, бывает :)

Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем.
Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.

Проблема в том что упоротых менеджеров слишком много. Так и не встретил адекватных. Везде всякие скрамы и аджайлы применяются как попало.

Ушёл в итоге нафиг из большого ИТ и сам себе техдир, строю свое ИТ в небольшой компании.

я сам лишь со стороны поддержки этого всего знаком, но вот со стороны впечатление такое, что менеджеры просто берут либо тот инструмент, которым они умеют пользоваться (типа "всегда работал в скраме, не хочу канбан - там ниче непонятно") либо тот, который именно им удобен. Не смотря на необходимость и/или удобство для команды конкретно этого инструмента

да и без всякого скрама, меня лид HR вгонял в ступор, обозначая огромную бесформенную гига-задачу на "подумать" и мгновенным вопросом - сколько тебе нужно времени на нее?
Я долгое время думал, что это со мною что-то не так, и наверное когда-нибудь я научусь их оценивать... (а там, например, на одну только четкую формулировку задачи из этого бесформенного может уйти не одна неделя) И вот я стою, представляю, что это может занять от 1 минуты до бесконечности - и прямо так в лоб и отвечаю - может завтра сделаю, а может через год - не знаю)

— Капитан, как скоро вы сможете приземлиться?
— Не могу вам сказать.
— Мне можно, я доктор.
— Я просто этого не знаю.
— А предположить вы не можете?
— Займёт не меньше двух часов.
— Вы так долго будете предполагать?

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

Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 100500 теоретически требуемых фич, а порядок их реализации (и нужна ли реализация вообще) определяется по факту их реального использования в поле. Легкость или сложность оценки задач при этом вообще не важна. Описанное вами является не Скрамом, а, к сожалению, очень типовым случаем, который представляет собой водопадную разработку, завернутую в псевдо-Скрам. В вашем сценарии не имеет никакого значения, будет задача реализована за 2 спринта, или за один, т.к. конечная цель неизменна: реализовать заранее определенный заданный функционал. В такой ситуации Скрам вообще не нужен, т.к. если у нас нет изменений требований в процессе разработки, то нам не требуется Скрам. Если я буду писать софт для управления ядерным реактором, то использовать там Скрам не имеет никакого смысла, т.к. все требования к его функционалу жесточайшим образом уже прописаны на 100500 листах документации, и никаких отклонений изначально не планируется и не допускается. А вот если я буду разрабатывать игру, то Скрам там зайдет просто идеально, т.к. изменение требований может происходить чуть ли не каждую неделю, и ни разработчики, ни сама целевая аудитория заранее не могут 100% быть уверены, что понравится, а что нет.

Когда требования и планы могут меняться каждый месяц...

Вы сейчас описываете не скрам, а аджайл манифесто.

Скрам то изначально и задумывался действительно как противовес ватерфолу и как одну из реализаций идеи гибких методологий. Но со временем вырос в большой корпоративный карго-культ.

"Scrum is an agile project management framework"
https://www.atlassian.com/agile/scrum

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

который представляет собой водопадную разработку, завернутую в псевдо-Скрам.

Я всегда думал, что если скинуть всю шелуху, то весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.

Могу вас одновременно обрадовать огорчить :)

  • Вы на 100% ошибаетесь, когда понимаете Скрам как "серия коротких (длиною в спринт) вотерфолов "

  • К сожалению 99% "внедрятелей Скрама" именно так его и понимают + дэйлики, которые часто длятся по часу каждый день, где внезапно могут начать решать любые проблемы и т.д. В результате народ совершенно справедливо шарахается от Скрам как черт от ладана.

Проблема на мой взгляд состоит в том, что есть два основных ресурса, связанных со Скрам, которые отвечают на вопрос "как", но абсолютно игнорируют вопросы "в каких случаях?" и "зачем?"

Agile Manifesto
https://agilemanifesto.org/iso/ru/manifesto.html
Собственно документация по Скрам
https://www.scrum.org/

Игнорируют они эти вопросы потому, что авторы этих методик прекрасно себе представляли, для решения каких конкретных проблем они создаются, и совершенно не рассчитывали на то, что успех данного подхода в его конкретной нише приведет к настоящему карго-культу, когда Скрам пихают везде и всюду, при этом не имея ни малейшего представления, как он на самом деле должен быть организован, и зачем он нужен.
Дополнительных проблем добавляет то, что другие аджайл методики, не документированы практически никак. Т.е. есть те, кто в теме, и знают, как и когда ими пользоваться, но эти знания передаются исключительно коллегам во время работы. Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности. Между тем имеется целая охапка только наиболее популярных базовых аджайл методик: Scrum, Kanban, Scrumban, Feature-Driven Development (FDD), Extreme Programming (XP)б Dynamic Systems Development Method (DSDM), и еще масса менее известных.
Теперь конкретно про Скрам и ваше заблуждение. Я, разумеется, не могу тут пересказывать всю документацию, но это и не надо. Основной проблемой, которую решает Скрам, является разработка с заданием "Сделай то, не знаю что". Заказчик представляет, что он хочет, в самых общих чертах (хочу программу торговли на бирже, хочу шутер и т.п.), т.к. не имеет опыта, не знает, что понравится его аудитории, как будет работать его персонал, какие конкретно процессы появятся во время и т.д. и т.п. Как эту проблему решает Скрам (очень короткое и поверхностное описание). Мы пилим очень небольшой функционал в течении короткого времени (тот самый спринт) и сразу отдаем его заказчику на обкатку. Заказчик играется с полученной версией и дает отзыв в виде обратной связи, что и как надо поменять, а команда немедленно (уже в следующем спринте) реагирует на этот отзыв. Т.е. имеем список а-ля (просто как пример)

  • Фича A отлично подошла, но там есть пара багов. Вот баг-репорты

  • Фича B получилась неудобной в использовании, уберите ее. Вместо нее нам срочно нужна фича X, которая ранее была с очень низким приоритетом. С этого момента бросьте все силы на ее разработку, что мы получили фичу X как можно скорее

  • Фича C в общем неплохая, но там надо поменять вот это и это. Эти изменения важны, но их приоритет ниже чем у фичи X

Понимаете глобальную разницу между отписанным вами "серия коротких (длиною в спринт) вотерфолов" и данным процессом?

  • Во-первых, если у нас нет нужды менять функционал, и заказчик точно знает, что он хочет получить, что нам не нужен Скрам. Нам необязательно использовать водопад, возможно лучше подойдет другая аджайл техника. Чаще всего это Канбан или Скрамбан (надо смотреть ситуации). Но вот Скрам нам точно не нужен. Более того, даже если мы точно знаем, что функционал будет меняться на ходу, то и здесь Скрам не всегда оптимален. Повторюсь: это конкретный инструмент, созданный для решения конкретной (хотя и достаточно часто встречающейся) проблемы. Если я буду пытаться проделать отверстие в доске при помощи рубанка, это не значит, что рубанок плохой. Это значит, что я - идиот, который использует инструмент не по назначению

  • Во-вторых нет никакого водопада. Мы не разбиваем один большой отрезок разработки на кучу маленьких, а заказчик видит продукт в самом конце.

  • В-третьих заказчик принимает участие в разработке наравне с командой. В водопаде мы берем задание и заказчик может идти спать до даты релиза. В Скраме такое в принципе невозможно, т.к. для разработки нужно прямое и постоянное участие заказчика в процессе.

  • В-четвертых, у нас нет и не может быть сколько-нибудь долгого плана по работе, т.к. никто не знает, что будет разрабатываться даже в следующем спринте, не говоря уже о следующем месяце или квартале. Горизонт планирования - один спринт (обычно 2 недели)

И еще забавный момент. Если спросить "внедрятелей Скрама", какой длины должен быть спринт, то 99% ответов будет: "2 недели". Но если спросить "А почему именно 2 недели? А можно короче или длиннее?", то ответа не будет., т.к. у них нет ни малейшего понимания о вышеописанном процессе. На самом деле ответ очень прост, если знать вышеописанное: по результатам практического использования выяснилось, что 2 недели - наиболее оптимальный срок для заказчика, чтобы обкатать новую функциональность и дать по ней отзыв. Неделя - слишком короткий срок (хотя иногда встречаются проекты, где неделя оптимальна), а 3 недели и тем более 4 - слишком долгий срок без обратной связи, за который можно успеть наворотить массу ненужного заказчику функционала.

> что 2 недели - наиболее оптимальный срок для заказчика

...а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?

Потому что это очень сильный критерий применимости скрама.

абсолютно игнорируют вопросы "в каких случаях?"

Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом

  1. немедленно

  2. на реальных или идентичных реальным задачах

то вот и получился критерий "не тот случай"

а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?

Не в настолько явном виде. 30 дней прописаны в явном виде, а вот насчет времени для обкатки прописаны в виде "Product Goal". Тут мы опять приходим к тому, что создатели не описывали некоторые очевидные для них вещи. "Product Goal" - заказчик доволен текущей версией продукта. Он доволен, если успел ее обкатать и дать отзыв, что там надо поменять. А для этого ему нужно время и т.д.
https://scrumguides.org/scrum-guide.html#the-sprint

Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом

  1. немедленно

  2. на реальных или идентичных реальным задачах

то вот и получился критерий "не тот случай"

Именно так. Только под "пользоваться" надо, разумеется, понимать тестовую обкатку с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.

с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.

Первое требует второго. Хотя, конечно, второе не гарантирует первого.

"В лабораторных условиях" я и сам могу протестить, мне для этого даже и QA не нужен. А реальные задачи вне боевого не тестируются. У покупателя тоже нет лишних сотрудников, которые будут буквально повторять все реальные задачи обычных сотрудников на отдельном контуре.

...и это я ещё про "плавающие ошибки" не говорю ;-)

Первое совершенно не требует второго. Вы путаете тестирование в смысле тестирование на наличие багов и тестирование функционала. Под тестированием в Скрам имеется в виду именно функционал, а не ловля багов. Для тестирования функционала совершенно необязательно выкатывать его в прод. Как в Скрам организуется качество разработки (в смысле отлова багов) - это отдельная большая тема

так чтобы понять "удобно или не удобно" - опять же требуется долгосрочная работа по реальному, каждодневному сценарию.

то, что покажется удобным, в течении 5 минут, может оказаться нифига не удобным за 5 часов. То, что кажется удобным при тестировании одной функции, может оказаться неудобно, когда надо выполнять разные функции (в том числе никак не относящиеся к изменённому функционалу).

условно, в качестве фичи для фастфуда выкатили кофе-машину, в которой оператор работает на площадке, на которую надо по лесенке подниматься. Пока оператор тестирует ТОЛЬКО изменения - всё зашибись. А вот как только из тестового контура передеплоим в боевой, где надо продавать не только кофе, - сразу становится плохо. Но в чистой теории, конечно, если покупатель выделит несколько сотрудников которые в full time будут повторять работу других сотрудников и ничего кроме этого - тогда можно и на тестовом. Либо частичный деплой, берём 5% сотрудников покупателя и переключаем их на работу с тестовой сборкой в реальном контуре.

будь оно иначе - не требовалось бы две недели на спринты давать, хватило бы полдня.

Мне кажется, у нас есть глобальное недопонимание, т.к. некоторые очевидные для меня вещи, для вас неочевидны :) Разумеется, некоторые версии выкатываются в реальный прод после соответствующих тестов на баги. И если по результатам реального прода будет выявлено, что какая-то уже одобренная фича не подходит, то она снова будет изменена. Проект в Скраме не является чем-то застывшим, в.т.ч и уже одобренный функционал. Абсолютно любой функционал может быть изменен в любой момент, если окажется, что он не устраивает заказчика. Это процесс продолжается до тех пор, пока заказчик не будет удовлетворен результатом и / или пока у него есть время и деньги на разработку.

Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности.

Канбан неплохо описан в книгах по управлению производством, правда там отдельный упор на вытягивающее производство, а это далеко от разработки ПО

Может быть я как-то неправильно прочитал Ваш комментарий, но, тем не менее, я из него не смог понять, чем, с Вашей точки зрения, сценарий развития событий в рамках одного спринта существенно отличается от каскмдной модели?

Вы говорите о неопределённости для продукта в целом, об обратной связи. Но разве это не вопрос масштаба?

Нет, если говорить о получении финансирования от внешнего заказчика, который пытается вывести продукт на рынок с высокой конкуренцией, то можно говорить о важности коротких интервалов, необходимости оперативно реагировать на настрой конечного потребителя продукта и рисках проиграть гонку конкурентам.

Но разве это не вопрос масштаба?

Разработчики, к примеру, Windows 95 тоже не знали, что линейку свернут в пользу Windows NT и понятия не имели, какой должна получиться Windows 11. Чем это концептуально отличается от описанного Вами? "Спринты" в несколько лет вместе двух недель? Долго ждали обратной связи?

Так это, опять же, вопрос масштаба.

Необпределенность требований (на отрезке в 30 лет) была? Была. Обратная связь важна? Важна.

Что тогда остаётся от "спринт - это вовсе не маленький водопад"? Условное деление на "готовый продукт" и "кусочек будущего продукта"? Ну так, это опять вопрос масштаба.

Или, всё-таки есть принципиальная разница?

Чем это концептуально отличается от описанного Вами? "Спринты" в несколько лет вместе двух недель? Долго ждали обратной связи?

В т.ч. и это - принципиальное отличие, о чем я писал в этой ветке выше. Продукт меняется не через 100 лет, когда все уже перестало соответствовать условиям, а прямо сейчас.

Так это, опять же, вопрос масштаба.

Нет. Это - принципиальное отличие. Пока вы в вашем "большом масштабе" через -цать лет отреагируете на изменения, эти самые изменения уже 100 раз успеют поменяться и выша реакция не будет соответствовать текущим реалиям. Весь смысл именно в мгновенной реакции на изменения окружающих условий здесь и сейчас. Поэтому в Скрам явным образом прописано, что 30 дней - максимальный размер спринта, а на практике спринт обычно длится 2 недели, т.к. за месяц можно успеть наворотить массу ненужного
https://scrumguides.org/scrum-guide.html#the-sprint

Я, всё-таки, про логику рассуждения спрашивал, совсем не о том, как сделать востребованный продукт.

Вы говорите о том, что есть принципиальная разница между получением обратной связи и реакцией на изменения на коротких временных интервалах и на длинных. И, вероятно, о том, что без оперативной реакции и корректировки направления разработки будущего продукта можно получить то, что заказчику совершенно не пригодится.

И вот это как раз понятно.

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

Но Вы говорите, что нет, это не так потому, что... И далее говорите о вещах которые уже за рамки спринта выходят. То есть, исходный тезис забыт.

Я понимаю, что можно сказать, что я к словам придираюсь (хотя, Вы там человеку намекнул, что он не прав, хотя по его исходному утверждению ничего не сказали, так что, вряд ли это стоит считать придиркой) или что рассуждения о сферических спринтах в вакууме не имеют никакого смысла, но мне кажется, куча людей занимается рассуждениями на тему "Agile vs Waterfall" не замечая, что это классическое сравнение темплого с мягким.

Теперь я понял, что вы имели в виду. Извиняюсь за непонимание. Да, формально в рамках одного спринта у нас водопад. Т.е. вот эти типовые две недели у нас ведутся с заранее согласованным планом, и если рассматривать их обособленно от всего остального, то мы получим 2-недельный водопад. Тут, конечно, можно начать углубляться в детали, что, например, в Скрам нет заданных ролей (т.н. трансформация Т ролей в Х роли), соответственно, по сравнению с водопадом там, например, нет отдельных тестировщиков для ловли багов и т.д., но в целом, да - вы правы: формально получаем 2 недели водопада.

весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.

Вы так говорите как будто это что-то плохое)

Principles behind the Agile Manifesto

Ну, если взять только третий принцип, творчески его перефразировать, а остальные 11 выкинуть - то да :)

Но уже наверное доллжно быть понятно, что оставив только 1/12, вы наверное пришли к чему-то другому :)

Проблема не в методологиях, а в их применении. Если шуруповертом забивать гвозди, то это не шуруповерт плохой, а дурак тот кто взял его в руки. Скрам хорошо ложится на продуктовые компании с плановыми релизами. Но абсолютно не подходит для корпоративных разработок и внедрений где важні сроки и бюджеты. Канбан хорошо подходит для поддержки. А какой нибудь XP для проектов которые прое.... и уже подгорает ж.....

UFO just landed and posted this here

КМК проблема в том, что ПМ и СМ — разные роли. С тем же успехом можно одному разработчику сказать, что он ПМ, СМ, QA, Фронтенд, Бэкхенд и СММщик. Лучше он от этого работать не станет и проблема будет не в конкретном СММ, а в экономии на человеколюдях.

Scrum — рак, убивающий индустрию

Готов подписаться под каждым словом!

Полностью согласен.

Agile манифест, создан разработчиками и и говорит примерно следующее:

Давайте мы не будем называть сроки и стоимость, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.

Потом пришли менеджеры и сказали, мы тоже хотим быть гибкими и представили скрам который говорит о следующем:

Давайте мы не будем ставить конкретных целей и менять их каждый день, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.

Итог: бизнес умер.
ПС: Agile это не методология а список влажных фантазий разработчиков.
Scrum тоже не методология, это продукт инфоциган который замаскирован под методологию для продажи сертификатов. На эту хрень ведутся только только нерадивые руководители которые не способны наладить бизнес процессы в своей компании и ищут серебряную пулю, как следствие тут же попадают на мошенников в лице скрам.

ПС2: Все сказанное основано, на моем опыте, более 12 лет в разработке на разных позициях от разработчика до директора в компаниях заказной разработки. Я точно знаю что ни одна компания разработчик занимающаяся чем то сложнее разработки лэндосов не смогла решить свои проблемы при помощи Scrum и Agile. Все описанные выше проблемы легко решаемы внедрением риск менеджмента, объективных средств контроля и правильного KPI.

Я таких умников видел мало) Чаще только болтать могут, но не делать. Можно внедрить KPI. Только продукты разные бывают. На каждый нужен свой. Все пытались внедрять ещё 10+ лет назад. Тогда ещё встречались очешуенные метрики по подсчёту количества строк кода и премии за них же) И даже про обратное слышал, т.е. меньше строк кода - больше премия. Вот только пока такие умники пилят систему KPI их конкуренты уже продают продукт. В моей сфере это пол года. А через пол года новый продукт, уже другой, к которому и метрики нужны будут новые. Или может ты тут готов ответить за свои слова показав мастерство и указав метрики для всей IT?

Но вообще проблема даже не в методологии а в ее понимании людьми, и в том что ее впаривают тем кому она совсем не нужна.

Скрам это методология развития своего продукта предназначенная для продуктовых компаний и не предназначенная для команд разработки. Роли в скрам всего 3 это Владелец продукта (тот кто пытается построить бизнес), Скрам менеджер (тот кому владелец продукта должен отдать деньги за то что тот научит его правильно взаимодействовать с внешними подрядчиками либо с отделом разработки) и команда (и тут главная проблема, многие понимают под этим команду целиком, хотя подразумевается Проджект менеджер и Архитектор).

И существуют компании и отделы разработки которые состоят из проджекта, архитектора, тимлида, дизайнеров, программистов, тестровщиков и девопсов. И из них только архитектор и пм должны взаимодействовать с овнером в рамках скрам. Сама же команда разработки должна реализовывать вотерфол. Т.е. на каждый спринт в рамках оценки по скрам должно быть написано ТЗ, и по нему должна производится разработка в формате вотерфола.

А идиоты пытаются натянуть методологию предназначенную для 2х ролей и временного помощника. На систему в которой 6+ и больше разных ролей и каждый раз терпят крах.

Когда я это говорил 10 лет назад, мне рассказывали про то, какой плохой водопад и что я ничего не понимаю. Ну, или что надо попробовать и сам все увидишь!

Водопад за 10 лет избавился от своих проблем?

Я за 10 лет не видел водопада ниразу. Я видел только сектантов, рассказывающих об ужасах водопада, и почему я должен принять именно их религию.

UFO just landed and posted this here

"Водопада" никогда не существовало

В молодости работал в аутсорсе. Ко мне приезжал документ с описанием требований к фиче. Я писал дизайн документ, он проходил ревью и утверждение. Потом документ с тест кейсами. Потом писал код.

Если это не водопад, то я даже не знаю... Правда, это было больше 10 лет назад.

UFO just landed and posted this here

Водопада" никогда не существовало как некой целостной "модели управления разработкой ПО, которой все раньше придерживались".

А для кого были писан вагон ГОСТ-ов? Хотите сказать они не применялись в госсекторе и всяких крупных хоз. секторах? Да чего там ГОСТ, в том же PMBOK до середины 2000х итеративные модели не рассматривались.

UFO just landed and posted this here

А что такое "каноничный водопад"? Вики под этот термин подводит любые каскадные модели, в том числе в PMBOK-е опиcанные. Думаю большинство собеседников примерно так же используют этот термин: waterfall - каскадные модели, agile - итеративные.

И много есть каскадов, в которых прям вот не возвращаются на предыдущий этап, но проект выстреливает? Ну то есть увидели ошибку в ТЗ в момент производства, но чертежи не правят?

UFO just landed and posted this here

Было бы интересно, если бы вы привели ссылки на первоисточники, которые упоминаете.

UFO just landed and posted this here

Почитал тот доклад. Кому интересно, вот он (15 стр). Слово waterfall, кстати, в докладе вообще не используется. Вся суть доклада о том, что большие программы (которые он определяет в кол-ве инструкций в районе 100 000) дорого стоят, сложно модифицируются и жить так дальше нельзя :)
При этом в общих чертах описана некая каскадная модель разработки.
Не думаю, что этот первоисточник можно считать каноническим определением waterfall-а, т.к. там ни термин не встречается, ни конкретного описания процесса нет, а только в общих чертах, ну и в конце-концов не определено никакого запрета на "перетекания", параллельность, уточнения и прототипирования.

водопад как 10 лет назад не существовал примерно нигде, так и не существует...

У водопада нет проблем, все адекватные команды его применяют уже больше 60 лет, он идеален для разработки т.к. создан именно для нее. А скрам предназначен для взаимодействия овнеров с подрядчиками. Это не конкурентные методологии они предназначены для разных вещей.

Сарказм? У водопада есть маленькая проблема - абсолютное большинство проектов не имеет полностью сформулированых требований, а если имеют, то эти требования меняются в процессе.

Вы путаете проекты с продуктами. Продукты динамичны и постоянно развиваются. Проекты нет, они выполняются для достижения коннчных определенных целей и задачи проекта всегда известны заранее.

Вся статья пропитана субъективным восприятием по типу

"я из за не умения пользоваться молотком размаждил себе палец, по этому молотки это зло созданное чтобы ломать пальцы"

В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.

Проблема в людях, которые относятся к нему как к унивирсальной пилюле, сующтх скрам туда где он не нужен.

Потом его" адаптируют" и получается нечто что можно охарактеризовать как "работа по спринтам"

А дальше пишут статьи что скрам плохой...

В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.

Как и везде? Было бы странно рассматривать методологию в отрыве от практики ее применения.

Сам по себе скрам неплох, но увы - делают с ним что-то не то.

Если рассматривать скрам как методологию то она хороша. Если как компанию то они моральные уроды которые впаривают скрам там где он не нужен и тем кому он не нужен, обещая что он решит их все их праблемы. Мало того остальные компании берут дезинформацию от скрам и желая приобщиться к мейнстриму начинают врать уже о своих продутках. А в итоге страдают разработчики которые даже не предусмотренны как роль в самой методологии.

Ну когда у тебя и пм и аналитик и скрам мастер это один и тот же человек, а какой эффективности может идти речь?)

Вот всегда было интересно - а зачем нужны одновременно ПМ и срам мастер на одном проекте? Дейлики по очереди проводить и задачки по борде двигать?

ну в теории, ПМ(Product Manager?) должен быть адвокатом бизнес/клиентов команды, в то время как скрам мастер - помощником команды. Объединять их в одну роль, значит создать конфликт интересов.

Ну и по объемам - для маленькой команды с ограниченным потом задач можно еще найти баланс в одном человеке, но когда будет много задач, несколько команд(в теории SM должен поддерживать максимум 2 команды, на деле может быть и 5-6) - то тут будет банальный завал + желание по пути наименьшего сопротивления.

PM -- по умолчанию всегда Project Manager, так же как "филфак" по умолчанию филологический, а не филосовский.

Скажем, PMBOK -- про управление процессами, а не продуктом.

Объединять их в одну роль, значит создать конфликт интересов.

Забавно, что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.

PM -- по умолчанию всегда Project Manage

Я бы тоже рад так думать (меньше путаницы), но в большинстве современных американских компаний, PM это Product Manager. А чистый Project Manager уже давно вымирающий вид. Даже TPM - это Technical Program Manager.

что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.

ну у бизнеса и разработки слишком разные интересы. Дай волю бизнесу, разработка будет в мыле и работать 24х7.

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

Правильно. Но мы начали разговор выше о том, почему объединение роли представителя заказчика и роли представителя разработчиков в одну персону, создает внутренний конфликт интересов и может закончиться не сильно хорошо.

Cоздает внутренний конфликт интересов и может закончиться не сильно хорошо.

Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.

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

Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.

Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).

Для понимания скрам мастер по задумке не должен участвовать в бизнес процессе. Его задача прийти в компанию на 1-3 мес, наладить скрам процессы (как правило написать расписание митингов, объяснить менеджеру что он должен вести продакт лог и делить проект на спринты) и покинуть компанию.

В руках мастера любой инструмент — грааль. Это я так ласково о том, что если не получается танцевать, то, возможно, дело не в балетках. Самое важное в любом фреймворке — это: понимать, когда нужен не он; и правильно внедрить.

Когда я сталкиваюсь с тем, что моя работа не может уложиться в какую-то методологию, и меня спрашивают, смогу ли я селать работу по методологии, я объясняю какую работу я должен сделать (написать код) и спрашиваю менеджера (обычно методолгист - менеджер)

- я рассказал, какую работу я должен сделать, как мастер методологии расскажите мне пожалуйста как мне уложить мою работу в эту методологию?

Я просто перестал считать себя супер профессионалом Скрама (в частности), и что я все понимаю и все в нем знаю. Профессионал Скрама - менеджер, я, как профессионал написания кода пробую найти с ним, как со специалистом в другой области контакт.

На самом деле проблемы у многих команд всего 2: 'Заставь дурака Богу молиться, он себе голову расшибет' и 'Бери ношу по себе, чтоб не падать при ходьбе'

А еще "назвался груздем - полезай в кузов" и "торговали - веселились, подсчитали - прослезились"

Из личного опыта. Во многоих, очень многих случаях скрам превращается в карго культ.

очень много букв, но посыл понятен. Тем не менее, после короткого практикума в скрамтрэке, я наконец понял куда этот скрам пихать надо. Если коротко — в нулёвые проекты у которых есть только идея из которой начинает порезаться проект. Как только проект набрал ход — то там уже рулит канбан.

Проблемы начинаются когда команда не понимает когда какую методолгию применяют, что менеджмент, что линейные исполнители, тогда начинаются проблемы

Однако ловкие продавцы церемоний усвоили только часть:

Добро пожаловать в реальный мир.

Именно так всегда и происходит с прекраснодушными мечтами о построении идеала - в реальности, мечты воплощаются не так как мечтали мечтатели.

Важно понимать, что есть две разные беды:

  • Кто-то неправильно понимает, как использовать методологию, где она применима и зачем нужна. Это не так плохо, можно учиться и пытаться научить людей

  • Кто-то хорошо понимает, что он неправильно что-то применяет. И делает это очень осознанно, так как это позволяет получать зарплаты/премии, руководить все большими коллективами, выступать на мероприятиях, писать статьи и книги. Практически вокруг любого бизнеса появляется толпа людей, которые хотят отщипнуть себе деньги, как только они появляются. В ИТ и в управлении проектами сейчас просто безумное количество денег, и неудивительно, что рядом летают те, кто их хочет. В такой ситуации практически бесполезно писать статьи о том, почему «ХХХ - плохая технология/методология», важно четко понимать, что именно и зачем вы делаете

    Поэтому важно понимать, с кем вы работаете - с человеком, который делает что-то по ошибке, либо с тем, кто зарабатывает на этом деньги

Зачем мы используем скрам?

Потому что надо что-то использовать, а тут есть привычка и отлаженные "церемонии и инструменты". Что тоже неплохо.

Нюанс в том, что под это определение не попадают RnD задачи, то есть задачи, в которых присутствует большая доля неизвестного

Так их туда можно не загонять. В реальности аналитик/архитектор/дизайнер работают все скрама, ну или в спринт-1. Т.е. проблемы нет.

Откройте Agile Manifesto. Вы удивитесь, насколько мало общего такие вещи, как SAFe, имеют с этим документом.

Тут респект за обраащенгие к истокам, к сожалению да. Это проблема и многие реально потеряли "фокус" и понимание зачем

----------------------

Проблема в другом. Люди вообще часто теряют фокус, что и зачем. И по любой методике пинают балду, либо изображают очень занятых на клеточном уровне. Тут не методика нужна, а личный подход

10 часов скрам церемоний в неделю, которые не дают сосредоточиться на выполнении задач, на которых постоянно спрашивают про статус этих задач (хотя статус можно узнать, просто заглянув в Jira).

Это вы сейчас не скрам описали, а что-то другое. Потому что The Scrum daily is not a status pull; if it is - you are not doing Scrum.

Вы мне про теорию, а я вам про практику. Если такого нет, почему я это вижу во многих проектах разных компаний разных стран?

почему я это вижу во многих проектах разных компаний разных стран

Ну значит они используют не SCRUM, а что-то совершенно другое. И соответственно то, что вы описываете, к скраму не имеет никакого отношения.

Потому что везде менеджеры одинаковые и пытаются контролировать процессы? Да, теория разбивается о практику, что люди не готовы терять ощущение контроля. Скрам то тут при чем?

Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. 

Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.

RnD задачи не вписываются в спринты

Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.

Однако ловкие продавцы церемоний усвоили только часть:

  • процесс важнее всего

В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.

И чем крупнее организация, тем более единообразными хочется делать эти процессы.

Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.

А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.

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

Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.

Вы не разбрасывайтесь словами. Kanban! Для автора 33 летний скрам это "новое".

Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.

Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".

И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.

Наверное можно, мне не доводилось видеть процесс, где это хорошо и повторяемо работает. Я бы хотел такое увидеть и понять, как у людей это получается на постоянной основе.

В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить.

К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.

А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер?

Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.

Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.

Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.

Вот так хорошо начал. Скрам плохо здесь, Скрам плохо там. Я подумал что, вот оно, сейчас приземлят на потребности бизнеса, и.... внезапно "Возьмите Канбан в нем нет оценок" я прямо осёкся.

Скрам отлично подходит для своей среды. Особенно, если вы не знаете куда идти. И особенно если Клиент не знает куда идти и какую цель достигать.
Но в RnD проектах ЕСТЬ ЦЕЛЬ. Просто часто непонятно "КАК её достигнуть". Ну так может сесть и подумать? Для этого даже специально обученные люди были.... как их там?... а вот вспомнил! Архитектор программного обеспечения!

А если вы не знаете куда идти, так может остановиться с просить Клиента, " А ты, вообще, какую проблему решаешь?"

Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
1. Что происходит?
2. Когда будет готово?

И ему главное чтобы было: Сказал - сделал. Или выполняй обещания или не обещай. Правильные спринты Скрама дают эту прозрачность. Да и неправильные спринты тоже дают это. Только это называется "план-фактный анализ" и проводится каждую неделю. Часто никак даже не называется потому, что в понедельник нужно понять "Чем они будут заняты и почему я должен им платить?"

Вы подаете свой тезис под соусом "скрам за все хорошее и против всего плохого".
У меня нет претензий к скраму как к методологии. Как мне кажется, это хорошая, продуманная и целостная методология, которая была нужна индустрии, особенно энтерпрайзам.

Проблема (и моя претензия) в применении методологии на практике. Когда скрам спускают сверху, не глядя, а что там за процессы у команд. И когда на крики снизу "нам эти спринты только мешают, ну не ложится процесс на них, приходится выдумывать синтетические костыли" им отвечают "вы просто неправильно работаете, надо по скраму, а вы все по-старинке".

Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:

  1. Что происходит?

  2. Когда будет готово?

Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.

Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.

Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.

В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.

Эмм, ну и что там мы увидим? "Задача....", плановый срок выполнения через 3 месяца, начата неделю назад. Полезной информации почти 0. Точно все идёт как надо и будет сделано как надо и когда надо? А другие пути решения есть? Может более эффективно хотя бы часть проблем решить на уровне коллег по команде, а сейчас они даже не в курсе? И да, если действительно все идёт как надо, ваша речь на митинге вряд-ли будет дольше 30 секунд.

Архитекторы - вымерший вид. В некоторых специальных сферах есть мини-архитекторы - тематики

Архитекторы - вымерший вид

:)

Ну либо вы просто пока еще далеки от них

да, живее всех живых, ну и специализация существует

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

То есть по вашему выходит, что если в ходе классического "системного анализа" выявить подсистемы и реализовать их по-отдельности, а потом совершить "синтез", то есть собрать всё в одном билде, то свойство "эмерджентности" испарится? Всё, потеряли целевую систему?

Отличные наблюдения - мы в нашей команде придумали специальные RnD спринты:

  1. Копим ижесы в течение определенного времени

  2. Объединяем их в вехи - прорабатываем задачи

  3. Проводим что-то вроде защиты, на которой принимаем решение достаточно ли экспертизы для промышленной реализации

  4. Потом уже запускаем стандартный процесс через скрам

Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.

1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.

наверное, зависит от команды. очевидно может быть не всем.

плюс в процессе обсуждения можно выявить, что кто-то увидит подводные камни неочевидные для остальных, тогда такая оценка увеличивает вероятность выявить нюансы.

ну оценка важна, это факт. Но вот концепция абстрактных сторипоинтов - это дичь. Они не нужны никому, любой кто использует оценку всегда хочет поиметь её в реальных днях.

Оценка трудозатрат и оценка сроков это 2 разные оценки. Абстрактные единицы отражают стоимость а не сроки.

Ключевое что мы делали на оценке - это убеждались, что команда единообразно понимает задачу. То есть 3-5 это норм, а 2-13 означает, что один хочет поставить костыль, а второй-написать мини фреймворк. И вот тут надо обсудить, а что сейчас реально стоит делать. Порой это реально не очевидно.
(ну и до 8 это футболки, а не фибоначи, 1 у нас был "полденька с перерывом на перекуры")

А так при нормальной нарезке оценка действительно не важна - если всем ставить 1, а факт будет различаться в 4 раза, то статистически на пяти спринтах все утрясется.

Честно говоря даже читать толком не стал – автор или кто там всё это писал явно не понимает о чем вообще речь.

Скрам это лишь обертка от конфеты, а сама методология является формализацией здравого смысла до которого вы всё-равно дойдете, но со временем и опытом. Любой здоровый проект хочешь или не хочешь приходит к тому, что написано в методологии. И это вообще не связано с IT напрямую, это здравый смысл в целом в любом производстве, будь то фабрика, строительство.. или IT.

Поэтому поливать скрам, канбан, и любые гибкие методологии, это просто неумение их готовить которое выражается в превалировании процессов над здравым смыслом в производстве.

Если не работает и есть сложности – разбирайте сложности и руководствуйтесь здравым смыслом. Всё. Все эти процессы, "церемонии", и прочая типовая лабуда сама придет, но будет служить на пользу, а не потому что так положено.

Просто ищите где рвется, вот весь рецепт.

Кажется, автор отлично описал, где рвётся. В проекте, который разрабатывает новые фичи, интеграции и имеет сложность чуть выше, чем «собрать из кубиков готовый функционал», — чтобы провести оценку и декомпозицию задачи, нужно сначала провести ресерч, который будет содержать до половины реализации задачи и при этом сам невозможно оценить. Для проектов, где таких задач несколько больше нуля, — скрам неприменим, но его там всё равно пытаются применить.

Пример задачи — увеличить размер предзагруженного буфера в плеере до 10 минут. Может быть, это xxs и решится одной строкой в настройках, может s, потому что придётся написать и подменить какой-нибудь класс, отвечающий за буфер, а может 2xl, потому что придётся менять библиотеку плеера. И оценить это за час чтения документации не получится — потому что потом окажутся нюансы: ведь строка в настройках работает, но окажется, что в память влезает только 2 минуты, а свой класс не интегрируется в зависимую библиотеку и т. д.

...а потом (я из легаси) окажется, что после увеличения размеров буфера плеера у тебя печать документов на бумагу стала работать с задержкой в несколько часов. Пока не накопится документов страниц на 100 - принтер даже не начинает печатать. Ну вот так оно когда-то получилось, когда скрам и аджайл свели к "сделай просто, чтобы уже завтра продать".

нужно сначала провести ресерч, который будет содержать до половины реализации задачи

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

Окончание ресёрча и решение задачи (пусть на уровне MVP) - это зачастую синонимы.

P.S. Кстати, вынесение задачи документирования в отдельный спринт/таск *не работает*.

По факту либо ты пишешь полную документацию "сразу в жиру", а весь таск сводится к "переписать из Жиры в Ворд" (но откуда тогда брать человекомесяцы на это?), либо таск на документацию отъезжает на пару лет, а через пару лет какой-то новый техрайтер - с нулевым знанием проекта - приходит разрабам (чьи мозги уже начисто промыты ещё 100500 тасками с тех пор решёнными) и говорит "ну, рассказывайте, что вы там за фигню наворотили два года назад, а я это в Word перепишу, один час вам на всё так и быть разрешу списать".

Но вот действительно - куча народу говорит что "вы не умеете готовить скрам", но показать на своем примере как надо - пока еще никто не показал.

У меня вот недавно была задача по глубокой переработке определенного функционала - ну разбил я ее на части, а толку? Если выложить на прод я могу только все вместе, иначе есть риск что там данные поедут не туда.

Спринты по две недели, а задача вышла на месяц. И что скрам предлагает в таких случаях делать?

показать на своем примере как надо - пока еще никто не показал

Как этот показ должен выглядеть? Расшарить вам доступ до трекера и репозиториев на 1 год? Транслировать все созвоны по ютубу?

Нет, описать конкретный подход вот в подобных случаях. Роли, кто что делает, кто за что отвечает, какие существуют варианты решения и почему выбран какой-то один из них.

Скрам - это ведь когда накидывают задач с лопаты на каждый день и ты бежишь как белка в колесе и нету даже денька расслабиться?

А ещё потом к текущим задачам прибавляются задачи in progress от QA и вообще ни конца ни края не видно задачам.

насчет "бежишь как белка" - это твоё отношение. Можно ведь и по другому посмотреть.

если тебе накидали 100 задач с равным приоритетом - то это твоя свобода и гибкость.
прочитать эти задачи, сгруппировать их для себя (по технологиям, которые нужно вспомнить, по модулям которые надо переписать, по соседним отделам с которыми совместно надо будет решать - как тебе удобнее). Потом берёшь одну группу, по своему выбору, погружаешься в неё один раз и начинаешь пилить "отсюда и до обеда".

конечно, 90% задач пролетают по срокам, но они ВСЁ РАВНО пролетели бы. И твоя реальная ответственность только в ВЫБОРЕ, какие из 10% НЕ будут сорваны.

Собственно, "100 задач с лопаты" это твой личный горизонт планирования себя. Когда ты просматриваешь это список, прислушиваешься к своему самочувствию, и решаешь. Сегодня я "голодный", я хочу закопаться в глубину и нахрен отрефакторить один говномодуль. А завтра я "с похмелья" и трёх переменных в голове не удержу, сделаю я лучше три мелких фикса, которые можно на рефлексах исправлять. И т.д.

Неужели было бы лучше, если бы ты с утра видел ровно две таски, о которых ты ничего заранее не знал, но которые до заката надо отресёрчить, имплементнуть, оттестить и передать в QA ?

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

Детский сад. В нормальном процессе планируются не таски, а работа и результаты. При этом инструменты могут быть любыми Скрам - ОК, Канбан - тоже ОК, банальный эксель с произвольными записями - и то подойдёт, плюс-минус. И RnD планируется тоже нормально. Автору бы спуститься на уровень и узнать, что такое планирование вообще, а потом натягивать на него конкретные методики. Все хотя быть гурами сакральных истин, а всё уже до них давно придумано, только они этого знать не хотят, иначе огонь в глазах погаснет и их идеи не купят.

Проблема не в Скраме как таковом, а в том, что редко где есть хоть какое-то правильное его внедрение и поддержка. Ну не может быть человек с 0 знаний в PM и прошедшего недельный курсы scrum master (для получения CSM), построить какой-либо правильный процесс. Такие курсы должны быть для членов команды, что бы просто понимать общий процесс, или уже для человека с опытом управления проектами.

Scrum это так - общая оболочка. А к нему еще нужен багаж опыта и знания(по объему не меньше классического PMBOK).

Скрам, вотерфол, Канбан подбирают по соображениям атомарности. Кому весь проект сразу, а кому по фиче в день. Атомарность подбирают под жизненный цикл. Например, MVP это вотерфол, а багфиксам со скачущими приоритетами ближе Канбан. Компании часто применяют не какую-то одну практику, а комбинацию их элементов. Но холиварят до сих пор.

Для RnD существуют более подходящие методологии.

Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах.
Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.

Лет 10 назад мы просто работали по самым разным методикам, и всё было отлично.

А сегодня сделано следующее: тому, что раньше никак не называлось, а просто делалось, теперь были придуманы англицизмы (совершенно идиотская их заимствованность, что у нас в своём языке не нашлось слов для этого? Тупейшая мода на англицизмы выдает низкий уровень интеллекта и идиотское следование моде...), совершенно придурошное равнение на запад (ну вот нахуа...), при этом "те, кто не в теме этого сленга" - идут лесом - ещё один идиотизм...

Лет ещё через ...цать до людей начнет доходить вся абсурдность и идиотизм такой моды, равно как и очевиднейшая дискриминация по сленгу.

Ещё и HR внедрили - посадили кучу тупых крашеных девиц с уровнем интеллекта хлебушка и деревенским воспитанием (в лучшем случае), все функции которых может заменить бот-скрипт, написанный на коленке за пару часов.

Можете минусовать, но лет через 10 ещё вспомните этот пророческий пост 😏

англицизм это обычный профессиональный жаргон, удобный тем что отсекает лишние контексты.

англицизм - это явно прописанный namespace/scope/module.

переработка может означать что угодно, например печать газеты на бумаге из макулатуры.
а вот refactoring - это конкретно, и crunch - тоже конкретно.

Я говорил немного о другом.

Ожидаемые минусы это подтверждают (что неудивительно 😁)

Одно дело, если в определенном социальном круге используется свой сленг - это совершенно нормально.

Другое - когда этот социальный круг дискриминирует (относится свысока, пренебрежительно, отчуждённо) к тем, кто этот сленг не знает/не использует.

Происходит именно второе, т.е. это чистой воды дискриминация, причём, по совершенно несущественному признаку.

А к каким результатам приводят подобные дискриминации легко видеть, если изучить человеческую историю :)

Не очень понимаю кого и как может дискриминировать всемирном теневое правительство программистов. Отказать в доступе на порнхаб? Научить хомячка уклоняться от кликов? Заставить чатГПТ придумывать анекдоты тупее чем у соседа?

Если вы чего-то не понимаете - качайте интеллект, чтобы понимать.

Либо оставайтесь на своем уровне развития, получая удовлетворение от осознания собственной причастности к такому же большинству.

Выбор за вами.

неолурк://мне.вас.жаль

пробежал глазами по комментариям, и вроде никто не написал правильный ответ.
Программисты:
- дорого стоят
- текучка
- текучка с угрозами для бизнеса, когда уходит сотрудник на котором многое держалось.

Бизнес соориентировался - необщительных сотрудников быть не должно. Об этом фактически говорят на всех докладах. Вы должны позволять себя вас грабить!
Пусть лучше галера плывет в три раза медленнее, но с уходом любого сотрудника коллективный разум пострадать не должен.

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

...а этот понимающий бизнес нанимает техрайтеров, которые сразу по закрытию инженерной задачи подлетают к разрабу, выспрашивают у него всё-всё-всё, от верхнего уровня идей до неочевидных ловушек на низких уровнях, и записывают это в структурированной и регулярно обновляемой документации?

когда уходит сотрудник

...и чо?

вариант 1: Главный Начальник сдувает пыль с машины времени и заставляет "пустого" новичка, только что из HR, просмотреть в реальном времени все "митинги" с участием ушедшего. Сколько это времени займёт и какой процент этого потока слов новичок реально осознает?

вариант 2: новичку дают доступ к "гиту" и "жире" и говорят - быстро изучи всё, что сделал Вася Пупкин. Переменная количество_митингов_на_которых_послушно_ораторствовал_ушедший, при этом вообще не используется.

Все эти митинги никак не коррелируют с накоплением корпоративного знания. В лучшем случае это самообман.

нет.
РП следит чтобы не было узкой специализации.
Если Вася пишет лучше всех на какую-то тему, то нужно отдать эту задачу кому-то другому. Пусть лучше потеряем время, но компетенция появится у другого человека. (Вася вынужден будет делиться компетенцией).
В итоге, если Васю переедет трамвай, то коллективный разум не пострадает. "Его задачи" делали много кто.

Ничего не имею против такой схемы, особенно если Васе дадут часы на это "делиться компетенцией", но однако причём тут всякие митболы и прочие кнедлики по скраму? Обсуждение инженерных задач инженерами происходит постоянно, без привязки к красным дням календаря и без церемоний. Кнедлики только отнимают время, которое инженеры могли бы потратить на обмен опытом.

P.S. да и РП в данном контексте едва ли относится к бизнесу, скорее это прораб, самый тёртый жизнью из программистов.

Фото про Джиру - это и есть первоисточник Джиры. А потом ее изуродовали не-разработчики.

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

Кучу лет в scrum, если кратко, для себя создал вывод

  1. Если у вас тиражируемый проект, scrum не нужен, нужен waterflow, неизвестностей же нет. Зачем строить хрущевки по scrum :), а вот измененя можно запустить по scrum

  2. RnD это всегда Kanban, даже не пытался по скрам, очевидно, что не получится

  3. SAFE если у вас реально один большой продукт, который вы не можете разбить из за домена. Есть интересные мысли, но имхо очень сложно заставить работать.

  4. Scrum хорошо работает если его уметь правильно применять на подходящих проектах.

И меня, как бизнес, устраивает оценка с точностью 50%

Плюс-минус согласен.

RnD это всегда Kanban

Вот здесь что-то не совсем понял. Изначально kanban пришел из конвейерных производств и главной фишкой его было то, что он позволял визуально выявить проблемные участки, чтобы обеспечить бесперебойное производство. Но если у вас R&D, то как вам kanban поможет?

Хорошо, kanbanом я назвал просто доску, где сверху самое важное, его и делаем, оценки могут быть на задачи, но общие сроки непонятны. Конечно это не канбан тойоты

Ну так и скрам у вас будет точно так же работать. Самое важное, ну то что у вас "сверху", это следующий спринт. Его вы планируете.

Потом вы что-то сделали, как-то показали что у вас в итоге вышло и планируете следующий спринт.

А общие сроки точно так же непонятны. Это ведь как раз основная фишка всех гибких подходов: можно работать даже если точно не знаешь как должен выглядеть конечный продукт. В отличии от подходов когда сначала пишется полное ТЗ и озвучиваются сроки.

разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.

А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.

В 99% обычных задач, я сразу скажу сколько попугаев/маек и буду достаточно близок, а вот с RnD очень непонятно время, даже для очень опытных разрабов... Т.е. подход "копаем с утра и до обеда"

разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.

Вам нужно достичь цели спринта. Но результат совсем не обязательно должен быть "визуально-функицональным". Он должен быть, должно быть определено какой он должен быть и у заказчика должна быть возможность его проверить.

А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.

Вот вы сегодня утром начали копать. У вас есть какая-то цель или вы просто генерируете случайный код и смотрите что он делает?

Ну то есть я кучу раз в скраме делал всякие прототипы и PoC'и всё отлично укладывалось в скрам. И да когда делаешь такие вещи, то часто результат спринта заказчика не устраивает, он выкладывается и начинаешь снова. И да, бывает что в конце спринта вообще нечего показывать. Ну так это нормально.

цель в RnD конечно есть, но как ее достичь никто не знает, даже декомозировать иногда нельзя и результат спринта, должен быть потенциально готовым к проду. Да иногда в RnD садишься и с утра и до обеда ищешь выход, я понимаю, что вы клоните к исследовать такой то ресурс, попробовать то, написать нейронку... но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти. А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна. Или когда берешь тему, потянул ниточку, а там еще вывалилось на год вперед... Конечно можно за уши притянуть, но это все не про задачи на 8 часов...

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

но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти.

Можно. И это не проблема. Вы же можете ставить как задачу "поставить такой-то эксперимент и отчитаться о результатах". То есть результат может быть отрицательный, а задача всё равно выполнена и заказчик может проверить результат.

А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна

Если она вашему заказчику не нужна, то зачем он вам за это платит?

Конечно можно за уши притянуть, но это все не про задачи на 8 часов...

А никто и не говорит что задачи должны быть ровно на 8 часов. Допустимые размеры задач и длительность спринтов вы сами можете определять.

можно так делать и можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены. Если нужно чтобы технология Х дала нужный результат... я обычно делаю цель, а вот сроки очень размазанные и daily не имеют смысла, скорее раз в несколько дней, т.е. это уже не скрам. А так да через спринт поймем куда дальше грести.

можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены.

Ну так это любому подходу к разработке будет "почти соответствовать". А какой-то всё рано надо.

и daily не имеют смысла, скорее раз в несколько дней

Daily имеют смысл каждый день. Чтобы люди, которые работают над одним проектом и/или в одной команде могли синхронизироваться. То есть понять если где-то какие-то проблемы с которыми кто-то не может справиться в одиночку. И это в общем-то единственная цель этих самых daily .

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

Но если удастся раздробить все по 8 часов, то тогда конечно скрам может подойти..

Откуда у вас эти "8 часов" взялись? Кто вам запрещает делать задачи побольше? Надо вам неделю, ну так сделайте задачу на неделю. До тех пор пока задача влезает в спринт это не проблема.

а поэтому смысла в дейли не очень много.

Я не особо понимаю о чём вы. Вам не надо на дейли отчитываться о сделанной задаче. У вас может быть задача на весь спринт, но вы при этом где-то застряли и у вас что-то не получается. Вы это озвучиваете на следующем дейли и другие разработчики прикидывают не могут ли они вам помочь. А вы наоборот слушаете других и прикидываете не можете ли вы помочь им.

все верно, но в действительно сложны RnD задачах другие слабо могут помочь, там в контекст можно пару дней углублятся

Проблемы бывают очень разные. Например банально у кого-то не получается виртуалку запустить. Или при использовании библиотеки какая-то непонятная ошибка вылезает.

Опять же если на дейли всем нечего сказать, то дейли сразу и заканчивается. Мы например его всегда делали по утрам когда первый раз все вместе шли за кофе. По дороге выяснили есть ли вообще какие-то вопросы. Пока машина всем делает кофе их уже и обсудили. А если вопросов нет, то просто взяли кофе и пошли работать.

Для какого количества людей такие daily нужны? То есть, какое минимальное количество людей должно быть в команде, когда они уже точно не знают о выполняемой в данный момент работе коллеги?

Для какого количества людей такие daily нужны?

Для любого.

То есть, какое минимальное количество людей должно быть в команде, когда они уже точно не знают о выполняемой в данный момент работе коллеги?

Каким образом каждый в команде должен узнать что конкретно делают другие и есть ли у них какие-то проблемы? Ну если не разговаривать друг с другом на эти темы?

Ну если не разговаривать друг с другом на эти темы?

Писать текстом в каком-нибудь 'дневнике разработки'?

Или в списке рассылки. Который почтовый и который изобрели... давно. (нет, не чатах - у них с совместимостью, поиском и интеграцией не очень хорошо).

Есть какие-нибудь методики, нацеленные на письменное общение и фиксацию происходящего?

Или у нас в индустрии, постоянно работающей с текстом и, по идее, должной уметь это делать хорошо, так до сих пор и не изобрели ничего подобного?

Писать текстом в каком-нибудь 'дневнике разработки' Или в списке рассылки

То есть писать какие-то дневники или рассылки и заставлять всех их читать по вашему более простой и удобный способ чем просто потратить 5 минут на короткий разговор? Если вообще 5 минут.

То есть вы как хотите, а лично мне точно удобнее просто обсудить дела пока идём за кофе.

Есть какие-нибудь методики, нацеленные на письменное общение и фиксацию происходящего?

Зачем такое фиксировать? Кому это надо? Это проходные вещи, которые уже на следующий день никого больше не интересуют.

То есть писать какие-то дневники или рассылки и заставлять всех их читать по вашему более простой и удобный способ чем просто потратить 5 минут на короткий разговор? 

С некоторой точки зрения - да. Потому что асинхронно - разные люди читать и писать могут в разное время. Кроме того, сам факт записывания - способствует укладыванию мыслей в голове.

Это проходные вещи, которые уже на следующий день никого больше не интересуют.

Те, кто пишут ядро линукса, скажем, так не думают. Архивы доооолго хранять.

Потому что асинхронно - разные люди читать и писать могут в разное время.

Так а тут вам нужно чтобы люди это делали в конкретное время. Потому что речь идёт о блокерах, который не дают кому-то сегодня что-то сделать.

Те, кто пишут ядро линукса, скажем, так не думают. Архивы доооолго хранять.

Это слегка о другом. На дейли могут обсуждаться и вещи вроде "а мне завхоз так и не дал новую мышку".

К счастью, аджайл не ограничивается скрамом. Даже наоборот, скрам
несмотря на все старания не смог убить хорошую идею в основе гибкого
подхода.

Почитал ответы, увы до большинства так и не дошло, что автор сказал. Кстати, чего-то вспомнилось, что когда время позволяло посещать ПМ-конфы замечал, что большинство народа там просто банально безграмотные, то есть они знают что такое "скеджуал", "грумминг" и "рефайминг", но банально никто не понимал, когда спрашивали, например про "цикломатическую сложность задачи" или "факторный анализ".

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

Я когда вижу эти методики, всегда вспоминаю ту веселую книгу 60х годов от разведки США, про "тихую" подрывную деятельность, в которой в том числе было про метрики, совещания и бюрократию)

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

Не надо так. Методологии описаны сферические в вакууме. Дальше надо адаптировать их под бизнес, а не переделывать бизнес под методологии)

Вспоминается вот один проект где:

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

  • задачи не должны быть в работе больше дня. Да - это значит что если задача оценена в 4 дня допустим и декомпозировать лучше ну не выходит - будет 4 задачи (ну или будет декомпозиция весьма условная).

  • задачи должны выполнятся за спринт. потому что графики. по факту если понятно что задача не выполняется (ну ошиблись), она удаляется из старого спринта и добавляется новый (если это фича а не дефект - закрывается и клонирутся).

  • объем спринта увеличивать низзя потому что графики. но при этом бывают что прилетают дефекты либо от тестировщиков либо из внешних источников. заводится задача Буфер-под-дефекты, иногда не одна, и время с нее используется для тех самых дефектов.

Дичь какая. Что за галеры в которых оценки задач в часах и минутах, и не больше дня. Закрывать таски, сроки горят, больше фич, запланировано на следующие 2 часа! Релиз, гроб, кладбище, ПМ.
В таких условиях же вообще невозможно сделать что-либо нетиповое. Ни тем более узнать что-то новое разработчику. Я бы к такому адовому конвейру на пушечный выстрел не подошел.

У любого инструмента есть поклонники и хейтеры, чаще всего хейт рождается по причине того, что хейтер просто не смог совладать с тем или иным инструментом. Рождённый ползать летать не будет. А вообще... пчёлы не тратят своё время, чтобы доказать мухе, что мёд лучше дерьма... не нравится скрам - не пользуйтесь.

Как всегда: проблема в людях, а не в методике)

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

как замечательно, что я даже не знаю что это такое

По поводу R&D - абсолютно согласен. Исследовательские задачи плохо оцениваются, поэтому это просто надо проговаривать. Но и границы нужны, поэтому хорош такой подход

- Через сколько времени погружения мы сможем более-менее точно понять картину и что еще нужно сделать.
- Через сколько времени станет понятно что нужен "план Б" и не добивать эту задачу до конца, или принимать какие-то другие решения.

По поводу "недооценок" - это не совсем верно, потому что тут главное не оценивать сложность точно, а понять сколько сложности мы можем переварить в спринт. То есть - если мы недооцениваем всегда одинаково, то все равно видно сколько таких недооцененных задач по суммарной сложности мы делаем.


Столкнулся с SAFe, впечатления по итогам полутора лет - отвратные. Тот же вотерфолл, только обвешанный модными блёстками. Пришло новое руководство, им стукнуло в башню, что все работают неправильно, и надо срочно всем внедрять SAFe. Почему, зачем, неважно - SAFe - это модно!

1) 3-х месячные итерации(PI), на которые надо подписываться кровью. Изменений в скоупе в течение трёх месяцев быть не может никаких, пришли новые требования/пообщались с клиентом - нет, всё, уже закоммитились, теперь только выполняем. Гибкость потерялась вся. Спринты проходят по 2 недели, но т.к. скоуп поменять нельзя, то смысла в них особо нет.

2) Исследовательские задачи никто не хочет брать, т.к. хрен знает, во что это выльется - а нужны 100% гарантии выполнения 3х месячного плана. И одновременно 100% загрузка ресурсов при планировании. В итоге любая внештатная бага/тикет/архитектурная проблема по итогам дизайна - и люди начинают кроить нужные задачи в попытках выгадать какое-то время чтобы успеть в 3 месяца. Задачи на выход начали выходить подозрительного качества. Техдолг менеджить стало в разы сложнее.

3) Все 20 департаментов по 50-100 человек должны естественно выполнять ритуалы связанные с релиз трейном. Это значит - посещать митинги на сотни человек (по 2-3 представителя от департамента), и что-то там слушать, показывать презентации и отчитываться. Толку от этого - примерно ноль, до этих PI за 6 лет работы в компании я даже не представлял, что большая часть этих людей существует. И с нашей работой они не пересекаются вообще никак. Но все сидят часами на этих планнингах, митингах, занимаемся рисовкой отчётов, рисовкой презентаций на выброс и прочей хренотой.

4) Релизы должны быть синхронизированы! Чтобы все показывали глобальное демо после 3х месяцев (опять на сотни рандомных человек) и чувствовали как движутся вперёд! С учётом пункта (2), при загрузке 100% и требовании 100% выполнение плана - времени релизить нет. Релизы стали выпускаться вместо каждого месяца - раз в три месяца, чисто чтобы под демо успеть. Зачем делать релиз если фидбек с него никак не будет использоваться ещё минимум 2 месяца до следующего планирования?

В итоге имеем падение качества продукта, падение частоты релизов, уменьшение гибкости (по 3 месяца ничего в требованиях менять нельзя), падение качества требований (т.к. надо с заказчиком/РнД/QA/Delivery всё обсудить и утрясти ровно перед планнингом, по актуальной информации, а на такой огромный скоуп это невозможно). В общем, выстрел себе в ногу удался.

Вот вот, но всякие сторонние коучи учат жить...

А вообще если есть зависимости между командами, то проще в двух командах сделать задачи ссылки в спринте, как обязательные, + некоторый commitment на уровне разработчиков. все равно же планируем исходя из того, что 70% можно только запланировать, остальные 30% на всякий саппорт уйдёт. Мне это гораздо больше SAFE понравилось, главное никого не отвлекаешь на эти ритуалы дурацкие. Блин, ночь торгов, придумали же, чтобы котики велись на эту чушь

От такой "работы" даже не выгорание наступает, тут психическое расстройство может случиться. Если бы Кафка был жив, он бы наверняка написал что-нибудь про современную индустрию разработки ПО.

Пока все радуются от систем типа copilot для программного кода,
я уже всерьез задумался о создании помощника для ведения задач в jira, (а заодно и актуализации вики).

Примерно полтора десятка ссылок на задачи в jira и страницы в вики, связанных с одной разработкой.
Если в работе параллельно четыре - пять задач, и в каждой по столько ссылок, которые нужно актуализировать, то... я меньше времени код пишу, чем статусы в задачах переставляю, и вики актуализирую :)

Проще надо быть, я забыл о jira, передал просто на доски кайтен без скрам, просто их расположился опреленным образом, бесплатно все и очень функционально

Все это дело годится только для контрактов поддержки и сопровождения, также, возможно, заказчики - частные компании тоже подойдут. Но аджайл совершенно не подходит для заказчиков из гос.сектора, и тут, как говорится, от тюрьмы и от сумы не зарекайся. Гос.заказчик обязан принять результат, только если он соответствует всем требованиям контракта, а исполнитель начинает лепетать про договорённости, "слонов, которых хотели съесть по частям", важность общения.

У меня сложились аналогичные впечатления: Scrum противоречит Agile. Но мне кажется причина в требовании коммитмента на сроках. То из-за чего:

... сотрудники находятся под постоянным давлением из-за того, что задачи не ложатся идеально на спринты

В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии. Мы все жертвы когнитивных искажений которые приводят к ошибке планирования. Он scrum переводит ответственность за это на разработчика.

Но мне кажется причина в требовании коммитмента на сроках
В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии

Во-первых, agile и гибкая методология это одно и тоже, это буквальный перевод.

Во-вторых, agile в целом ничего не говорит про коммитменты, он скорее про коммуникации и построение процессов вокруг коммуникации, а не вокруг документации. Сверху можно навалить больше методологических слоев, которые уже помогут зафиксировать сроки, обработать риски и прочее, например - тот самый SAFe.

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

В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии

Я имел в виду что коммитмент противоречит духу Agile. А не ставлю противопосталяю Agile и гибкую методологию.

Я бы так не скзазал. Мое понимание Agile таково, что он про гибкость, но это не исключает коммитменты. Просто не нужно делать коммитменты, которые исключают гибкость: например, можно зафиксировать бюджет, что зафиксирует человеко-часы, но при этом будет гибкость по деливери.

С другой стороны, можно зафиксировать скоуп, но тогда либо сроки будут плавать, либо качество.

Не на разработчика, а на команду. Ну и вообще commitment - сделаю все от себя зависящее, чтобы это случилось, вроде как нормально звучит... У меня раз в команде был не очень надежный девелопер, он мог просто забухать за пару дней до демо, ничего как то раскидывали, делали, вот зрелость команды крайне важна.

в конце-то концов на разработчика.

вроде как нормально звучит... 

Для меня не нормально. Когда ты можешь быть уверен, что сделал все возможное?

 У меня раз в команде был не очень надежный...

Для него я думаю и commitment не проблема

Это внутренняя ответственность каждого, если что то идёт не так, скажи команде, тебе помогут, если задача важная. Команда чётко понимает, сделал ты все возможное или нет, поэтому команда зрелой становиться через год работы друг с другом, когда все понимают кто и что выдаст и помогают друг другу. Иногда уходит меньше времени.

Я бы сказал, что помощь друг другу - важнейшая часть скрам.

А если кто то систематически косячит, то команда его вытолкнет со временем.

Да-да все Scrum Musters так говорят на тренингах. А по факту спринт набит под завязку и чтобы переключиться, нужно что-то выбросить, вводить в курс тестировщика или аналитика - себе дороже.
Но вообще я не об этом. Мы можем много спорить о деталях, о том что я не умею его готовить и тп. Но мой основной тезис - откуда в гибкой методологии взялся commitment? Commitment - не может быть гибким по определению, а это сердце Scrum-a.
Нам под соусом Agile (который я поддерживаю) завернули не понятно что.

Теплое с мягким путаете. Я даже не хочу общаться с распиз...ями, которые не берут commitment , мне "ехать", нет результата - до свидания.

Теперь про гибкость, гибкость заключается в том, что не надо выполнять все задачи спринта, это лишь доп фичи.. Более того, если у кого то задача сильно больше, то ему помогут, если задача важна.

Я вам это говорю, так как я не теоретик с треннингов, а практик.

Похоже только вам известно, что такой гибкость.

 Я даже не хочу общаться с распиз...ями,

Вы перешли границы. Я не собираюсь продолжать этот спор, потому что это не конструктивно. Дискуссия должна вестись с уважением к собеседнику, и если этого нет, то нет смысла продолжать. Желаю удачи в дальнейшем.

жаль, что вы приняли моя слова на свой счет, вообще я под распи..ями имел ввиду некоторых особ, которые могут забухать за пару дней до демо... т.е. они не держат commitment, ну забухал я , не смог....

По поводу того, что скрам подходит для проектов сопровождения это отчасти правда. Вы пробовали сопровождать 1С. Там на лёгкую на первый взгляд ошибку могут уйти дни