Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
У меня всегда было чувство, что скрам придумали в первую очередь, чтобы мочь продавать такой Продукт как Официальные Тренинги и Сертификации. Certified Scrum Master (TM).
Вы классно сказали, посмотрите не на кол-во жир, а на изменение метрик в проде.
Посмотрите на типичную Scrum-команду.
Вот это всё описанное ниже - это уже не Scrum. Это карго-культ под маской скрама, или скрамно́, или ещё как угодно. Да, продавцы скрама постоянно твердят, что-де все ритуалы обязательны, действительно допродают дополнительные фреймворки. Но это их история.
А так нигде гвоздями не прибито, что спринт обязательно должен быть 2 недели, а планирование - 2 часа. Умеете быстрее - делайте быстрее. Более того, уже лет 5 назад 2 недели считалось в иных местах слабым показателем.
Вместо спринтов я предлагаю поток.
А это практически в чистом виде Канбан.
А что тогда такое Scrum по вашему?
Система работы короткими итерациями фиксированой длины (это основное отличие от прочих agile методологий), с получением готового к проду продукта в конце каждой. Исходно задуманная как средство выживания в условиях быстро изменяющихся требований, это вы верно заметили.
Разумеется, привязка к календарю несёт некий оверхэд в плане реагирований на эти самые изменения требований. Но а) эти требования надо ещё сформировать, между инсайтом от рынка и требованием в любом случае лаг будет; и б) можно спринт и однодневным сделать: это всё ещё будет скрам.
Встречал мнение, что использование скрама без WIP-лимитов крайне часто превращает его в мини водопад, когда задачи массово доезжают до последних стадий под конец спринта и перегружают систему: типа на QA или продактов сразу вываливается большой объем работы по приёмке.
Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
Аргумент про карго-культ я слышу каждый раз, когда кто-то критикует Scrum. Мол, проблема не в Scrum, а в том что его неправильно готовят. Но если подавляющее большинство команд «готовят неправильно», может, проблема всё-таки в рецепте?
Однодневный спринт формально возможен, спору нет. Но вы видели хоть одну команду, которая реально так работает со всеми церемониями? Планирование, ревью, ретро каждый день? Это же абсурд. А если церемонии убрать, чем это отличается от потока?
По поводу канбана, пересечение есть, не спорю. Но я говорю не только про организацию потока. Я говорю про то что сами роли в команде и скорость работы изменились настолько, что фиксированные итерации любой длины становятся лишними. Канбан про то, как двигать карточки. Я про то, что карточки стали другими, и люди которые их двигают тоже.
Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
с AI-инструментами заменяет трёх узких специалистов ... этому инженеру не нужен Scrum, чтобы быть продуктивным. Ему нужно понимание продукта, доступ к проду и свобода действовать.
К такому комбо надо бы добавить материальную ответственность за функционирование продукта. Катнул на прод ИИ-слоп который сложил сервис - минус 50% премии и замечание/выговор. Три замечания - и нам с таким ИИ-инженером не по дороге. И вот что интересно - когда людям приходится отвечать своей зарплатой за ИИ-выхлоп, то "внезапно" производительность такого уникально ценного передового ИИ-ассистед инженера резко падает до исходных значений, или даже ниже. Потому, что когда человек что-то делает сам, он машинально адаптирует и делает множество проверок "в голове" прямо в процессе работы. Как правило, это "задел на будущее" или "что-то тут не очень хорошо получается, наверное я что-то пропустил в исходной постановке - а не уточнить ли мне этот вопрос".
Пока что все диалоги с адептами ИИ выглядят так:
Я написал офигенный продукт с помощью ИИ!
Им кто-то кроме тебя пользуется? Он тиражируем? Насколько он масштабируем?
Пока только я, вот докер контейнер, я не думал
Через пару дней продукт становится неинтересен и отправляется на кладбище петпроектов на гитхаб. В общем, СДВ в чистом виде. Сделать 30% от PoC спомощью ИИ, понять что дальше надо пахать, забить болт и уйти срочно писать еще более интересный проект - и конечно "с чистого листа"!!! Ибо ИИ-ассистент хорошо генерирует бойлерплейт, а вот с пониманием кодовой базу у него так себе, как у стажера
Спорное мнение, одно из тех, когда со всеми словами согласен, но не можешь согласиться с общим выводом.
Пока Scrum, он как демократия — наихудшая форма правления, если не считать всех остальных.
Да, ритуалы раздражают, особенно когда проводятся формально. Да, две недели — искусственный срок. Упрёки можно продолжать, но что взамен?
Команда из четырёх-шести человек. Все фуллстеки разной глубины, но каждый способен довести фичу до прода. У каждого есть понимание продукта, его пользователей, его бизнес-модели.
Это верный путь вытащить очередную галлюцинацию ИИ в прод. Может для развлекательных и сервисных приложений это может сработать, но для приложений критической инфраструктуры это катастрофа, путь в бездну.
Когда листаешь ленту шортсов (каюсь), то время от времени попадаются ролики полностью созданные ИИ, в которых сразу ощущается некая вторичность, как многократно переработанный продукт (чем по сути является выход ИИ). Вам это неочевидно, но ваш путь ведёт к такому же, но в приложениях — к череде вторичных клонов. Ваш метод не сможет их сдержать, даже Scrum, не сможет, но он хотя бы создаёт трение этому процессу.
Постирония в том, что у вас создалось ощущение, что ритуалы Scrum лишь "создают ощущение контроля". Вы просто на втором уровне абстрагирования, но ещё не осознали этого.
когда вы в последний раз выходили со стендапа с мыслью «вот это было полезно», а не «ещё пятнадцать минут жизни, которые я не верну»
Ни разу. Ни разу не был на стендапе. В тех двух компаниях, где я поработал за 13 лет, такого не было. Сейчас есть летучки по утрам, там раздают задачи на день. Менеджеры договариваются между собой, у кого есть что срочное или не срочное, а мы говорим, что всё сделали, хотя это и так видно по закрытым задачам. Обычно, вместе с проверкой, что все на работе, и болтовнёй о том, кто как зубы полечил, это занимает не больше 20 минут. Иногда 10.
Задачи я не обсуждаю. Мне командуют — я делаю. Надо это кому-то или нет, не моё дело. Я сделал — мне заплатили.
два фронтендера, три бекендера, девопс, QA, дизайнер
Кучеряво. У меня обычно было, что один фронтендер, один бэкендер, а дизайн уже нарисован, но можно считать, что дизайнер всё же есть. На прошлой работе были два тестировщика на всю компанию, сейчас иногда появляется фрилансер, но обычно заказчик сам тестирует на проде. Как оно попадает на прод, знают бэкендеры, у них там где vpn, где просто по ssh, я без понятия.
Судя по тому, что везде знают аджайл, я даже не уверен, смогу ли я сменить работу, я слишком дед.
Как и любая методология, это не прямое указание действия, а набор рекомендации. Все адаптируется под конкретный процесс.
То что у автора нет планирования разработки на пару месяцев вперед хотя бы - это понятно. Но не у всех же так.
Я считаю, что планирование разработки на 2 месяца вперед в современном мире - это не только не полезно, но и вредно. Такое длинное планирование нужно только в очень специфичных продуктах, где важен комплаенс или очень высокая безопасность. В большинстве приложение такие сроки планирования - это абсурд
Там где я работал по спринтам в 2 недели, эти спринты наоборот помогали команде разработки, потому что человеку вот накидали задач, и он защищен от ежедневной МарьПетровны, которой надо перекрасить кнопки в жопно-розовый с наивысшим приоритетом. Для действительно горящих задач в спринте выделялся буфер в 1 день, но их надо было согласовать, обосновав срочность.
Что же касается итераций разработки - в разных местах бывает разное. Если задачи позволяют выдать за день мвп и накладывать заплатки на каждый чих - возможно есть смысл просто в канбане жить, с другой стороны серьезные фичи в ответственных местах можно делать и полгода, и пока на них знак качества 15 человек не проставит, к проду их не подпустят. И тут фикс. итерации это меньшее зло, т.к позволяют хоть как-то увидеть траекторию проекта
Очередной скрамбан.
Кажется 90% недовольных скра ом понятия не имеют, в чём же его суть.
Ритуалы ритуалят и удивляются, что не работает.
Ну так и канбан без понимания сути у вас не заработает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum должен умереть