Comments 75
Из раза в раз в подобных статьях замечаю, что речь начинает идти о крайне странных вещах, типа обязаловки скопа спринта, каких-то "сроках", про которые в скраме нет ни слова, и каждый раз речь идет о каких-то имплементациях, которые забывают, что скрам идет снизу вверх, от ситуации к инструкциям, а не от инструкций к ситуациям.
В этом как раз нет ничего странного. Вот пара моментов, раскрывающих эту точку зрения:
1. Все дело в том, что скрамоёб...любы говорят "вдвое больше работы за половину времени" (книга же так называется), но в реальности скрам - это скорее "неизвестное количество работы за неизвестное время", неопределенность и все такое. К тому же, как правильно замечено в статье, почти все проекты в реальности имеют и дедлайны и ограничения по бюджету, даже всякие НИОКРы и R&D и то обычно ограничены по бюджету.
2. В скрам-гайде было написано: легок для понимания, но сложен для освоения (дословно: "Difficult to master"). В новых версиях эту фразу почему-то скрыли, но от того она не перестала быть правдой. Скрамо-менеджеры спотыкаются об эту сложность (и об игнорирование скрам-идеей реальности), и всё внедрение скрама заканчивается тем, что теперь они недели называют спринтами, добавляют 8 совещаний и устраивают понедельное планирование. Особенно смешно(нет) получается, когда только команда разработки играет в скрам, а вся остальная компания нет, потому что извините, у них поставки, отгрузки, декабрьский ажиотаж и прочее - в итоге - Scrumfall (спасибо за новое слово!).
Основная проблема была в том, что в waterfall была не низкая нагрузка на разработчиков, а из-за линейного планирования, могла быть полное отсутствие нагрузки на некоторые команды, пока они ждут свою очередь плана.
В agile (в том числе и скрам), есть возможность каждый спринт давать задачи всем.
Что же по поводу стресса - так ставьте нормальные дедлайны, которые включают в себя среднюю, а не высокую нагрузку на людей. Отдыхать можно вне работы, во время обеда, либо вообще если на задачу выделено адекватное количество времени, то в это время включено и обдумывание лучшей стратегии, а не срочно тяп-ляп любыми способами.
Таким образом я в корне не согласен с тем, что " Спринты лишены перерывов, сильно ограничивают автономию и не дают достаточно времени на подготовку. "
Ограничения и лишение перерывов не дает менеджмент, а не спринты.
Вы рассказываете, извините, сказки. При долгосрочном планировании работ никакие *команды" не простаивают. А сам waterfall которым всех пугают не существовал НИКОГДА. Это термин из статьи описывающей ГИПОТЕТИЧЕСКИЙ линейный процесс, теоретическую вымышленную ситуацию, но к сожалению, из статьи выдернули только термин, исказили смысл и дальше в клювиках понесли миру страшилки. А так то - некоторые из нас умеют играть в шашки тьфу в шахматы тьфу в разработку, а некоторые не умеют. И никакие ритуальные церемонии это не изменят :-)
Простите, я в таких работал лет 10. Я знаю ватерфалы не из статьи а из практики.
Когда идет разработка/поддержка какого-нить небольшого проекта в крупном ентерпрайзе на 10-20 человек. Релизы по полгода. Половина команды ничего не делает первые 1-2 месяца, половина вторые.
Я пока не понимаю откуда простой берется. У нас после того как заканчивалась стадия разработки проекта 1, брался в работу проект 2. Тем временем тестировали проект 1,и если там находили баг то кто-то из команды переключался на фикс. Хотя конечно тестировщики работали более расслабленно, но они и при скраме тоже могут так работать.
В ентерпрайзах могут быть довольно старые проекты, которые почти не разрабатываются. Основная задача - обеспечить работу в новых версиях платформы и может быть пофиксить какой-то баг. При этом для каждого релиза необходимо провести полный цикл тестирования.
Вот и выходит - за полгода имеем новую версию джавы, новую версию докера, новую версию парочки библиотек, с точки зрения девелопинга - почти никаких изменений, с точки зрения тестирования - полный цикл старых полумануальных тестов, которые некому автоматизировать.
В остальное время простой. А за все позиции компания исправно платит 5-10 лет и ее все устраивает.
Я знаю команду, которая в крупном интеграторе полгода вообще без дела сидела. Люди приходили на работу, смотрели сериалы и получали полный оклад
Ограничения и лишение перерывов не дает менеджмент, а не спринты.
Полностью поддерживаю. Я закладываю в спринты всё: и отдых, и подготовку, и саму работу. И ещё накидываю на форс-мажоры. А ситуация, описанная автором статьи — от неправильного планирования. У нас в команде есть негласное правило: проджект следует за возможностями команды, а не за хотелками сейлзов.
Так эти «простои» это и есть то самое счастье, ради которого я потел последние месяцы и наконец-то могу пару недель смотреть проф. видосы, читать проф. статьи и прочее, что откладывал в избранное месяцами. Когда перешли на Скрам, я продержался полтора года и ушёл на фриланс. Тут тоже свои особенности, но я доволен выбором и никогда не вернусь в офис в привычном понимании слова
почти все проекты в реальности имеют и дедлайны
Из треугольника функциональность-деньги-время в водопадных проектах обычно ограничивается функциональность и деньги, поэтому сдвинуться (а сдвигается всегда в одну сторону) могут только сроки, но тут возникает желание их ограничить - вот и горячка в конце проекта.
В случае инкоементально-итеративного подхода сроки могут быть ограничены, верно, но функциональность может плавать. В любом случае к дедлайну (который определён планом, рынком, конференцией, договором с партнёрами..) основная функциональность будет поставлена и уже работать.
факт "в скраме нет ни слова" прям очень кайфово резонирует с фактом "ни разу за 15 лет не видел чтобы было иначе".. )) в лучшем случае, мудрое руководство просто дает возможность команде периодически "расслабиться" в стиле "ну, давайте, ладно, этот спринт на рефакторинг".. (только роадмап рефакторинга не забудьте подготовить))))
Да, действительно, какая-то странная форма, как будто человек зашит в какой-то шаблон.
"В спринте нет времени на подготовку", "спринт не кончатся" ээээ... Автор МП или как? Т.е. планировать часть работ в спринте как анализ и подготовку к следующему он не догадался? Запланировать "лёгкий спринт" не может? У него нет плана проекта чтобы понимать, когда пахать, когда сеять?
Пример с мышами ещё смешнее. Если людей заставлять, они работаю хуже... Да, верно, никто не спорит. А как же сроки?
Вот и получается какой-то скрам из учебника, к реальности не привязанный. Какой то "инвалидной", простите.
Увы, идеальный скрам существует лишь в фантазиях его апологетов. А в реальности, его применяют в большинстве случаев потому, что это модно. Вот несколько интересных моментов в скраме:
Серьезные фичи не вписываются даже в 2-3 спринта. Не будет никакого инкремента по бэклогу продукта в одном спринте. Как вариант, такую фичу можно сделать подпроектом. Со всем вытекающими церемониями и артефактами. Это усложнение ведения проекта. Вы так делаете? Я думаю, мало кто делает. На спринт ревью в итоге не результат показывают, а тупо перечисляют сделанные задачи (просто список задач с отметкой done).
Скрам-мастер. У вас он был? Или менеджер проекта это он и есть? Многовато тогда функций на PM падает, не думаете? Вести проект и ещё обучать всех скраму(команду, владельца продукта и прочих стейкхолдеров). Вот они и "горят" как спички. Похлеще разработчиков.
Сроки. Вы видели описание работы со сроками в скрам гайде? Предлагают работать эмпирически. Т.е. проведи не меньше 3 спринтов, высчитай велосити и рассчитай вероятный срок релиза. Зашибись! А то что этапы в разработке разные, люди могут болеть, ценность отдельных спецов может быть высока (заболеет - вся команда встанет) и т.д.? Как объяснить стейкхолдерам, что сроки релиза будут меняться после каждого спринта?))) А изменение срока - это обычно и изменение бюджета. Зарплату команде платить же надо.
Чисто по-человечески я понимаю. Это разумно. Типа работаем как можем, вот вам прогноз. Он может меняться, такова жизнь. Но в бизнесе это так не работает.
Согласен. Считаю чтобы поставлять каждый спринт инкремент нужна разная длительность спринтов. Да и вообще скрам предполагает что у нас команда фуллстек разработчиков что в реальности не так. Короче это фреймворк не для корпораций а для стартапа. Где команда может действительно гибко управлять процессом. А иначе по факту получается буллщит.
Как говорят, Скрам - это гибкая методология, где можно все "поднастроить".
И вам придется все поднастраивать постоянно =)
Вы всё равно будете работать только так, как можете; но если бизнес не подстраивается под возможности производства, то либо падает качество, либо, через некоторое время, производство уходит в другой бизнес.
Мы всё время даем бизнесу возможность забыть, что торговля -- это производная от натурального обмена излишками. Излишками, а не отжимками.
Не давайте себя отжимать. Уходите оттуда, где вас отжимают. Оставляйте любителей выжимать человеков делать любимое дело друг с другом.
Продолжительность спринтов команда определяет самостоятельно, исходя из своего стиля работы и удобства. При этом важно соблюсти баланс: за слишком короткий спринт команда не успеет создать значимую часть продукта, а за слишком долгий — команда потеряет концентрацию на целях.
Сейчас у меня в компании спринт длится 2 недели, а каждый пятый спринт - нерабочий, когда можно или доделать какую-то работу, или спланировать следующий инкремент.
Есть конечно свои недочёты в scrum, но почему-то в последнее время частенько стали появляться критикующие статьи, как-будто мой коллега пишет :)
Скрам имеет одну неразрешимую проблему: итеративность искуственна. Тоесть она не привязана к реальности проекта или продукта.
Все реализации скрама так или иначе пытаются сгладить эту проблему, но не избавиться от неё.
Возможно это не проблема, а особенность. Со временем приучиваешься декомпозировать задачи на спринты. И в некоторых проектах это даже полезно. Мы с вами в разных проектах работаем, поэтому имеем различное мнение. Сколько слышал споров в команде по скрам методикам, а в итоге как работали, так и работаем.
Рассказывали, что в армии взвод солдат на пробежке должен был до собственно команды "бегом" делать "бег на месте" - вот чтобы показать свою готовность. И это жутко выбешивало людей. Но в армии это делалось для улучшения дисциплины и следование принципу: не надо думать, делай что говорят.
В ИТ конторах ситуация несколько другая. Поэтому, подозреваю, и "принудительный бег" по бревну для мышек и, собственно, "принудительный бег" по спринту для разработчиков - всё будет выводить людей из себя. И чем более интеллектуальная основная работа, тем больше будет стресса от таких "активностей".
Причём (проведём аналогии с "бегом на месте") если пытаться делать такие "предложения":
давайте при беге на месте меньше поднимать ноги - будет легче, меньше устанете;
давайте при беге на месте немного вращаться вокруг оси - какое-то разнообразие;
Оно всё ситуацию не облегчает. Всё равно "активность" вызывает стресс.
Как можно уменьшить стресс? Убрать "бег на месте".
Так что со статьёй согласен - разработчики должны контролировать свой рабочий процесс и отличаться от мышек, принудительно бегающих по бревну.
Можно ли это сделать в рамках скрама? Сомнительно, там спринты и ритуалы.
Хоть один бы описал, как у него в компании построен тру-каноничный-скрам
Так много написано про стресс. А в чём проблема поставить такие сроки, чтобы работать в комфортном темпе без стресса?
Проблема в том, что 80% усилий дают 20% результата, иногда при планировании это забывают. Ну и еще влеты задач в спринт - нельзя впихнуть невпихуемое, и тут либо убирать какие то задачи ради влетевшей, либо заранее планировать время для вот таких вот влетов, а они всегда будут.
Это всё называется отсутствие навыков планирования. Если разработчик оценил задачу в два часа, значит надо ставить 4, потому что ещё час на тестирование и ещё час на возможные доработки в случае, если QA вернёт задачу. Если задача сложная и большая, можно запросить развёрнутую оценку у нескольких разработчиков, посмотреть, за какие сроки делались похожие задачи ранее, и т.д. В идеале вообще всегда давать пессимистическую оценку, чтобы в конце спринта оставались неотработанные часы, и тратить эти часы, на те самые "влёты" или, например, на погашение технического долга.
А если ПМ поставил 4, а потом выяснилось, что еще чего-то не хватает, и надо уже 8 или 80?
Планирование без осечек - заведомо нерешаемая задача на дистанции.
Адепты scrum этот момент очень и очень хорошо понимают, и добрая половина скрам-гайда посвящена предложениям к решению этой проблемы.
Своеобразные решения конечно для многих, но они предлагаются (и у кого-то даже работают)
Если эстимэйт оказался недостаточный, то ПМ должен уведомить об этом клиента и обосновать, что к чему. После этого как правило, задача либо будет на несколько спринтов, либо вообще откладывается на потом, если у клиента ограничения по бюджету.
Клиент с бюджетом и спринты? Если у вас такое практикуется, то менеджменту можно выписать грамоту в номинации "Прорыв года".
Скрам это про продуктовую разработку, и как правило in-house.
На внешнего заказчика это может работать только по схеме time & material, что в реалиях РФ и СНГ встречается крайне редко.
Всё остальное от незнания и попытки использовать хайповые подходы без понимания их сути, и для чего они изначально создавались.
Вы только что изобрели канбан
Дельное замечание, кстати. Тоже думал об этом, но почему-то нет внятного ответа. Бизнес хочет быстрее, но не понимает специфики работы программистов.
Вопрос, пожалуй как вы оцениваете и куда вы двигаетесь.
Спринт - 2 недели. КПД в попугаях, попугай пол дня. Норма - 13попугаев. Куда делись ещё семь, на поговорить (как же мы без дейли), на подумать (прокрастинировать любят все), на почитать (приходится и заглядывать в документацию).
В целом, выходит вполне хорошо. Мне повезло с руководством, никто тебя не будет пинать, за спринт с условными 8попугаями, может что-то пошло не так.
Когда в расчетах закралась ошибка (считали на одного лишнего человека), и не выходило условные 100попугаев на команду, три спринта. То в первую очередь шли разговоры о том, что мы плохо оцениваем, а не вы все ....сы ленивые.
Но есть и дедлайна, выставки, релизы и прочее. А тех кто в творческом поиске перманентно (давайте девы самы будут решать когда и как им работать) - у нас просто выгоняют, иногда с проекта, иногда с компании.
Многое зависит от команды/проекта/руководства /заказчика. Может быть дело вовсе и не в сраме.
П.С не совсем дев, системный инженер, или как можно говорить девопс с не слишком большим стажем работы. Может не успел ещё выгореть, но становится интереснее и интереснее на работе
у нас 8 попугаев на две недели. два попугая - день офис в неделю.
дружище, просто девопс это совсем не дев и тут гораздо меньше стресса) Еще и если ты труъ девопс (не член отдела на компанию/кучу команд, а условно отдельный челобрек на продуктовую команду)
Хотя на самом деле может я не прав и мне всю мою карьеру в devops (около двух лет) просто везло с командами
У девопсов тоже много стресса. Если процессы поставлены не очень хорошо, то задачи на девопс/админов регулярно приходят с ДД на вчера.
Я в принципе в странно проекте. У нас 4 девопса, на одного тестера и 3х девелоперов.
Мой опыт не релевантен. Но есть и дедлайны, и прочие радости. И да, мы команда, под один продукт, в немного разных вариантах, но технически он один.
Однако я сторонник того, что нужно правильнее планировать. Если от вас хотят задачу на три дня за два рабочих, то это вопрос не спринтов, а хотелок и планирования.
О, коллега. У нас тоже спринты, 1 попугай - задача до 2-х часов по сложности, 13 - весь спринт (2 недели). Есть планирование, где треть задач это "вот таска, она нужна завтра, и эта завтра и вон та завтра, и ту сегодня вообще после планирования возьмите". А еще я не чистый девопс, а инфра в том числе, поэтому есть тьма абсолютно не прогнозируемой текучки, а еще дежурства по инфре, дневные и ночные, а еще аварии, а еще часть других отделов забивает на планирование и приходят с "надо срочно для бизнеса" и это надо впихнуть в "спринт". Выгорание? Нет, но я твердо уверен, что куча процессов в айти давно бесповоротно сломана. Формально за мной закреплен проект и пара команд, по факту - кто пришел, тот и любит (как у женщин с низкой социальной ответственностью, да).
что вам мешает переносить задачи в следующий спринт и делать спринты длинее?
Спринт это не данность "решить 1 задачу сейчас". Может быть больше одной задачи и больше одного спринта.
В целом стресс зависит от вашего планирования, а не выбранной системы планирования.
Можно перейти на канбан и через какое-то время внезапно обнаружить, что надо отчитываться перед руководством о том, что сделано за прошедший месяц. Еще через какое-то время ты начинаешь по такому случаю планировать задачи и фичи на ближайший месяц, а конец месяца становится уже привычным дедлайном, потому что потом встреча с руководством. А еще по такому случаю появляется желание устраивать ретро по итогам каждого месяца.
И вуаля, у тебя канбан, который выглядит как скрам, только с длиной спринта 1 месяц ))
Могу только подписаться под каждым тезисом этой статьи. Искуственность итераций, необходимость регулярных ритуальных приседаний, всё это вредит разработчику и разработке. Но, поскольку решения принимаются менеджерами, скрам стал практически стандартом индустрии. Скрам решает проблемы менеджмента, а не разработки.
Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
Ситуация когда не сделали 60-80 процентов задач это сигнал что что-то очень неправильно.
Либо оценка задач, декомпозиция проводились неправильно. Либо вам задачи в спринт засунул менеджмент несмотря на совокупную мощность команды. Либо предельно нарушен процесс разработки и кто-то грязными руками лазил и дёргал разработчиков.
Нужно остановится и подумать (о ретро об этом, не так ли?). Но, к сожалению, чаще просто переносят тачки дальше.
Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
Слон в том, что команда сама планирует. У разработчика спрашивают, сколько займёт та или другая задача в спринте.
Никто не хочет завалить спринт. Никто не хочет сидеть без задачи. Так берите в спринт адекватно. Это же в ваших возможностях?
И будет вам 80% ежеспринтово и стремление к 100 как цель
Но ведь это не в наших возможностях. Об этом и был мой комментарий.
Мир непредсказуем. Как ты ни крутись, но 100% всё равно не попадёшь. И статистика это подтверждает, можете сами посмотреть, как в индустрии обстоят дела с предсказуемостью.
Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
Нет задачи попадать на 100%
Набейте спринт задачами, 60% которых -- обязательные и ещё 60 -- опциональные. С очень высокой вероятностью обязательные будут сделаны, а общий выхлоп будет плавать то в пределах 80-110%.
Пытаться каждый раз делать спринт на 100% -- это утопия, но скрам даёт возможность команде подстраиваться под самое себя.
Вы не с тем человек спорите. Я то считаю, что 60-80% это вполне ок. Мне вот пишут, что это мало и надо 100%.
Не спорю, уточняю, скорее.
60% -- это не ок, это допустимый очень изредка минимум.
Да, мне думается, что усреднённо делать около 100% возможно; важно лишь разумно эти 100% наполнить на 60% обязательными, а остальные 40%, грубо говоря, набирать из бэклога типа "несрочное" и позволять разработчику(команде) скоуп этих 40% перенаполнять по ходу спринта.
Ну так вносите непредсказуемость в вашие естимейты.
Это и есть основная идея теории хаоса.
У маленьких проектов в принципе больший процент неправильных естимейтов.
У нас вообще прикольно сделали. У каждого проекта свои несихронизированные спринты. Команда разработки участвует в нескольких проектах, то есть у команды сразу несколько спринтов. Как в таких условиях живется команде, менеджеров не волнует. У них-то всё по феншую.
Работа это вообще стресс, особенно когда еще спрашивают результат
Вы еще про Rapid development почитайте)
Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.
Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
Так ретроспектива не для это же предназначена. Я всю жизнь думал, что ретро - это мит где обсуждают проблему отсутствия очистителя воздуха в офисе
Да, многие так и думают. :-) Хотя реально это важнейшая вещь, часто куда важнее спринт ревью. И как-то у меня обычно люди реально говорят, что им нравится и не нравится в процессе, что пошло не так, что и как стоит попробовать иначе, и очень редко это отсутствие очистителя. :-) Именно по итогам ретроспектив можно процесс настраивать. Scrum -- это, имхо, в последнюю очередь ритуалы. Если некий ритуал мешает, мы его просто заменяем тем, что нам надо, и пусть хоть сто книжек возмущаются, именно в этом суть нормального вменяемого Agile, идеи которого в ориентации на реальность, а не на процессные правила.
В большинстве компаний Scrum вообще используют совершенно безумно, а потом удивляются, что люди выгорают и увольняются. Особенно меня умиляет желание сразу реализовать какой-нибудь SAFe в армейском стиле хождения строем. Но зовут варваров-консультантов, платят им миллионы и не думают, не фигню ли мы делаем. Это же во всём мире принято. :-)
А ещё в головах сеют полный бред типа "суть Agile в том, что всё решает команда". В плане принятия решений суть в том, что всё должны решать те, кто имеет компетенции для принятия именно этого решения, а не демократическое голосование. Часто это команда. Или команда + продакт овнер. Или ещё и представитель бизнеса, знающий нужный аспект. Или часть команды. Или даже конкретный человек. Но не некий "начальник" и не голосование людей, ничего не знающих о вопросе.
Ретроспектива - важнейшая часть любого agile подхода, так как именно ретроспектива делает из вашего подхода гибкий подход. Все проблемы которые в ретроспективе зависает больше, чем на несколько спринтов - повод к рассмотрению текущей реализации скрама, и поиск как можно его изменить и адаптировать.
Без ретроспективы - какой же тут аджайл будет...
Интересное мнение, но тут как посмотреть и смотря кому :)
Я, например, учился так работать (Scrum/Kanban) — так и работаю, ощущая себя очень комфортно в этой парадигме. И меня раздражает отсутствие краткосрочного планирования (дедлайнов на след. неделе), ректроспектив и постоянного обсуждения «а что же происходит, а что мы делаем/сделали/будем делать».
Да, другие методы разработки продуктов тоже содержат в себе эти процессы, однако они лишены такой динамичности — лично для меня это минус, потому что библейский вопрос «а не йухню ли мы делаем?» никто не отменял, но ответ на который лучше получать постоянно и непрерывно, пока не поздно.
При этом с некоторыми пунктами я не согласен. Например, про отсутствие автономии и априори недостаточность подготовки. Всё это сводится к конкретным случаям/продуктам/командам/задачам. Если процесс плохо выстроен, а исполнители не особо понимают что они делают, то неважно какая методика используется — будет хаос.
Современные продуктовые команды в рамках Scrum, на мой взгляд, наоборот, расширяют автономию каждого из участников, позволяя всей команде выбирать путь наименьшего сопротивления для достижения конкретной цели «здесь и сейчас», а не иллюзорного результата через месяц-год-полтора. Коммуницирование в Scrum стоит во главе угла, поэтому, если все налажено, не может возникнуть ситуации, когда тебя ну прям вот заставляют что-то делать. При этом никто не отменяет использование вспомогательных инструментов, как burndown chart — чем не помощник в планировании и уменьшении стресса связанного с «я не готов морально работать постоянно, потому что не вижу ни конца, ни края задач».
Но, с чего и начинал, опыт у всех разный, команды/продукты/процессы/задачи у всех разные, поэтому каждому своё.
Спринты все же являются частью квартального, годового планирования, например, и их бесконечность уже не так пугает.
По личному опыту работы менеджеры(продакты/проджектов) за очень редким исключением могут подходить к команде/продукту/процессам индивидуально, адаптивно и в целом включать голову, в основном это дикий карго-культизм без понимания и зачем оно вообще нужно и нужно ли оно здесь вообще. Мало того, что эти люди как правило не понимают технической составляющей вещей, из-за чего любые созвоны затягиваются на жутко долгое время, так они и по своей части как правило просто следуют каким-то средним по больнице практикам, которые зачастую приносят больше вреда, чем пользы.
И порой думаешь, что хотелось бы видеть на этих позициях людей с техническим бэкграундом. Но, тут беда в том, что люди с техническим бэкграундом редко идут на эти роли и индустрия это никак не поддерживает (ведь даже если ты уже хороший сеньор, то ты просто обязан расти как специалист в своей сфере, ты и будешь уверен в своём будущем и к тому же станешь только скилловее и наверняка прибавишь к зп). Не говорят о том, что технические специалисты чаще являются интровертами, по мере работы им больше необходимо тратить времени на самообразование, на исследования и тд, что тоже их отдаляет от качеств, более необходимых для менеджера.
В итоге имеем то, что имеем. Задача не простая и тут, наверное, надо с умом подходить к системе образования специалистов. Да и методики надо сильно менять, либо заставлять менеджеров хотя бы прочитать их полностью, а не выжимки в пару абзацев.
Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
Очень странная статья. А как автор предлагает планировать работу в IT? Водопадом? - Хорошо, когда у вас есть монопроект, один заказчик, делайн и бюджет. А когда маркетплейс и 200 одних маркетологов в штате, у которых идей через край каждый день?
Канбан? - Но это как-раз про белку в колесе с бесконечным днём сурка.
Возможно, как было сказано выше, дело в том, что надо подстраивать скрам под свои реалии. У нас в команде плюс от скрама - это ритмичное планирование со стороны бизнеса. Раз в две недели прегруминг, раз в две - груминг. Люди знают, в какие окна подавать предложения, чтобы разработка взяла их к себе в план. Второй плюс: у разработчиков есть некое подобие начала и окончания работы. Чисто психологически это более комфортно людям. Я чётко вижу, что в начале спринта люди работают активнее, в конце более расслабленно.
Но мы у себя отделили релизы от завершения спринта. Именно поэтому нет совершенно никакой цели впихнуть не впихуемое и зарелизиться во чтобы бы то ни стало ко второму четвергу недели. У релизов свой план. Такой подход, конечно, предъявляет повышенные требования к руководителю команды, зато позволяет сглаживать моменты со сроками.
И ещё очень непонятно, когда люди пишут о принципиальной невозможности оценок задач. Мы у себя процентов 80 задач оцениваем с точностью до 10%. Понятно, есть отдельные исследовательские задачи с открытой постановкой вопроса, но большинство - банальная работа с сервисами, которые уже существуют. Развивайте свой профессионализм, делайте анализ предыдущей работы, прокачивайте навык оценки.
>>Спринты никогда не кончаются
А почему они должны кончаться? Это все равно что слесарь-сантехник будет сетовать: "я каждый день меняю краны смесители, а они все не кончаются".
Дедлайн - это момент, после которого уже не надо.
Отметил бы следующее. Scrum позиционировался, как фреймворк управления процессом разработки, чтобы делать быстрые поставки, получать обратную связь, и на основе обратной связи принимать решение, куда двигаться дальше. Т.е. фрейвморк для работы в рамках неопределённости. У нас же его пихают везде, и в разработку маркетплейса (не понятно, что и когда нам надо будет) и в проект (нам надо систему А заменить на систему Б, оставив 90% функционала "как есть"). И если в первом варианте ещё "ок", то во втором это уж на еже.
Для себя я отметил бы следующие моменты, которые я отношу к минусам данного фреймворка:
1. Это фреймворк. Т.е. инструмент, который надо использовать "как написано", а не допиливать его. Иначе - это "не считово" и именно по этому у вас "не получается"
2. Команда берёт на себя коммитмент, чтобы сделать задачу в течении спринта. И в рамках спринта мы должны сделать "всё" и уточнить требования, и разработать и протестировать и хорошо бы "задеплоить". И вот с этим всегда проблемы. Заказчику не нужны задачи "создать сущность ПОЛЬЗОВАТЕЛЬ", "Сделать формочку регистрации", "реализовать API для регистрации", "Реализовать логику регистрации пользователя", "Отправить письмо о регистрации со ссылкой подтверждения почты", "Подтвердить адрес электронной почты". Пользователю нужны две пользовательские истории "Я как пользователь хочу зарегистрировать", "Как зарегистрированный пользователь хочу подтвердить свою почту". И если первые задачи влезают в спринт, то пользовательские истории редко влезают в спринт.
3. Из этого следует следующий "минус". Т.к. мы не можем поставить(с деплоем) функционал в рамках спринта, то мы не можем сделать ревью, т.е. показать пользователю работающий функционал, но можем показать "данные в табличке". И всякие такие "заплатки". Что автоматом приводит к ощущению "отчёта перед заказчиками", а не к процессу получения обратной связи от заказчика.
4. И ещё один больной момент - непрозрачность процесса. Т.е. часть работы по процессу делается "за рамками" спринта, и значит - задачи. Либо мы делим задачи на "предварительный анализ"(до спринта), задача же для взятия в спринт должна удовлетворять критериям DOR и саму разработку, либо одну задачу мы делаем в рамках двух спринтов (1 - анализ, 2 разработка). И вот тут на сцену вылезают оценки. При переезде задачи из спринта в спринт надо менять оценку? А как изменённая оценка должна учитываться в пропускной способности команды (в спринте)? Как изменённая оценка влияет на предсказание поставки?
Почему Scrum так изматывает