Сообщений в теме: 14

[TatianaS]

Здравствуйте, коллеги.

Назрели у нас в компании две острых необходимости.

1. В отделе QA очень не хватает системы работы с задачами.
Хочется пока малого - хранить все задачи в одном месте, оценивать время и смотреть за сколько выполнили задачу сотрудники, видеть что каждый сотрудник сделал за день. Возможно, в будущем, понадобится что-то еще, когда начнем работать по этой схеме.

2. Планируется расшарить процесс работы с задачами между всеми отделами (художники + 2 отдела программистов). Тогда уже нужна, возможно, какая-то иерархия - руководитель дает общую задачу, эта общая задача разбивается на подзадачи для отделов, в отделах уже каждый руководитель пишет задачи на конкретных сотрудников. Нужна такая система, что бы увидеть какой отдел задерживает выполнение главной, общей задачи. Понять почему это происходит и чего не хватает в отделе, или в руководителе или в процессе.

БОльших и более четких требований у меня нет.

Из ПО, у нас Team Foundation Server и sharepoint.
Первый вариант - слишком громоздкий, с ним надо слишком долго разбираться. Но пока нет более четкого представления о том как мы будем с тасками работать - не вижу смысла TFS использовать.
Второй вариант - легкий, легко настраиваемый, но и практически никаких возможностей (правда, пока не глубоко его смотрела) для второй части работ. Но зато его можно начать использовать уже завтра, и по ходу действий добавлять нужные поля, менять правила работы с задачами и прочее.


К вам обращаюсь по двум поводам.
Собственно, возможно, вам есть что сказать по поводу моих мыслей и по поводу того, как у вас организовывалась работа с задачами.
И, может быть, кто-нить поделится материалом (ссылки на бумажные книжки, статьи в инете) о жизненном цикле задач. Пробовала сама искать - почти все - сплошь реклама каких-нить программ для работы с задачами. Статей полезных не нашла.

Понимаю, что надо начать работать с задачами, а дальше уже по хожу работы станет понятней, что еще нужно. Но хочется узнать как у других, как может быть иначе.

[LeshaL]

Привет!

Когда-то, еще на предыдущей работе, проводил исследование бесплатных тулов для трэкания тасков.
Наиболее понравившейся оказался такой тул - Request Tracker
http://bestpractical.com/rt/
В результате мы с успехом его использовали.

Все что вы хотите он умеет и 1 и 2.
Раньше (а это было >3х лет назад) ставился только на линукс, но вроде бы сейчас написано, что можно и под винды. При установке, помню, были шаманские танцы с бубном, но думаю, что за 3 года они должны были много чего поравить.

[Alfa]

Соглашусь с предыдущим оратором.
То, что Вам нужно это Issue tracking.

Могу лишь предложить еще несколько инструментов:
Bugzilla - бесплатный широко распространенный, можно использовать не только как bug tracking, но и как Issue tracking систему
Jira - платный, но относительно (других) дешевый, недавно как раз такое использование jira обсуждалось на форуме тут:
http://software-test...w...ost&p=49451

В принципе, в качестве Issue tracking можно использовать практически любую продвинутую bug tracking систему, зависит от Вашего вкуса.

[maximkr]

Здравствуйте, коллеги.

Назрели у нас в компании две острых необходимости.

1. В отделе QA очень не хватает системы работы с задачами.
Хочется пока малого - хранить все задачи в одном месте, оценивать время и смотреть за сколько выполнили задачу сотрудники, видеть что каждый сотрудник сделал за день. Возможно, в будущем, понадобится что-то еще, когда начнем работать по этой схеме.

2. Планируется расшарить процесс работы с задачами между всеми отделами (художники + 2 отдела программистов). Тогда уже нужна, возможно, какая-то иерархия - руководитель дает общую задачу, эта общая задача разбивается на подзадачи для отделов, в отделах уже каждый руководитель пишет задачи на конкретных сотрудников. Нужна такая система, что бы увидеть какой отдел задерживает выполнение главной, общей задачи. Понять почему это происходит и чего не хватает в отделе, или в руководителе или в процессе.

БОльших и более четких требований у меня нет.

Первый пункт есть почти у всех bug/issue tracking систем. Единственный туманный момент - учет времени, особенно если требуется учет времени по видам деятельности в рамках каждой задачи (сколько ушло на исправление ошибок, а сколько на тестирование) и по проектам (сначала считаем затраты по задачам, потом на их основе считаем затраты по проектам и т.д.).

По второму пункту все хуже: обычно в issue tracking системах очень плохо с поддержкой иерархий, а в project management (где иерархии есть) - с поддержкой workflow. Я когда-то писал по этому поводу небольшую статью, посмотрите тут:
http://www.trackstud...issue-1685.html

и далее по ссылкам.

[greesha]

Если весь QA расположен в одном помещении, или хотя бы в соседних комнатах, для начала я бы предложил Task Board (в смысле, настоящую доску с бумажными наклейками).

http://agilerussia.r...m...0&Itemid=29

После того, как я повесил Task Board в нашей комнате, мы практически перестали использовать наш трекер для ежедневного/еженедельного планирования, а перевели его на учёт более объёмных и длительных задачи.

[TatianaS]

Если весь QA расположен в одном помещении, или хотя бы в соседних комнатах, для начала я бы предложил Task Board (в смысле, настоящую доску с бумажными наклейками).

http://agilerussia.r...m...0&Itemid=29

После того, как я повесил Task Board в нашей комнате, мы практически перестали использовать наш трекер для ежедневного/еженедельного планирования, а перевели его на учёт более объёмных и длительных задачи.

