Когда Scrum не работает. Пять основных проблем его применения

Всем привет, меня зовут Алексей Киселев, последние 10 лет я работаю в IT, половину этого срока в роли Java-разработчика, а половину — как менеджер проектов разных уровней. Сейчас управляю пятью командами в R&D-департаменте Playtika.

Эту статью я решил написать после многих собеседований с кандидатами на менеджерские позиции. Тогда я обнаружил, что многие PM’ы работают только по скраму и думают, что он спасает в любых ситуациях. Материал будет полезен начинающим менеджерам и любопытным разработчикам.

Scrum framework стал священной коровой современного IT, им пользуются все, и про него не принято говорить плохо. Любой адепт скрама скажет, что если он у вас не работает — значит вы просто не умеете его применять. На конференции разберут Agile-трансформацию очередного банка, юридической фирмы или даже завода, который успешно и под аплодисменты стал работать по Scrum.

При знакомстве скрам подкупает своей простотой. PMBOK состоит из 700+ страниц, после любой из которых хочется закрыть его навсегда. Библия скрама, Scrum Guide, уместилась всего на 13 страницах.

Но эта простота обманчива. Скрам — самый требовательный фреймворк в проектном управлении, в первую очередь к команде. О ней и поговорим.

Иллюстрация Марии Рыбак

Проблема оценки проекта

Представьте, вы скрам-мастер новой команды. Проект стартует через неделю. Заказчик прислал требования и на первом созвоне интересуется: сколько времени примерно займет разработка и сколько денег ему отложить на проект? Вы идете смотреть в Scrum Guide...

Что говорит скрам: никакой конечности разработки здесь не предусмотрено. Требования постоянно появляются в бэклоге с помощью продакт-оунера и сжигаются командой. Никаких сроков, оценок и так далее в скраме нет, зато есть предсказания.

Предсказание строится на знании производительности (velocity) команды. А знать мы будем это не раньше чем через 1,5–2 месяца работы. Поэтому извини, заказчик, мы тебе ничего не скажем. Давай лучше просто стартанем и каждые две недели будем радовать тебя новым кусочком сделанного. Но денег приготовь много. На всякий случай.

Проблема планирования

Прошло 1,5–2 месяца. Вы узнали производительность команды. В первый спринт она была 20 SP (story points), во второй — 40, а в третий — 15. Можно ли по таким данным делать выводы? Обычно нет. На старте команда притирается, да и сам «эталонный» story point часто меняется в процессе разработки.

Но как только вы собрались посчитать, сколько времени займет весь проект, лид бэкенд-разработчик сообщает, что хочет в отпуск на неделю. Еще через неделю идет в отпуск другой бэкендер, а дизайнера забирают на другой проект, потому что он выполнил свою часть работы и будет подключаться по необходимости. Вы смотрите в Scrum Guide, что делать в такой ситуации...

Что говорит скрам: если меняется хоть один человек в скрам-команде — перед нами новая команда. Старая производительность уже не годится, и нужно начинать считать заново. Заказчик, конечно, доволен, что прогресс по его проекту есть, но он совершенно не понимает, когда это все закончится.

Даже если команда стабильна и мы можем взять среднюю velocity, обычно бэклог проработан всего на пару спринтов вперед, а дальше — только очень высокоуровневые «хотелки» заказчика. Команда их не изучала, а Scrum Guide не дает инструментов для грубой оценки.

Проблема специализации

Проходят дни, пролетают года. Команда выросла до 9 человек, а новые User Stories в бэклоге становятся все более сложными. Вы замечаете, что при мощности команды в 60 SP не можете взять задачу даже на 30 SP, не заглянув внутрь бэклога: а вдруг там много бэкенда и почти нет фронтенда? Тогда фронтендщики останутся без работы. Или наоборот. В итоге команда негласно разбивается по специализации на несколько подкоманд, которые следят за своим бэклогом и не сильно интересуются соседями. При этом все тяжелее закрывать задачи целиком: в любую User Story входит работа многих людей, и, например, заливка на продакшн может уже не поместиться в спринт. То есть команда сама начинает нарушать definition of done своих задач во имя хоть какого-то инкремента.

