Comments 120
Если "продуктовый майндсет" это отсутствие нормальных компов и доступа к интернету ключевых разработчиков, то да, я пожалуй, потеряюсь.
"работа спринтами. Люди, не готовые работать в авральном режиме"
????
имелось ввиду, как я понял, на постоянной основе. Есть люди, которые не готовы постоянно так работать
Как так? Почему должны быть авралы, если команда сама определяет цель спринта и планирует, что будет поставлено?
Наверное потому что есть дедлайн, и сбой скорости спринта приводит к его сдвигу. В итоге, приходится делать всё не останавливаясь, чтобы поддержать нужную скорость.
И ещё, вы всегда прямо точно всё планируете? Особенно новые неизвестные фичи, прямо точно в фичепоинтах угадываете скорость каждого спринта?
Из моего опыта 50%-70% спринтов в итоге "проваливаются" по различным причинам: неучтенная сложность, внешние зависимости, болезни и т.п. Но на самом деле это неважно. Важен сам факт пересмотра целей в конце каждого спринта. Если есть дедлайн, то можно пересмотреть подходы, которые не сработали, поискать возможности срезать углы или предупредить менеджмент о том, что в сроки не уложимся заранее, а не в последнюю неделю.
Настоящие дедлайны случаются раз в пару лет (например требования законодательства), все остальные - выдумки эффективных менеджеров, с которыми каши не сваришь при любом процессе.
Когда спринты перманентны это должно называться марафон. Даже Форест Гамп после перманентного бега устал и ушел домой бросив всех.
В марафоне нет остановок. В скраме они предусмотрены в виде церемоний.
О чём тут тема, напомните? Вроде как о том что люди выгорают и уходят от того, что фактические реалии отличаются от модели.
И винят в этом скрам. Якобы при вотерфоле или канбане выгореть нельзя.
Я о том, что правильный скрам дает автономию команде в том числе и в планировании. Но бывают и карго культы, которые под видом скрама по факту просто устанавливают регулярные интервалы для удара кнутом: легкий удар каждый день (дейли) и хороший хлесткий удар в конце спринта.
Еще бывает конечно низкое чсв членов команды, что приводит к самобичеванию. В этом случае нужен мотивирующий наставник, сейчас для этого есть отдельная роль - аджайл коач. Я работал с несколькими и могу сказать, что не все аджайл коачи одинаково полезны.
Проблема в том, что дезинформирующие данные на входе приводят к чудовищным результатам. Потому как автономия - это самостоятельность. Самостоятельность команды.есть только в опенсорс/пет проектах. В коммерческой или производственной разработке самостоятельности нет. Точка.
Есть много продуктовых компаний, где самостоятельность приветствуется. Бизнес ставит задачи, а команда решает, как их выполнять. Если есть жесткие сроки, то обговариваются варианты, как в них уложиться при имеющихся ресурсах. Но это в Европе, тут переработки и стресс в принципе не приветствуются.
И мы сейчас обсуждаем выгорание и "ливнувших" игроков команды в Европе?
Какая разница в Европе или где-то еще? Компании все разные. Я всего лишь делюсь опытом работы в скрам команде без стрессов и выгорания.
Я вас понимаю. Но не верю что вы не видите разницу между работой по скрам в Европе и в наших компаниях. Это примерно как убить человека заточенной зубной щеткой и потом говорить :"Видите, чистить зубы опасно для здоровья".
Я не работал в российских компаниях. Я из Украины, и там разработчиков вообще "носят на руках" из-за перегретости рынка. В Европе не так сладко, но тоже неплохо, в том числе из-за трудового законодательства. Мне сложно, но интересно понять, почему в России до сих пор все настолько жестко.
В Неньке не во всех стеках "носят на руках".
На всё, что более менее востребовано на рынке, можно найти компанию, где будут носить. Есть масса возможностей по переезду в Киев, Харьков, Львов. У меня нет знакомых из IT, кто жаловался бы на условия труда в Украине. Знаю как минимум пару человек, кто решил не оставаться в европках по вышеуказанным причинам.
Есть стеки, где ты будучи на позиции мидла с зарплатой мидла должен сказать сроки выполнения любой доработки любого типового приложения на несколько миллионов строк с массой неизвестного количества легаси-доработок с точностью до часа на любом оборудовании и любой среде и это потом будет использовано как аргумент против тебя.
Скорее всего дело не в стеке, а в компании. Обычно такие называют "бодишоп" или "галера". Ну и у мидла конечно выбор не настолько широкий. Я сам через это проходил. Но с позиции синиор открываются все лавры и появляется возможность диктовать условия.
Именно дело в стеке. В нем ты вечный мидл, будь у тебя хоть 25 лет опыта и сотни своих успешных проектов, а компании в которых используют "экспертный метод оценки времени выполнения" с перекладыванием ответственности на рядового специалиста называют не галерами, а франчами.
А в нормальной компании по скраму в этом стеке просто спринт за спринтом работаешь нон стоп. 176 часов. Из месяца в месяц.
Да, всё так и есть, единственное, когда вы предупреждаете менеджмент о том, что сроки уедут, первым делом начинают выяснять причины медленной скорости, например, много внеспринтоаой работы, мало людей в спринте и т. Д. В итоге принимается некоторое решение, по которому эти проблемы стараются убрать, но гонка остаётся, т. Е вы без передыха из одного спринта а другой делаете задачи и пытаетесь уложиться в запланированное для задачи время.
Бывает, что задача оценена сильно больше, чем есть на самом деле и тогда можно на ней "отдохнуть", но в основном всё наоборот, особенно для джуниоров и мидлов и новых людей в проекте.
А человек он такая натура, если каждый день на скраме ты говоришь, что ещё не сделал, ещё осталось Х-2 часа, хотя рабочий день 8 часов, то и перед командой тебе стрёмно и команда на тебя смотрит, как на лентяя или ламера.
Вот и пытаются всё делать так, чтобы показать, а вот я смог. Но это не нормально и ведёт к перенапрягу.
Менеджеры может и выдумщики, но сроки им дают разработчики, на основании чего они принимают решение, стоит ли вообще проект делать.
Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
Дедлайн для фичи то есть, если одна фича зависит от другой, то и будет вам дедлайн реализации ыичи на несколько спринтов.
Роадмап же менджер делают, мол в 2022 вы получите поддержку вот этой нацстухев фичи, а в 2023 вот этой и пользователи ориентируются на это - попробуй не успей во время.
Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
Грамотный менеджмент закладывает риски и мыслит стратегически в том числе и о человеческих ресурсах. Дедлайны ставят либо наивные, либо ушлые, чтобы красиво отчитаться и продвинуться по карьерной лестнице ценой выгорания команды исполнителей.
Ну нет, иногда важно быстро выпустить новый продукт, чтобы быть первым на рынке. И у менджемнта всегда дилема между качеством, стоимостью и временем.
Как говориться, Быстро, Качественно, Недорого, выбери два.
И если менеджмент выбрал быстро и качественно, но очень дорого, то вы и все будут в мыле.
Да, но скрам тут абсолютно не причем.
Вот что мешает передвинуть на следующий спринт фичу если она оказалась сложнее чем оценивалась?
Ну по сути, если ты работаешь постоянными спринтами, то нет времени, чтобы сидеть и тупить полторы недели, а потом за ночь всё быстренько сделать. Слишком всё прозрачно.
Нет времени остановиться и подумать а правильно ли мы идём, а можно ли решить проблему проще, а не висит ли на нас грузом неправильное решение с прошлого месяца. Стратегическая слепота это классическая болезнь скрама.
О, а что с таким делать, кстати. Я для себя, например, не до конца определилась, нравится ли мне работать по скраму, так как пока применяю только в небольших и условно конечных проектах.
Если вы с этим что-то можете сделать, вы счастливый человек. Обычно Скрам спускается сверху как серебряная пуля. Вообще если говорить терминами аджайл, есть такое понятие tailoring - адаптация процесса под нужды организации/команды. Правда в связи с тем что Скрам это зарегистрированная торговая марка, любое отклонение от "библии" приводит к тому что вы теряете право называть свой процесс Скрамом.
Если подходить с открытыми глазами, смотрите какие артефакты Скрама вам помогают а какие просто пустая трата времени. Универсальных советов тут нет, т.к. очень сильно зависит от размера команды, проекта или проектов, опыта сотрудников. К примеру у нас на команду из 8 человек в зоне ответственности 20 проектов разной степени легаси. От махровых Java 1.5 до Spring Boot 2.6. В таких условиях ретроспективы и командные стандапы это пустая трата времени (слишком широкий скоуп). Чем короче спринт, тем выше накладные расходы на распланировать/подвести итоги. Чем длиннее спринт, тем хуже утилизация команды.
Держать спринт закрытым - продуктовые горящие баги будут футболиться в бэклог (знаю примеры таких команд). Дать возможность докидывать срочные таски - получается хаос а не спринт. Разделить команды на разработку (Скрам) + техподдержку - придется набирать больше людей. Когда в спринте гетерогеные команды (бэк + фронт + аналитик) очень сложно обеспечить равномерную загрузку каждому. При уходе человека из тимы идёт сильная просадка скорости из-за несбалансированности. С учетом текучки кадров в ковидную эпоху, скрамовские команды постоянно недоукомплектованы и тем оправдывают свою низкую эффективность.
Для меня лично наиболее удобный вариант - помесь канбана и водопада. Канбан многополосный по сути и мне комфортно переключаться между свимлайнами если у меня затык на внешней стороне (доступ, доп. информация, UAT) Водопад позволяет "просеивать" фичи через сито заинтересованных. Но как я уже писал выше, у нас условия достаточно экзотические так что рекомендовать не буду.
Agile - это про гибкость.
Scrum-команда может и должна поменять свои процессы так, чтобы всем членам было комфортно.
Но почти все забывают о том, что «люди важнее процессов»: мы получаем карго-культ и стратегическую слепоту.
А ещё у нас есть аутсорсинг всякий, который использует итерации для удобства клиента: смотрите как мы быстро работаем. Очевидно, что здесь проблема не в скраме.
P.S.: остановиться и подумать - это встреча команды на пару часов. Очевидно, что проблема не в скраме. Вы точно работали по нему?
>> P.S.: остановиться и подумать - это встреча команды на пару часов. Очевидно, что проблема не в скраме. Вы точно работали по нему?
Какой-то вы скорострел. Мне пары часов не хватает. Иногда нужен день, иногда неделя.
Возможно разные задачи. Есть фоновое думание, есть сфокусированное думание. Обычно задаи не требуют сфокусированного думания и только его в течении недели, нет?
Либо это рождение каких-то артефактов типа дизайнов либо это исследования.
Исследования и дизайны вполне могут быть частью беклога.
В "остановиться и подумать" главное — остановиться, а не подумать. Думать-то вы всегда думаете (надеюсь). Но чтоб подумать на дальнюю перспективу, надо для начала прекратить думать на короткую.
И вы останавливаетесь на несколько дней и думаете не производя при этом никаких артефактов?
зачем для этого останавливаться на несколько дней?
в чем проблема собраться на пару часов обсудить как это лучше реализовывать? и запланировать необходимое время на реализацию этого?
Хм, а в чём конкретно заключаются претензии к скраму в этом контексте? То есть он вас по хорошему даже обязывает это делать минимум один раз за спринт.
вот мне тоже непонятно, откуда в скраме обязательный авральный режим и отсутствие планирования реализации
то описано больше похоже на то , что команда в оценке никак не участвует, все сроки спускают сверху, и сроки такие, что ничего кроме костылей сделать не получается
вот мне тоже непонятно, откуда в скраме обязательный авральный режим и отсутствие планирования реализации
Потому что при планировании спринта все забивают на принцип Парето - 20% усилий дает 80% результата. Поэтому забивают время в спринте под 100% и получают аврал (т.к. будут накладываться мелкие проблемы, несогласованности и т.п.) и выгорание.
не говорю про все команды, только про супер ответственных, а таких немного на самом то деле, вот для них это превращается в аврал, когда надо и цель спринта выполнить и тех долг бы по хорошему сделать весь и помочь коллеге джуну и т.д. В оценке команда всегда участвует сама, РОшник говорит ЧТО нужно сделать, ребята решают сами КАК будут делать. Но, руки то тянуться сделать больше и больше
Вы можете за пару часов обсуждения с командой выстроить план "как выяснить, что и не так"?;
Вы можете взять на весь спринт задачу "research этой проблемы" и думать только об этом.
Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления дедлайнами и я оставшуюся часть спринта буду работать в комфортном для себя режиме?
Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления
Я не скрам мастер, но по гайду
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Соответстенно вы лично не можете, но у вас есть совещательный голос как разработчика.
См также:
https://www.scrum.org/resources/commitment-vs-forecast
One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.
Ну то есть как в меме про сбербанк. "Люди важнее процессов, скрам это про гибкость, а не про дедлайн, есть ретро, планирование, нет никакого давления, вы просто его неправильно используете". А по факту: "Продолжаем работать в авральном режиме"
По факту в сбере оно "Другое подразделение вывалило на вас новые требования посреди спринта? Ну, это ваши проблемы. Таких подразделений не одно, а десять, и с новыми требованиями приходят они не по одному? Всё еще ваши проблемы (с)".
Проблема была бы, если бы требования надо было сделать в этом же спринте. А так оно откладывается на следующий.
Я не знаю, кому и что вы пытаетесь доказать, но нетрудно заметить, что по факту оно так и происходит.
Подобные требования внешних сил — это отдельное от команды явление, и ни в какие спринты оно не укладыватеся (еще бы, у сбера этих работающих-типа-по-аджайлу команд — сотни, и расписание у всех разное). В этих условиях вопрос "когда это надо сделать" вообще никак не связан (и не может быть, чисто исходя из вводных) со спринтами. Если повезет, то да, можно будет отложить, сделать, вот это всё. Если повезет.
Ну так если у вас регулярно есть такие "требования внешних сил", то вы резервируете под такое слоты в спринте.
Либо если их много и/или они абсолютно хаотичны, то просто ищите вариант работать вообще без особого планирования. Потому что вам всё равно тогда не удастся ничего нормально планировать. Ни в скраме, ни в водопаде, ни ещё где-то.
В том что я наблюдаю, требования об других команд возникают в середине спринта но при этом обычно выполняются в следующем.
Бывают срочные баги, но очень редко срочные новые требования.
Возможно, вам подходит что-то типа канбана
Ну вообще-то там написано "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint."
То есть в "ванильном" скраме именно разработчики(а точнее "команда разработки", то есть вместе с тестерами и всеми остальными) решают что будет делаться в спринте. Product Owner может максимум влиять на приоритеты. Но не на объёмы.
Смотрите, как это работает:
- PO: эта задача влезет в спринт?
- devs: да
- PO: а эта?
- devs: нет.
- PO: а эта маленькая?
- devs: да.
Решает команда. Если она доверяет вашим суждениям, то ваш совещательный голос превращается в последнее слово.
На самом деле оно выглядит скорее так:
РО: эта задача на сколько потянет?
Девы: хз, может на пол дня, может на неделю.
РО: вы неделю будете делать 1 простую задачу?!?
Девы пол часа играют в покер и пытаются друг друга переубедить
Девы в итоге приходят к тому, что с 90% вероятностью сделают за 1 день.
РО: отлично, берём в спринт вот эти 5 задач по 1 дню.
С вероятностью 40% спринт провален.
Ну во первых "РО: отлично, берём в спринт вот эти 5 задач по 1 дню." это уже не скрам. РО ничего никуда не берёт.
А во вторых ну случилось так один раз. Ну два. Ну три. Но рано или поздно "девы" должны понять что оно так не работает. Ну если они совсем не идиоты...
Вы своей придиркой прекрасно продемонстрировали, как вроде бы не совсем идиоты, могут обсуждать несущественные детали часами без полезного выхлопа.
А вы где-нибудь видели в скраме использование теоремы Байеса для оценки выполнимости спринта?
А вы где-нибудь видели в скраме использование теоремы Байеса для оценки выполнимости спринта?
А вы считаете что без этого вот никак нельзя найти способ адекватно оценивать объёмы работы на пару недель вперёд?
П.С. Да и какой толк вам будет от теоремы Байеса если вероятности всё равно из пальца высосаны? :)
Теорема Байеса говорит, что даже зная точную вероятность выполнения отдельной задачи к сроку, мы не сможем обеспечить приемлемую вероятность успеха спринта просто складывая оценки отдельных задач без многократной перестраховки. Грубо говоря, можно достаточно уверенно утверждать, что за рабочую неделю будут выполнены лишь 2 однодневные задачи. Неуверенно - ещё одна. А если взять 5, то точно что-то будет либо не доделано, либо сделано спустя рукава.
Ааааа. Вот вы о чём. То есть мы просто перестаём планировать в ИТ и всё. Ну ведь если мы уж спринт в скраме спланировать не можем, то про всякие водопады и заикаться не стоит. Я правильно вас понял?
Единственное что я не понимаю это как тогда куча фирм и команд умудряется более-менее нормально планировать свои спринты и релизы? :)
А очень просто: фиксируется дедлайн, и либо объём работ является неопределённой величиной, либо качество. А если сильно не угадали с дедлайном - начинаются разборы полётов в духе "вы же закоммитились, чего вы так медленно/некачественно работаете?".
Вообще-то всё ещё проще: если что-то из запланированного не усправают сделать, то просто не успевают и всё. Это легитимно, хотя и не особо привествуется. Если такое происходит часто, то просто начинают планировать немного более "пессимистично".
По крайней мере так было в тех фирмах где я работал со скрамом.
Как забор ни перекрашивай суть остаётся одна: либо этот прогноз бесполезен для всех, либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться, когда они не будут оправдываться.
Наверняка есть такие люди, которые бесятся от любого несоответствия прикидки и реальности. Интересно, что вы даже не допускаете существования людей, которые относятся к прикидкам не так как вы.
Как это происходит у нас. Команда комитится на несколько фич в спринт. Может даже на ноль. Обычно это жесткие зависимости. Остальное время делают найс ту хев фичи. Они облегчают жизнь пользователям, но в принципе не срочные. Если за спринт сделаны не все найс ту хев фичи, то это ок.
После нескольких спринтов новичок понимает, что можно не успевать найстухев и все ок и не особо парится.
Ну бывают иногда гиперответственные которые парятся на любое несоответствие реальности картине мира.
Да. Еще пробовали в конце спринта пытаться затолкать фичи со срезанием углов по качеству, но оказалось, что потом себе дороже. У нас баги в проде довольно дорого стоят и расмотрев на ретроспективе пришли к выводу что лучше бы фичу отложили но выпустили качественно
вы даже не допускаете существования людей
А я-то тут при чём?
Как это происходит у нас. Команда комитится на несколько фич
Зачем?
А я-то тут при чём?
Вы же сказали "либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться" соответственно именно вы и не допускаете
Зачем?
Обычно это зависимости (другой команде нужно к какому-то сроку), новые требования законодательства или публичные обещания руководства. Бывает есть крупный заказчик, который не будет внедрять продукт, если там нет какой-то фичи и с ним договорились.
Из практики решения, мы жили в скрамбане не брезгуя всем тем, что нам дал вотерфол и PMI - до начала спринта менеджер/мастер просчитывал ёмкость команды с учётом занятости каждого.
Техлид максимум 20-30% времени может потратить на разработку, у всех есть свой скил, который со временем отрастает + поправки на "Серёга переболел ковидом, -40% от его способностей на месяц".
Дальше само распределение по типам задач или корзинам, есть общая ёмкость, в ней 20% резерва, 10% на пиздец, остальное на отдельные эпики 50% и 20 на поддержку (может меняться в зависимости от целей спринта).
Соответственно больше ёмкости задач не бралось ни под каким видом, если что-то срочное залетает после/во время, то с согласования с бизнесом выносится, что-то равнозначное.
И да на каждой колонке тоже есть ёмкость и навалить 40 задач на 150 дней в тест, когда там два живых человека нельзя. Система не даст, но тестирование и его учёт внутри планирования отдельная история.
А есть англоязычная стать с картинками для самых маленьких на эту тему? Мне бы для заказчиков ой как пригодилась:))
С вероятностью 40% спринт провален.
Да хоть с 100%. Какая разница, от точности оценки скорость не изменится.
"Провальность спринта" - это уже к эффективному менеджменту.
А что вы будете делать, если не взяли задач в спринт?
По сабжу, аджайл еще и про то, что "команда состоит из мотивированных профессионалов".
И в спринт берет задачи команда, а не вы лично. Поэтому к вам возникнут вопросы от коллег: самоорганизация. По сути, отсутствие ролей "начальник/лид и т.п." компенсируется большей личной ответственностью и необходимости мотивации от членов команды.
А что вы будете делать, если не взяли задач в спринт?
Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
И в спринт берет задачи команда, а не вы лично. Поэтому к вам возникнут вопросы от коллег: самоорганизация. По сути, отсутствие ролей "начальник/лид и т.п." компенсируется большей личной ответственностью и необходимости мотивации от членов команды.
Самоорганизация, личная ответственность, отсутствие начальников вообще никак не связаны со скрамом. Могут быть любые сочетания этих параметров со скрамом или без.
Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
Это модно, но только в Канбане )
Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
Это хорошо работает когда вы один или у вас одна команда от которой никто не зависит. Тогда вы можете просто спокойно так работать.
Но если от вас зависит кто-то ещё, то ему обычно нужно хоть какое-то планирование. Хотя бы на пару недель вперёд.
Ну что значит "по порядку"? Порядок определяет PO на планиниге. Вы не знаете, какие задачи нужно взять, поскольку не в курсе текущих приоритетов бизнеса. Один из принципов agile:
Изменение требований приветствуется, даже на поздних стадиях разработки.
А если фичи требуют работы не одного, а нескольких специалистов?
Или вы зарелизили фичу, молодец. А маркетологи потом - почему нас не предупредили, мы не сделали анонс? Аналитики еще прибегут. А потом придет PO и скажет: эту задачу делать было не нужно, бизнес передумал.
Agile scrum без самоорганизации, личной ответственности и т.д. не работает. Еще несколько принципов agile:
- Над проектом должны работать мотивированные профессионалы
- Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно корректировать стиль своей работы
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
"Люди важнее процессов". В наших реалиях многие воспринимают этот слоган по-своему. Ну типа "семейных ценностей". Только вот семья не ваша, а их.
В конце каждого спринта в SCRUM предусмотрены ретроспектива и планирование, как раз для того, чтобы остановиться и подумать.
Если отбросить церемонии, то SCRUM - это всего лишь планирование на короткие промежутки времени, пара недель вместо 3-х месяцев.
Дедлайны не имеют прямого отношения к SCRUM. Менеджмент решает, делать конец спринта дедлайном или нет.
А менеджеры, которые не дуеры, они чем вообще занимаются?
А менеджеры, которые не дуерыОни тоже «дуеры», только другие. В стульчик дуют. Есть ещё «рукой» водители.
Много чем, только с потоком проблем не справляемся, тушим пожары на локальном уровне, например, у тебя выбор, либо пойти обстукивать все двери бюрократии, чтобы контрофер дать и не потерять разработчиков - чтобы приоритетный для компании продукт продолжал развиваться и приносил деньги, либо собрать все данные по текучке, сделать обзор рынка и т.д., дойти до СЕО компании и решить это комплексно для всех. Оно понятно, что второе важнее, но очень долго, по дороге потеряешь всех, поэтому приходится все делать параллельно и качество и скорость от этого не в нашу пользу. Главная задача менеджера - создавать все условия для эффективной работы команд
Ок. Про железо для разработчиков сказали. А на мой любимый вопрос - как быть при Scrum/Agile с железом для выполнения того, что накодили? Своё (долго закупается; если закупать с запасом - дорого), облака - за них кто-то в корпорации готов платить (и иметь шанс навсегда "прилипнуть" к сервисам условного Амазона)?
Если будет вторая статья о том, что происходит на границах Scrum'а, то будет очень круто.
Всё просто – работа спринтами. Люди, не готовые работать в авральном режиме, быстро выдыхаются
С чего это вдруг спринты стали авральным режимом?
Каждый раз мы собираемся всеми силами, чтобы сделать этот рывок, а как итог – через год-два в компаниях демотивированные сотрудники, которым ничего не приносит радости и мотивации: ни отпуск, ни новые продукты.
Ну так может просто не надо никаких "рывков"? Что вам мешает запланировать в спринт адекватный объём работы?
Если честно, пока я не знаю.
Очень просто: пока не умеете планировать объёмы работы точно, просто возьмите и запланируйте меньше. И если вдруг в конце спринта будет нечем заняться, то никто не запрещает взять что-то из бэклога.
Тут всё просто. Часто менеджеры становятся решателями всех проблем команд.
Откуда у вас в скраме менеджеры? Product Owner? Так они не менеджеры. У них есть своя зона ответственности и она чётко ограничена.
Я вот тоже не понял, откуда взялся менеджер :). Видимо, очень хочется менеджерить, общаться и быть doером.
С чего это вдруг спринты стали авральным режимом? - говорила про отдельных личностей, не всю команду)
Ну так может просто не надо никаких "рывков"? -Что вам мешает запланировать в спринт адекватный объём работы? - так и делаем) только это не останавливает наших трудоголиков никак, неужели у вас таких не было? сколько не учи, не говори куда это приведет, все равно берут молча делают днями и ночами
Откуда у вас в скраме менеджеры? Product Owner? Так они не менеджеры. У них есть своя зона ответственности и она чётко ограничена. - нет в скрам командах менеджеров, есть в структуре большой компании и их задача не микроменеджерить, а создавать условия для эффективной работы команд
А как вы планируете спринты? Есть ли какое-то планирование поверх спринтов? Как отслеживаете зависимости?
так и делаем)
Если бы вы так делали, то вы бы скорее рассказывали что у вас проблема что люди иногда не знают чем в конце спринта себя занять...
наших трудоголиков никак, неужели у вас таких не было? сколько не учи, не говори куда это приведет, все равно берут молча делают днями и ночами
У нас такие если и были, то не то чтобы настолько много чтобы это создавало пробемы о которых стоило рассказывать. И на мой взгляд "притормозить" таких людей не особо то и проблема. Было бы желание.
нет в скрам командах менеджеров, есть в структуре большой компании и их задача не микроменеджерить, а создавать условия для эффективной работы команд
Хм, тогда я вообще не понимаю почему у вас статья называется "Scrum приводит к потерям. Как с этим справляться". Причём здесь скрам то?
"2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели."
Вот это вот какая-то дичь, которая говорит о том, что менеджмент в компании дно, которые понятия не имеют о том, что такое обратная связь.
Вендор vs in-house тема спорная и просто так брать и инвестить в in-house может быть опрометчиво, там критерии совсем другие, хотя в вашем случае надо было просто сменить работу с вендорами.
Я из тех кто не любит Scrum, хотя бы только за то, что все факторы производительности сводятся в burndown chart и velocity, как понять какие факторы повлияли на эти значения - непонятно.
Бывает операционная и спонтанная активность, которая непредсказуема, мы ее просто логируем, хотя это уже как бы не scrum/
Вообще история создания Scrum мутная и не фундаментальная, тот же RUP, куда более фундаментальный, хотя по нему никто особо и не работал. Ну и продавцы scrum очень любят противопоставлять waterfall vs scrum, но waterfall это была первая формализация процесса, с выделением этапов и сам же автор говорил о цикличности этих этапов, об этом почему-то продацы scrum умалчивают.
Качество процесса определяет результат, ядро Linux пишут без скрама, а оно работает от калькуляторов до супер компьютеров.
Вообще за более, чем 20 летний опыт написания софта, я пришел к выводу, что если команда(в том числе менеджмент) не может придумать себе процессы для облегчения взаимодействия между собой, то это слабая команда и не более того.
Более формализованные процессы нужны, когда взаимодействует несколько команд, но и там всегда можно договориться.
Если же смотреть шире, то производство софта это детский утренник по сравнению с процессами и сложностью авиазавода например.
У меня вся родня с завода, плюс я также был в IT подразделении на другом заводе. То, что вы пишите с одной стороны правда, бюррократия и старый подход, который не пытается обойти конкуренцию, а наоборот ее подавить.
Но я бы хотел акцентировать внимание на другом. Если в софте можно откатить много чего и вернуть все назад в 95% случаев, то косяки на производстве стоят просто на порядки дороже.
Завод это прежде всего материальное производство, необходимо управлять запасами. Косяки в производстве сложных деталей могут просто заруинить все изделие (например ракету) и откат там невозможен в принципе.
Связи между цехами, людьми и этапами намного жесче, чем в IT и управление всем этим балаганом требует куда больших усилий, чем когда одна команда использует api сервис другой.
Не нужно пытаться натянуть сову на глобус. Scrum и не нужен глобально для ядра/завода. У фреймворка есть определённые границы применимости: заказчик не знает чего хочет, бизнес-требования меняются довольно быстро, некоторые виды R&D, эксперименты.
Ни и всегда можно найти отдельные кусояки завода, где итерации хорошо подойдут для переоценки ситуации.
А таким на уровне таких крупных предприятий используется канбан, например. От японцев 5s иногда перенимают.
Инвестировали в инхаус не сразу, начинали с 1ой команды) мы не пропагандируем скрам, мы за здравый смысл, у нас также много проектов которые работает по ватерфолу, по канбану, просто работают применяя лучшие практики отовсюду или же работаю так как работали, потому что результат удовлетворяет всех.
Когда комментарии важнее статьи... Думаю надо дать шанс этой статье.
И водопадный принцип был переиначен и скрам также извратили. Не давать команде оборудования - это, знаете ли, не проблема скрама или водопада. Уравнивать спринты с авралом. Это - разруха в головах. Не надо делать из методологии управления проектом соковыжималку.
Как хорошо что некоторые компании о себе такое рассказывают честно и добровольно.
менеджеры становятся решателями всех проблем команд.
это их работа
Команды несут и несут свои проблемы, по итогу менеджер становится сотрудником своих сотрудников.
удивительная мысль.
у вас феодализм, или скрам? почему менеджер не должен решать проблемы коллектива? почему член команды не может обратиться к менеджеру за решением проблемы?
он так хотел править и руководить, но его вынудили работать на результат и на команду :(
бедный менеджер!
Это происходит потому, что никто в команде не готов взять ответственность и начать решать проблемы самостоятельно, без привлечения менеджера
это его чертова работа, решать проблемы!
если все проблемы успешно решаются без менеджера — он не нужен и будет уволен.
бедный менеджер!
менеджер не может отказать
а кто ему дал право отказывать, если это его работа? если же это не его работа (проблема, с которой обратились вне зоны ответственности менеджера) — почему не может отказать/перенаправить/делегировать/посодействовать/походотайствовать от своего имени, не "отменеджерить" вопрос?
если менеджер отказывается менеджерить — он должен быть уволен.
бедный менеджер!
Идеально все выразили.
Работал в компаниях, где менеджер(или PO) - твой лучший друг и товарищ. Правда, зачастую, эти люди выросли из технической среды (ну и, не редко, их уровень CTO/founders небольших компаний).
И меня все эти стоны «менеджеров» крайне удивляют. Им бы ещё сказать, что в аджайде есть понятие «служащий лидер».
Люди, чья работа - обеспечивать функционирование процессов, жалуются на то, что они не смогли построить взаимодействия. Чудовищное извращение понимания своей роли: обслуживание и развитие процессов.
Сколько смотрю на скрам-мастеров и в большинстве случае это девушки не очень обременённые умственными способностями, но любящие пообщаться — вот и возникает вопрос, это они выбирают такую позицию или позиция притягивает к себе подобных?
"Если есть дежурства, давать отгулы, а не дополнительные деньги."
А если давать выбор? Некоторым деньги важнее.
По хорошему, полагается давать и деньги и отгулы.
Из опыта с последней компании (еком):
1) Выстраивать процессы, по пути их автоматизации для уменьшения количества касаний и встреч, в том числе менеджеров/бизнеса, а не только разработка/менеджер.
После передачи команды в руки приемнице, она сделала качественные дашборды и договорилась с бизнесом схлопнуть 3 встречи до 1й + обновления дашборда. Тех лид стал свободнее и менеджер/мастер получила пространства для работы и жизни.
Я этого не сделал, потому что переоценил свои силы - взял себе больше проектов и был в огне.
2) Выстраивание границ с четким их соблюдением, временных, пространственных и прочих.
С командой договорились, что после 19 часов, бизнес может писать только в саппорт (у тех есть есть контакты дежурного разработчика, но это тоже про процессы) или менеджеру напрямую, но только в случае, если шеф всё упало и сломалось и только после уведомления саппорта.
В членов команды напрямую ходить категорически запрещено, каждый может ответить любому, кто придёт: "Идите на фиг, мне мама запретила разговаривать с незнакомыми!". Работает на всех, даже на топов.
Сами менеджеры стараются не упарываться, регулярно делятся о таких ситуациях на 1-2-1 с руководителями и общих встречах с коллегами по цеху и все в команде берут 1-2 дей офф, если понимают, что подкатывает.
3) Про фриланс и вторую работу - это очень хорошо чувствуется на уровне лида или выше, если этим лид решил сам пострадать.
Можно решать на уровне общения тех/тех с минимальным привлечением менеджера, если договориться не получается и страдает и сам пациент и его проекты, то решение о расставании может инициировать менеджер.
4) Лучше несколько небольших отпусков, чем весь год без отпуска и вот мои 28 дней.
Регулярный отдых помогает выжить, особенно на полной удалёнке. И это хороший повод посмотреть на ком слишком много замкнуто и расшить такие места, потому что незаменимый тех/тимлид - это бомба с часовым механизмом.
5) Корпоративные активности - меньше онлайна и больше оффлайна в любом доступном виде. В этом году у компании был юбилей, который HR вместе с топ, полностью решили провести онлайн.
Такой дизмарали давно не видел, при этом волна ковида была на спаде и можно было извернуться, но нет.
И отдельная часть комментария про изменения в большой корпорации - надо чётко понимать зачем вам это нужно, прежде чем ввязаться в бой.
Для изменения орг. структуры в моей предыдущей компании, мне пришлось эскалировать, понять что никто из линейных руководителей и топов не хочет брать ответственность, взять её на себя, просчитать экономику вместо линейных, защитить её у топов и добиться фиксации новой структуры в бюджете.
У меня мотив был, что должно быть правильно, логично и я знал, что если потерплю поражение, компания потеряет 2-3 талантливых инженеров.
Разменом стала сама работа, к которой были вопросы, а после решения не типовой задачи вне моих рамок компетенции, желание работать с этими людьми отпало.
Слишком много букв для простой мысли: Скрам - говно.
Менеджеры становятся «Do'ерами»
Лучше и не скажешь! У менеджеров есть план по надоям дедлайн, к которому они стремятся прийти в независимости от того сколько правок было в проекте и сколько для их реализации потребовалось времени. И начинается бесконечная дойка команды...
Обычно такие ребята сопротивляются всему новому, не любят ивенты, им лишь бы по ТЗ работать и ни с кем не разговаривать, а мы, представьте, хотим, чтобы они с конечным пользователем заговорили и делали то, что нужно конечному пользователю.
Обычно "такие ребята" устают от того, что им пытаются продать проект, который не прошел стадию экспертизы, под видом одной из заповедей Agile о готовности к изменениям на любой стадии проекта. И как любой нормальный человек, им попросту жалко потраченных времени и сил, которые попросту выкидываются в мусорное ведро с каждой новой правкой.
Я достаточно долго поработал в Agile-командах в Казахстане и у меня абсолютно иное видение причин по которой команды теряют людей. Где-то в первых версиях вашей статьи была фраза о том, что многие не готовы постоянно работать в авральном режиме, которая затем приобрела более политкорректные обороты.
Так вот! Хорошая команда разработчиков может работать по Agile без менеджера проектов (я даже не помню чтоб такая роль была предусмотрена в SCRUM) и скрам-мастера, при этом они будут выдавать хорошие результаты! А вот менеджеры, уж точно не могут работать без команды разработчиков. Помните об этом, когда делаете выводы о том, по какой причине вы теряете людей.
Интересно - а как много людей вносит в оценку времени скрама - сам скрам? 4 встречи в неделю по 15-30 минут - по факту займут суммарно 4 часа (минимум 5 минут до, 15 минут встреча, минут 30 чтобы после встречи просто вернуться в работу и помножить на 4 дня) .
Затем вносим час на планирование - опять по факту затрат времени 1.5-2 часа.
Если добавляем ретро - еще 1.5 часа.
По факту получаем практически потраченный день в неделю чисто на скрам. И внезапно 40 часов для работы превращается в 32.
Интересно — а как много людей вносит в оценку времени скрама — сам скрам?
Я бы сказал что если у кого-то в скраме начнают оценивать таски в часах и планировать таким образом спринты, то это уже не особо хорошо. То есть мы так пробовали(вопреки совету скрам мастера), но получилось хуже чем брать абстрактные вещи вроде тех же стори поинтов. Ну и да, когда мы так делали, то отводили "таски" и под сам скрам.
Если люди работают в авральном режиме это значит скрам мастер не выполняет свою функцию. Спринт должен быть грамотно спланирован. Проджект менеджеры должны проработать задачи на должном уровне и разбивка должна быть достаточно мелкая. Прописные истины. Тогда и текучка будет меньше. Хотя поекты в основном будут гарантированно 'over budget' потому что продажникам наплевать на скрам и их задача продать, а не планировать. Поэтому то и отказалась моя компания от скрамов.
Кто вообще сказал, что развитие без команды невозможно. Скорее это пичканье командной работы всезде где ни попадя-ведет к постепенной деградации. Совершенно очевидно, далеко не всякая работа должна и может быть командной. Да и команды командам большая рознь, не всякая командная работа предполагает именно скрам. Кстати, наилучшими экспертами чаще всего являются именно работники-одиночки. А во многих случаях скрам вообще неприемлем и даже вреден. Это просто сейчас так называемая командная работа(та что относится к скраму)-превращена скорее в моду, сектантство и карго-культ.
Scrum приводит к потерям. Как с этим справляться