Алексей Палаткин
Большое спасибо за комментарий!
Очень хорошее замечание, обязательно учтём и возьмём в работу.
Ты правильно заметил что это цикл статей. Я думаю что чем дальше к концу, тем будет интереснее))) .
Ты всегда можешь прочитать все наши статьи в нашем блоге https://koniglabs.ru/agile-transformation-services-contractor-selection-criteria/ . Будем рады любым твоим комментариям!
Хорошего тебе дня!)
Спасибо что конкретизировала. Да, на самом деле изначальная статья разбилась на две. По факту проблемы тут у обоих. Там просто вся часть с тем как проходило заключение контракта вынеслась в отдельную статью))
Если погружаться в реальность, то часто на стороне заказчика есть ИТ менеджеры или аудиторы, которые со своей стороны валидируют результат. И если они этого так же не знают, то косячат как они, так и подрядчик, который конечно наверное обязан это знать.
Конечно Acceptance Criteria конечно то же может быть хорошим инструментом для того что бы синхронизировать ожидания, но ты их уже пишешь на придуманное решение. Т.е. ты изначально формулируешь Epic->Feature->UserStory и уже к ним пишешь Acceptence. Тут основная мысль в подходе откуда придумывать решение. Если ты уже сделала UserStory просто на основании пускай даже реальных данных и пускай даже это реальные пользовательские истории то тебе уже тяжело мыслить по другому. Идея в том что бы постоянно задавать себе вопрос: А как моё решение повлияет на метрику или индикатор? Или иногда можно задать вопрос: А что будет, если я этого вообще не буду делать?
Что будет если я не буду вообще рефакторить этот метод?
Про опережающие индикаторы можно прочитать ещё тут https://www.scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/
В статье они следующие
Опережающие индикаторы:
-Промежуток времени с момента возникновения инцидента до старта работ администратором.
-Время, которое тратит администратор на решение инцидента.
-Количество критичных инцидентов в системе в месяц.
К примеру можно было бы выявить так: Какую ценность данная система могла бы вам принести?—-> Ну мне бы меньше влетало от начальства потому что было бы меньше критических проблем-—>А сколько сейчас этих критических проблем?—>> Ну много-—>> Миллиартд в год?—->> Нет, что вы, меньше-—> 100 в месяц?—->> Ну критических прям меньше, скорее около 10 в месяц-—-> И получаем кол-во инцидентов в системе.
По другим опережающим индикаторам так же в процессе выявления требований.