Что говорит скрам: команда — кроссфункциональна. Это значит, что в ней есть все необходимые компетенции для выполнения работы. При этом единственная роль для разработчиков в скрам-команде — разработчик. Других нет. Скрам не признает разные виды разработчиков и проблему их синхронизации. Выравнивание загрузки каждый спринт лежит на продакт-оунере, который становится таким god object — он должен хорошо понимать не только каждую задачу с продуктовой стороны, но то, сколько внутри работы Back-end, Front-end, DevOps, QA. Иначе приоритизировать бэклог не получится. Перекос в любую сторону — и спринт гарантированно провален.

При этом скрам требует, чтобы в команде только один человек отвечал за бэклог, независимо от его сложности. Это усложняет жизнь и ведет к появлению прослоек — прокси продакт-оунеров, бизнес-аналитиков и так далее.

Проблема ответственности, или Колхоз им. Д. Сазерленда

Со временем вы начинаете замечать, что мидл бекенд-разработчик Миша каждый раз быстро закрывает свои задачи, а его лид Гриша в основном коментит чужой код и статьи на ДОУ. Гриша всегда берет одну-две самых больших задачи и делает их весь спринт. Но успевает же! Значит, никаких проблем?

Что говорит скрам: команда несет коллективную ответственность за все, что она делает. Никаких персональных метрик. По сути, убивается личная ответственность разработчиков за результат своего труда — хвалят или ругают всех одинаково, даже если кто-то впахивал весь спринт, а кто-то — Гриша.

Проблема раздувания оценок

Вы решаете присмотреться к Грише. Как у него получается закрывать больше всех стори-поинтов и при этом, мягко скажем, не потеть?

Дело в том, что стори-поинты в скраме оценивают сложность задачи, а не срок ее выполнения. Эксперты рекомендуют использовать planning poker для оценки задач перед началом спринта — церемонию, когда все члены команды одновременно выбрасывают карточку с цифрой, во сколько оценивают работу, и обсуждают отклонения. На «покере» зачастую возникает такой диалог:

Скрам-мастер: Во сколько оценим эту задачу?

Миша: 5.

Гриша: 13.

Скрам-мастер: Гриша, почему 13?

Гриша: Ой, ну там, кроме разработки, нужно еще учесть пару корнер-кейсов, поправить тесты, выделить общую функциональность в отдельные классы...

Миша: Согласен, ставим 13.

Примерно так из-за желания перестраховаться, быть хорошим для начальства или просто из-за лени и происходит инфляция стори-поинтов. В компаниях, где velocity команды — единственная метрика ее успешности, такое видим постоянно. Цифры в отчетах растут, значит команда огонь! Вот только заказчик никак не может дождаться новой версии продукта.

Что говорит скрам: команда должна быть самоуправляемой, это значит, что она сама лучше знает, кто, сколько и чего должен делать. Скрам-мастер почти не имеет инструментов, чтобы вмешиваться в ее работу, разве что задавать наводящие вопросы.

И хорошо, если внутри команды хватит зрелости разобраться с этой проблемой, но происходит такое довольно редко.

Вместо вывода

На самом деле, я люблю скрам — это классный фреймворк для командного решения сложных технических проблем. Меня смущают способы его применения. В украинском IT все описанные проблемы подпирают костылями. «У нас есть скрам-мастер, но в паре с ним поставили деливери-менеджера для работы с рисками, сроками, ну и чтобы разработчиков подгонял», «мы оцениваем в стори-поинтах, но на самом деле это все те же человеко-часы, чтобы потом заказчику сроки выполнения давать», «нам не нужен менеджер, мы сами управляемся. Если тимлид сказал овертаймить, мы овертаймим» и другие.

Такие рассказы я часто слышу на собеседованиях от разработчиков\менеджеров из разных компаний.

Если все же желание «подкрутить» скрам непреодолимо, прочтите заключение Scrum Guide: «Описанный здесь фреймворк Scrum не подлежит изменению. Хотя использование отдельных элементов Scrum допустимо, полученный результат не будет Scrum. Scrum существует только в качестве цельного фреймворка».

