org-agenda vs youtrack

Так вот, в org-agenda всё завязано на планировании задач под определенную дату для построения спринтов

ЯННП, зачем ты ставишь дедлайн на 50 задач, если не собирался их выполнять. Лежат себе они в todo и лежат. Что планируешь взять на выполнение – поставил дату и дедлайн, они отображаются в календаре. Глобальный todo список можно посмотреть отдельно.

Я заметил, что задачи в основном бывают или емкие или которые могут за неделю не решиться. Тут сразу скажут: надо сегментировать. Допустим, есть задача освоить ЯП_name. Я задачу поставил и тружусь. Можно сегментировать по заглавию. Но зачем мне это надо? Постоянное сегментирование - это трата времени на менеджмент. И тогда я не работаю, а большую часть времени сегментирую эти задачи. Целесообразней просто ёмкие задачи ставить и по выполнению им присваивать done. А так-то у меня задач

◉ TODO [100%] [0/0]
◉ TODO [62%]  [33/53]
◉ TODO [0%]   [0/26]
◉ TODO [0%]   [2/10539]

Я не хочу сегментировать, а хочу ехать

PS: а еще задачи в youtrack воспринимаются как задачи, а не как текст. Не знаю почему. Может прямоугольнички решают? :)

Я в последнее время не использую для работы спринты. ВООБЩЕ.

Допустим, я поставил 50 задач в спринт

Признаться, не очень понятно чего вы делаете и чего хотите добиться.

Я не хочу сегментировать, а хочу ехать

Календарь нужен чтобы планировать время. Если ты решаешь задачи в свободном темпе, то тебе всё это не нужно.

◉ TODO [62%] [33/53]

Но, какое же это TODO если оно более чем наполовину сделано? Задачи К Исполнению просто лежат и ждут, когда на них обратят внимание.

Допустим, есть задача освоить ЯП_name.

Для таких задач, мне кажется, все эти todo/in-progress/done не очень подходят. Они подразумевают некий чётко очерченный результат: «Пройти сертификацию $certName». Вот тут сразу ясно, что делать, как делать, как понять, что уже сделал. А «улучшить навык общения с дамами» — этому можно посвятить всю жизнь. Ну и смысл иметь задачу, навечно зависшую в состоянии «в работе»?

Разбей на сабтаски

Для таких задач, мне кажется, все эти todo/in-progress/done не очень подходят

В принципе подходят, но не так как это делает ТС. Например хочу выучить язык X. Ставлю себе в календарь повторяющуюся задачу с 20:00 до 21:00 каждый день кроме выходных урок языка X.

Я хотел так: по матрице ABCD я закидываю задачи(их много и в B и в C и в D) и тегирую их по сервисам/проектам. Например

◉ TODO taskA
...
◉ TODO taskB(много задач)
 ○ TODO задача1 :emacs:
 ○ TODO задача1 :prj1:
 ○ TODO задача2 :prj1:
 ○ TODO задача2 :prj2:
◉ TODO taskC
..
◉ TODO taskD
..
◉ TODO taskZ
 ○ TODO проверить что-то там

Потом я беру из taskB или B,C,D задачи(скажем 10 штук) и беру их в работу. Но задачи могут быть ёмкими, сегментировать я их не хочу(оверменеджмент) и просто выполняю. Если это не делать через планирование, то мне надо создавать отдельный ◉ TODO taskСurrent и потом из этого карент переносить куда-то в B или где там они были изначально. Это всё превращается в конкретную трудозатратную историю. Если бы в агенда можно было бы делать спринт не на неделю, а на год - было бы идеально. А в конце каждой недели каждый раз изменять спринт у задач - тоже накладно. Я могу их взять не 10, а 50

Youtrack пока что поиспользую для связки с gitlab, может найдется ответ для agenda. Всё-таки текст он по-надежней будет

Я не совсем понял о чем ты. Ты пробовал SСHEDULED дату таскам выставлять?

Они будут всегда висеть в агенде на сегодня с количеством просроченных дней, отсортированные по датам, когда взял. Или тебе принципиально чтобы не было этого ярлыка x36?

Лично я даты не проставляю, я добавил доп статус, «NEW» - таски которые висят как идея, но еще не взяты, а TODO это то над чем работаю сейчас.

https://x0.at/LRRw.png

Похоже, ты хочешь подобное: https://habr.com/ru/articles/484572

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

спринт не на неделю, а на год

