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