Ответ на вопрос «А что тогда делать?» заслуживает отдельной статьи. Как минимум не идеализировать скрам — это инструмент со своими ограничениями и подойдет он далеко не каждой компании. Кроме того, пробелы методологии можно закрывать добавлением инженерных практик из ХР или «классическим» управлением проектами. Например, считать путь до MVP продукта проектом, а значит инициировать его по правилам PMBOK, расписать иерархическую структуру работ, дать заказчику сроки и вперед.

Напоследок приведу цитату одного из авторов Scrum Джеффа Сазерленда. Мне кажется, она хорошо отражает изначальную суть этого подхода.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

А как поживает ваш скрам?

👍НравитсяПонравилось20
В избранноеВ избранном7
Подписаться на тему «Scrum»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


66 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В Consulting/Outsourcing модели бизеса Scrum не работает по определению. Только если работаешь напрямую внутри бизнеса (т.е. in-house dev team), он ложится на процесс. Такова правда жизни. Много копий сломано, а результат все тот же.

На самом деле, работает (есть реальные примеры в Сигме), но только если заказчик сам готов работать по этой модели и доверяет команде со стороны подрядчика.

Да, но такое бывает исключительно редко. Типичная ситуация — fix price, fixed deadline. В этих реалиях простора для Scrum особо нет.

Даже

fix price, fixed deadline

— не проблема, если scope проекта является переменной величиной. Вот где Agile действительно не работает — это когда «гвоздями прибиты» все вершины проектного треугольника. Но, в 2021 году, хвала богам, такие проекты встречаются не так и часто.

Прекрасная и лаконичная статья о священной корове, проблемы которой у нас традиционно не принято обсуждать.
А за привязку стори-поинтов к часам, я думаю, существует отдельный котёл))
Автору спасибо!

Можу сказати зі свого досвіду, що чомусь вважається, що всі айтішники з пелюшок знають що таке Agile/Scrum і як їх застосовувати.
Я не пам’ятаю, щоб в компаніях, де я працював, проводили семінари/воркшопи/тренінги по скрам або просто пояснювали співробітникам на мітингах як ази, так і просунуті речі.

Насправді назва статті відповідає вмісту. Я не згоден з критиками, все нормально.
Хотілося б тепер прочитати статтю в стилі «Скрам — синонім успіху» або «Як скрам зробив мене мільйонером»

«Фантастика у нас на другому поверсі» © Старий анекдот

Use the right tool for the right job in the right way ©

Дякую, Сергій. Написати можу тільки «Як, на мою думку, краще всього застосовувати скрам в проектах». Щодо «Як скрам зробив мільонером» — то треба аджайл-трансформаторов спитать :)

Дякую, буду чекати новин

Я всего один раз видел, когда скрам действительно использовали правильно и эффективность разработки выросла в разы. А так в основном люди называют какой-то период времени спринтом (иногда это просто период до следующего релиза, от двух недель и до нескольких месяцев) и считают это скрамом. А иногда на столько ударяются в скрам церемонии, что тимлид кодить не будет (в команде из 3 человек), а будет только по митингам ходить.

Чаще всего наблюдаю картину, что одни говорят: «Вы тулите скрам везде, это неправильно! Есть кучу других подходов». Другие же говорят: «О боже, скрам все решит, давайте скрам! Больше скрама!»

При этом мне кажется, что ни первые, ни вторые не понимают его сути.

Давайте обратимся к PMBoK. Что это такое?
Цитата:
«PMBoK — a guide of all the things about Project Management»

Когда тот же Scrum:
«Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.»

Так вот причем тут одно к другому? Каждый из подходов решает определенно свою задачу.
В частности, весь блейминг на скрам приходит из сферы аутсорса, где отношения команды с конечным пользователем лежат через заказчика, которого интересуют такие вопросы как цена контракта, сроки выполнения, в первую очередь. А вот саму команду интересует качество отработки объёма данного контракта. Что по сути скорее заставляет забить на велью, а наоборот подраздувать таймлайны, для пущего комфорта команды.

Когда же в продуктовых компаниях команда и ее финансовые показатели на прямую зависят от конечного пользователя и предоставленного велью.

Так почему ПМБоК мешает Скраму или наоборот?

Хотите решить проблему естимирования? Ок, круто! Да, скрам вам тут мало чем поможет.

Хотите решить проблему трека велью и работы команды над развитием продукта и самой себя? Скрам круто подойдет.

