Если нужно знать "сколько это делать", то стоит устраивать сессии с проработкой беклога всеми членами команды — оценка по реализации должна поступать от разработки, а не от аналитика. Плюс там же приоретизация — как итог, беклог будет готов и поставка задач по конвееру в спринт налажена.
Мне кажется проблематика, которую вы описываете, проявляется благодаря: 1. отсутствие у воспринимающего (ученика) абстрактного мышления как такового 2. неумении учителя выбрать адекватный (большинству аудитории) уровень абстракции
Согласна с вами практически во всём. Насколько вижу, в компании понимают, что мы шизофреним в некотором роде. Ситуация может быть в корне решена только в самом старте — по-другому строить отношения и опорные точки рулежки проекта, да.
Спасибо за вопросы Такое впервые? Что было предпринято для повышения точности планирования после предыдущего пролёта-над-сроками? Если таки впервые - почему не дали припуск по срокам х2 "на первый раз"?
Потому что клиент, например, давит по срокам. Вы же помните, что у всех свои цели?
Стоп, дзинь!
Если фича настолько неважная, что её не надо прорабатывать при добавлении в бэклог, - может, её не надо добавлять в бэклог вовсе? Чтобы не вышло ситуёвины, что оценили при добавлении одно, а в работу по той же задаче пошло совсем другое, например?
Тут вопрос не про "важность". Это зависит от соотношения ресурсов на проекте. В конкретный момент аналитика может быть перегружена подготовкой материала для загрузки специалистов "далее по конвееру". Соответсвенно, как только часть ресурса аналитики освобождается, можно направлять внимание на проработку фичей и подготовки их к планированию.
Продукт с минимально-необходимым функционалом для того, чтобы считать его отвечающим требованиям заказчика. А так как ситуация "требования заказчика меняются на ходу" всем известна, то и состав MVP порой шатает (хотя не должно в идеальном мире).
Эта рисовалочка хороша https://excalidraw.com/, как быстрый вариант).
Если нужно знать "сколько это делать", то стоит устраивать сессии с проработкой беклога всеми членами команды — оценка по реализации должна поступать от разработки, а не от аналитика. Плюс там же приоретизация — как итог, беклог будет готов и поставка задач по конвееру в спринт налажена.
Мне кажется проблематика, которую вы описываете, проявляется благодаря:
1. отсутствие у воспринимающего (ученика) абстрактного мышления как такового
2. неумении учителя выбрать адекватный (большинству аудитории) уровень абстракции
Интересный разговор вырисовывается.
Да, с этим заказчиком впервые работаем.
Отловленный оттенок действительно есть ¯\_(ツ)_/¯
Согласна с вами практически во всём. Насколько вижу, в компании понимают, что мы шизофреним в некотором роде. Ситуация может быть в корне решена только в самом старте — по-другому строить отношения и опорные точки рулежки проекта, да.
Спасибо за вопросы
Такое впервые?
Что было предпринято для повышения точности планирования после предыдущего пролёта-над-сроками?
Если таки впервые - почему не дали припуск по срокам х2 "на первый раз"?
Потому что клиент, например, давит по срокам. Вы же помните, что у всех свои цели?
Стоп, дзинь!
Если фича настолько неважная, что её не надо прорабатывать при добавлении в бэклог, - может, её не надо добавлять в бэклог вовсе?
Чтобы не вышло ситуёвины, что оценили при добавлении одно, а в работу по той же задаче пошло совсем другое, например?
Тут вопрос не про "важность".
Это зависит от соотношения ресурсов на проекте. В конкретный момент аналитика может быть перегружена подготовкой материала для загрузки специалистов "далее по конвееру". Соответсвенно, как только часть ресурса аналитики освобождается, можно направлять внимание на проработку фичей и подготовки их к планированию.
Продукт с минимально-необходимым функционалом для того, чтобы считать его отвечающим требованиям заказчика. А так как ситуация "требования заказчика меняются на ходу" всем известна, то и состав MVP порой шатает (хотя не должно в идеальном мире).
спасибо)