Перевод не идеальный, непонятные моменты лучше в оригинале уточнить

Good news everyone!

Мы переехали на единый источник правды в puml-файле. Теперь мы из него автоматически генерируем mindmap, png-файл, readme с базой знаний.
Про то, как теперь контрибьютить: https://github.com/tlbootcamp/tlroadmap/blob/master/CONTRIBUTING.md
А вот так теперь выглядит картинка с картой: https://github.com/tlbootcamp/tlroadmap/blob/master/roadmap.png

Егор, спасибо!

Чтобы ссылки работали, можно генерировать .svg, я правда не знаю как там с поддержкой маркдауна

вот насколько я знаю, не поддерживается

но ссылки в mm работают, так что норм

Там теперь еще одна интересная техническая задача появилась.

Есть файл roadmap.puml, который источник правды. Есть папка examples, в которой находятся примеры тимлидов в разных компаниях. puml файлы в examples представляют собой подмножество веток из roadmap.puml.

Было бы гипер круто придумать, как автоматически апдейтить примеры вместе с аплейтом основного файла. Под апдейтом подразумеваю переименование веток и доьавление к ним ссылок.

Всем привет!


Наверняка многие пользуются jira и гоняют там итерации (спринты).

Я хочу получить такую аналитику (в идеале также по уже завершенным спринтам):

* Сколько SP / issues было на начало спринта запланировано;
* Сколько SP / issues было в конце спринта с разбивкой по статусам задач;

Дополнительно, в идеале:
* Видеть динамику по дням — а-ля cumulative flow report — в какой день сколько SP / issues в каком статусе было, с возможностью провалиться в задачки;
* Видеть, сколько SP / issues было добавлено в процессе спринта;

Эти данные хочется иметь в разрезе по людям в команде.

Насколько я понял, из стандартных отчетов такое собрать невозможно.

Задачка выглядит классической, думаю многие с ней сталкивались.

Подскажите, кто как делает такие отчеты?

P.S. Попробовал pivor report аддон — близко к этому, но он не умеет показать сколько было в начале запланировано (либо я не разобрался, как заставить его это сделать).

P.P.S. Использую jira cloud (знаю, что многие плагины там недоступны), но на решения для jira server тоже взглянул бы.

@augspb - можно там спросить

а мы просто переехали на YouTrack )

Спасибо, написал туда.

Если серьезно, то итерации в жире по дефолту «скрамоподобные» из коробки графики со всеми подробностями доступны, но имхо нет смысла смотреть далеко назад

Ретро должно решать этот вопрос, а не рефлексия опосля год

А есть целесообразность еженедельных ретро для команды в 8 человек?

Если есть что обкашлять - целесообразно, независимо от количества людей

Основная мысль в continuous improvement, а не в попытке решать проблемы внутри команды. Здесь часто происходит подмена понятий

Ретро в Скраме - это событие для инспекции и адаптации процессов, инструментов, качества  и взаимодействия членов команды. Если среда, в который вы работаете,  комплексная/запутанная, то такое события всегда ценно в конце итерации.

побуду занудой (может получится)
это ценно всегда. в том месте и в то время, когда происходить срань.

тут как с продуктом, чем меньше TTM, тем лучше