А почему бы и не совмещать эти прекрасные подходы?? Ведь в том же скрам гайде сказано: Да будет скрам ОБЛЕГЧЕННЫМ фреймворком. Что в моем понимании означает только одно — Вы поменяли подход и вышли за пределы скрам гайда? Ок! Это работает? — Вы молодец!

Скрам в аутсорсе вообще редко взлетает, как минимум по причине отсутствия реального Владельца Продукта, который в Скраме предполагается таким себе mini-CEO, который отвечает за финансовые показатели продукта, определяет видение и стратегию его развития и, в случае конфликта стейкхолдеров, имеет решающий голос.

В 99% аутсорсных историй такой человек если и есть вообще (спойлер: в энтерпрайзе с коллективной безответственностью для его появления нужна сначала организационная трансформация), то для какой-то там оффшорной команды доступен, в лучшем случае, раз в квартал на таунхолле на 500 человек.

А почему бы и не совмещать эти прекрасные подходы??

Disciplined agile delivery именно такой путь и проповедует )

И, даже если не говорить конкретно о DAD, то важно понимать, что сам по себе итеративно-инкрементальный подход можно (и, в большинстве случаев, нужно) применять и там, где требуется более строгий project governance, чем предлагаемый скрамом.

Но тут уже нужно чинить «разруху в головах» у многих PMов с чёрно-белым видением в духе «или SCRUM, или кондовый waterfall»

Не уверен, что таких людей можно считать ПМами не по должности, а по квалификации. Нужен специальный термин для людей, которые в лучшем случае изучили Скрам и при этом считают, что поняли, как управлять проектами.

Скрам не інструмент для оцінки дедлайнів цілих проектів наперед та проектного планування, це просто методологія розробки, інструмент в руках серед інших багатьох інструментів.

Для оцінки вартості й часу проектів і проектного менеджменту взагалі використовуються інші інструменти

Взагалі ідея SP для того й видумана, щоб не було бажання перетворювати жопогодини в обіцянки клієнтам, бо часто так і виходить з жопогодинами.

Кейс Гриші — ну а якщо Гриша своїм роздутими корнер кейсами на 13 збереже дві доби даунтаса в продакшені, це все ще буде роздута оцінка?

Ну стаття типу читається як: чому скрам не працює тоді, коли це єдиний інструмент в моїх руках, і коли я з нього очікую те, для чого він не створений, і він чомусь не дає відповідь на такі питання, для яких він в принципі не підходить. Може в тому й задум статті, але виглядає наче критика скрама ні за що :)

Таке шось, за деревами лісу не видно. Як мінімум якщо на інтерв’ю ПМ щебече тільки про скрам — це не ПМ в принципі навіть.

да, именно это и побудило написать статью, обилие ПМ на рынке с одним этим инструментом )

Так и хочется написать, и чО?
Да, про скрам без инженерных практик (ХР) писал дедушка Фаулер еще в 2009ом году! martinfowler.com/bliki/FlaccidScrum.html
побуду капитаном очевидность и напомню почему все так любят скрам. Это самый простой фреимворк для построения итеративной разработки продукта, маленькие итерации скоуп который нельзя менять дают уверенность команды. Планирование и приоритизация дает ПО возможность управлять приоритетом выполнения задач, ретроспектива дает возможность улучшать процессы и самое главное — все в индустрии понимают как он работает, ты берешь человека с улицы и он сразу же вливается в процесс.
Есть ли смысл работы по скраму когда весь беклог проекта заэстимирован и скоуп и дедлаин зафиксированы? Есть. как сказано в статье это будет не скрам, но я готов поспорить что это может дать определенные преимущества связанные с итеративной работой и фидбеком, связанным с скрам церемониями

не совсем согласен. в моем опыте, когда есть проект — методы проектного управления и без скрама дают хорошие результаты. Проводить синки каждый день и двигаться итеративно — это ведь и до скрама все было, он тут ничего нового не сказал

есть скрам, который знает и понимает каждый джун, а есть какие-то методы проектного управления понятные только лишь опытному ПМу. Со скрамом как и с паттернами, ценность в общем словаре

Думает, что

знает и понимает
Дело в том, что стори-поинты в скраме оценивают сложность задачи, а не срок ее выполнения

