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