Перейти к содержимому

Публикации maximkr

21 публикаций создано maximkr (учитываются публикации только с 29 марта 2023)


#59508 Управление билдами в JIRA.

Отправлено автор: maximkr 08 августа 2008 - 08:41 в JIRA issue tracker

Но всё-таки JIRA плохо подходит. Вот если бы версии были древовидными...


Это потому, что JIRA в первую очередь для общения с клиентами делалась, а уж внутренняя кухня разработчиков - как получилось. А клиентам разбираться с глубокими деревьями версий/проектов сложно, особенно если они багтрекер в первый и последний раз видят.



#57851 Принципиальная разница между Severity & Priority

Отправлено автор: maximkr 27 июня 2008 - 12:28 в Тест-дизайн и ручное тестирование

После этого багтрекер на основе всей этой информации вычисляет приоритет ("вес" мнения у разных участников процесса может быть разным) и все участники процесса должны ориентироваться именно на этот вычисленный приоритет.

То есть вместо того чтобы полагаться на одно решение, вносим фактор ошибки многих решений. Бр-р-р.


Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

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

В качестве примера - посмотрите приоритеты багов по JIRA 3.12.x. Там critical-ом оказалась "Unclear error message when bulk moving issues whose reporter cannot create issues", а что-нибудь типа "Moving portlet up reults in IndexOutOfBoundsException" оказалось minor.

Ситуация, когда все подряд назначают "своим" багам приоритет повыше, конкурируя за время команды похожа на "трагедию общих ресурсов":
http://www.seed.slb....nge/tragedy.htm

===
Термин трагедия общих ресурсов появился в 1968 году в статье Гаррета Хардина. Он считает, что проблемы, попадающие под эту категорию, технически решения не имеют. Они требуют изменения поведения и привычек человека.
...
Проблема в том, что большинство из нас действует лишь в собственных интересах, желая получить немедленный эффект. Но потери от влияния этих действий на климат планеты мгновенно не ощущаются. Я могу ездить на большом автомобиле, потому что мне так удобно. Дискомфорт от повышения уровня моря или количества штормов может появиться лишь через несколько десятилетий. Я не вижу прямой взаимосвязи между своими действиями и этими последствиями. Фактически, если бы на большой машине ездил один человек, то негативных последствий не было бы. Так же и пастух, который добавляет одну овцу к стаду – преимущества очевидны и мгновенны, в то время как потери пространны и растянуты по времени. Когда все пастухи поступают так, то в результате в проигрыше оказываются они вместе.

Решение требует взаимодействия людей, вместе принимающих решение об изменении поведения всех, включая себя.
===



#57849 Принципиальная разница между Severity & Priority

Отправлено автор: maximkr 27 июня 2008 - 11:29 в Тест-дизайн и ручное тестирование

Описанная система не отвечает на вопрос: что делать в случае, когда багов сотни? Да, вы получите более тщательную разбивку по весам, но в каждом весе опять будет несколько десятков багов.


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



#57814 Принципиальная разница между Severity & Priority

Отправлено автор: maximkr 26 июня 2008 - 19:26 в Тест-дизайн и ручное тестирование

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

Ситуация: в компании есть какое-то количество проектов со своими менеджерами, внутреннее руководство, внешние клиенты, и разработчики, которые все это разгребают. Но чтобы назначать приоритет (фактически, порядок выполнения задач), менеджер должен иметь список всех задач конкретного разработчика и потом указывать - сначала это, потом то. А для этого менеджер проекта должен знать, что на разработчике висит по другим проектам, насколько эти другие проекты важны, какие клиенты стоят за этими багами и насколько они важны. Если задач в проекте сотни и тысячи - уследить за этим по каждой задаче просто не реально. В итоге это может приводить к ситуации, когда:
- клиенту надоело ждать и он ставит всем багам максимальную важность
- тестировщика давно нервирует какой-то баг и он старательно ставит ему максимальную важность
- большой начальник накануне релиза поигрался 30 минут с продуктом и он ставит максимальную важность тем проблемам, которые нашел сам, не особо вникая в остальные

