Зачем спринты?
За все время работы в айти я не понял, зачем нужны спринты.
Как правило, спринт — это период от двух недель до месяца. В него набирают задач и пытаются их сделать к концу спринта. Потом спринты оценивают: этот был лучше, чем в прошлый раз, а этот хуже. Тут собрали двадцать стори-поинтов, а тут восемнадцать. Проводят ретро, которые убивают время.
Все это кажется мне бредом. Зачем делить время на равные участки? Зачем считать стори-поинты? Какое знание дает цифра 18 стори-поинтов? Чем это хуже, чем 20 поинтов?
В чем проблема, если задача из одного спринта переносится в другой? Кто от этого пострадал? Если задача не умещается в спринт, то может просто не впихивать невпихуемое?
Нужно обсудить процесс? Так проведи серию звонков 1 на 1 с разработчиками. Не обязательно ждать ретро.
В моем понимании процесс управляется релизами. Скажем, поставили мы задачу выкатить новый релиз через два месяца. Договорились, что в релиз войдет то, се, пятое-десятое. Не успеваем? Что-то упрощаем, что-то откладываем в следующий релиз.
Зачем нам спринты? Почему все следуют карго-культу гуглов-амазонов? Нужно думать своей головой, а не как менеджер Гугла.
UPD: сюда же относятся эстимейты. Воистину, самое тупое и бесмыссленое, что есть в айти. Эстимейтить все и вся, ошибаться на порядок и потом рвать задницу, чтобы успеть.
Нашли ошибку? Выделите мышкой и нажмите Ctrl/⌘+Enter
Болгарин, 2nd Dec 2024, link
“рвать задницу” – вот как раз для этого. Это ж все не для удобства наемных сотрудников придумано, а для капиталистов, чтобы выжать соки по-максимуму.
Роман, 2nd Dec 2024, link
Чтобы узнать скорость, нужно измерять пройденное расстояние через равные промежутки времени.
Это скорость.
Тем, что разработка замедлилась и надо как минимум попробовать оценить причину и возможно задуматься о какой-то корректировке процесса.
Если это не большой факап, то никакой проблемы нет. Ну и в общем-то это не проблема, а скорее сигнал. Сигнал, что что-то идёт не так.
Именно так
И чем это отличается от спринта - те-же яйца только в профиль. Опять выделили срок и выделили объём работ. То что, срок больше и он не фиксированный - так о всех косяках вы узнаете к дате релиза, когда править уже поздно. Дальше или полный факап или грубой силой релизим во чтобы то ни стало. Именно так как правило и делается, а потом вдогонку тонны багфиксов на скорую руку, овертаймы и стресс
Потенциальные проблемы обнаруживаются максимально рано и есть возможность что-то подкорректировать не в режиме «жопа в мыле за день до релиза»
Всё и вся не нужно, но совсем отказываться это тоже бред. Разработка стоит денег, как-то оценивать разработку нужно. Насчёт «на порядок» - в свое время один коллега поделился со мной эмпирическим правилом, которое довольно неплохо работает :) - оценочное время на разработку нужно умножать на ПИ.
Ну и в заключение добавлю - все эти спринты и эстимейты, вернее их применимость в конкретном проекте, критически зависят от квалификации менеджера проекта, что в реальном мире как раз встречается исчезающе редко.
Грамотно разбить проект на спринты выглядит как изи-бризи, что подкупает молодые и неокрепшие умы, которые начинают мнить себя гениями менеджмента, но это нихрена не так и работа PM-а не так проста как кажется. В итоге в большинстве случаев, с которыми сталкивался я, вся эта возня действительно выглядит как профанация, но это не отменяет того факта, что схема вполне обоснована и имеет право на жизнью
Юстас, 3rd Dec 2024, link
Наёмные сотрудники тоже хороши. Проверено. Взять хотя бы фрукта из второго комментария.
Это не скорость. Скорость меряется неизменными… кхм, как это по-научному называется… порциями. Величина сторипойнта же может “плавать”.
Если задачу оценили как “влезающую”, а она таки не “влезла”, факап, очевидно, есть. Большой или маленький - не суть, суть в том, что план оказался недостаточно чётким. И с этим в очередной раз было сделано нихрена потому, что “Если это не большой факап, то никакой проблемы нет.”
Спринт - попытка набить во временной отрезок решаемых за этот временной отрезок задач. “выкатить новый релиз через два месяца” - наоборот.
Более абстрактные вещи не трогаю - нам бы с базой сначала разобраться. Либо по ту сторону баррикад какой-то совсем бастардизированный аджайл - либо у нас тут рецидив типичной айтишно-ПМской проблемы, одни и те же термины значат в общем-то разные вещи.
Ну, да. Потому, что делаются не на базе документации (по текущему состоянию проекта + хотя бы высокоуровневый план требующихся в релиз изменений), а пальцем в небо. Как я своими глазами наблюдал в своё время. Техлид читает описание задачи вида… ну, скажем, “применить стили на чекаут” (почти дословная цитата, это ВЕСЬ текст в задаче), изрекает “Я сделаю эту задачу за 6 сторипойнтов - но на этот спринт я занят, поэтому делай ты за 8”, скрам-мастер подмахивает… а через две недели становится жидко-жидко.
Роман, 19th Dec 2024, link
Вот как раз разбить на одинаковые порции и есть задача PM-а. К сожалению это редко соблюдается, но это проблема скорее в целом низкой культуры разработки, когда PM это просто «чувак, который проработал у нас дольше всех»
А так именно по задумке это (количество стори-пойнтов в единицу времени) именно скорость разработки. Да оно блин даже называется «пойнт», что как бы намекает.
Зачем переиначивать и выдумывать? Про «никакой» проблемы не было ни слова - я ясно указал, что это сигнал. Сигнал задуматься, что у нас что-то идёт не так. Небольшой факап может иметь вполне понятные причины, типа заболел человек, что не является критичной проблемой так как причины ясны и понятно как это фиксить.
А может быть, что никаких видимых проблем нет, но скорость разработки снизилась и в спринт «не влезли» и вот это уже реальная проблема, потому, что непонятно, что именно делать и как проблему решать. И тут уже возможно всё - от прямого саботажа, до выгорания сотрудников. И вот это уже то, что можно смело называть «проблема».
«Недостаточно четкий» план это уже вопрос к компетенции PM-а. Опять же спринт как раз позволяет выявить эти «нечеткости» как можно раньше.
Сфига ли это наоборот? Тоже самое, только более крупно. Что такое новый релиз - это тот-же набор фич, которые в свою ни что иное как задачи. Или по вашему это просто «че-то пилим, а через два месяца просто вывалим что есть?». Ну коли так, то у меня для вас плохие новости … хотя такой подход «..як ..як и в продакшен» тоже довольно распространён
Приехали … «смешались в кучу люди-кони» …. весь этот скрамо-аджайл это как раз попытка уйти от высокоуровневых планов к минимальным но вполне ощутимым и физически реализуемым в рамках спринта изменениям. Вы походу не вполне понимаете о чем говорите. Если есть документация и план то какой нахрен аджайл и зачем он тогда нужен?
Юстас, 19th Dec 2024, link
Не знаю, какая была задумка. С моей точки зрения velocity - мера общей нагрузки на команду и к скорости отношения не имеет.
Между “налить хоть сколько воды в десятилитровое ведро” и “налить десять литров воды хоть в какое-нибудь ведро” разницу видите? Так яснее?
Аргумент взрослого человека, которому надо объяснять разницу между подходами к планированию с помощью вёдер и воды. Да. Я хотя бы нашёл в себе смелость кинуть ваш айтишный гадюшник, чего и Вам желаю.
Юстас, 20th Dec 2024, link
А теперь самое вкусненькое.
Дело не в “чтоб как в гугле”.
Дело именно в думаньи своей головой.
С чем в 2024 году большие проблемы.
Работа управленца сама по себе не сахар. А уж в такой мудрёной сфере как IT и подавно.
Даже если объект управленческой деятельности счислим и понятен управленцу, раскид ресурсов по времени требует довольно специфических навыков, которым не во всех университетах нормально учат.
В IT же надо вдобавок ДОСКОНАЛЬНО разбираться в управляемом объекте, чтобы ХОТЯ БЫ не снимать лапшу с ушей на каждом митинге. Ну и адекватно организовать постановку задач и контроль.
А лапша будет. Много. По причинам, которые как-то неприлично обсуждать. Все всё понимают, не маленькие.
Поскольку как минимум на постсоветском пространстве управленец-айтишник - краснокнижный зверь, приходится работать с кем есть.
Т. е. либо уламывать техлидов/архитекторов, которые не хотят менеджить официально по тем же неприличным причинам.
Либо охотиться на людей с двумя высшими образованиями, что бьёт по бюджету найма при плохопредсказуемом выхлопе.
Long story short, рано или поздно бизнесу приходит в голову наиохеретительная идея: а давайте примем сертиифкат “PO/BA за две недели” как достаточный критерий для найма PO/PM!
Две недели слушанья охренительных историй, конечно же, не заменят вышки.
Зато “лучшие практики PO/BA” из яндекс.дзена , которыми незрелая дорвавшаяся до должности молодёжь пытается компенсировать нехватку нормального образования, начинают применяться направо и налево там, где им не место. . .
Роман, 20th Dec 2024, link
Я вижу, что в планировании вы не разбираетесь, плюс очевидные проблемы с абстрактным мышлением. При этом даже не понимаете этого. Судя по тому, что как вы пишете «ИТ гадюшник» вы покинули, это лишь подтверждает мои догадки.
В ИТ? Ну приехали - а в других областях это не требуется? Везде кроме ИТ я так понимаю кристально честные и компетентные эльфы работают? Да и задачи можно ставить «на от..сь» и контролировать видимо необязательно. Детский сад какой-то.
Перевожу на русский - не осилил. И всю вину перевалил на «ваш айтишный гадюшник». Ну что сказать - смельчак каких мало.
Любопытно - в какой сфере вы нашли себя?