1 December 2019 at 00:03

Типичные ошибки Владельца продукта в Скраме

Sandbox

Comments 10

insane-jo 01.12.2019 at 02:23

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

Пока команда разрабатывает и закрывает историю спринта — готовятся будущие истории, но никак не на год вперёд.

ksigne 01.12.2019 at 02:24

Ведь никто не мешает попросить оценить сразу истории наперед и из них уже составлять свои планы?

Здесь был предусмотрен сарказм?

Shpiler 01.12.2019 at 05:40

А как быть, если заказчику не нужен мотоцикл с вашей схемы? Он оплатил автомобиль, хочет автомобиль и согласен ждать пока его не до делают целиком и полностью. Мне кажется в таком случае работа по схеме not like this потребует несколько меньшего объёма работы

AVil 01.12.2019 at 08:41

Как мне кажется, в этом и есть смысл Скрама — выявить реальную потребность пользователя продукта за счет малых итераций и быстро перестроиться. Решается это общением с Заказчиком. Если Заказчик изначально против, то поставка итерациями не получится и применение Скрам не имеет под собой фундамента — это будет лишь синтетическая итеративность в рамках того же водопада.

Shpiler 02.12.2019 at 06:03

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

ggo 03.12.2019 at 10:31

Да, есть куча областей, где не нужен мотоцикл. Нужен сразу автомобиль.
Это все лишь означает что не нужно пользовать Скрам.
Да, скрам не универсален, как и все остальное в мире. Пользуйте то, что лучше всего работает в конкретном контексте.

AntonSazonov 01.12.2019 at 10:31

Режим зануды.
А почему вы пишете слово "Владелец" с большой буквы?

402d 01.12.2019 at 11:13

Типовая картинка для иллюстрации методики скрама мне никогда
не нравилась. Любой продукт решает какую то задачу пользователя.
Пусть мы решили выпускать дрели. Как один умный человек сказал,
в этом случае фактически мы продаем ДЫРКИ.
Пользователь будет выбирать продукт из условий минимизации себестоимости единичного отверстия для себя. И если это не забывать, то сразу становиться прозрачно
(какой будет рынок сбыта)
И итерации продукта можно проиллюстрировать
от простого коловорота до станка с ЧПУ. И максимальная выгода
скорее всего будет на уровне переносного перфоратора.

Mikluho 01.12.2019 at 12:13

Слабенько…
Помесь капитанства с очень узким взглядом. Местами и вовсе Истрия про бузину и дядьку.

На мой взгляд, две главные проблемы тех, кого назначили владельцем продукта — это микроменеджмент и царёвство (я начальник, ты дурак). Остальное уже про неправильный скрам.

OnYourLips 01.12.2019 at 16:38

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

Вы неправильный термин используете.
TDD касается исключительно инженеров разработки ПО, причем зачастую каждого разработчика в отдельности, он про превентивное модульное тестирование, про него незачем знать не только менеджменту, но и даже QA.

Возможно вы имели ввиду BDD или другие виды тестирования.
В любом случае я настоятельно рекомендую узнать разницу.

Only those users with full accounts are able to leave comments. Log in, please.

Типичные ошибки Владельца продукта в Скраме

Comments 10

Your account

Sections

Information

Services