Обычно это приводит к тому, что у очень большого кол-ва задач становится максимальный приоритет, или разработчики вообще забивают на приоритеты в трекере и планируют по своему усмотрению.

Решение: нужно дать возможность высказаться каждой стороне в своем отдельном поле. Т.е. пусть клиент выставляет поле Severity как ему хочется, большое начальство - выставляет приоритет целым проектам, саппорт - заполняет поле "важность" для клиента, менеджер продукта - оценивает насколько ему удобно исправлять это прямо сейчас. После этого багтрекер на основе всей этой информации вычисляет приоритет ("вес" мнения у разных участников процесса может быть разным) и все участники процесса должны ориентироваться именно на этот вычисленный приоритет.

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

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



#55389 Перспективы TestComplete

Отправлено автор: maximkr 15 апреля 2008 - 08:08 в SmartBear (AutomatedQA) - Functional Testing

Интересное обсуждение. По поводу суперпопулярности weblogic/websphere - мы году в 2000 круто попались на эту удочку :-) До того мы занимались заказной автоматизацией, преимущественно Weblogic/ORACLE, поэтому первые версии TrackStudio работали исключительно под WebLogic/ORACLE - это же (теоретически) очень популярная платформа. Так вот, пока не сделали поддержку других СУБД и контейнеров типа Tomcat (на это ушло еще полгода) - продажи были 0 целых 0 десятых.

Если смотреть на нынешних клиентов (а среди них стартапов - процентов 10, наверное, им подобные системы просто не нужны), то
- в качестве сервера приложений большинство используют Tomcat или Jetty, дорогие коммерческие сервера (weblogic/websphere/etc) - процентов 10 клиентов.
- По СУБД - в процентном отношении ORACLE используется российскими клиентами раза в 3 чаще, чем у иностранцев. Есть несколько инсталляций на мэйнфреймовой DB2, а все остальное - MS SQL Server, mysql, PostgreSQL, дефолтный HSQLDB.

С чем связана такая разница между нашими данными и официальной статистикой - я точно не знаю. Версий 2:
- при оценке популярности дорогих продуктов их сравнивают между собой, какое соотношение инсталляций ORACLE и PostgreSQL никого не интересует.
- ORACLE используется для тяжелых продуктов типа SAP, где без ORACLE совсем нельзя. Все остальное стараются туда не ставить чтоб не грузить лишний раз БД, не иметь проблем с доступом к БД для апгрейдов/ручной правки.

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

На западе ситуация во-многом отличается. Если у той же Serena, например, 3000 клиентов TeamTrack, то только 3000 человек в мире (админы) понимают как подобные системы настраивать и что там нужно крутить, это капля в море. У большинства иностранных клиентов опыт разве что с bugzilla и (реже) mantis, изучение TrackStudio идет тяжело. Хотя в последние годы ситуация улучшилась (наверное, из-за популярности JIRA), вопросы типа "а зачем нужен настраиваемый workflow и иерархия задач" у пользователей возникают на порядок реже.



#54272 помогите подобрать багтрекинговую систему

Отправлено автор: maximkr 21 марта 2008 - 19:07 в Инструменты управления тестированием ПО

Когда-то работал с PVCS Tracker-ом. Очень нравился. Похоже у продукта не легкая судьба с тех пор.
Вот нашел http://pvcs.synergex...cker_specs.aspx
В то время он работал только под виндой и вроде бы только с MS SQL.


А я думал что он уже того... Несколько лет назад Serena купила TeamShare TeamTrack за $11M, купила (?) PVCS и занималась мигрированием клиентов с PVCS на TeamTrack.
Судя по вот этой страничке, PVCS Professional Suite теперь в качестве issue tracker-а использует именно TeamTrack.

А вот имеет ли какое-нибудь отношение PVCS Version Manager к старому PVCS - не знаю.



#54250 помогите подобрать багтрекинговую систему

Отправлено автор: maximkr 21 марта 2008 - 13:21 в Инструменты управления тестированием ПО