Пропущено очень важное слово: относительную сложность, т.е., говорить про 13 или 5 поинтов можно только тогда, когда у команды есть какое-то количество элементов бэклога, оцененных в 1-2-5-8-13-... стори поинтов, и все понимают, чем задача на 13 была сложнее той, что на 8, а та, что на 5 — той, что на 3. Тогда вешать лапшу становится тяжелее :)

Задача со звездочкой: читателю предлагается самостоятельно найти в Scrum Guide словосочетание story point.

Задача с двумя звездочками: почитать статью, лежащую в основе Скрама и подумать, из каких людей должна состоять Скрам-команда и почему 99% команд, которые так называются, примерно так же далеки от Скрама, как «ланос» с антикрылом — от Porsche 911 GT3 и Nissan GTR. Материал для самостоятельного изучения: The New New Product Development Game

все так. И тем не менее, все «имплементаторы» скрама в компании (простые СМы, аджайл коучи, всякие там трансформаторы и тд) рекомендуют оценивать только в стори-поинтах, а про команды — ну о том и речь что он про идеальную команду в вакууме, а в жизни такого зачастую нет под рукой :)

Ну так может стоит писать статью на тему: почему "то что всякие имплиментаторы называют Скрамом им не является, не работает как я хочу и мне не нравится"?😂

ну вот на этапе замысла где-то так оно и называлось, да 😁

Кен Швабер в эфире, посвященном очередной версии Скрам Гайда (2017, ЕМНИП) сказал сакраментальную фразу: «Scrum is not for people who cannot think».

Основная проблема в том, что тем people, которые can think, Скрам не нужен, потому как он не рассказывает им ничего такого, чего бы они не знали раньше.

не рассказывает им ничего такого, чего бы они не знали раньше.

Ну-у, тут несколько спорно, так как стоит учитывать и исторический контекст. А он такой: на момент появления SCRUM «балом правили» тяжеловесные формализованные методологии, и революционная легковесность сабжа, в общем-то, произвела полезный эффект сдвига сознания в сторону «а что, так можно было?!»

Я не уверен, что успех легковесных методологий можно так сильно привязывать к Скраму. До украинских реалий XP, например, добрался намного раньше. Если есть какие-то данные, что именно Скрам произвёл массовый сдвиг в сознании, будет интересно почитать.

Возможно, вы и правы. По крайней мере, у меня нет железобетонных объективных аргументов в доказательство моей позиции — это, скорее, больше по ощущениям и воспоминаниям из собственного опыта.

В частности,

До украинских реалий XP, например, добрался намного раньше.

— это совершенно точно так. Я и сам читал книги и по XP, и вообще про Agile разработку Алистера Кобёрна сильно раньше, чем пошла волна популяризации скрама.

Вместе с тем, то же XP среди меня и моих коллег породило интерес, скорее, к инженерным практикам (юнит тесты, CI, рефакторинг). А вот как на инструмент именно управления проектом на него смотрели, как на экзотику, так как прекрасно понимали, что предлагаемая XP модель ну никак не натягивается на реалии аутсорса начала 2000х.

Давайте уже честно признаемся, что говорим заказчику «работаем по SCRUM», чтобы ему было спокойнее, а сами работаем по системе гибридный ЛеЩуР, где ЛеЩуР — лебедь, щука и рак.
Мне кажется, что все люди с опытом давно понимают, что теория из книжки — это теория из книжки. Плохо, когда её не знаешь. Ещё хуже, когда считаешь, что её можно применить онтосительно реальной жизни без напильника.
Все мои проекты, где хотелось максимально приблизиться к академическим паттернам (для того чтобы потом перед друзьями похвстаться) в итоге либо утонули, либо отрастили жабры и щупальца и задорно посеменили куда-то вбок от изначального направления.
Был молод и наивен. Каюсь.
Автор молодец, высветил проблематику. С другой стороны замечания тратящих рабочее время на комментирование статей на ДОУ тимлидов верны. Где предложения? Как с этим бороться?
Ждём продолжение статьи.

та я не то что трачу)) просто накипело уже, вот и отписал. зашел на доу раз в месяц )

Я тоже стараюсь слишком часто не заходить. Нервы надо беречь 😂

спасибо за отзыв, продолжение будет)

