В теме 3 ответа, и 4 участника, последнее обновление сделано пользователем 
Sergey.Shimansky 14 г, 6 мес. назад.
-
Сообщения
-
Разработчики работают по задачам в таск-/баг-трекинг системах. QA иногда тоже
.
Что по поводу аналитиков?
Вы лично как аналитик работаете по задачам в таск-/баг-трекинг системе или нет?Да, именно в баг/таск системе.
Заказчик создает в системе задачу, она попадает аналитику. Идет обсуждение с заказчиком, после достижения ими консенсуса — задача переходит девелоперу, после этого — QA-ю. После одобрения QA-я и заказчика задача закрывается.На данный момент работаю в трех баг/таск системах:1) Koyako
2) Track Studio
3) FaZendУ каждой из систем есть свои преимущества и недостатки. Например, мне нравится, что в Koyako и Track Studio клиент моет создать тикет/таск просто написав письмо и отправив его на адрес, заранее установленный для использования баг/таск системой. Ответить на такой тикет так же можно не заходя в систему, а просто ответив на письмо из своего почтового агента (для изменения статуса и назначения тикета на другого сотрудника придется залогиниться, к счастью в теле каждого письма система автоматически прописывает номер тикета). Такой функциональности мне не хватало при использовании MS TFS поправьте меня, если такая функциональность там присутствует.
С системой FaZend я только начал работать и пока не могу полноценно поделиться впечатлениями, единственное, что можно сказать это то, что документирование требований и работа с тикетами в этой системе несколько отличается и не похожа на все остальные, с которыми мне приходилось работать ранее.
Есть опыт работы в Jira. Очень удобный тул с точки зрения координации работ и отслеживания статуса. Вариантов настройки может быть много, в зависимости от выбранной вами методики работы.Например, на разработку функциональной области или модуля заводится таск, напр. "Functional Area". Далее, на каждый юскейс в рамках функц. области, вы заводите сабтаск типа "Use case". Когда аналитик завершил работу над Use case, то переводит его в Review (соотв. изменился статус таска), далее передает в разработку (при этом назначая на конкретного разработчика). Далее разработчик передает в тестирование и т.п.
Документацию (если вы не используете систем контроля версий) можно ранить в виде attachment к таскам. Плюс, есть возможность обмениваться комментариями.Крайне желательно, чтобы с выбранным тулом работала вся команда. Если, например, вы используете Lotus Notes, а разработчики работают в Jira, то им придется прыгать в Lotus Notes, чтобы взять артефакты, посмотреть комментарии и т.п. В данном случае страдает также менеджмент, т.к. не видит целостной картины.
Вы должны авторизироваться для ответа в этой теме.