Добрый день! я тоже новичок в системах баг трекинга, и мне на рабте как раз дали задание, наити ниболее подходящую, ине очень дорогую систему баг трекинга.
По поводу Borland StarTeam - я искал в интернете, и нашёл вт такую ссылку: http://www.securityl...lity/347882.php
Врде как получается, что Borland StarTeam какой-то уязвлённый....
Не подскажите, какие бывают вообще баг трекинги и какие из них лучше? (Про Borland StarTeam я понял и мне он тоже нравится, тем более, что я имел счастье с ним работать.).
З.Ы. Хотелось бы услышать ваши отзывы таже о Клир Квест.


TrackStudio посмотрите. Русская БД/интерфейс, русский саппорт (в моем лице, в основном), возможности сравнимы с ClearQuest, но стоит гораздо дешевле



#54200 Набор ПО для организации процесса

Отправлено автор: maximkr 20 марта 2008 - 22:36 в Управление проектами

У меня сложилось устойчивое мнение, что при организации процесса разработки выбор инструментов нужно производить в последнюю очередь. Так, чтобы инструменты не навязывали кем-то заложенную в них модель разработки, а наоборот, адаптировались под работающую модель. А вот эту модель как раз и нужно описать, и это и есть самая трудная задача.


По этому поводу есть сейчас 2 противоположных мнения:

1) Нужно сначала выбрать модель, а потом под нее выбирать инструмент, реализующий эту модель. В этом случае переход от "неправильной" модели к "правильной" происходит за один большой шаг. Гибкость инструмента тут абсолютно не нужна, т.к. методология считается безусловно правильной и чем точнее инструмент заставит ее соблюдать - тем лучше.

2) Автоматизируем бардак, потом смотрим что получилось, потом меняем настройки системы, опять анализируем и т.д. В данном случае методология не так важна, т.к. инструмент должен уметь настраиваться на любые процессы и позволять менять процессы в ходе работы.

Т.е. в первом случае мы подгоняем процессы под требования методологии и инструментов, а во втором - подгоняем инструменты под свои нужны. Первый подход хорош для быстрого тиражирования не самых плохих методик на большое количество сотрудников, второй - для поиска "своего пути".

Если инструмент заточен под конкретный процесс - анализировать текущую модель смысла нет, ведь ее все равно придется заменять и избавляться от нестандартных для новой модели процессов. А если система позволяет настраивать (и перестраивать) процессы, то нет необходимости все анализировать и делать идеально с первого раза - вполне можно двигаться мелкими шагами. Думаю, главная проблема тут в том, что многие инструменты (особенно open source) заточены под вполне конкретную модель разработки, но никак ее явно не описывают. Если и собственные процессы никак не описаны - выбрать конкретный продукт может быть очень сложно.

Naumen несколько лет назад пыталась сделать продукт для автоматизации процессов на основе нескольких open source проектов, потом проект закрыли, вот выводы одного из разработчиков:
===
1. Причины остановки проекта
Прекращение внешнего финансирования только одна из причин. В конце концов проект могли развивать и "для себя"...
Дело в том, что "подспудной идеей" проекта была мысль: "Давайте возьмем все лучшие фриварные средства управления проектами и поинтегрируем в одну систему... должно получиться круто."
С большим или меньшим гемороем, задача была решена. Но! Выяснилось, что все эти "лучшие средства" имеют очень четко выраженные _иделогии_ и методологии (если хотите — свой собственный "миф" о том что такое есть "разработка софта"). И разумеется, эти "мифы" — разные.
Таким образом, сумма хороших инструментов... не оказалась удобным инструментом (ибо не понятно, по какой методике вести в ней разработку).
===



#52540 Сравнение баг-трекинг систем

Отправлено автор: maximkr 06 февраля 2008 - 11:40 в Инструменты управления тестированием ПО

Макс, карточки они используют в качестве "пособий по наглядной агитации". Через Jira все у них трекается.


Предлагаю всем заинтересованным лицам прочитать описание их внутреннего процесса от первого лица и решить самим, ссылки я давал :-) Мне их процесс показался довольно интересным, хотя и странным.



#52496 Сравнение баг-трекинг систем