Где предложения? Как с этим бороться?

Вы не могли бы уточнить, пожалуйста, на какую тему хочется предложений и с чем именно хочется бороться. Спасибо.

Думаю, если свести всё к одному пожеланию, то это была бы тематика «Адаптация методов разработки к современным украинским реалиям»

Проблема оценки проекта

А зачем вы применяете Скрам в проектной деятельности? В Scrum Guide слово проект упоминается единственный раз: «Each Sprint may be considered a short project», с планированием бэклога спринта у опытной команды обычно проблем нет.

Проблема со Скрамом обычно ровно одна — сначала аккаунт договаривается с клиентом про fixed price/fixed scope, а потом зачем-то соглашается делать его по Скраму (потому что клиент слышал, что тогда можно делать проект без детальных требований).

как раз сейчас я работаю в продуктовой компании и этой проблемы не стоит. Но при попытке нанять нового ПМ/СМ сталкиваюсь с очень большим количеством кейсов натягивания скрама на что угодно. статья как раз об этом.
Плюс, скрам уже и не говорит что он исключительно «продуктовый». Он скромно говорит — «мы решаем комплексные проблемы, не обязательно даже в разработке ПО».

В продуктовой компании точно так же могут быть проекты, более того, я считаю, что непродуктовых компаний не бывает, просто продукты у всех разные (но это тема отдельной дискуссии). А вот проблема натягивания Скрама на все подряд действительно есть, в основном, у людей, которые кроме Скрама ничего не видели и не понимают, для чего он нужен. Его же придумали и популяризировали люди, которые до этого по двадцать лет пахали над водопадными проектами, и которые отлично понимали, где проектный подход работает, а где нет. А у нас, в 90% случаев (исключительно собственные наблюдения с собеседования кандидатов в Скрам Мастеры) люди работали по принципу «х*як, х*як — и в продакшен», а потом им кто-то рассказал, что можно задачи вешать на доску, и синкать команду на дейли, и они других способов хоть как-то организовать бардак в принципе не знают и не видели.

Плюс кажущаяся простота работы Скрам Мастера, я как-то собеседовал девочку с дипломом пединститута и четырьмя годами опыта, из них два — личным ассистентом, год — эйчаром (тоже ха-ха отдельное) и еще год — координатором проектов в веб-студии какой-то (которая, понятно, к энтерпрайз-разработке имеет отношение примерно такое же, как детский самокат — к карьерному самосвалу). Понятно, не взял, но через полгода кто-то другой — взял, успешно «вошла в айти», теперь «статечна людина, член суспільства, депутат палати лордів».

Так что это все не про подходы, а про людей, как обычно. С 1987 ничего особо не изменилось: «...The implication is that they are part of the high-tech world. Just between us, they usually aren’t. The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are appliers of their work. We use computers and other new technology components to develop our products or to organize our affairs. Because we go about this work in teams and projects and other tightly knit working groups, we are mostly in the human communication business. Our successes stem from good human interactions by all participants in the effort, and our failures stem from poor human interactions».

Да с Time and Material тоже самое — скрам тут вообще не причем. Проработка детальных требований (формализация) по сути своей и есть одна из
важнейших частей проекта. А кодировать можно и обезьяну научить. ИМХО проблема разных срамов — это когда абсолютно другие, причем ещё и кривые процессы называют скрамом, т.е. по сути спираль. Когда возникает — мной подмечено что это связанно с не ИТ менеджерами в ИТ. Настаивает клиент на своем менеджере, а менеджер до того управляла продавцами и мерчами в офлайн магазине, прошла курсы скрама. В итоге чертишо — а не процесс, но даже не в этом дело не понимает менеджер как делать софтверные проекты что для этого нужно и т.д.

Это если детальные требования имеет смысл прорабатывать. А если мы разрабатываем инновационный продукт, который основан на наших гипотезах о поведении клиентов, то единственный надежный способ эти гипотезы проверять — это быстро и максимально дешево (идеально — без инженеров вообще) делать MVP и дальше развивать те фичи, гипотезы которых подтвердились. Другой кейс — когда количество взаимозависимостей такое, что согласование хотелок всех стейкхолдеров тупо стоит дороже, чем уже начать делать и в процессе допиливать (да, это очень неприятно для перфекционизма инженеров, но продукт же не для инженеров делается).