Спринт длинною в год это не спринт. Это чортов марафон. Если у задачи есть срок где-то через полгода-год, значит у неё нету вообще никакого срока.

Я бы на вашем месте вообще не стал заморачиваться со спринтами (я, кстати, ими и не пользуюсь в org-mode). Есть задачи в статусе todo они ждут моего внимания. А есть — in progress, ими я занимаюсь в текущий момент. Всё. Зачем усложнять?

И тогда я не работаю, а большую часть времени сегментирую эти задачи.

Срочно отряд менеджеров быстрого реагирования в этот отдел, тут опасные мысли у сотрудника!

Если бы в агенда можно было бы делать спринт не на неделю, а на год - было бы идеально

Ну так его можно делать, ставь дедлайн через год. Другое дело, что непонятно зачем это нужно. Календарь нужен для планирования задач в течение дня/недели, а не чтобы пометить целый год как «год питона».

Я вот думаю над тем, как это всё организовать. Допустим, у нас есть inbox, туда скидываем всё. Потом сортируем ABCD. И дальше надо это всё разделять на проекты. Вопрос только как. Я вижу это примерно так

Inbox
A
B
C
D

Когда задачи сортируются в inbox, им надо проставить тег. Тег наименования проекта и тег принадлежности к чему-то. Например:

:devops:emacs:
:devops:dyndns:
:prj_name:backend:srv_name:

Или можно это расклыдывать посредством отдельных веток

** prj_name
*** backend
**** srv_name

Имхо, первый вариант предпочтительный т.к позволяет фильтровать by tag. Что скажете?

Оба подхода хороши вместе. Ветка относится к какой-то логически изолированной вещи, а метка — к понятию. В стиле

** prj_name
*** backend
**** srv_name
***** TODO настроить мониторинг :k8s:devops:observability:

Есть пул задач, я его приоретизирую и потихонечку выполняю.

вам нужно определиться, по какой методике вы планируете работать, через kanban или scrum

по описанию из поста вы пытаетесь делать какой-то микс из этих двух подходов

Делать категориями, а не тегами еще нужно(скорей всего) затем, чтобы не мешать понятия и изолированные вещи :)

А еще: Inbox прям нужен или без него можно обойтись? Когда появляется задача, сразу ее ABCD? Или может их в D/C кидать с каким-то тегом? :unsorted:?

И еще: при такой схеме у нас отсутствует приоретизация внутри prj_name. Не строить же внутри prj_name ABCD?

org-agenda vs youtrack (комментарий)

ugoday org-agenda vs youtrack (комментарий)

А еще: Inbox прям нужен или без него можно обойтись?

Зависит от вашего подхода. Можно отдельно через capture template накидывать задачи чем бы в принципе было неплохо заняться, а потом растаскивать их по проектам (типа backlog groomming в этом нашем agile). А можно просто заходить в нужные проекты и создавать задачи по месту. Тут уж как вам удобнее.

P.S. Как-по мне, так вы слишком всё усложняете и пытаетесь излишне детализировать.

P.P.S. Лучшая стратегия в моём случае, когда неясно как делать, а единственно правильного ответа явно нету — делать как-нибудь не очень вкладываясь в единообразие и качество результата. Что не работает, таким образом, отомрёт само собой. А что останется — то и есть правильный (для вас) подход к организации списка дел.

Насчет инбокса - всё ясно. А вот как быть с приоритетами внутри проектов? Городить внутри них ABCD? Вот если бы тегами в общем списке ABCD делать т.е

Inbox :i:
A :a:
B :b:
  task1 :prj1:back:bug:srv_some:
C :c:
  task1 :prj1:back:feature:k8s:
  task1 :prj2:
D :d:
R :r: (reject)

Тогда можно было бы фильтровать по :c:prj1:

PS: фильтровать тегами [A] [B] самим org - не вполне удобно и, наверно, не применимо в контексте этого всего

ugoday так как же быть? org-agenda vs youtrack (комментарий)

Это от вас зависит. Весь смысл в том, чтобы система планирования подстраивалась под пользователя, его привычки и потребности, а не пользователь натягивался на систему планирования.

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

Если не уверены, просто пробуйте делать так и эдак. Что-нибудь да подойдёт. Главное (если вы не немец) не пытаться заранее сделать всеохватную, детально прописанную систему правил, чтоб потом скурпулёзно не смотря ни на что ей следовать.