Отправлено автор: maximkr 05 февраля 2008 - 13:26 в Инструменты управления тестированием ПО

Все-таки, я останусь при своем мнении. Мнение таково, что да, багзилла ущербна, но и этого достаточно чтобы смогла работать небольшая команда. И она точно лучше, трэкатья багов письмами, бумажными карточками или в excel-e.


Кстати, не факт :-) Jira уж точно не хуже bugzilla, а в Atlassian используют именно бумажные карточки для автоматизации внутренних процессов, о чем они сами неоднократно писали. Можете посмотреть переписку тут и далее по ссылкам.



#52463 Сравнение баг-трекинг систем

Отправлено автор: maximkr 05 февраля 2008 - 08:19 в Инструменты управления тестированием ПО

Максим, а разве в багзилу мало денег вбухали? Я думаю не мало. Причем ее выбирают и используют. Теже создатели еклипса, например. И на тигрис-е, завуалировав под названием issue-tracker и слегка поменяв шкурку.


Тут моменты такие:

1) tigris, eclipse - проекты довольно старые, багзилла там используется давно. А году в 2000 bugzilla была не столь уж морально устаревшей (многие коммерческие багтрекеры, которые написали в те годы просто копировали функциональность bugzilla с другим интерфейсом), perl был гораздо более живой, и т.п.

2) Если у вас коммерческий продукт/проект - не стоит ориентироваться на то, какую систему выбрал такой-то open source проект, у них другие цели и проблемы. Для open source проектов характерно большое количество "случайных" пользователей и простые/неформальные внутренние процессы, соответственно багтрекер для open source проекта обязан быть максимально простым для случайного пользователя, обязан иметь анонимный доступ, желательно уметь ставиться на недорогой хостинг. Т.к. open source багтрекеры писались в первую очередь "для своих", то неудивительно, что они удовлетворяют этим требованиям.
Issue tracker для коммерческих проектов - это в первую очередь средство организации работы _внутри_ команды, тут важна поддержка ролей, возможность создания задач с разными workflow, настройка прав пользователей, интеграция с LDAP, учет почасовой оплаты и т.п. У разработчиков open source проектов таких проблем никогда не было, поэтому эти возможности в open source багтрекерах традиционно поддерживаются в последнюю очередь и довольно плохо.

3) Есть такая книжка Брукса - "Мифический человеко-месяц". Одна из идей там - чтобы проект жил долго и хорошо развивался, нужно чтобы архитектуру/ядро системы разрабатывало минимальное количество людей, а остальные разработчики им бы помогали ("операционная бригада"). Для многих некоммерческих open source проектов это объективно сложно сделать - ключевые разработчики могут заниматься проектом максимум несколько часов в день (где-то еще работать надо), а патчи от сторонних разработчиков приходится принимать, даже если они не вполне вписываются в архитектуру системы (иначе прогресс вообще остановится). Если за open source продуктом стоит компания, которая может нанять на fulltime ключевых разработчиков и платить за реализацию конкретных фич - все становится гораздо проще. Если open source продукт - это реализация стандарта (например, XML) - все еще проще.

Итого: даже полное переписывание багзиллы вряд ли позволит сделать из нее хотя бы бесплатный аналог Jira, для этого им сначала нужно найти деньги и стать commercial open source. Даст ли под нее кто-нибудь денег сейчас (не зависимо от того, сколько и кто вложил до того) - не уверен.

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


Если бы я был ограничен только open source продуктами, то начал бы смотреть с Trac. А скорее всего попробовал бы вытрясти с руководства немного денег: все-таки для софтверной компании issue tracker - ключевой продукт, а самое дешевое и самое популярное - не всегда самое подходящее (пример - Жигули). Никому же не приходит в голову идея вести бухгалтерию магазина на open source продуктах, хотя какие-то продукты есть :-)

И еще, текст, на которую вы ссылаетесь - мысли вслух какого-то человека, живущего в маунтин вью. Возможно он девелопер мозиллы. Но написаное в его личном блоге не может быть официальной информацией, не так ли? А может все так и есть, как там написано.
Надо бы вот тут посмотреть, если там конечно есть чего-нить интересное http://wiki.mozilla....ugzilla:Roadmap