Ну а про менеджеров я выше написал практически слово в слово то же самое :) Справедливости ради — технических специалистов, у которых в анамнезе только КА «Шаг», пачка онлайн-сертификатов и аппетит к сырам по 1000 грн (думаю, 500 уже давно неактуально) — не меньше.

аккаунт договаривается с клиентом про fixed price/fixed scope

Причём, гвоздём в крышку гроба скрама здесь будет именно fixed scope. С fixed price, как таковым, у скрама проблем нет — он под это вполне заточен.

С другой стороны, как можно договариваться на fixed scope при отсутствии детализированных требований — вот это уже уму непостижимо.

Как-как, деньги нужны ну или показать начальству что взяла/взял проект (что в общем тоже самое но косвенно). Поэтому подписать даже кабальный контракт частенько считают удачей, все лучше чем совсем никакого. Так или иначе конкуренция в нашей отрасли одна из самых больших в мире, сравнима с биржевыми маклерами.

Спасибо за статью, но о чем она?
Что вы хотели донести? Или это статья ради статьи?
Да, на Украинском рынке, так же как и на других рынках не все как в книгах. Но для этого и существуют профи, чтобы адаптировать, выжимать по максимуму из всего что есть вокруг!

Проектный менеджмент != scrum. Это фрейм ворк, в котором есть разные инструменты в виде артефактов, процессов для решения определенных задач.

Вы пишите:

Предсказание строится на знании производительности (velocity) команды. А знать мы будем это не раньше чем через 1,5–2 месяца работы. Поэтому извини, заказчик, мы тебе ничего не скажем. Давай лучше просто стартанем и каждые две недели будем радовать тебя новым кусочком сделанного. Но денег приготовь много. На всякий случай.

А что тут плохого? Если ребята могут делать так бизнес, то они молодцы и в одно место можно засунуть статьи про скрам и тд. пусть делают и зарабатывают деньги, пока супер умные люди пишут о скрамах и бабоках...

ИМХО
Хотелось бы видеть больше контента на тему «Как», а не «все пропало, все идиоты». Жду вторую часть в который вы расскажите как нужно, чтобы другие компании могли адаптировать свои решения к идеальным с вашей помощью.

Жалко, что не удалось донести свой посыл в статье. Она о накипевшем — ОЧЕНЬ многие ПМы на собеседованиях не видели ничего кроме скрама и считают его волшебной таблеткой. Не надо так)

А почему вы считаете, что вы видели что-то большее чем только скрам ?
Я так понимаю, ваш помёт в том что люди однобоки и словом скрам хотят решить все вопросы.
Но тогда я вам задам вопрос, а что же насчёт вас? Вы не такой? Вы делали проекты по разным методологиями разными типами контрактов? С разным кол-вом людей?

Почему же вы не говорите, что повсеместно говорят о SAFe и ничего кроме него не знаю...

Это я к чему, я не очень воспринимаю информацию от людей которые сами ничего не могут.
Было бы неплохо сделать так, представишься, рассказать почему именно вас нужно слушать и воспринимать, а потом уже говорить о проблеме и о том как ее нужно решать с вашей точки зрения.

Пока что это наброс на вентилятор человека который работает в ИТ. Все

А ты сам кто такой? Чего ты добился? © ;)

Та я так. Просто ))))
Ничего особенного

