Пытаюсь разобраться со смыслом спритов исключая термины "скорость" и "планирование", которые нужны исключительно для управления в рамках сроков.
Допустим, мы компания, которая работает над своим продуктом, и нас не драйвит срок, только качество. Мы можем зарелизиться через неделю, а можем через 2 месяца, главное сделать работу качественно. Какой смысл в фиксированных спринтах, если можно просто спланировать срез работы и двигаться к его завершению?
Это получится не вотерфол, где берется вся работа, а срез, т.е. в нашем случае движение итеративное (по 1-2 фичи, например), но и нет ограничения по срокам выполнения, т.е. как только будет готово, можем двигаться дальше.
В теории, в таком случае теряется смысл Agile, потому то Agile это способ трекинга жизни проекта и возможности принятия решений вовремя, а если нас не драйвят сроки, то этой задачи просто нет.
Выходит, для проектов которые драйвятся не сроками, нет смысла в классическом Agile.
Какие у вас мысли?
Нужны ли спринты если проект драйвится качеством?
спринты нужны чтоб давать более-менее точную оценку времени необходимого на реализацию фич. без рамок "сколько работы мы сделаем за 2 недели" это все останется на уровне "будет сделано когда будет сделано". а оценка времени нужна как минимум
1 - есть другие команды для которых эта фича - блокер. не зная когда она будет сделана - они не могут планировать свои сроки. и дальше по цепочке. т.е фича бо базе блокирует апи, апи блокирует апдейт юи, отсутствие нужного юи усложняет работу сейлазам, а без подписаного контаркта компания-аутсорсер не сможет начать пилить свою интеграцию с апи.
2 - оценка необходимости фичи. время на разработку = инвестиция. имея более-менее точные сроки на разработку можно ставить приоритеты в том числе и по времени на окупаемость
3 - политические игры внутри компании. "нам нужно больше людей потому что мы ничего не успеваем" - плохой аргумент. "нам нужно больше людей т.к. тогда мы до конца года успеем сделать А, Б и начнем делать В, что в свою очередь уже через 2 года окупится и начнет приносить прибыль" - хороший аргумент.
Роман Якимчук, Боб Мартин не истина в последней инстанции, а скорость можно мерять и без спринтов.
Никто в принципе вообще не запрещает стащить отдельные хорошие идеи из разных фреймворков и сделать такой инструмент, который в вашей команде будет идеален
Допустим, мы компания, которая работает над своим продуктом, и нас не драйвит срок, только качество. Мы можем зарелизиться через неделю, а можем через 2 месяца, главное сделать работу качественно.
Как это наивно. В зрелой компании всегда есть функция маркетинга, а программисты - их производственный ресурс. И если какая-то фича нужна к определенному времени (ну, например, подборка новогодних товаров, неожиданно, к новому году), она должна лечь в спринт перед этим определенным временем. Эта фича не обязательно должна быть к определенному времени, а раньше конкурентов, к моменту запуска новой рекламы, к дате нового партнёрства и т.д.
Как раз в продуктовых компаниях спринты нужнее, чем в заказной разработке.
Простой
