Comments 23
Мы обычно пользуемся не вложенными задачами, а связанными. Например, для решения задачи A требуется сначала решить задачу B, но задачу B нельзя считать вложенной в A, т.к. это самостоятельная задача (нужна сама по себе, независимо от того, существует ли задача A), просто пока она не решена, A решить невозможно. При таком подходе получаются не «папки», а просто связи между задачами. Для каждой задачи можно посмотреть, от каких она зависит, и какие, в свою очередь, зависят от нее.
+2
Мы пользуемся, и постоянно. В списках задач отражаются все задачи (если есть родительская задача, это помечается), в трудозатраты родительской задачи включаются затраты дочерних задач.
Поиск, по-моему, при этом наоборот облегчается: если ищешь какой-нибудь «отчет» по какому-то конкретному функционалу, то не надо перебирать тонну задач с заголовком «отчет», а достаточно перейти по ссылке из родительской задачи, у которой уже будет уникальное название.
Связанные задачи тоже используем, но тогда трудозатраты не суммируются, а это порой удобно.
И даже бывает так что выкладывать задачи не в совокупности смысла нет — и тогда кроме как иерархию для отображения этого факта ничего и не придумаешь, наверное.
Поиск, по-моему, при этом наоборот облегчается: если ищешь какой-нибудь «отчет» по какому-то конкретному функционалу, то не надо перебирать тонну задач с заголовком «отчет», а достаточно перейти по ссылке из родительской задачи, у которой уже будет уникальное название.
Связанные задачи тоже используем, но тогда трудозатраты не суммируются, а это порой удобно.
И даже бывает так что выкладывать задачи не в совокупности смысла нет — и тогда кроме как иерархию для отображения этого факта ничего и не придумаешь, наверное.
0
А не могли бы Вы немного рассказать о своей структуре задач? Как разбиваете, какова глубина вложенности, как согласуете между собой?
+1
Глубина вложенности — обычно 2-3 уровня
На верхнем т.н. «эпики», т.е. какие-то крупные нововведения, эпики бьются на задачи, задачи — на подзадачи. Найденные при тестировании задач баги отправляются на уровень подзадач, там же находятся задачи на code review и тесты.
Стандартный процесс: от заказчика сваливается нечто с формулировкой «ДОРАБОТКИ», открыв описание, я вижу, что доработки там разноплановые и что их можно распараллелить, делю задачу на соответствующее числу доработок количество подзадач, распределяю по людям, в итоге получаю оценку родительской задачи и могу следить за ее выполнением, тестированием, правкой багов и код ревью.
Либо приходит что-то, что можно определить как эпик вследствие объема, тогда делю ее на задачи, каждая из которых может быть реализована и протестирована отдельно. Соответвенно, в задачах уже будут подзадачи с багами, тестами, ревью. Если задачу можно разделить на этапы, также выношу это в подзадачи.
На верхнем т.н. «эпики», т.е. какие-то крупные нововведения, эпики бьются на задачи, задачи — на подзадачи. Найденные при тестировании задач баги отправляются на уровень подзадач, там же находятся задачи на code review и тесты.
Стандартный процесс: от заказчика сваливается нечто с формулировкой «ДОРАБОТКИ», открыв описание, я вижу, что доработки там разноплановые и что их можно распараллелить, делю задачу на соответствующее числу доработок количество подзадач, распределяю по людям, в итоге получаю оценку родительской задачи и могу следить за ее выполнением, тестированием, правкой багов и код ревью.
Либо приходит что-то, что можно определить как эпик вследствие объема, тогда делю ее на задачи, каждая из которых может быть реализована и протестирована отдельно. Соответвенно, в задачах уже будут подзадачи с багами, тестами, ревью. Если задачу можно разделить на этапы, также выношу это в подзадачи.
+1
Любую задачу можно разбить на несколько более мелких задач. Этот процесс называется декомпозиция. До разумных пределов конечно. Что автор увидел в этом неестественного?
0
Я нигде и не пытался сказать, что декомпозиция плохо. Я лишь отметил, что большинство наших пользователей испытывают трудности при проведении этой самой декомпозиции. Причем трудности настолько большие, что им проще отказаться от разбиения задачи на более мелкие и перейти к плоскому списку задач. Причем, я привел пример, что это не только с системами управления задач такое происходит, но и, например, при работе с файловой системой.
При этом вижу по результатам опроса, что большинство все же пользуется иерархией задач. Пока, что приходит в голову, что, возможно, нужна не иерархия в общем виде, а какие-то ее частные случаи: например, ограничение глубины, чек-листы, что-нибудь еще.
При этом вижу по результатам опроса, что большинство все же пользуется иерархией задач. Пока, что приходит в голову, что, возможно, нужна не иерархия в общем виде, а какие-то ее частные случаи: например, ограничение глубины, чек-листы, что-нибудь еще.
+1
Возможно, вы пытаетесь изобрести велосипед. Ничего лучше иерархии нет. Это абстракция понятная каждому. А трудности, которые испытывают пользователи — это проблема плохого дизайна ПО.
Хороший пример с файловой системой. Папки и подпапки — это чрезвычайно удобно. Доказано временем. Хотя это не единственный способ для организации данных.
Просто дайте людям возможность создавать подзадачи. Если они хотят плоский список, пусть не создают подзадач. Какая проблема? Я и правда видел на своём веку людей, которые все свои файлы хранили в одной единственной папке: музыку, документы, картинки и т.д. Но все люди разные, и всё сильно зависит в команде от того, как работает менеджер. Вы его работать по-своему не заставите. Просто дайте инструмент. И сделайте его простым, понятным и очевидным.
Не надо за людей решать: вам не нужны подзадачи (потому что мы не знаем как сделать работу с ними удобной).
Хороший пример с файловой системой. Папки и подпапки — это чрезвычайно удобно. Доказано временем. Хотя это не единственный способ для организации данных.
Просто дайте людям возможность создавать подзадачи. Если они хотят плоский список, пусть не создают подзадач. Какая проблема? Я и правда видел на своём веку людей, которые все свои файлы хранили в одной единственной папке: музыку, документы, картинки и т.д. Но все люди разные, и всё сильно зависит в команде от того, как работает менеджер. Вы его работать по-своему не заставите. Просто дайте инструмент. И сделайте его простым, понятным и очевидным.
Не надо за людей решать: вам не нужны подзадачи (потому что мы не знаем как сделать работу с ними удобной).
0
Не могли бы Вы рассказать какой иерархией задач на проектах, одном проекте пользовались?
+1
Программный комлекс, состоит из 3-х систем.
Проект
— Система 1
… — Модуль 11
… — Модуль 12
…… — Решение задачи XXX
…… — Интерфейс
……… — Реализация
……… — Логгирования
…… — Решение задачи YYY
……… — Подготовка данных для исследования
……… — Разработка структуры
и т.д. и т.п.
Если в одном трекере будет это всё валяться сплошняком, будет ад. Теги, связи — конечно хороши, но они не дают надёжную чёткую структуру что из чего состоит, потому что иерархия задач подразумевает: какая работа частью какой работы является. Она может зависеть от других задач, быть с ними связана, укладываться на диаграму, быть триггером для старта/завершении цикла, но она всегда является частью чего-то большего.
В любом случае иерархия есть, как минимум в разрезе Проект — Задачи. По сути проект это и есть одна большая задача. Хотя мне не нравится, когда некоторые разработчики выбирают подход «Всё есть задача». Тоже фейл но в обратном направлении.
Проект
— Система 1
… — Модуль 11
… — Модуль 12
…… — Решение задачи XXX
…… — Интерфейс
……… — Реализация
……… — Логгирования
…… — Решение задачи YYY
……… — Подготовка данных для исследования
……… — Разработка структуры
и т.д. и т.п.
Если в одном трекере будет это всё валяться сплошняком, будет ад. Теги, связи — конечно хороши, но они не дают надёжную чёткую структуру что из чего состоит, потому что иерархия задач подразумевает: какая работа частью какой работы является. Она может зависеть от других задач, быть с ними связана, укладываться на диаграму, быть триггером для старта/завершении цикла, но она всегда является частью чего-то большего.
В любом случае иерархия есть, как минимум в разрезе Проект — Задачи. По сути проект это и есть одна большая задача. Хотя мне не нравится, когда некоторые разработчики выбирают подход «Всё есть задача». Тоже фейл но в обратном направлении.
+1
Структура понятная, но рано или поздно попадается задача, которая может быть отнесена как к модулю 11, так и к модулю 12. Кроме того, при такой структуре не так уж и просто понять где и какие задачи уже сделаны, а какие еще нет.
+2
Во-первых, при такой структуре можно посмотреть готовность работы на любом уровне иерархии. Что называется, не вдаваясь в детали. Это очень удобно для менеджеров, которым может нет дела как идут дела с реализацией отдельных функций отдельных программистов, а текущее состояние задач по-крупней. Во-вторых, подзадача не может быть отнесена к двум задачам. Потому что иерархия проекта и иерархия задач — разные вещи совершенно. Хоть и на начальном этапе возможно сходство. Поймите, наконец, что иерархия в задачах — это декомпозиция. Большие задачи разбиваются на мелкие, но это в совокупности одна и та же задача. Это не просто папка для подзадач. Так вы своих пользователей запутаете.
0
Наш багтрекер не поддерживает вложенные задачи. Однако, руководство не умеет разбивать задачи на этапе формулировки (например, сваливает совершенно несвязанные проблемы из нескольких жалоб пользователей в одну задачу и обзывает ее «проблемы, найденные пользователями» и ставит milestone на следующий релиз). Тактика «закрывать абсолютно любую задачу, содержащую список, как невалидную по формальной причине необходимости разбить» только привела к конфликтам. Не знаю, помогли бы в такой ситуации подзадачи или нет, но, думаю, не попробовав, не узнаю.
0
Ну, руководителя тоже можно понять. Ему неважно, на какие задачи разбиваются эти «проблемы, найденные пользователями» — ему главное к следующему релизу быть уверенным, что все эти проблемы решены. И контролировать это ему удобнее в одной задаче (сразу видно, решена она или еще в работе), а не выискивать кусочки задачи по всему багтрекеру.
+2
А что за продукт то?
+1
Вложенные задачи нужны однозначно, это гораздо сложнее для разработчика в реализации, но для пользователя это однозначное благо, т.к. если нет необходимости — этой вложенностью можно и не пользоваться.
То, что у каждого свое видение структуры – есть такое, но это неизбежно, т.к. классическая древовидность предполагает одного родителя у узла дерева.
Вот про поиск и выдачу задач – действительно, не совсем понятно как удобнее выводить пользователю. Но это сложности разработчика. Навскидку – просто выводить рядом путь в дереве. Для большинства случаев хватит за глаза.
Мы тоже работаем над системой управления задачами, в ней постарались реализовать древовидность без каких-либо ограничений. Могу дополнить копилку сложностей всего лишь одним аспектом – разруливание возможных противоречий между родительской задачей и дочерними, если их допускать нельзя. Т.е., к примеру, если в родительской задаче установлены какие-то параметры, то и дочерние должны им соответствовать (если это важно). К примеру, сроки, бюджет, время и т.п. – должны ли сроки подзадач укладываться в сроки родительской и т.п. Аналогичная ситуация, к примеру, с метками задач или их аналогами – должны ли подзадачи их наследовать или нет. У каждого пользователя свои предпочтения.
Ну и по мелочи — у пользователей разное видение того, что должно произойти с подзадачами при выполнении родительской задачи. Кто-то считает, что должны быть автоматически помеченые как выполненные все подзадачи (как в Google Tasks), но это далеко не всем подходит. Аналогичная ситуация с родительскими задачами – что должно произойти при выполнении всех подзадач – должна ли родительская задача стать выполненной?
То, что у каждого свое видение структуры – есть такое, но это неизбежно, т.к. классическая древовидность предполагает одного родителя у узла дерева.
Вот про поиск и выдачу задач – действительно, не совсем понятно как удобнее выводить пользователю. Но это сложности разработчика. Навскидку – просто выводить рядом путь в дереве. Для большинства случаев хватит за глаза.
Мы тоже работаем над системой управления задачами, в ней постарались реализовать древовидность без каких-либо ограничений. Могу дополнить копилку сложностей всего лишь одним аспектом – разруливание возможных противоречий между родительской задачей и дочерними, если их допускать нельзя. Т.е., к примеру, если в родительской задаче установлены какие-то параметры, то и дочерние должны им соответствовать (если это важно). К примеру, сроки, бюджет, время и т.п. – должны ли сроки подзадач укладываться в сроки родительской и т.п. Аналогичная ситуация, к примеру, с метками задач или их аналогами – должны ли подзадачи их наследовать или нет. У каждого пользователя свои предпочтения.
Ну и по мелочи — у пользователей разное видение того, что должно произойти с подзадачами при выполнении родительской задачи. Кто-то считает, что должны быть автоматически помеченые как выполненные все подзадачи (как в Google Tasks), но это далеко не всем подходит. Аналогичная ситуация с родительскими задачами – что должно произойти при выполнении всех подзадач – должна ли родительская задача стать выполненной?
0
UFO just landed and posted this here
Выделили вам как менеджеру большую задачу, а вы уже колупайте её как хотите и раздавайте своим подчиненным. Если у подчиненных есть свои подчиненные, они могут поступать аналогично. Или разбивать задачу на подзадачи чисто для себя и для правильной организации и оценки времени. Не ищите проблем там, где их нет :)
0
Когда пользователям даешь новую фичу с богатым функционалом и простором для воображения, всегда есть период, когда фича используется как попало. По-идее, со временем народ вырабатывает какой-то свой подход ее использования.
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.
+1
Я полагаю иерархия зада становится естественной, если она повторяет другую существующую в проекте иерархию. Скажем у вас есть дерево целей, которое переносится в трекер в виде задач приближенных к корню, а на более глубоких уровнях уже располагается декомпозиция.
Кстати, в youtrack очень простая и удобная иерархия на мой взгляд.
Кстати, в youtrack очень простая и удобная иерархия на мой взгляд.
0
Sign up to leave a comment.
Кому нужны вложенные задачи в системе управления проектами?