Это больше подходит для маленьких команд, имхо.
Только QA у нас - 7 человек. Вместе с другими командами, которые мы надеемся потом подключить к работе с тасками вообще человек 20 наберется. Да и с другими отделами одной расшаренной доски будет мало. А еще не хочу, что бы сотрудники видели таски друг друга.
У меня гигантский список задач - одни задачи быстрые и по ходу работы, другие задачи - "как-нибудь когда-нибудь хорошо бы сделать, как время будет". Наклейки у меня как с монитора по осени отлипают, так и с доски опадут :)

Мне очень нравится идея с наклейками - она веселая и так работать приятно. Но не очень надежная, на мой взгляд :)

[LeshaL]

...А еще не хочу, что бы сотрудники видели таски друг друга.

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

[grr~]

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

[Offtop]

...А еще не хочу, что бы сотрудники видели таски друг друга.

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

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.
В моем проекте данные по таск трекингу доступны всем его участникам, кстати, неплохой мотивационный фактор для новичков - есть ориентир по перфомансу.

[Alfa]

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

Это пока у вас одно неудобство, дальше больше. Зачем изобретать велосипед? Когда и так все написано: бесплатное, платное, такое, другое. Бери и пользуйся.
Все-таки трэкер - это совершенно отдельная вешь и реализовывать ее на таблицах ... Успех сомнителен.

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.
В моем проекте данные по таск трекингу доступны всем его участникам, кстати, неплохой мотивационный фактор для новичков - есть ориентир по перфомансу.

Не понимаю зачем скрывать задачи от людей, которые делают общее дело. Если мне надо будет узнать, что делает(делал) коллега, то как тогда? Как обмениваться опытом? Как видеть глобальную цель?

[LeshaL]

...Не надо скрывать таски одних сотрудников от других....

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.

Извините, но мне тоже не понятно какие есть плюсы в ситуации, когда таски скрыты от других участников рабочего процесса. Могли бы вы привести их?
Вопрос без подвоха, т.к. на самом деле интересно. Единственная ситуация, которую я придумал - когда в компании разрабатывается сверхсекретный продукт. В такой ситуации, вполне допускаю, что _все_ не дожны видеть чужие таски. Но, все-равно, те кто над этим секретным проектом работают, скорее всего должны знать, кто чем занимается в команде.

[TatianaS]

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

Это пока у вас одно неудобство, дальше больше. Зачем изобретать велосипед? Когда и так все написано: бесплатное, платное, такое, другое. Бери и пользуйся.
Все-таки трэкер - это совершенно отдельная вешь и реализовывать ее на таблицах ... Успех сомнителен.

Понятно, что лучше выбрать готовое ПО, но тогда получится - тестовые наборы в TFS, требования в sharepoint, багтрекер тоже отдельный, а теперь еще и для тасков надо свое ПО искать - выбирать, устанавливать, настраивать. А зачем, если я еще не знаю как у нас пойдет?
Потому и искала какие-нить статьи - хоть бы узнать какие статусы люди используют, как связывают таски между собой - по багам много такого можно найти, а вот по таскам нет.

Потом, если вдруг на таски перейдет вся компания, то, тогда уж стоит все в одном месте объединить - багтрекер, слежение за требованиями, таски и пр.

[grr~]

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

Это пока у вас одно неудобство, дальше больше. Зачем изобретать велосипед? Когда и так все написано: бесплатное, платное, такое, другое. Бери и пользуйся.
Все-таки трэкер - это совершенно отдельная вешь и реализовывать ее на таблицах ... Успех сомнителен.

Если отталкиватся от того что есть, можно использовать шарепоинт. Если есть возможность - ставить таск трекер.

...Не надо скрывать таски одних сотрудников от других....

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.

Извините, но мне тоже не понятно какие есть плюсы в ситуации, когда таски скрыты от других участников рабочего процесса. Могли бы вы привести их?
Вопрос без подвоха, т.к. на самом деле интересно. Единственная ситуация, которую я придумал - когда в компании разрабатывается сверхсекретный продукт. В такой ситуации, вполне допускаю, что _все_ не дожны видеть чужие таски. Но, все-равно, те кто над этим секретным проектом работают, скорее всего должны знать, кто чем занимается в команде.

Скрывание тасков в ситуации со секретным проектом - это не плюс, обычно в таких проектах люди понимают степень ответственнтсти, тажке их ограничивают котнрактные обязательства. И при достаточном количестве мотивационных факторов на приватность тасков всем по большому счету просто плевать.

Из плюсов, могу отметить только два, все остальные могут появится только в определенных условиях:
+ Нет ориентира для других сотрудников в виде медленной\плохой работы
+ Меньшая вероятность утечки информации

[LeshaL]

+ Меньшая вероятность утечки информации

Именно это я имел ввиду, когда писал о секретном проекте.

[rlabs]

Понятно, что лучше выбрать готовое ПО, но тогда получится - тестовые наборы в TFS, требования в sharepoint, багтрекер тоже отдельный, а теперь еще и для тасков надо свое ПО искать - выбирать, устанавливать, настраивать. А зачем, если я еще не знаю как у нас пойдет?
Потому и искала какие-нить статьи - хоть бы узнать какие статусы люди используют, как связывают таски между собой - по багам много такого можно найти, а вот по таскам нет.

Потом, если вдруг на таски перейдет вся компания, то, тогда уж стоит все в одном месте объединить - багтрекер, слежение за требованиями, таски и пр.

Есть мнение, что написать свое средство для интеграции нескольких продуктов вам будет проще, чем найти комбайн всё-в-одном, удовлетворяющий всем требованиям.

[Alfa]

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

Если вы искали какие-нибудь статьи то могу посоветовать вот эту статью.

Там подробно описывается что используют и как.
Доклад по этой статье был сделан на SECR-2007, вызвал бурное обсуждение.