https://vk.com/fabularasa сообщество вк Бориса

Съёмка есть, наверное Алексей выложит)

О здорово! Уже жду )) спасибо Макс!

Только для тех кто регистрировался. Борис просил ограничить круг.

Понимаю ;)

Всем добрый день!
В марте митапа не будет, так как готовится грандиозный ITGM, анонс будет позже

У нас есть небольшая просьба для тех, кто лично был вчера на митапе- дайте орг.комитету обратную связь, чтобы скорректировать наши дальнейшие форматы проведения мероприятия под ваши интересы.

Ссылка на форму: https://forms.gle/qHvcPXteKXTwCK7HA , это займет совсем немного времени, а принесет огромный профит сообществу.

Также напоминаю, что спикером нашего митапа может стать любой из вас! Если есть желание и время- велкам, таблица с расписанием митапов  и докладчиками вот тут https://cutt.ly/wr7rxpi

Можно выбрать любой митап любого месяца, любой формат выступления в  сообществе. Если есть сомнения о чем рассказывать или как  или нужна помощь в подготовке- орг.комитет вам поможет:) пишите!

Кто работает со Scrum. У вас есть технические спринты? Когда вылпачивается техдолг и идет рефакторинг. В интернете вижу противоположные точки зрения:
1. Технический спринт - это круто, т.к. команда может потратить время на улучшение кода
2. Технический спринт - это плохо, т.к. не привносится очевидной ценности в продукт

В одну итерацию (спринт) можно же запихнуть и то и то.
Но технический спринт может выйти во внутренний релиз недоступный внешнему заказчику

У меня команда рассматривает идею раз в квартал делать такой спринт, а я не могу понять, противоречит ли это фреймворку. И если противоречит - то как

Мы делаем технические спринты по согласованию с заказчиком — когда накопилось, и вот прямо надо уже.
Как раз сейчас вот заканчиваем такой.
Вообще в принципе у нас все задачи, которые мы делаем поделены между несколькими Scope area, и часть из них уходят в CapEx, а часть в OpEx автоматически и отчёт с этим разделением прикладывается к инвойсу заказчика (прямо из нашей корпоративной системы учёта времени).
Таким образом, заказчик прямо в деньгах видит, сколько мы в этом месяце потратили времени (=денег) на новые фичи и бизнес-импрувменты, а сколько на технический долг и прочий мэйтенанс

New Feature, Business improvement, NFR improvement - это CapEx, всё остальное - OpEx (условно - поддержка).
В этом спринте был только OpEx  у нас

Вопрос, на какие атрибуты качества продукта влияет технический спринт?

В SAFe есть что то подобное: https://www.scaledagileframework.com/inspect-and-adapt/ .    Понимание теории I&A есть, но на практике, как правило, по ходу проекта не успеваем это делать. Чаще всего уже после сдачи работ Заказчику, в  рамках гарантийного сопровождения.

Хмм... А почему технический долг это opex? Чем не capex? По такой логике вроде бы получается что любая плохо сделанная фича (с плохими defenition of done) автоматически генерирует будущий opex (что совсем не кажется логичным). Или чего-то не понял?

Всё верно, так и выходит.
А чего нелогично? Надо-то делать сразу хорошо :)

- Нашли неприятный баг, долго откладывали, а заняться надо
- поработать над проблемой медленной работы одной из частей системы
- провести рефакторинг в некрасивом куске кода

Примерно вот такие задачи могут быть. Вместо стандартных а-ля "добавить меню выбора тарифного плана в настройки услуги"

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

Хорошее замечание, спасибо, упустили этот момент, учтем. Наврут, я надеюсь, не наш случай, мы же смотрим и поле комментарий, где люди указывают на какой активности не были. Переделаем опрос с учётом замечаний

Скрам против технических спринтов. В качестве альтернативы можно сделать квоту капасити на техдолг.
IP в сейфе не про тех долг. Там долгая история, но эта итерация про инвестиции а не про долги

Плюс, можно приучиться шире смотреть на велью. Нефункциональные требования это тоже велью