Комментарии 101
С 2020-го? Камон, я эти все истории с 2013-го слышу минимум....
Я только с 16-го управляю проектами. Первое время только и слышал о переходе на SCRUM-процессы. Очевидно критика была, но в СНГ в основном восторженные отзывы. Многие ориентировались на EPAM, забывая о специфике своих проектов и активно нанимали коучей.
Ну тогда их действительно пытались пришить ко всему подряд. Но опять же, именно благодаря этому довольно быстро стала понятна ниша, в которой скрам работает, и краевые условия, по наступлению которых он работать перестаёт.
К сожалению, учитывать эти условия приходило в голову сильно не всем, что изрядно репутацию попортило.
Я в 2008ом уже студентам рассказывал про проблемы Scrum и граничных условиях )
Мне кажется вы свой ограниченный опыт проецируете на всю отрасль. Это как если бы человек, которого в море покусала акула, начал утверждать, что купание - зло.
Мой опыт, опыт коллег, анализ публикаций по теме, данные статистики об успешности проектов, сведения об отказе от SCRUM в крупных компаниях (что интересно даже в тех, где методология показала себя неплохо) полагаю дают достаточно репрезентативную картину. Я не хейтер методологии и управлял проектами в её рамках (правда без скрам-мастера), более того завершал успешно, но есть проблемы её применения без модификации, как я их вижу - описал в посте. Я не первый об этом пишу, в т.ч. на Хабре.
https://habr.com/ru/articles/430890/
https://habr.com/ru/articles/430890/
https://news.ycombinator.com/item?id=34742515
https://www.quora.com/Can-you-please-elaborate-on-why-Scrum-Agile-is-bad-for-developers-from-a-developer-s-perspective (тут особенно интересно, что пишет магистр компьютерных наук Александр Атанасов из Болгарии)
https://blog.mb-consulting.dev/scrum-sucks-9960011fc5cf
https://www.reddit.com/r/Frontend/comments/vs3w1z/i_hate_scrum_is_it_only_me_or_other_programmers/
Я могу продолжать долго, очень долго. Я не отрицаю, что в scrum есть много привлекательных вещей, которые полезны в разработке, но в чистом виде они нивелируются врождёнными бесполезными, а иногда вредными недостатками.
Если речь о ситуации в которой акулы нападают на каждого второго купающегося, то, думаю очевидно, что купание - зло. А не злом оно является лишь в изолированных бассейнах и водоёмах, где нет акул.
Предполагаю, что ваш опыт и опыт коллег скорее всего касается крупных производств в которых зачастую преобладает кровавый неэффективый энтерпрайз и в них очень тяжело приживается любой agile (не всегда) и в этой тусовке много хейтеров как скрама так и вообще всего agile.
А если вы возьмете b2c с его высококонкурентной средой, то там сплошь и рядом будут успешные кейсы работы по scrum и прочим agile-ам.
Что касается ваших ссылок, то я ради интереса зашел сюда https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/ и тут можно сразу не читать после
The study, conducted by Dr. Junade Ali and reported by Engprax (who offers a commercial alternative to Agile)
Исследование схоже на коммерческий булшит. Я уверен, можно найти сотню других исследований с противоположными выводами. Это лишний раз подтверждает то, что в различных отраслях различный опыт.
Если посмотреть на b2c web, то в нем скрамоподобные процессы сами собой зарождались еще в начале нулевых, когда слова agile и scrum особо никто и не употреблял. Просто потому что web сильно упрощал доставку ценности клиенту (svn up и готово), сильно удешевлял цену ошибки (svn up -r и вуаля) и подталкивал конкурирующие гибкие команды к короткому релизному циклу, что влекло за собой остальные моменты, свойственные скраму. И эта отрасль все эти годы успешно живет на подобных фреймворках.
В b2c web с небольшой командой, как мне кажется, можно просто брать Agile-манифест и следовать принципам, а не заряжать структурированную методологию с кучей ритуализированных нагромождений, но это ИМХО. Опять же есть ли говорить об абстрактной оценке задач и покер скраме, то они полноценно применимы там, где все и так корректно соотносят условный сторипоинт с часами или днями. Итеративная поставка ценности - да, и я упоминал, что это пожалуй лучшее, что есть в скрам.
А вот регулярная обратная связь - уже ситуативно, это опять может стать проблемой на практике, иногда, даже в упомянутых b2c проектах лучше максимально полно собрать и документировать требования, и заряжать источники требований на их более тщательное обдумывание на старте, чтобы их массированное изменение в процессе не превратило разработку в сумбур и не повело по пути бесконечного улучшения. Так как при гибких изменениях требований в процессе уже запланированного спринта, особенно если речь идёт о неких блокирующих задачах, стройное планирование итерации может полететь в тартар.
В таких проектах также можно выстроить порядок сбора требований (подготовки артефактов) и проектирования (блок-схемы, вайрфреймы, дизайн интерфейса страниц и т.п.) таким образом, чтобы минимизировать изменения в процессе. Иными словами есть много факторов, которые затрудняют универсализацию подходов, если конечно проекты не совсем конвейерно-типовые.
Вообще, в скраме еще и очень медленная обратная связь (и нет никаких требований к ее ускорению). И это крайне грустно для любых более-менее нормальных процессов и продуктов.
Изменения - это данность, почти в любом плюс минус сложном бизнесе, с этим надо жить, эджайл потому и появился, как признание этого факта. Другой вопрос, что действительно, не надо приучать "бизнес", что любые изменения легко даются и можно хотелки в беклог всовывать легко и непринуждённо.
О какой куче ритуализированных нагромождений речь? Причем тут покер скрам? Вы вольны выбирать любую методологию оценки и скоринга задач, скрам вам их не навязывает. Вы вольны проводить планинги, груминги и прочие ретро так как вы хотите, скрам лишь предлагает некие ориентиры, которые вы можете тюнить под себя как хотите. Создается ощущение, что скрамом вы называете не скрам гайд, а какую-то сильно конкретизированную сборку на его основе, с которой вам пришлось столкнуться.
лучше максимально полно собрать и документировать требования, и заряжать источники требований на их более тщательное обдумывание на старте, чтобы их массированное изменение в процессе не превратило разработку в сумбур и не повело по пути бесконечного улучшения
Конкуретный рынок с таким подходом выбросит вас на обочину. fake it till you make it не на пустом месте родилось. Пока вы будете тщательно собирать требования, конкуренты захватят аудиторию.
Хм, в небольших командах скрам особенно избыточен и негибок. Там проще брать канбан, минимизировать количество ритуалов и нормально работать. Скрам там и дорог и неэффективен. Ну и, конечно, считать скрам - аджайл-методологией довольно странно, в гайде отчетливо "процессы важнее людей".
Да, хороший менеджер, играя роль скрам-мастера, может выкинуть или переосмыслить скрам-гайдт и нарисовать нормальный рабочий процесс. Но без гайда у него получится еще быстрее и проще.
Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
В больших проектах можно уже найти хотя бы одного нормального менеджера, который настроит вменяемые процессы, а не скарм (в котором, заметим, вообще нет инструментов координации команд, там нужно идти в LeSS или SAFe, а это совсем грустные тяжелые жесткие методики).
Проблема совместной оценки сложных задач решается, в первую очередь, работой с архитектурой и обратным законом Конвея, скрам там вообще никак не поможет. А уж "субкоманды" - это явный скрамбат, к скраму отношения не имеющий.
Почитал о том, адепты чистого скрам считают причинами скрамбатов. Там огромное количество "истинных причин" вполне соответствуют распространённому когнитивному искажению - предвзятости подтверждения. Т.е. любую попытку модифицировать методологию под конкретные условия и отойти от догмы, объявляют следствием причины, которая существует лишь в рамках парадигмы того, что скрам в чистом виде лучший фреймворк на земле и обладает достоинствами, которых нет у других фреймворков и методологий (главное правильно молиться соблюдать ритуалы). Т.е. таки "серебряной пулей", но то, что "осиновый кол" с "чесноком" в ряде случаев работают значительно лучше и без танцев с бубнами скрам-мастера, никто не из них не пишет.
В Беркли сейчас учат "Processes drive team’s behavior, and behavior drives results” (или типа того). Процессы не так чтобы важнее людей - а помогают направлять настроение и в итоге продуктивность людей в определенное русло.
Вот у нас маленький нормально расписанный фокус на две недели, вот он в родмапе на стене, вот у нас все нормально все хранится, наши совещания быстрые, дружелюбные, я не теряю на них час и не молчу , вот гарантировано можно спросить сейчас или на летучке, вот можно сказать о проблеме и ничего не будет плохого, это тоже часть процесса, вот мы регулярно осваиваем новое и успешно добиваемся с этим классных фишек, а вот еще лидер проекта поддерживает, развивает, прикрывает участников команды, если нужно, и в курсе личных дел и помогает тоже. И не лезут с микроменеджментом, да - мне интересно реализовать задачу самому, и я это умею.
А вот мы отметили релиз и нам каждые несколько дней доставляют обратную связь от клиента, в тч благодарности и успехи - и они заряжают чувством полезности - это тоже часть процесса.
Если процесс ломает людей, а не вносит комфорт, продуктивность, личное развитие, не поощряют самостоятельность, не поддерживает чувство вовлеченности, смысла, значения своей работы и др - с этим тоже нужно работать.
Были исследования, в которых с удивлением обнаруживали, что для высококвалифицированных профессионалов деньги с определенного уровня уже не влияют на результативность - а на первый план выходят вещи типа упомянутых выше. Освоение нового, автономия, чувство создания чего-то важного или хотя бы понятного, и др.
В общем, тут все тонко и далеко не просто. Инструмент - это только инструмент…
Хм, а причем тут скрам? И agile manifest не про "ненужность процессов", а про "люди важнее процессов". И если людям удобно поменять процесс - его надо менять (даже если при этом придется отойти от скрамгайда).
Скрам не является agile именно потому, что любое отклонение от скрамгайда уже не является скрамом.
А от чего вам хочется, но не дают отклониться, можно конкретно?
Одно из обязательных в скраме - inspect and adapt и экспериментировать - анализируй и меняй - процессы, документы, что шло хорошо и что плохо в спринте, и что приводит к лучшим результатам.
То есть это все инструменты в первую очередь не проект сделать, а команду, которой удобно сделать проект.
Бэклог, план дел на 24 часа на летучке, приоритет чтобы работало , а документация вторична - что из этого вам мешает и хочется выкинуть?
Кроме того, выделенная в скрам команда проходит стадии forming - storming - reforming - performing - и это все адаптация, эволюция. Это как бы не расписано в скрам, но подразумевается и неизбежная часть работы лидеров.
Не понимаю, что значит “Скрам не является agile именно потому, что любое отклонение от скрамгайда - уже не скрам". Это будто сетовать, что вам не даёт похудеть режим трехразового питания🤷
А подходит конечно не всем и не всему.
Хм, в скрайм-гайде дофига странного.
Регулярные ретро (которые нужны не слишком опытным командам), цель спринта (которая имеет смысл довольно редко), сами спринты (очень сильно увеличивают нагрузку на команду) и так далее.
Кстати, никакого "приоритет чтобы работало , а документация вторична" в скраме нет. Лидеров в скраме тоже нет никаких (только скрам-мастер, но он про другое). Плана дел на 24 часа, кстати, тоже нет (впрочем, это довольно сомнительная практика).
Но, чисто формально, скрам не соответствует agile-манифесту. Впрочем, большая часть скрама - и не противоречит манифесту (и вообще не касается его тем).
Ну, не нужны, так не нужны. Цели, ревью, этапы, план на день… лучше, в целом, и не работать.
Ну, нет в скрам роли product owner, так нет - пусть скрам мастер решает как удобно клиентам, сам с ними общается, вникает, как им удобно и как вообще в этой сфере устроены лучшие решения, а заодно пусть оплату с них берет. И само собой команду и задачи курирует как следует весь день. Да и вообще, клиенты не нужны и понимать, как работают, не надо.
Ну, нет там приоритета working software over comprehensive documentation https://www.dummies.com/article/business-careers-money/business/project-management/scrum-for-dummies-cheat-sheet-207541/ - так нету)
Главное чтобы получалось и нравилось.
Опять передергивания )
Цели спринта - очень часто не нужны (и даже вредны), особенно в исследовательских задачах в сложных предметных областях. Есть много одновременных эпиков, над которыми нужно работать. И, заметим, одновременная работа над одной задачей нескольких человек обычно снижает эффективность.
Про product owner я вообще ничего не говорил, причем тут он? И роль PO в скраме предполагает только управление бэклогом, к общению с клиентами она не имеет никакого отношения (может лицо, играющее роль PO этим занимается, может нет - скраму на это пофиг).
Использование каких-то левых ресурсов для подтверждения неверного мнения про скрам - довольно странное. Скрам определяется скрамгайдом и только )
Так PO и есть лидер проекта (не команды, а проекта)))
И по-вашему владелец проекта - Product owner, обладающий полной властью над тем, что нужно сделать и несет ответственность, какие будут результаты проекта, и формулирует максимально точные задачи и порядок их выпуска (Скрам мастеру) - берет свое видение не из общения с клиентами и стейкхолдерами и понимания, как они этим всем пользуются?)
Скрамгайд настолько абстрактен, что отклониться от него весьма непросто.
SCRUM это не Agile, SCRUM это противоположность Agile мимикрирующая под Agile чтобы манагеры не способные (а скорее не нужные) в Agile могли внедрить у себя якобы Agile сохранив работу и при этом продолжая все максимально контролировать как и раньше.
Мой опыт включает два противоположных результата
1 Команды работали внутри банка и разрабатывали ПОдля банка. Соответственно заказчик банк - исполнитель банк. Скрам с некоторой адаптацией прекрасно работал, дейли по 5 -10 минут не больше, ретро до часа.
2 Команды работают внутри ИТ компании, у которой договор с заказчиком и конкретное ТЗ. ТЗ написано так себе, сделанное по ТЗ иногда просто невозможно использовать, заказчик начинает осознавать и выкатывать новые требования - реально полезных вещей но их нет в ТЗ. Гибкая разработка говорит - ДА давайте делать полезное. Договор говорит - тебе заплатят N рублей только если ты сделаешь, то что написано в ТЗ, а за сделанное сверх хоть и полезное никто не заплатит. И если компания заказчик с Гос участием там еще и закупочные процедуры и бюрократия которая почти ничего в договоре поменять не позволяет, и иногда готовы вроде отдельный договор на доработку - но план бюджета не позволяет и т.д.
Тут начинается такая "гибкая" разработка, которая скрам методологии и не снилась.
Имхо фикспрайс и эджайл - это антонимы по определению.
Только в реальности обычно так и бывает. На верхнем уровне проект оценен в XXX млн рублей и продан. Все документы подписаны и спускается сверху команда: "Ребята, мы все продали, вы там внутри команды играйте в свой аджайл, но чтобы вот этот проект к такому сроку был готов."
Клиенты поопытней и сами понимают, что так не работает, на выходе будет кака и тёрки по доплатам и начинают пробовать аутстафф и прочий не совсем фикспрайс.
Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
Кажется, Билл Джой как-то сказал (цитата не абсолютно точная, но по смыслу очень близко): великие программы создаются одиночками или очень маленькими группами единомышленников, а не толпой посредственностей, вкалывающих до усеру. Понятно, что великих (да и просто хороших) программистов очень мало. Степень сеньористости почти никогда не отражает истинный потенциал программиста. Я знаю очень скромных людей, не имеющих никаких званий, чьи знания и навыки вызывают оторопь и восхищение. Скрам, аджайл, груминги и иже с ними - это процесс, цель которого попытаться заставить посредственности (имя им - легион) что-то и как-то наговнячить более-менее работоспособное в минимально короткие сроки, дотащить до прода и приняться за новую поделку того же уровня качества.
Так что мне нисколько не жаль ни скрама, ни аджайла. Придумают что-то новое, в еще большей степени бессмысленное и бестолковое. Танцы с бубном не прекратятся. Просто будут танцевать под чуточку иную музыку.
Алан Чумак заряжал банки с водой, скрамота пытается сделать то же самое с программированием, заряжая головы разработчиков пышной болтовней.
Извините. Я знаю, что обижу многих. Минусуйте, что же поделаешь :)
Скрам - это ещё про повышение прозрачности перед заказчиком (за что его исполнители и не любят). Внедрив некий гибрид скрама в один проект с ковбой-менеджментом, наконец удалось отшить бизнес с постоянными наездами "вы тут ни хрена не делаете, ничего не происходит, платим много, а результатов нет". Когда вся работа визуализировалась, стало проще тыкать бизнес в собственный бардак и хоть немного, но упорядочить работу.
может и так, только это все про "великие программы". А таких на всей планете штуки 3. Весь остальной софт пилится спокойно "толпой посредственностей, вкалывающих до усеру"
всё верно, только не "посредственности" и "наговнячить", а "обычные люди" и "разработка с предсказуемым результатом." Именно то, что нужно корпорациям. Потому что, невозможно нанимать одних гениев. А вот нанимать людей, выдающих предсказуемый результат, очень даже возможно. Более того, их можно найти много, собрать из них много команд, писать и поддерживать много программ и зарабатывать много денег. Именно то, что нужно корпорациям
Тезисами и по делу:
Скрам не методология.
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Обнял.
Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
И это верно, но вопрос оправданы ли риски такого внедрения.
В Скраме нет проджект менеджера.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно.
Тогда возникает вопрос в чем в принципе его ответственность?
Скрам лишь запрещает отказываться от роли целиком.
Очень гибко)
Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты.
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
"Минимизация бюрократии" - от создателей "документация не нужна".
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
Если в вашей команде не умеют проводить эффективные митинги
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Или он ранее от тоже казался ненужным?)
Напротив, очень полезный человек)
либо "адаптаций"
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
При этом я ни в коем случае не называю Скрам серебряной пулей
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Искренне рад, что вы нашли свой путь. Обнял.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
Я нигде не утверждал, что чистый Скрам работает и я знаю такие команды.
Я утверждаю, что вы делаете вывод "Скрам не работает" на основе ложных посылок.
Более того, что случится, если я назову команду, где чистый Скрам работает? Вы уверуете и удалите эту статью?
Меня привлекла аргументация "Почему Скрам не работает". Собственно, разбору этих аргументов и посвящены мои комментарии. Не более того.
Тем не менее, все о чём пишет автор вполне справедливо. Современный повсеместный скрам это скорее какой-то монстр, который не имеет ничего общего с тем, каким его придумали. Это скорее говорит о его несостоятельности. Идея заменить методологию конструктором методологии сильно зависит от человека. Это как создать самый технологичный танк, не учитывая, что нужно будет за месяц научить им пользоваться условного вчерашнего тракториста.
Если это монстр, почему же он так популярен? Причем везде на планете, причем в очень высококонкурентном бизнесе, где попробуй только смузи не того цвета на кухне предложить - твой компании конец !!
p.s. у меня два варианта, либо это заговор рептилоидов, либо одно из двух
Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает.
Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
Ну, в мире у эффективных компаний не так много скрама, кстати. И высококонкурентный бизнес не так уж сильно зависит от эффективности разработчиков, как ни странно.
Ну и в индустрии вообще любят очень неудачные решения, так как про них проще рассказывать на конференциях.
Это не какой-то конкретный монстр. У каждого этот монстр свой.
Как видится мне, основная проблема во внедрении Скрама заключается в изначальном желании "адаптировать" Скрам, а не инициировать изменения в компании.
В итоге компания, которая недовольна текущей орагнизацией работы, протаскивает эту неэффективность в свою "адаптацию" Скрама.
Мне кажется все ровно наоборот. Изначальный скрам нельзя адаптировать. Потому что это не методология. Это набор кирпичиков Лего, строй из них что нужно.
И он скорее одинаковый, чем разный. Мне кажется причина в том, что менеджеру надо как-то оценивать качество своей работы. Даже правильные действия не всегда ведут к результату для бизнеса. Поэтому по результатам не получится. Вот и превращается это в процесс ради процесса.
Скрам мастер должен поставить процессы, которые будут приводить к результатам. Но, вместо этого просто фигачат кучу процессов, ведут дейлики и занимаются непоймт чем.
Недавно прочитал книгу автора скрам Джеффа Сазерленда. Оказалось, что тот скрам, по которому я 10 лет работал, это совсем не то, что придумали изначально. И, книга отвечает на все вопросы, которые вы поднимаете в статье. Там написано, как надо делать. Но, по факту в компаниях обычно все так, как вы в статье описали. Вы прям один в один описали тот скрам, по которому я работал 10 лет.
Спасибо, я стремился описать именно этот скрам. Только автор статьи я, а не @ozzyBLR
Да, про отсутствие планов и документации - огромная глупость; наоборот нужно супер грамотно и ультра быстро все рисовать-расписывать - иначе через две недели будет не релиз, а понимание, что надо сделать описание и чек лист)))
Agile гибок здесь только в том, что команда может это в удобной ей форме визуализировать/хранить/вести (по сравнению, например, с правилами головной компании - и то не во всем)
>> Почти неизбежно это приводит к задержкам и снижению качества продукта.
Извините, но неизбежно это приводит только к подгоранию пятых точек эффективных, а на качество продукции это часто влияет только позитивно, так как суперсрочная и важная фича со сроком "вчера" в 90% случаев оказывается маловажной прихотью, без которой все переживут еще пару спринтов без особых издержек для бизнеса.
На практике SCRUM не приветствует изменения задач в ходе спринта. Любой скрам-мастер скажет, что это допустимо, но такие изменения потребуют дополнительных издержек в виде оценки, планирования и декомпозиции. Доходит до абсурда, когда для добавления простой и интуитивной понятной фичи, на всякий “маловероятный пожарный случай” создаются новые артефакты анализа, проводятся встречи по оценке задачи и т.д.
Так надо не внутрь спринта. На новый спринт планируйте. Текущий доделывайте как есть.
Короткие спринты позволяют это делать.
Единственный повод менять текущий спринт - поставленные задачи отменены.
А если спринт трёхнедельный, так как поставка ценности в другие сроки невозможна?
И всё ещё - если все согласованные фичи актуальны, команда продолжает их делать.
Новые фичи - на новые спринты. Гибкость же не в возможности тасовать задачи каждый день. Гибкость в коротких спринтах, в противовес ватерфолу в полгода.
И всё ещё - если все согласованные фичи актуальны, команда продолжает их делать.
Извините, но это примерно как в анекдоте:
-Доктор, у меня болит рука, когда я её вот так поднимаю!
-А вы не поднимайте!
То есть проблема есть, но вместо того, чтобы сказать что это проблема и попытаться найти её причину и решение - предлагается не признавать это проблемой. На лицо нигилизм.
Какая проблема?
Спринт - рабочая единица времени для команды. В начале спринта вы оценили и взяли в работу задачи. Задачи делаются, всё хорошо.
То, что у кого-то есть желание засунуть в команду ещё задач, не значит, что стоит так делать.
Представьте на секунду, что спринт длится по 12 месяцев. Новые задачи нельзя запихнуть, и вы утверждаете, что:
То, что у кого-то есть желание засунуть в команду ещё задач, не значит, что стоит так делать
И вот в чем проблема. Для нас здесь сейчас очевидно, что 12 месяцев это перебор (тут думаю мы с вами с этим согласны? Или вам 12 месяцев тоже норм?). А если это будет 6 месяцев , это не перебор? А 2 месяца? А 3 недели? А может 1-2 недели? А почему бы не 3 дня?
Где здесь та граница между "тут слишком много" и "а вот сейчас в самый раз"? Ведь задачи все равно будут поступать, и не все задачи возможно запланировать (срочные, экстренные). Проблема не в самом спринте, а в правилах спринта, что нельзя вмешиваться.
Получается, проблема в том, что потребность вмешиваться есть, но Скрам её запрещает. Вместо того, чтобы думать как её решить, мы ничего не делаем и говорим, что это не по скраму. И вот, проблема есть, проблема откуда не деётся, просто так не делайте.
Вы же как то планируете спринты. Оцениваете задачи, оцениваете загрузку участников команды. Всё это делается, чтобы получать относительно предсказуемый результат на выходе.
Когда вы меняете состав спринта - в идеале надо переоценить задачи, объем задач в спринте и всё такое. И тогда недолго скатиться к "абсурду", с которого эта ветка комментариев и начата.
Если у вас срочные и экстренные задачи - норма работы команды, закладывайте на это ресурс. Отложите условные 20% времени (а лучше оцените это с командой, учитывая её опыт) на срочные задачи и не напрягайтесь. Если срочные задачи прилетят - у вас есть время на них. Если не прилетят - сможете взять мелочей\техдолга в работу, если будет желание.
А граница между слишком много и в самый раз - она в опыте команды и в окружающих условиях. Нет никакого идеального решения, каждый сам подберёт себе удобный вариант. Я работал по 4-5 дневному спринту, работаю по 2-недельному и был опыт месячных спринтов. В 5 дневном спринте никакой менеджер не прибегал с криками "срочна-срочна", потому что это довольно короткие спринты и легко добавить новых задач в бэклог с высоким приоритетом, чтобы команда взяла потом. А вот в месячном это было нормально, потому что некоторые вещи можно было обнаружить посреди спринта и требовалось переосмыслить наши как команды планы.
И к слову, не хотел бы я (как разработчик) работать с команде, где планы меняются регулярно, где постоянно срочность и прочее.
А в чем проблема-то изменить список задач, если приоритеты поменялись?
Почему это запрещено? В чем смысл?
Нет проблемы. Отменяем спринт, планируем новый. Спринт - это единица времени для управления.
Т.е заново проводим груминг, спринтплэнинг, вносим в спринт уже вносившиеся задачи, занимаемся перерасчетом времени команды, вместо оптимизации текущего спринта?
Именно так. Спринт по каким то причинам не выполняется, новый спринт начинается с начала.
Но только в случае, если текущий спринт не требуется завершать. Иначе спринт очевидно идёт как идёт. Можете выкинуть мелкие неважные задачи, если они стали неважны, но если вся цель спринта стала неважна - спринт нужен новый.
Э, когда это спринт стал единицей времени для управления?
И вообще, мы про скрам говорим или про что-то другое?
В скраме нет запрета на изменение состава спринта, запрещено только изменение цели спринта (и это вполне логично).
Хм, по последнему гайду нельзя только цель спринта менять, все остальное - вполне допустимо. И изменение задач, и добавление новых и так далее - вполне разрешено.
Добавление новых по типу "надо бы добавить настройку для фичи, сделать за час и протестировать за час" - вполне. И аналогичные изменения. Это никогда не было запрещено.
А вот то, что может повлиять на достижение цели, из разряда "ну тут бизнес хочет ещё отчёт налабать", а у команды нет ресурса - то каким образом это делать, не создавая тот самый "абсурд" с переоценкой, про который пишет автор?
Ну, это как раз про то, что у скрама очень плохо с t2m. И если нужна быстрая реакция на изменения - то скрам категорически не подходит, нужны другие методики.
Скрам - это для неторопливой простой работы в хорошо известной области. Если нужно за год написать 1000 похожих отчетов, тогда скрам замечательно подходит.
У скрама с т2м всё просто - за спринт. И быстрая реакция тоже там же - в спринт.
Нет, гораздо больше, чем спринт, обычно три спринта (в одном груминг и анализ, в другом разработка, в третьем доработка после демо). И это очень долго (
Так это же зависит.
Когда 1 марта говорят что нужна реклама к 8 марта, её делают за 2 дня и выкатывают. Потому что решение типовое, задача срочная, все согласны на хорошие решения.
А когда сроки только в голове у бизнеса, задача непонятна, а надо сделать на отлично и никак иначе - да, уйдет минимум три спринта. Придётся выяснить что именно хочет заказчик (продукт овнер, бизнес, короче тот кто хочет фичу). Придётся сделать и показать. И если не угадали - доделывать.
Только я не согласен, что это проблема с т2м. Это проблема с задачей. Когда команда знает предметную область, когда им понятно что от них хотят - они способны делать фичу в спринт.
Ну и понятное дело, что невозможно запустить большую фичу за неделю. И тут я не видел хороших решений в любых аджайл фреймворках. Всегда будет убито время на аналитику (в спринт минимум, может больше). Пропорционально будет время на разработку и тестирование (пара спринтов). И даже проводя демо после каждого спринта (по результатам аналитики, по результатам разработки) всё равно реальность может показать, что что-то упустили. Это жизнь, команда получила опыт, в новой фиче похожего рода они будут лучше и быстрее.
Очень долго - субъективно. Очень долго в моём понимании - это когда 2 месяца собирали требования и писали ТЗ. Потом 4-8 месяцев реализацию писали разработчики. Потом до 2 месяцев тестирования с исправлениями. И вот спустя год - фича на проде. Можно то же самое за полгода, что всё ещё долго. И вот в сравнении с таким подходом, 2-3 спринта по неделе - это быстро.
Угу, я и говорю, скрам - для понятной предметной области и простых типовых задач. Ну и для средних команд и плохих менеджеров.
Именно потому, что задача в канбане легко реализуемая за неделю (день на обсуждение, три дня на реализацию, день на правки), в скраме потребует 6 недель.
Так, а канбан как решает эту проблему?
Если что, скрам тоже не запрещает запланировать "обсуждение", "реализацию", "тестирование" на спринт и сделать.
Ну, можно назвать скрамом что-то, где задачу планируем где-то в середине спринта, сразу показываем бизнесу, вносим исправления и выкладываем. Но тогда там не будет ни планинга, ни демо ни, собственно, спринтов (что, впрочем, сделает процесс только лучше).
Но это будет уже не по гайду
Планируем в начале спринта - команда считает что задача простая, берут в работу.
Аналитик прорабатывает, устраиваем PBR, обсуждаем. Разработчик делает. Тестировщик тестирует. Опа, фича готова. Никаких нарушений гайда.
Во-первых, нужно ждать начало спринта.
Во-вторых, нужно уже постановка на начала спринта (иначе как команда решит, что она простая). Ну и, заметим, ты потерял обратную связь с заказчиком )
Если следовать формальностям слово в слово и не думать головой и не пытаться сделать результат лучше - действительно, производительность будет хуже.
Скрам гайд не мешает провести обратную связь раньше, отдельно, не дожидаясь конца спринта и формальной даты. Гайд говорит что надо бы провести демо по результату.
Единственный повод менять текущий спринт - поставленные задачи отменены.
А если ко мне прибегает CEO с диким воплем: "Твою мать, комплаенс банка требует передвинуть на три строчки вверх галку согласия на странице платежа! Если это через полчаса не будет в продакшн, нам счёт закроют!" - это тоже не повод? Увы, подобные вещи встречаются сплошь и рядом.
Вообще-то в эджайле я "ветеран" - начинал аж в 2002, когда один заказчик (душевный друган Кента Бека) нам его притащил. Не сразу зашло, конечно - но вскоре преимущества перед вотерфолом стали очевидными, по-другому с тех пор не работаю. Только вот за всё это время ни разу не удалось внедрить ни одну из эджайл методик без адаптации к конкретным условиям. А SCRUM в чистом виде так даже и не пытался - ибо было очевидно, что по тем или иным причинам он в конкретный проект не лезет. В основном именно из-за неоправданно высоких затрат на ритуализацию и бюрократизацию, и неприменимость в случаях, подобных описанному.
А если ко мне прибегает CEO с диким воплем: "Твою мать, комплаенс банка требует передвинуть на три строчки вверх галку согласия на странице платежа! Если это через полчаса не будет в продакшн, нам счёт закроют!" - это тоже не повод?
Если спринт в итоге не страдает (делается за 1 день, спринты в 2 недели и сроки всё ещё выполнимы) - то на здоровье. Если это задача на неделю+ и спринт в итоге страдает, то спринт в мусорку (отодвигается скорее всего), делаем то что просит СЕО.
Скрам что, запрещает что ли? Просто скрам говорит, что если делаете не так - то спринт не принесёт результатов.
Спасибо за статью. Добавлю только, что проблема с относительными оценками связана с тем, что их воспринимают как оценку. Если отнестись к этому как к категоризации, с учётом прошлого опыта, и создать "калибровочную" таблицу, то возникает поле для обсуждения с заказчиком. Таблица - 5-7 категорий задач, в которые отнесены ранее сделанные задачи "эта по разработке 2-3 дня, но тестировать много и контрагенты тупят, поэтому 8SP, а не 3" позволяет анализировать поток (привет канбан) и говорить о пропускной способности команды на спринт
Так получилось, что я как раз весной проходил курс Agile в Berkeley Extension (доп курсы в UC Berkeley).
И мне особенно запомнились немного другие моменты (и это все полностью бьется с тем, что я вижу в нашем стартапе и своем прошлом опыта в компании). Для наибольшего успеха необходимо, помимо прочего:
1) разрешать Agile-команде меньше бюрократии (хотят, условно, телеграм и Гугл Диск вместо принятых в компании Слака и Дропбокса - да пожалуйста, документацию хотят заполнить после первых 5-6 итераций - не вопрос, лишь бы это хранилось адекватно и было понятно новым людям в команде)
2) сажать в одной комнате - так и вопросы быстрее решаются, и новости проще и быстрее распространяются
3) подбирать людей с классным общением друг с другом (в идеале с «химией»).
Это, кстати, круто вывели на новый уровень в Spotify - там целые «племена» сотрудников, собранных не только по специализации, но и по ценностям/драйву. Теперь эту модель так и называют - Spotify, и вот в университетах преподают.
Люди, разумная простота процессов и кайф от работы рождают продуктивность, часто недоступную «бюрократам».
То есть гибкость удаленной работы не влазит в Agile ? Как и подобор по скилам, а не просто "класный парень" ???
Я только передаю: и документ лекции, и наш преподаватель, доктор наук и реальный консультант бизнесов - Nathan Crews, говорили о максимальной продуктивности agile - в офисе, и более того - в комнате.
У нас тоже удаленка. Мы значительно выросли, введя ежедневные созвоны, иногда по 10 раз, но тем кому надо, более-менее оптимизировав их. Но в целом я тоже за офис.
По скиллам. У команды есть определенный sustainable rate, «стабильная выдерживаемая производительность», без тормозов и без авралов - каждый человек должен его тянуть / либо руководитель / участники должны понимать его комфортный темп и адекватно планировать нагрузку.
Никто не говорил, что agile - это просто) все наоборот - это же попытка воспроизвести дух и преимущества успешных стартапов, которые превзошли корпорации и которые не только драйвовые, но в которых нет места слабости )
Из: компетентные люди, психологическая «химия», близкое удобное общение внутри, быстрое удобное общение с клиентами, удобно адаптированная ими для себя бюрократия / процессы, качественное планирование с бешеной скоростью - в Agile нужно все и сразу) Это далеко не просто.
Хм, я был о Berkley лучшего мнения.
Офис - да, иногда бывает эффективным (а иногда - наоборот).
В Spotify как-то не видно особой сверхэффективности компании (впрочем, число их разработчиков я не знаю, как и чем они занимаются, только пользуюсь).
Ну и успех стартапа нефига не зависит от духа команды. Да и успех стартапа вообще довольно странная метрика успешности.
"В Spotify как-то не видно особой сверхэффективности компании"
Тем временем Spotify: почти 100-кратный рост выручки с 2012, до $14 млрд/год, прибыль в этом году может дойти до $1 млрд/год (в основном от подписок), #1 сервис в мире, топ-300 самый дорогих компаний (капитализация 2х Газпрома).
Кстати, это далеко за пределами ПО: только за права на подкаст Джо Рогана они выделили $250 млн (https://variety.com/2024/digital/news/joe-rogan-renews-spotify-deal-not-exclusive-1235895424/amp/)
"успех стартапа нефига не зависит от духа команды"
Тем временем Дэниель Эк, создатель и CEO Spotify: “все мое время - это работа с людьми, чтобы они понимали, куда идем и в чем предназначение их работы, чтобы она была им по душе и они кайфовали и от процесса, результата - я помогаю им эффективнее и комфортнее организовывать наши процессы, встречи, реализацию идей, стараюсь выращивать ближайших людей, чтобы они перенимали эти ценности и транслировали дальше" - только в одном интервью “people” встречается почти 40 раз.
https://www.theobservereffect.org/daniel.html
И правда, чего там изучать, и нафига мировые директора, консалтинговые агентства, университеты изучают феномены таких взлётов компаний.
Эээ, доходность компании крайне редко связана с эффективностью разработки. В случае спотифая - вообще не связана. Где тут сверхэффективность команды (и какой команды? Основа роста спотифая - в договорах с поставщиками контента и в юристах, при чем тут IT?)
90% выручки Spotify - $12 млрд /год - формируется подпиской нескольких сотен миллионов пользователей на приложение. Никаких тебе объединенных подписок и аккаунтов - качай, регистрируйся, подписывайся, плати - и всем нравится.
https://www.statista.com/statistics/245125/revenue-distribution-of-spotify-by-segment/
Несмотря на неограниченные ресурсы и возможность интегрирование свои приложение сразу в сотни миллионов устройств в мире и брать за это три копейки или ничего - Apple и Google с аналогичными приложениями - отстают все больше:
https://www.chartr.co/stories/2021-09-03-1-spotify-extends-lead-in-streaming-wars
Весь мир удивляет, как при этом Spotify управляет компанией и проектами, что там необычного, и авторы прямо говорят, что это драйвер их роста.
А оказывается, "Основа роста спотифая - в договорах с поставщиками контента и в юристах, причём тут IT”
Видимо, Apple и Google еще не придумали или не накопили на юристов🤷♂️
Ну что мы все об этом. Вы же тоже можете поделиться чем-то интересным, кроме говорить что все ерунда? Какими-то позитивными примерами из вашей работы, учебы, знаний можете поделиться, пожалуйста?
И? Где там в Spotify эффективность разработчиков? Spotify отличается именно количеством контента, который определяется просто бизнес-схемой. У Гугла подобных продуктов я вообще не помню, Эппл сильно ограничен платформой (но на своей платформе вполне себе конкурирует с Spotify).
Так что я не очень понимаю, а при чем тут такой восторг?
Можно сравнить Spotify c конкурентами (Tidal, например) и там как раз заметно, что как продукт Tidal лучше.
Да всем все просто.
Пока сами не делают.
А потом говорят, что другие виноваты или им не повезло. Или у них это лучшее, просто другое хуже - а совокупности никак не могут добиться.
Кроме тех, кто лучше организовывает людей, и побеждает.
Их опыт и изучают, а другие изучают совокупность опытов и находят, по крупицам, рабочие решения для своего успеха. И потом уже их успех изучают.
И с чего решили, что успех Spotify хоть как-то связан с тем, что рассказывают (а не просто с тем, что первые вышли на рынок стриминга или просто повезло)?
Это на конкурентных рынках многое зависит от эффективности команды. А для стартапов, создающих новые рынки - больше от случайности. Ну тот же Facebook - ничем не лучше ни в управлении, ни в команде, ни в технологиях.
Ну и agile - вообще не про "попытка воспроизвести дух и преимущества успешных стартапов, которые превзошли корпорации и которые не только драйвовые, но в которых нет места слабости", откуда это взялось?
Agile manifesto - это попытка нескольких коучей и менеджеров вывести несколько простых советов по улучшению управления. И, собственно, все, что там изучать-то?
del
Вынужден не согласиться с автором. Всегда воспринимал Scrum как чуть ли не единственную методологию, которая позволяет работать с «неизвестное неизвестное». Это когда непонятно даже какой вопрос задать. Т.е. квадрат «запутанное» в модели Кеневин. Например, выпуск нового продукта, но непонятно еще какого.
Если проект в целом понятно как делать или хотя бы понятно на какие вопросы надо найти ответ, то Канбан и другие методологии прекрасно работают.
На моей практике очень мало компаний/команд, которые действительно могли успешно и вменяемо вести скрам. Как правило это что-то "по мотивам" скрама. Не всегда это плохо, кстати.
Когда-то был сплошной махровый вотерфол. Я, ископаемое мира айти, но тьфу-тьфу не застал тех времен. Когда я начинал карьеру, на стыке тысячелетий, вокруг уже витали идеи аджайл и звучное "экстрим програминг" будоражило умы. Да, он не был таким повальным трендом, каким стал его преемник - скрам. И даже на собеседованиях частенько спрашивали "в каких случаях вы выберете аджайл, а в каких вотерфол?", не боясь выглядеть сумасшедшими. А во многих конторах вообще не парились с классификацией своих процессов. Где-то в 2010м все поменялось, скрам сходу предстал таким трендом, не следовать которому казалось автоматическим проигрышем. Расплодились коучи, которые брали от 2 тысячи евро за час пересказа скрам манифеста и игру в скрам покер. Чем лучше у собеседуемого отскакивали от зубов все определения и практики скрама, тем выше были его шансы получить офер. Однако со временем хайп улегся, скрам стали модифицировать, подстраивать под свои нужды, состав команды и прочие особенности. Иногда и от скрама-то мало что остается. А некоторые вообще позволяют себе канбан и прочий сатанизм. Остались и ортодоксы, которые соблюдают свято все ритуалы, потому что так велит священное писание, но по моим личным ощущениям таких меньшинство.
Реквием по SCRUM: всё равно уже хайп прошёл