А вот страница с описанием перспектив переписывания багзиллы на разные языки, вполне себе "официальная". Но я вообще не представляю себе, как можно багзиллу переписать - ведь все пользователи багзиллы по команде не перейдут на новый продукт, кто-то будет продолжать использовать старую багзиллу, править глюки и вносить доработки. Какой-бы язык программирования они не выбрали - не все нынешние разработчики поддержат выбор, не все этот язык будут знать, так что команда разработчиков будет в значительной степени другая.
Повторять в новой багзилле тот же пользовательский интерфейс и те же проблемы с функциональностью и конфигурированием - тоже никакого смысла.

Т.е. "переписать багзиллу на другом языке" - это значит запустить новый проект с другим названием, другими разработчиками, другим продуктом. Но таких продуктов уже есть десятки, шансов что новая багзилла будет значительно лучше их всех - никаких, о причинах я писал выше.



#52447 Сравнение баг-трекинг систем

Отправлено автор: maximkr 04 февраля 2008 - 20:48 в Инструменты управления тестированием ПО

Это Bugzilla, в обоих случаях. Вероятно просто кастомизированная - код ведь открыт.
Открытость кода и значит возможность его изменять (подстраивать под себя) и есть одно из преимуществ Bugzilla (да я знаю что Jira отдает код в продвинутых конфигурациях).


1. Atlassian отдает код Jira отдает во всех конфигурациях.
2. JRA-1330 показало, что даже наличие исходного кода, 100+ разработчиков, миллионы долларов оборота и прочее не может помочь с решением проблемы, если о ней не подумали 5 лет назад. Проблемы bugzilla куда более серьезные и застарелые.

В общем я бы не надеялся на открытый код как на большое преимущество. Собственно, из ссылки в моем первом посте понятно, что разработчики bugzilla и не надеются - они там подробно описывают причины.



#52446 Сравнение баг-трекинг систем

Отправлено автор: maximkr 04 февраля 2008 - 20:39 в Инструменты управления тестированием ПО

Мне кажется, вы не учитываете того факта, что bugzilla при всех ее недостатках - бесплатная.

Я ни разу не адепт фриварных идеологий, но в случае с Багзиллой всё-таки выскажусь :) Ну её нафиг с её бесплатностью - более куцого внешне решения я не видел и работать с ней бр-р-р-р :) ИМХО.

А если у организации нет 1-1.5к на покупку годовой лицензии для инструмента чендж-риквест-менеджмента, это уже в топку :) Опять-же ИМХО.

Готовьте топку, топите печку - вот вам парочка кандидатов:
https://bugs.eclipse..._bug_wizard.cgi
http://subversion.ti...ssues/query.cgi
Ишью-трэкер, не багзила - но по функциональности ровно тоже самое.

Да и маленькие стартапы, не будут тратить 1.5К. И правильно сделают. На 10 человек - багзилы достаточно.


А зачем багзилла ? Есть много более приличных open source продуктов, тот же Trac.
Думаю, из вот этого списка набрать штук 20 бесплатных/недорогих систем будет несложно. Если они перепишут bugzilla на другом языке - чем новая багзилла будет лучше всех этих систем ?



#52444 Сравнение баг-трекинг систем

Отправлено автор: maximkr 04 февраля 2008 - 20:30 в Инструменты управления тестированием ПО

Если у Jira появится бесплатный конкурент - который имеет примерно туже самую функциональность - кому грозит смерть или забвение?


Бесплатному конкуренту, естественно. Нужно ли аргументировать?

Конечно же нужно. У меня другое мнение.
Взять хотя бы eclipse, появление которого сделало нецелесообразным разработку некоторых комерческих IDE.


Ну, за eclipse стоит IBM, они ее очень активно продвигали на всяких мероприятиях. Я про eclipse впервые узнал именно из такого IBM-овского семинара из уст какого-то большого начальника по Sales, они там говорили, что вбухали в этот продукт очень много денег. C bugzilla ситуация совершенно иная - продукт явно старый и бесперспективный, зачем кому-то тратить много денег на его переписывание - не понятно.



