Воронин Максим @mgvoronin
User
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Agile-коуч, Scrum Master
Lead
Agile
Scrum
Kanban
Project planning
Optimization of business processes
Building a team
Project management
Development management
Business process management
Product management
Прекрасное замечание, но...
1) Для большинства не-it-шнтков слово "фреймворк" несёт в себе примерно столько же информации, как для англоговорящего человека karkas - набор звуков да и только.
2) термин framework используется ещё и потому, что в английском нету отдельных слов для Методики и Методологии - там все methodology. Причем, ладно, если бы использовался перевод "каркас" - это было бы хотя бы понятно, а так какой смысл?
Непосредственно про Скрам уже вроде аргументы написаны, и повторяться не буду. Но даже если отвлечься от Скрам, то использование Owner/Владелец в роли не соответсвует и общей менеджерской практике. Так, например, существуют еще такие понятия как Project Owner и Process Owner – и в том и в другом случае речь идет о людях, которые Заинтересованы в Результе Вцелом, а не каких-то точечных показателях. В вашей же интерпритации Product Owner (ввиду отсутствия ответственности за сроки и бюджеты) больше похож на тех продажников, которые обещают заказчику какую-то дичь да еще и в неизвестно откуда взятые сроки – главное продать, а потом хоть потоп, – а инженеры должны все это разгребать. В Скраме же Владелец Продукта – это именно Владелец классическом (устоявшемся) понимании. В итоге, когда человек, который ничего не знает про Скрам и Agile, но знаком с теорией процессов или проектов, впервые услышит термин Product Owner, у него скорее всего возникнут ассоциации куда ближе к Скрамовсому определению, чем к вашему. Это, в свою очередь, помогает людям быстрее находить общий язык, что и является целю профессиональной терминологии. Когда же понятия используются произвольно, в угоду моде, это затрудняет общение, потому что приходится переспрашивать: “а что конкретно вы имеете в виду?”, ну или пытаться угадать из контекста… Так и что в этом хорошего?
Хотя я конечно должен признать, что хайп как правило все-таки побеждает прозрачность понятий (((
Вот тут совсем не согласен. Внимание к качеству продукта регулируется Определением Готовности (Definition of Done, DoD), которому должен соответствовать инкремент. Если команда считает, что скорость поставки важнее качества и не включает тестирование в DoD, то Scrum тут не причем – необходимы инструмент он предоставляет. Причем достаточно гибкий: хочешь – можешь ограничиться “одобрямс” от Владелца Продуктом, хочешь – требования ISO включай.
С вашего позволения подключусь к вашему душному разговору )))
Роль РО была описана в Scrum (ну или по крайней мере вошла в широкое употребление, потому что является частью Скрама), и имеет истойчивую ассоциацию с ним. Возникает вопрос: зачем называть роль Скрамовским термином, если вы не используете Скрам? Ув. @neonox логично заметил, что есть общее понятие Product Manager – почему не использовать его? Зачем размывать устойчивый термин?
Поясню. Описывая конфликт приоритетов, вы пишите: “PO сосредотачивается на максимизации ценности продукта для пользователей и заказчиков, тогда как PM ставит акцент на соблюдение сроков и бюджета. Это может привести к конфликту между тем, что должно быть реализовано в первую очередь, и тем, что можно уложить в заданные рамки”. То есть выходит, что в вашем определении РО максимизация ценности входит в его обязанности, а сроки и бюджет – нет. Но в Скраме это не так: РО отвечает за все эти пункты! Например, цитата из курсов Скрам-мастера Джеффа Сазерленда (один из авторов Скрама, если что): “Product Owner Deliverables: 1) Increasing Value/Point, 2) Profitability of the Product”. Очевидно, что вы не можете говорить о прибыльности продукта, забывая про сроки и бюджет. Ну или можно обратиться к публичному Руководству по Scrum: “Product Owner… разрабатывает и точно коммуницирует Product Goal”. Опять же, логично ожидать, что если есть какие-то сроки и бюджеты, то они просто обязаны попасть в Product Goal, достижение которой – главная задача Product Owner`а. Поэтому получается, что ваше определение РО не соответствует общепринятому.
Почему это плохо? Потому что есть существенный риск того, что неопытный человек, прочитав вашу статью, сделает вывод, что сроки и бюджеты – это не есть забота РО. Причем из-за уже упомянутой тесной ассоциации роли РО со Скрамом, он, вероятно, решит, что и в Скраме это норма! А потом вдруг появляются люди, которые говорят, что “Скрам не работает”...
При этом, я отнюдь не хочу сказать, что ваша концепция двух таких ролей не имеет право на существование! Я лишь против использования устоявшихся терминов не по прямому назначению.
Как показывает изначальная статья, это не так. При этом она (статья) ведь не старая: оригинал - конца 22 года. Так что до сих пор люди пользуются Agile и Scrum, но толком не понимают, что такое Story Points - в голове каша. Соответственно, моя статья – это попытка объяснить Суть, используя знакомые для многих образы. Поэтому и уровень сложности указан «Простой».
Я не знаю, у кого какие цели были, но с точки зрения теории
Оценка должна быть не абсолютная (в часах), а относительная (в попугаепоинтах), и время при этом определяется по статистике выполнения обязательств (с необходимым качеством!)
Спрашивать нужно не у разработчика, а у команды (3-9 человек)
Спрашивать нужно не у абы какой команды, а у той, которая будет выполнять задачу.
В принципе, вы описали вполне разумные процессы, но вот в этом суждении:
вы, на мой взгляд, не попали практически нигде ?
большой акцент делается на каких-то ритуалах – Да, ритуалы в Скраме есть, но суть-то все-таки не в них. Как говорится в гайде: “Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum”.
менеджер, который понятия не имеет на сколько сложно сделать ту или иную задачу – В терминах Скрам – это скорее про Владельца продукта, но даже если он не особо технически прошаренный человек, то при использовании именно “попугаев”, а не часов, он вполне себе будет способен оценить масштаб задачи. У меня есть даже положительный опыт, когда Владелец продукта участвовал в голосовании по оценке вместе с командой. И хотя это не канонично, но это позволило ему синхронизироваться с командой. Через некоторое время мы отказались от этой практики, но на начальном этапе это было полезно, на мой взгляд.
разработчики, которые ничего не умеют кроме кода – Тут вообще все ровным счетом наоборот! Есть даже такой принцип T-shaped people – т.е. люди, у которых есть основная специализация, но подхватить могут много где. И чем фулстековее у вас члены команды, тем большего вы сможете добиться.
у каждого из них ещё десять параллельных проектов – опять же все наоборот: крайне не рекомендуется работать более, чем над одним проектом. Сазерленд, по крайней мере, на своих курсах ссылался на исследования, о том, что переключение контекстов для Каждого дополнительного (параллельного) проекта снижает продуктивность команды на 20%.
меняются каждый месяц и вообще все эти люди только неделя как познакомились – и снова нет :) Стабильная команда – это важный принцип.
Я имел в виду, конечно, Ретроспективу, а не спринт-ревью
Тут хочется вспомнить фразу Сазерленда, которую он на своих курсах повторял наверное каждые полчаса: “Teams that Finish Early Accelerate Faster”. Имеется в виду, что команда должна выполнять свои обязательства до конца спринта (всегда, а не “более-менее”). Если не получилось, то в следующий раз следует брать меньше. И только поняв, сколько реально вы можете выполнять работы с нужным качеством, вы сможете расти быстрее, используя спринт-ревью и постоянное улучшение.
Но опять же, я не знаю, как у вас все устроено. Вам на месте, конечно, виднее.
Конечно комфортнее, когда сравниваемые задачи различаются в разы, а не в десятки и сотни раз. И на практике так обычно и происходит: вы выбираете поинт, потом оцениваете 2-3, 10, 15 и потом уже 25. Но даже если разброс очень большой, то ряд Фибоначчи вам поможет. В этом случае, вам надо выбрать между 13, 21, 34, 55 и 89. Это существенный разброс, так что выбор не такой уж и сложный, даже если у вы ещё не оценивали промежуточные размеры. А далее работает "покер": каждый член команды дает свою оценку, и если разброс небольшой (не более двух ступеней), то берется среднее, в противном случае – те, кто поставил крайние оценки, обосновывают свою точку зрения – без дискуссии! – и переголосовываете. Если разброс все ещё большой, то повторяете (один раз, т.е. максимум три голосования) и берете среднюю оценку.
Это не занимает много времени, а работает обычно лучше, чем экспертная оценка в часах. Мне сложно сказать, что пошло не так именно у вас, но для этого и существует Спринт-ревью: вы обсуждаете, что не получилось, и исправляете. Если ошиблись в оценке, то это повод чему-то научиться…
Ну, кстати, да. Вариант. Вот только часы убрать, а вместо них в первом спринте выбрать тот самый "изъян" или "изи", и все остальное мерять относительно них.
Ну и второе (это уже вкусовщина, но все же), если следовать рекомендациям того же Сазерленда (хотя есть и другие), то числа следует взять из ряда Фибоначчи. Так проще выбирать, потому что между 8 и 12 разница ещё заметная, а вот между 20 и 24 – уже не столь очевидная. А так у вас будет 8, 13, 21, 34. В командном "покере" выбор будет проще, дискуссий меньше, а среднее число – хорошим результатом.
Но так, вообще, идея (обозначения) мне нравится. Утащу-ка к себе. Спасибо! :)
Поскольку автор в конце ссылается на Сазерленда, то по Сазерленду Story Points - это оценка, основанная на сравнении, а Planning Poker - это метод Проведения этой самой оценки. Почему автор их противопоставляет? Т.е. налицо расхождения с Сазерлендом уже в базовых понятиях.
И дальше можно почти к каждому абзацу подобный комментарий написать: и про Velocity, и про планирование спринта, но в 500 символов тут не уложиться.
По моему опыту, именно в решении обозначенных проблем Scrum может быть хорош.