1) Для большинства не-it-шнтков слово "фреймворк" несёт в себе примерно столько же информации, как для англоговорящего человека karkas - набор звуков да и только.
2) термин framework используется ещё и потому, что в английском нету отдельных слов для Методики и Методологии - там все methodology. Причем, ладно, если бы использовался перевод "каркас" - это было бы хотя бы понятно, а так какой смысл?
Непосредственно про Скрам уже вроде аргументы написаны, и повторяться не буду. Но даже если отвлечься от Скрам, то использование Owner/Владелец в роли не соответсвует и общей менеджерской практике. Так, например, существуют еще такие понятия как Project Owner и Process Owner – и в том и в другом случае речь идет о людях, которые Заинтересованы в Результе Вцелом, а не каких-то точечных показателях. В вашей же интерпритации Product Owner (ввиду отсутствия ответственности за сроки и бюджеты) больше похож на тех продажников, которые обещают заказчику какую-то дичь да еще и в неизвестно откуда взятые сроки – главное продать, а потом хоть потоп, – а инженеры должны все это разгребать. В Скраме же Владелец Продукта – это именно Владелец классическом (устоявшемся) понимании. В итоге, когда человек, который ничего не знает про Скрам и Agile, но знаком с теорией процессов или проектов, впервые услышит термин Product Owner, у него скорее всего возникнут ассоциации куда ближе к Скрамовсому определению, чем к вашему. Это, в свою очередь, помогает людям быстрее находить общий язык, что и является целю профессиональной терминологии. Когда же понятия используются произвольно, в угоду моде, это затрудняет общение, потому что приходится переспрашивать: “а что конкретно вы имеете в виду?”, ну или пытаться угадать из контекста… Так и что в этом хорошего?
Хотя я конечно должен признать, что хайп как правило все-таки побеждает прозрачность понятий (((
7. Недостаточное внимание качеству продукта из-за упора на быструю доставку работающих продуктов:
Из-за фокуса на доставку работоспособного продукта в конце каждого спринта, некоторые команды могут уделить недостаточно времени тестированию и обеспечению качества. Это может повлиять на стабильность и надежность окончательного продукта.
Вот тут совсем не согласен. Внимание к качеству продукта регулируется Определением Готовности (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”. Имеется в виду, что команда должна выполнять свои обязательства до конца спринта (всегда, а не “более-менее”). Если не получилось, то в следующий раз следует брать меньше. И только поняв, сколько реально вы можете выполнять работы с нужным качеством, вы сможете расти быстрее, используя спринт-ревью и постоянное улучшение.
Но опять же, я не знаю, как у вас все устроено. Вам на месте, конечно, виднее.
мы решили что стропойнт - создать новый метод для обращения по http и получить из БД набор данных, теперь давайте на основе этой задачи оценим сколько времени займет написание алгоритма для обработки 5 петабайтов данных в HDFS
Конечно комфортнее, когда сравниваемые задачи различаются в разы, а не в десятки и сотни раз. И на практике так обычно и происходит: вы выбираете поинт, потом оцениваете 2-3, 10, 15 и потом уже 25. Но даже если разброс очень большой, то ряд Фибоначчи вам поможет. В этом случае, вам надо выбрать между 13, 21, 34, 55 и 89. Это существенный разброс, так что выбор не такой уж и сложный, даже если у вы ещё не оценивали промежуточные размеры. А далее работает "покер": каждый член команды дает свою оценку, и если разброс небольшой (не более двух ступеней), то берется среднее, в противном случае – те, кто поставил крайние оценки, обосновывают свою точку зрения – без дискуссии! – и переголосовываете. Если разброс все ещё большой, то повторяете (один раз, т.е. максимум три голосования) и берете среднюю оценку.
Это не занимает много времени, а работает обычно лучше, чем экспертная оценка в часах. Мне сложно сказать, что пошло не так именно у вас, но для этого и существует Спринт-ревью: вы обсуждаете, что не получилось, и исправляете. Если ошиблись в оценке, то это повод чему-то научиться…
Ну, кстати, да. Вариант. Вот только часы убрать, а вместо них в первом спринте выбрать тот самый "изъян" или "изи", и все остальное мерять относительно них.
Ну и второе (это уже вкусовщина, но все же), если следовать рекомендациям того же Сазерленда (хотя есть и другие), то числа следует взять из ряда Фибоначчи. Так проще выбирать, потому что между 8 и 12 разница ещё заметная, а вот между 20 и 24 – уже не столь очевидная. А так у вас будет 8, 13, 21, 34. В командном "покере" выбор будет проще, дискуссий меньше, а среднее число – хорошим результатом.
Но так, вообще, идея (обозначения) мне нравится. Утащу-ка к себе. Спасибо! :)
Иногда оценку задач проводили в условных единицах (Story Point), а иногда в относительных (с помощью техники Planning Poker).
Поскольку автор в конце ссылается на Сазерленда, то по Сазерленду Story Points - это оценка, основанная на сравнении, а Planning Poker - это метод Проведения этой самой оценки. Почему автор их противопоставляет? Т.е. налицо расхождения с Сазерлендом уже в базовых понятиях.
И дальше можно почти к каждому абзацу подобный комментарий написать: и про Velocity, и про планирование спринта, но в 500 символов тут не уложиться.
По моему опыту, именно в решении обозначенных проблем Scrum может быть хорош.
Прекрасное замечание, но...
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 может быть хорош.