1. В скраме нет «Проблемы оценки проекта»
Скрам для разработки продуктов в комплексном домене. Может пока оставить вопрос «комплексности», а сосредоточиться на продукте.
У продуктовых и проектных подходов очень большая разница.
И если в проекте у вас есть спецификации, wbs , опыт в разработке подобных или похожих вещей, то помним о конусе неопределённости и планируем проект.
В продукте же есть идея ( или вижн), есть мысли как это может выглядеть и как работать. И все.
Начинаем процесс Discovery: собираем и валидируем наши продуктовые идеи. Хорошо бы уже сейчас на этом моменте подключить команду.
В любом случае, за процессом Discovery или параллельно с ним начинается процесс Delivery.
Как уже сказано выше, ‪Скрам используется в комплексных средах, в области Wicked или «злых» проблем, когда мы не знаем будет ли успешен продукт ( viability), можно ли его технически реализовать ( feasibility) и понравится ди он пользователям (desirability). Таким образом, каждый инкремент продукта в Спринте закрывает эти три риска, а Бэклог Продукта адаптируется в конце каждого Спринта.‬
И да, мы не можем сказать сроки заказчику продукта, потому что у продукта, в отличие от проекта, как правило нет дедлайна. Продукт развивается все время пока есть на рынке: собираются новые данные, новые хотелки пользователей, новые продуктовые идеи...
Но каждый инкремент, наш Заказяик будет получать самый ценный функционал, который позволит ему получить уже профит, как и обратную связь от рынка. И в любой момент, Заказчик может остановить разработку, посчитав, что своих целей он (Заказчик) достиг.
На подумать: сколько займёт разработка Facebook? Who knows, как говорится...
Концепция Velocity, часто ошибочно примеряющаяся как метрика производительности команды, говорит только лишь о способности команды трансформировать элементы беклога продукта в готовый инкремент. И может служить только как вводные данные на этапе планирования спринта ( при velocity driven способе планирования) или как вводные доя ретроспективы команды ( если наша велосити достаточно сильно нестабильна за последние спринты).
Велосити хорошо срабатывает если у нас стабильная команды, стабильный процесс разработки. А если же нет — в помощь другие способы.
Наличие же правильной велосити помогает строить прогнозы и например, планировать выпуск больших фич.
Очень бегло и вкратце о планировании в Скраме.

Абсолютно согласен. Я на той же стороне — скрам хорош исключительно в непредсказуемой продуктовой разработке. Но ведь вокруг его пихают вообще везде. У нас юрфирмы некоторые по скраму пытаются научить работать. Хотя он им во-о-бще никак не ложится по их процессам.

Всю статью можно было бы свести к этим пяти предложениям без потери смысла ;) А можно еще короче — «остерегайтесь дилетантов», всё, case closed.

да есть такое ru.wikipedia.org/wiki/Agile_Manifesto

Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

сначала не выполняем «входящие», а потом «ваша программа не работает»...

Нас уже 431 710

Да, интересно, сколько из этих «нас» можно назвать «мотивированными профессионалами».

Техническую литературу читать в переводе (тем более, русском) — не самая лучшая идея. А по делу — из двух дедушек я бы советовал слушать Швабера, потому что Сазерленд — отличный продажник, рассказы про миллионы миллиардов практиков Скрама в мире — его рук дело, а Швабер как раз объясняет, почему имплементация простых идей на практике требует массы усилий опытных людей.

www.mann-ivanov-ferber.ru/books/scrum-na-praktike

эта книжка не очень попадает в категорию «техническая»...

Это другой Сазерленд. Это Сазерленд-сын.

А, ну да. Ну, подозреваю, что там яблоко от яблони.

вы перепутали с вот этой наверное www.mann-ivanov-ferber.ru/books/scrum

Да, каюсь, Джей Джея не читал. А стоит?

ну там ответ на

У нас юрфирмы некоторые по скраму пытаются научить работать. Хотя он им во-о-бще никак не ложится по их процессам.
скрам хорош исключительно в непредсказуемой продуктовой разработке. Но ведь вокруг его пихают вообще везде.

Потому что у других итеративно-инкрементальных методологий были плохие пиарщики. Что вполне закономерно, так как на этих методологиях (кроме, разве что, Crystal в своё время) не пытались активно делать бизнес в виде коммерческих тренингов и сертификаций. В отличие от.

Полностью согласен. Скрам — это про пиар и про бизнес. Ну и да, иногда он и правда помогает, ряд примеров привели в комментариях.

Смысл статьи верен, хотя и ряд толкований скрама несколько не точен. Скрам — не является серебряной пулей, хорошо работает в продуктовой (а не проектной) разработке, в комплексном домене, ‪в области Wicked или «злых» проблем, когда мы не знаем будет ли успешен продукт ( viability), можно ли его технически реализовать ( feasibility) и понравится ди он пользователям (desirability). Таким образом, каждый инкремент продукта в Спринте закрывает эти три риска, а Бэклог Продукта адаптируется в конце каждого Спринта. ‬

Подписаться на комментарии