Нефункционалка она естественно велью :)

Технические релизы могут зайти в продуктовой компании. Руководство компании может решить сделать тех. спринт или вообще отдать планирование в команду... На моей практике такого не было ни разу 😂 руководство требовало фич. Потому спринты включали как тех долг, так и фичи.
В аутсорсинге продать клиенту спринт без фич довольно сложно. Зависит от того, насколько тех. долг мешает самому клиенту. Если клиент покусан аджайлом и сам ведёт спринты, то вариант аналогичен продуктовой компании.

Технические спринты не противоречат фреймворка. Но продать их клиенту довольно сложно. При этом можно получить претензию клиента вплоть до не оплаты 2 недель работы команды.
Для себя решил что спринты должны нести ценность клиенту. И смешиваю тех долг с фичами 👍

Скрам говорит, что должен быть инкремент, содержащий value. другое дело, что под value подразумевается приращение движение продукта вперед, а это трактуют как хотят

Чтобы продать техдолг клиенту нужно начать фиксировать инциденты(аварии и крит баги на проде) и техдолг который приводит к этим инцидентам начинает нести вэлью. Ключевое, что техдолг надо продать. Если не продается может и не нужно делать?

Минуточку, но мы же вот делаем тех.спринты и все ок - в аутсорсе. Сильно зависит от отношений с клиентом

Ну про продукт это тоже очень сильно зависит. У нас, например, планирование полностью в руках овнера

А что такое тех. долг для тебя?

Для меня тех. долг это набор улучшений, которые не выполнены, т.е. NFR improvements + баги. Потому тех. долг распадается на NFR imp = CAPEX + фикс застарелых багов = OPEX.

Хороший подход 👍

Согласен. Зависит от отношений с клиентом.

В нашем случае nfr improvements - это то, из-за чего к нам и пришли изначально, поэтому это не OpEx) у нас проект с клиентом стартовал с того, что у них после введения нового продукта (без нашего участия) возросла сильно нагрузка на сервис и с этим они к нам и пришли. Ну а дальше пошли всякие интеграции и прочее- скоуп на ходу пополнялся в духе «а вот нам ещё это надо, поможете?»

Это к тому, что часть тех долга можно внести как CAPEX. А корпораты это любят 😀
На сем думаю стоит закончить сравнивать CAPEX и OPEX 😉

чтобы начать фиксировать инциденты, надо взять эксплуатацию проекта в свои руки, что не всегда возможно. И почему-то складывается ощущение, что большая часть клиентов считает, что если баги есть, то это подрядчики накосячили и должны за свой счет это устранять. Соответственно команде просто не выгодно делать баги и лучше сразу делать по нормальному, не допуская возникновения техдолга за счет увеличения скоупа работ. В худшем случае заказчик уйдет к тем, кто готов фиксить баги за свой счет.

Если не получается новые фичи делать нормально, то это другое дело. А вот для техдолга/легаси идея в том, чтобы сделать ситуацию прозрачной. Если техдолг давит, то можно начать соотносить баги с модулем и если найдется явно проблемный то посчитать для заказчика сколько он заплатил за устранение этих багов за последнее время. Если все равно не хочет включать задачу на рефакторинг оного, то решать проблему за свой счёт если проект хотите.

Все зависит от ваших договорённостей с Заказчиком. Лучше всего интегрировать рефакторинги в задачи, чтобы каждый раз менять по чуть-чуть. Но если есть потребность сделать development freeze то его надо делать, главное дрговориться что поставки не будет. Также можно его поднять на уровень релизного цикла. Скрам не закрывает этот уровень планирования.

Девушки, с праздником Весны вас!
Желаю радости и счастья!
И чтоб проекты шли легко 👍😉

Ребята, всем привет!

Пообщавшись с участниками ITGM, обеспокоенными проблемой коронавируса, партнёрами мероприятия и компетентными специалистами,  команда Piter United приняла непростое решение – перенести ITGM на 13 июня (суббота)⛑

Ничего не отменяется, просто переносится на лето. А у нас с вами будет время получше подготовиться :)

🤦‍♂️

Тут надо как то делить, те кто отвечают “Нет”, они паникуют по поводу ужасного вируса-убийцы, или просто не планируют идти по любым другим причинам