Стандарт визначає практики і правила, а не ті, хто його по-своїму тлумачать.
Насправді, немає нічого однозначно поганого в блокуванні скоупу на ітерацію. Просто не треба це називати аджайлом, а просто ітеративним підходом. Працює — і ок.

В скрамгайді пошукав, такої рекомендації немає. Натомість, є така

During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality does not decrease;
The Product Backlog is refined as needed; and,
Scope may be clarified and renegotiated with the Product Owner as more is learned.

Якщо підкажете, в якому офіційному джерелі знайшли вашу цитату, я зможу прокоментувати — я дивився тут scrumguides.org/scrum-guide.html. В той же час, скрамгайд є найофіційнішим з усіх інших, можливо тільки Маніфест більш точний, бо не згадує жодних фреймворків. А в ньому сказано
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Тож знову не туди.

ні. формується Ціль Спринта — вона незмінна. але ніде не сказано, що спринт має фіксований скоуп.

Коли я говорив про СБМ, мав на увазі ситуацію, коли умовний розробник з досвідом в гемблінгу знає, як вирішувати технічні проблеми, пов’язані з гемблінгом і йде в ПМ на гемблінг проєкт. Але домени можна нарізати по-різному, я згоден з цим.

Мне неприятно читать статью, в которой коллеги именуются «бойцами». Кажется, что менеджмент уж очень звезду поймал.

з 11 метафор проєктного менеджменту 4 некоректнi. Але зроблено круто!

можна додати 12у:

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

це будуть данi про виконану роботу (Work Performance Data)

Что неловкого? Вроде написали же, что нет потолка зарплат из-за того, что на человеке не висит маржинальность. Т.е. не будет такого, что 5к потолок, потому что за 7к продали.

https://www.fedoruk.works/pm-101

там же отзывы и детали.

Честно говоря, ваш ответ можно сократить до

мы не пытались переизобрести LeSS.

вода

Сейчас это похоже на LeSS

Т.е. любой опытный менеджер сократил бы вам цикл обучения в разы.
Я прекрасно понимаю концепцию инструментов в контексте, но описанная в статье проблема имеет как минимум решение в.1.0. И ваш ответ в комментарии только подтвердил мое предположение.

Мне кажется, пора приучаться к тому, что статьи про структуру без диаграмм нечитабельны.

По всему похоже, что пытались переизобрести LeSS. Вопрос — почему просто не попробовали его из коробки?

Це некоректно. Те, що українські ПМи вважають за «контракт дедікейтед тімс» насправді є Витрати+Фіксована Винагорода (CPFF).

Така плутанина дуже звужує коло варіантів для ПМа на старті проекту. Ланцюг, дуже спрощено, виглядає так — розгляд бізнес-кейса, розуміння шляхів вирішення, пропонуємо модель взаємодії, встановлюємо тип контракту.

Це дуже легко перевірити, якщо провести мисленнєвий експеримент — ви можете вирішити проблему клієнта за допомогою staff augmentation та оформити контракт як time-and-material, якщо так зручно в контексті? Якщо так, ми повертаємося до мого базового аргументу.

Dedicated Development Center (DDC) — если заказчик хочет на долгосрочной основе расширить свой штат за счет офшорной команды.

это не тип контракта, а модель взаимодействия. не нужно путать.

Контракты — фиксированной цены, время и материалы, затраты+ и все производные.

Модели взаимодействия — проектная, стаф аугментейшн, девелопмент центр, консалтинг и т.д.

еще ж не было официального релиза. имелся ввиду 6ой?

Пока опыт мировой экономики (последние лет 50 так) показывает обратое.

хотелось бы увидеть сеньора девелопера, готового перейти на зарплату джуна пма (а больше давать смысла нет, потому что ценности нет).

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

По поводу обучения и курсов — обращайтесь, помогу чем смогу.

Перефразируя известный афоризм: «Работай над проектом так, как будто завтра будет аудит, и аудитор — маньяк, и знает, где ты живешь».

Короче, если есть возможность вести проект качественно изначально, то никакой аудит не страшен.

гм и что? как метод оценки задач соотносится или противоречит аджайлу?

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

Хороший разбор. И все же, я бы отметил, что каждый из «потенциальных» ответов обязан закончиться разбором инцидента. Иначе — все коту под хвост и повторяемость ошибок.

Но начинать, действительно, надо с указанных вариантов. Никакой «разбор полетов» на месте проблему не решает.