#52390 Сравнение баг-трекинг систем

Отправлено автор: maximkr 04 февраля 2008 - 11:20 в Инструменты управления тестированием ПО

Да мне нужны именно преимущества Тесттрак.Если у кого то они есть буду очень признательна.


Ну, наличие workflow - это очень важное преимущество, это же основа подобных систем. А по поводу bugzilla почитайте блог ее разработчиков:
http://avatraxiom.li....com/58084.html
===
Nowadays, almost all of our competitors have one advantage: they are not written in perl. They can actually develop features more quickly than we can, not because of the number of contributors they have, but because the language they're using allows it. There are at least two bug-trackers that I can think of off the top of my head that didn't even exist in 1998 and were developed rapidly up to a point where they could compete with Bugzilla.
...
In 1998, Perl was the right choice for a language to re-write Bugzilla in. In 2007, though, having worked with Perl extensively for years on the Bugzilla project, I'd say the language itself is our greatest hinderance.
...
Without taking some action, I'm not sure how many more years Bugzilla can stay alive as a product.
===

Они там собираются переписать bugzilla на каком-нибудь другом языке, мотивируя тем, что без этого проект может скоро помереть. Но и переписывание bugzilla на другом языке - это тоже смерть проекту, т.к. реализация тех же идей (со всеми плюсами и минусами) на другом языке программирования уже есть - это Jira.

А вообще попробуйте отписать в seapine, им такие вопросы должны через день приходить.



#52370 Русификация JIRA

Отправлено автор: maximkr 03 февраля 2008 - 13:07 в JIRA issue tracker

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


Насколько я помню, в JIRA language-файлы позволяли перевести только интерфейс обычного пользователя с некоторыми исключениями, интерфейс администратора перевести было нельзя. Как делать перевод плагинов - не понятно. Перевод базы (названия групп пользователей, состояний) через language-файлы не сделаешь, нужно будет таскать локализованный вариант БД. Ну и русскому интерфейсу хорошо бы еще русский мануал и русский саппорт, иначе пользователям придется самим догадываться, какая ссылка в русском интерфейсе соответствует "resolve bug", например.



#52320 Русификация JIRA

Отправлено автор: maximkr 01 февраля 2008 - 12:51 в JIRA issue tracker

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


А почему "кастомеры ее тоже используют" - аргумент ? Почему нельзя локальным разработчикам использовать русскую версию интерфейса, а кастомерам - английскую ? Тем более что возможность перевода состояния/действий там была.



#51055 Жизненный цикл задач (tasks)

Отправлено автор: maximkr 26 декабря 2007 - 20:36 в Управление проектами

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

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

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

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

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


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

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

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



#49454 Jira - не только баг-трек система ?

Отправлено автор: maximkr 26 ноября 2007 - 08:16 в Инструменты управления тестированием ПО

Ну, в самой компании Atlassian система JIRA (фактически) не используется для багтрекинга, а скорее именно как helpdesk. Обсуждение сего примечательного факта с одним из работников Atlassian тут:
http://maximkr.livej...l.com/8942.html

JIRA вполне можно использовать для help desk или bug tracking, но не для того и другого одновременно. Почему - почитайте JRA-1330, там пользователи JIRA детально рассказывают:
http://jira.atlassia...browse/JRA-1330



#47266 пРОект как подпроект

Отправлено автор: maximkr 03 октября 2007 - 09:11 в JIRA issue tracker

Не совсем понятен вопрос...
Поясните пожалуйста (если еще актуально).


Видимо, речь идет об иерархии проектов - общем виде этого в JIRA нет и, вероятно, не будет. А вот найти workaround для конкретной проблемы, наверное, можно.
saezar, расскажите пожалуйста зачем это нужно и для чего Вы это собираетесь использовать.



#46716 пРОект как подпроект

Отправлено автор: maximkr 19 сентября 2007 - 08:50 в JIRA issue tracker

Возможно ли в jira ввести проект как компонент для другого проекта?


Вот:
http://jira.atlassia.../browse/JRA-846