Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.
Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками. Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу. Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.
Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Здравствуйте, Аноним, Вы писали:
А>Убедите меня, что не стоит этого делать.
А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.
А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
они все так думали...
А>не проще уж написать самостоятельно?
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Если вам достаточно существующих систем и загвоздка только в интерфейсе — нет, не проще.
Если же вам надо что-то особенное (например, поддержку ScrumBut tuned by Vasissualiy Pupkin), можете попробовать озаботиться.
Re[2]: Разработка своей системы управления задачами
От:
Аноним
Дата:
15.11.13 06:24
Оценка:
Здравствуйте, Sharov, Вы писали:
А>>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
S>они все так думали...
Нет, не все. Написать таск-трекер как законченный продукт на продажу — это не то же самое, как написать таск-трекер только для своих конкретных требований, такой таск-трекер действительно довольно примитивен.
Здравствуйте, Аноним, Вы писали:
А>Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками.
Это не совсем правильно — задачи должны сортироваться сами, без вашего вмешательства.
Из опыта — лучше всего работает сочетание двух представлений:
1. Задачи, которые разработчик (менеджер, тестер) забрал себе. Группируются по этапу разработки (итерации), внутри каждой группы сортируются по приоритету и дате изменения.
2. "Общий вид" — все задачи по проекту, сгруппированные по состоянию (очередь разработки, разработка,очередь тестирования, тестирование...), внутри каждой группы сортировка по приоритету + дате изменения.
В траке (в основном работал с ним) это делается очень просто — создаём произвольный запрос, добавляем url в закладки.
А>Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу.
Как минимум в траке настраивается точно.
А>Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время. А>чтобы разработчик видел вообще только свои задачи
Это неправильно. Должен быть общий пул (очередь разработки), из которого разработчики сами забирают себе задачи. Более того, очень часто разработчики берут себе один длинный таск и одновременно закрывают кучу мелких багов — просто потому что большая задача выносит мозг и надо на время переключиться на что-то попроще. Так что даже если учёт времени и есть (в траке записывается время перевода задачи из одного состояния в другое) — это скорее оценка сверху, причём с очень большим запасом.
Если ставить задачу точного учёта времени — надо заводить ещё одно состояние ("Разработка — отложен") и заставлять разработчиков переводить отложенные тикеты в это состояние. На практике в небольших командах это очень неудобно и никто этим не заморачивается.
А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
Они не заточены ни под один из процессов (даже TFS предлагает разные профили). Подгонка остаётся за вами.
А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать. А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Оптимизм никто не запрещал, но я бы потратил время на что-то более полезное
Здравствуйте, Аноним, Вы писали:
А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Пишите.
Знаю компании/отделы, которые написали для себя, либо сильно допилили jira или что-то подобное.
На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).
Здравствуйте, Аноним, Вы писали:
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Пробуй пиши, если есть деньги и не проблема потратить с десяток человеколет.
Может что и получится полезное не только для тебя лично.
А вообще еще не видел не одного проекта, который был бы завален из-за неудобного тула для микроменеджмента,
ценность которого все равно весьма сомнительна.
Та же проблема с тестерами очень проста.
Просто скажите ему что не надо назначать девелоперов.
Делов то... И так во всем. А строить систему управления,
устойчивую к целенаправленному саботажу (тестер ради развлечения меняющий статус багов) — это реально детский сад.
Ну а не понимающего слов тестера можно просто уволить.
Дешевле чем писать свою собственную систему.
А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
Из личного опыта — два раза писал свою систему управления задачами (оба раза до конца и с внедрением), после чего наконец вкурил как устроен процесс в Jira и перешел на нее. О том, что именно я курил можно послушать вот в этом докладе:
Не проще, увы. Вторую версию я три месяца писал, при том что я в целом не самый бесталанный разработчик. Много мелких нюансов, особенно с разрешением конфликтов.
Re[2]: Разработка своей системы управления задачами
Здравствуйте, mtnl, Вы писали:
M>На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).
Это от неправильного выбора инструмента, перфекционизма и общего рукожопия. На Ruby On Rails то что хочет топикстартер делается за 2 недели одним опытным рубистом и одним яваскиптером. Там всего-то пара моделей и три вьюхи, и то 99% фич можно взять готовыми.
Здравствуйте, Аноним, Вы писали:
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Не проще. Вряд ли у тебя есть толковые программисты которые умеют писать быстрые прототипы, скорее всего у тебя обычные кодеры широкого профиля. Значит на разработку даже простейшей системы уйдет 1-2 месяца. Поскольку ты сам не очень представляешь чего хочешь, первая версия не будет работать как должно. В результате закладывай еще 2-3 месяца на вторую версию. Еще несколько месяцев займет внедрение, в результате эффект будет в лучшем случае только через год. Опыт яндекса, джетбрейнс и других контор которые писали свой тасктрекер говорит что год это крайне оптимистичная цифра. Так что можешь писать, дело твое, но я бы рекомендовал изучить дефолтный процесс джиры и работать в точности по нему. В конце концов, его не самые глупые люди делали.
Кстати, посмотри Trello. Приоритезация перетаскиванием там есть.
Дислексия — чума XXI века
Re[3]: Разработка своей системы управления задачами
Здравствуйте, smallpoxlet, Вы писали:
M>>На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).
S>Это от неправильного выбора инструмента, перфекционизма и общего рукожопия. На Ruby On Rails то что хочет топикстартер делается за 2 недели одним опытным рубистом и одним яваскиптером. Там всего-то пара моделей и три вьюхи, и то 99% фич можно взять готовыми.
Там проблема не в том, на чём делается, хотя даже вы показываете человеко-месяц (на каком-нибудь 1С оно пишется ещё быстрее, например),
а в том, что в ходе написания и начала работы с системой вылезает "Много мелких нюансов, особенно с разрешением конфликтов", как уже отметил Eye of Hell, которые влекут существенные изменения, усложенния и кучу переработок.
А дальше начинаются хотелки типа отчетов, кто сколько за месяц отгрузил и т.п.
Re[2]: Разработка своей системы управления задачами
Здравствуйте, Sinix, Вы писали:
S>Это не совсем правильно — задачи должны сортироваться сами, без вашего вмешательства.
ТС говорит не про сортировку, а про выставление приоритетов. А эту операцию действительно лучше выполнять тасуя мышкой карточки, потому что приоритет конкретной задачи зависит не только от нее, а еще и от других задач.
Дислексия — чума XXI века
Re[4]: Разработка своей системы управления задачами
Здравствуйте, mtnl, Вы писали:
M>Там проблема не в том, на чём делается, хотя даже вы показываете человеко-месяц (на каком-нибудь 1С оно пишется ещё быстрее, например),
На 1С этим невозможно будет пользоваться.
M>а в том, что в ходе написания и начала работы с системой вылезает "Много мелких нюансов, особенно с разрешением конфликтов", как уже отметил Eye of Hell, которые влекут существенные изменения, усложенния и кучу переработок.
Это и называется перфекционизм. Менеджеру кажется что стоит вот буквально чуть-чуть допилить и настанет счастье. Программисты все пилят-пилят, а счастье все не настает и не настает. Хоть можно в любой момент забить и пользоваться тем что есть.
M>А дальше начинаются хотелки типа отчетов, кто сколько за месяц отгрузил и т.п.
В одной из контор мы как-то написали себе CRM. Сейлзы сразу же начали просить всякие фишечки и отчетики. Хорошо мы догадались прикрутить CRM к экселю в качестве провайдера данных и добились моратория на дальнейшие изменения без ТЭО. Работает до сих пор, всех устраивает.
Дислексия — чума XXI века
Re[3]: Разработка своей системы управления задачами
Здравствуйте, smallpoxlet, Вы писали:
S>ТС говорит не про сортировку, а про выставление приоритетов. А эту операцию действительно лучше выполнять тасуя мышкой карточки, потому что приоритет конкретной задачи зависит не только от нее, а еще и от других задач.
А, тогда нужно что-то типа http://trac-hacks.org/wiki/QueuesPlugin
Re[4]: Разработка своей системы управления задачами
S>>ТС говорит не про сортировку, а про выставление приоритетов. А эту операцию действительно лучше выполнять тасуя мышкой карточки, потому что приоритет конкретной задачи зависит не только от нее, а еще и от других задач. S>А, тогда нужно что-то типа http://trac-hacks.org/wiki/QueuesPlugin
Или structure для Jira. До 10-и пользователей копейки стоит.
Re[5]: Разработка своей системы управления задачами
Здравствуйте, smallpoxlet, Вы писали:
EOH>>Или structure для Jira. До 10-и пользователей копейки стоит.
S>А для 11 уже $600, это известная разводка.
В чем разводка-то? На странице цен об этом написано...
Больше 10 человек на продукте — это уже что-то довольно большое, для которого 600 баксов не слишком много
S>При том что за следующую версию придется заплатить столько же.
Вроде 50% за апгрейд. К тому ж можно сидеть на старой версии и не апгрейдиться
Здравствуйте, Аноним, Вы писали:
А>Убедите меня, что не стоит этого делать.
А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.
А>Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками. Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу. Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.
А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Здравствуйте, enji, Вы писали:
E>В чем разводка-то? На странице цен об этом написано...
Что-то я не видел чтобы там было написано что заблокированный пользователь считается как настоящий.
E>Больше 10 человек на продукте — это уже что-то довольно большое, для которого 600 баксов не слишком много
Давай посчитаем: 1 служебный пользователь для интеграции с VCS и CI, 1 ПМ, 1 сисадмин, 2 фронтендщика, 2 бэкендщика, 2 тестера, 1 дизайнер. Это очень-очень небольшой вебный проект. Если таких проектов больше одного или мы хотим включить в команду контенщика шансов уложиться в 10 пользователей нет никакого.
Здравствуйте, Аноним, Вы писали:
А> Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.
Предположим, разработчик обновил состояние бага/задачи после сабмита, а не тогда, когда начал над ней работать. В результате, автоматически подсчитанное время равно 0. Что из этого воспоследует?
Предположим, разработчик научился обновлять статус задачи вовремя, и время, потраченное на задачу, считается автоматически правильно. Как это помогает Вам лучше управлять проектом? Например, добиваться того, чтобы проект был закончен к определённой дате?
