Юзер сторис
Что-то меня прорвало.
Еще одна тема, которую давно хотела обсудить - агильная разработка и юзер сторис.
Мне кажется, это часто "из пушки по воробьям".
Например сейчас я пишу юзер сторис для приложения, состоящего из базы данных рыночных цен и сопутствующих сервисов. И меня подбешивает, что в каждой маленькой истории надо писать, зачем это нужно в плане бизнес-пользы. Например описываешь импорт данных - ведь ежу понятно, что данные надо импортировать в базу. Чтоб они там были. Ан нет - везде надо писать "зачем с точки зрения бизнеса". То есть чтобы потом с помощью этих данных можно было например оценивать позиции портфолио. Импорты должны быть автоматизированы - это тоже ясно. Но у нас ведь еще не выступил началальник транспорртного цеха с упоминанием, зачем это нужно для бизнеса. Ах да, что бы оценивать позиции этими данными, которые автоматически импортировались. А если импорт не задался - то надо указать на ошибку. А зачем? Ах да, чтобы импорт починили, чтобы данные импортировались - и чтобы ими оценить портфолио.
Ну на фиг это все время упоминать? Если я уборщица в больнице - то у меня задания типа "протереть подоконники". А зачем? А чтобы в больнице не разверлась антисанитария и у больных не загноились раны. А еще надо пропылесосить пол. А зачем? А для того же. Йeто же с ума сойдешь, постоянно упоминать одну и то же высокую цель. Типа "потому что в кузнице не было гвоздя"
Или я что-то недопонимаю?
Как и все другое, агильная разработка не должна быть полностью оторвана от здравого смысла. Т Е в норме юзер сторис пишутся там, где неясно, как и что имплементировпть, чтобы этот самый юзер потом смог с приложением нормально работать. Если функции и методы и так ясны, как божий день, то нахрена их в юзер стори ещё описывать? Вот если там ещё содержание неясно или техника, тогда да, может помочь. Хотя, конечно, не панацея.
И меня подбешивает, что в каждой маленькой истории надо писать, зачем это нужно в плане бизнес-пользы
Никогда не видел. И не видел чтобы подобное требовалось. Ты в них пишешь кто, когда, что, с каким результатом. У вас кто-то видать спутал непосредственные результаты для пользователя с доказательством пользы для бизнеса. Нет там такого. Типа так:
Может дело в том, что у нас пользователь действительно представитель бизнеса. А в самом приложении - разве что админ.
В принципе да, конечно. У нас наверно боятся потерять цель из поля зрения. Все должно быть fachlich обосновано, техника не должна ничего решать.
Ну как бы "они" - это мы. А наши идеологи - это авторы всяких книг об агильности.
Погодь, а какое отношение имеет импорт данных к юзер стори?
Юзер вообще таких слов знать не должен.
В примере про уборщицу пылесосить пол надо в том числе и для того, чтобы собрать пыль, которая попала на пол после протирания поконников. А еще грязь, насыпавшуюся с подошв псетителей и прочая такая хрень..
А не глобально "для чистоты"
Юзер вообще таких слов знать не должен
админ системы - это тоже юзер. И вообще, Алла не сказала, кто этот импорт запускает/конфигурирует.
мне кажется может для этого множество причин, например:
- GDPR
- внутренные процессы учета
- наличие конкурирующих запросов для импорта. Может у них там каждый встречный и поперечный запросы на импортирование данных ставит, а потом оказывается, что 80% даже юзкейза ещё для данных не придумали
У нас уже четко определено содержание импортируемых данных. Поэтому то, что их надо импортировать, чтобы они оказались в сiстеме, казалось бы ежу понятно.
Попробую.
Не предыдущей работе я самосоятельно занималась таким приложением, и никому никаких историй не писала. Поэтому для меня нынешняя форма - бюрократизм.
Такие люди не должны юзер стори писать...
Кто-нибудь вообще видел 100% корректно организованный agile? Я - нет.
100% корректно организованный agile
этого по определению быть не может, т.к. организационные рамки в agile размыты. кстати, описание business added value надо было указывать и раньше в user requirement specifications , это не нововведение agile approach.
Ну, еще и в советские времена была должность "постановщик задач" и очень хорошие стандарты для описаний процессов и прочего. Не только в IT. Причем стандарты более-менее одинаковые и в русском, и в аглийском вариантах были. Так что ничего нового давно уже не придумывают, все новое - вариации на тему старого, причем редко превосходящие это "старое" по качеству.
В целом я с вами согласна, что базис и методы по большому счету "старые", вариация происходит в "подходе", если можно так сказать, который часто подстраивается под модные веяния в обществе. Сейчас модно быть "agile and digital".
Я лично не сторонница чистого agile, я больше за гибридную форму в сочетании с классическими элементами проект менеджмента.
Мне вот интересно было бы узнать, кто-нибудь у себя на работе наблюдал те пресловутые cost savings, которые обещаются при применении agile?