Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами.
Хотелось услышать мнение уважаемых господ, знаю, что вопрос поднимался уже кучу раз, но по-моему бесплатной и хорошо сделанной вещи — толком и нету. + сделать интеграцию в Студию для удобства. Вот хороший аналог есть BugNet — http://www.bugnetproject.com/, но он на классике и тяжеловесный.
Здравствуйте, SuperXren, Вы писали:
SX>Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами.
А чем он будет лучше существующих?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, SuperXren, Вы писали:
SX>>Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами. V>А чем он будет лучше существующих?
Ну сейчас из существующих бесплатных таких систем с интеграцией в студию — вообще проблемы. Табеж их просто нету
Здравствуйте, SuperXren, Вы писали:
SX>Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами.
Хорошая идея.
Я бы посоветовал близко познакомиться хотя бы с пятью-шестью популярными системами данного
"жанра" и позаимствовать некоторые идеи из них. Ибо все уже придумано до нас. Почти все.
SX>Хотелось услышать мнение уважаемых господ, знаю, что вопрос поднимался уже кучу раз, но по-моему бесплатной и хорошо сделанной вещи — толком и нету. + сделать интеграцию в Студию для удобства.
В слово "хороший" каждый вкладывает свой смысл.
Сделаете, допустим, чрезвычайно удобный в Вашем понимании инструмент, а другим он
покажется кривоватым, неудобным, будут говорить, что непредусмотрели какое-нибудь
там ветвление тасков или управление доступом, что сложно его конфигурировать...
И получится в результате еще один брат-близнец багзиллы, от которой многие плюются,
но тем не менее продолжают использовать за неимением лучшего.
Да и потом, современное ПО данного класса — оно все многозвенное.
Вместо того, чтобы сооружать универсальную систему управления задачами с багтрекером,
собственной базой данных и веб-сервером, лучше сконцентрироваться на одной из этих
составляющих, сделать ее качественно и обеспечить максимально широкие возможности
для интеграции в другие продукты и системы. Это, вероятно, будет востребовано.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, SuperXren, Вы писали:
SX>>Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами.
O>Хорошая идея. O>Я бы посоветовал близко познакомиться хотя бы с пятью-шестью популярными системами данного O>"жанра" и позаимствовать некоторые идеи из них. Ибо все уже придумано до нас. Почти все.
SX>>Хотелось услышать мнение уважаемых господ, знаю, что вопрос поднимался уже кучу раз, но по-моему бесплатной и хорошо сделанной вещи — толком и нету. + сделать интеграцию в Студию для удобства.
O>В слово "хороший" каждый вкладывает свой смысл. O>Сделаете, допустим, чрезвычайно удобный в Вашем понимании инструмент, а другим он O>покажется кривоватым, неудобным, будут говорить, что непредусмотрели какое-нибудь O>там ветвление тасков или управление доступом, что сложно его конфигурировать...
O>И получится в результате еще один брат-близнец багзиллы, от которой многие плюются, O>но тем не менее продолжают использовать за неимением лучшего.
O>Да и потом, современное ПО данного класса — оно все многозвенное. O>Вместо того, чтобы сооружать универсальную систему управления задачами с багтрекером, O>собственной базой данных и веб-сервером, лучше сконцентрироваться на одной из этих O>составляющих, сделать ее качественно и обеспечить максимально широкие возможности O>для интеграции в другие продукты и системы. Это, вероятно, будет востребовано.
Спасибо огромное за столь развёрнутый ответ.
Что конкретно Вам не хватает в текущих системах управления проектами или баг трекинговых системах?
Здравствуйте, vmpire, Вы писали:
V>А чем он будет лучше существующих?
А каких существующих? Не такой уж и большой выбор на платформе asp.net. Да и удобством с качеством они не блещут. У меня сладывается впечатление, что сейчас любой продукт, над которым хоть немного подумали, переплюнет существующие решения.
Здравствуйте, SuperXren, Вы писали:
SX>Ну сейчас из существующих бесплатных таких систем с интеграцией в студию — вообще проблемы. Табеж их просто нету
И вполне закономерно нет. Эта интеграция нужна только отсвечивать в списке фич. Студия и багтрекер, а тем более модуль ПМ, решают разные задачи — зачем их объединять?
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, vmpire, Вы писали:
V>>А чем он будет лучше существующих?
_R_>А каких существующих? Не такой уж и большой выбор на платформе asp.net. Да и удобством с качеством они не блещут. У меня сладывается впечатление, что сейчас любой продукт, над которым хоть немного подумали, переплюнет существующие решения.
А зачем пользователю багтрекера ограничиваться ASP.NET?
Вот мне, например, бсолютно всё равно на чём написана программа, которой я просто пользуюсь. Было бы удобно, а там пусть это будет хоть ASP.NET, хоть J2EE хоть PHP.
То, что ваш трекер будет на ASP.NET это не его приеущество, это вообще не важно никому, кроме того, кто будет его писать.
Здравствуйте, vmpire, Вы писали:
V>А зачем пользователю багтрекера ограничиваться ASP.NET? V>Вот мне, например, бсолютно всё равно на чём написана программа, которой я просто пользуюсь. Было бы удобно, а там пусть это будет хоть ASP.NET, хоть J2EE хоть PHP. V>То, что ваш трекер будет на ASP.NET это не его приеущество, это вообще не важно никому, кроме того, кто будет его писать.
SX>Ну сейчас из существующих бесплатных таких систем с интеграцией в студию — вообще проблемы. Табеж их просто нету
Рассматриваете вариант добавить интеграцию существующей системы в студию? Часто у таких систем хороший platform-neutral интеграционный api/механизм.
Тогда вам не придётся переизобретать велосипед, а только лишь добавить уникальную интеграционную фичу. И со стороны пользователей, и со стороны разработчиков системы вам будет почёт и благодарность.
Здравствуйте, SuperXren, Вы писали:
SX>Спасибо огромное за столь развёрнутый ответ. SX>Что конкретно Вам не хватает в текущих системах управления проектами или баг трекинговых системах?
Простого и качественного интерфейса, учета времени, интеграции с другими инструментами.
Например было бы круто наложить историю фиксов на дерево проекта. Это дает возможность определить проблемные места. А с авт. учетом времени можно даже затраты на такое фиксировать.
Наприемер смотрим, что файла в каком то фолдере модифицируются чуть не по любой причне и это занимает в среднем 2 раза в неделю и каждый раз на баг уходит от нескольких часов, при этом в цепочку вовлекается 5-6 человек (реальное положение дел).
Соотвественно это позволяет задетектить проблему и дальше её можно исправить.
Самый больной момент это UI, чуть не все трекеры стараются вытащить на самый верх как можно больше контролов. Особенно JIRA здесь старается. В итоге любая простецкая фича требует n-кликов и отбивает желание работать с трекером.
Здравствуйте, _Raz_, Вы писали:
V>>А зачем пользователю багтрекера ограничиваться ASP.NET? V>>Вот мне, например, бсолютно всё равно на чём написана программа, которой я просто пользуюсь. Было бы удобно, а там пусть это будет хоть ASP.NET, хоть J2EE хоть PHP. V>>То, что ваш трекер будет на ASP.NET это не его приеущество, это вообще не важно никому, кроме того, кто будет его писать.
_R_>Что бы на сервере зоопарк не разводить.
Так не надо его разводить. Кто заставляет-то? Вот у нас на вендовом сервере, например, стоит JIRA. Java/Apache/Tomcat. И никакого зоопарка.
Здравствуйте, Ikemefula, Вы писали: I>Простого и качественного интерфейса, учета времени, интеграции с другими инструментами.
Redmine ничего так.
I>Например было бы круто наложить историю фиксов на дерево проекта. Это дает возможность определить проблемные места. А с авт. учетом времени можно даже затраты на такое фиксировать.
Автоматический учет времени — если использовать Eclipse + Mylyn, думаю, должно быть доступно. Или простенькая программа с таймером и обновлением через JSON.
I>Наприемер смотрим, что файла в каком то фолдере модифицируются чуть не по любой причне и это занимает в среднем 2 раза в неделю и каждый раз на баг уходит от нескольких часов, при этом в цепочку вовлекается 5-6 человек (реальное положение дел).
Имеется ввиду интеграция с системой управления версий?
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, Ikemefula, Вы писали: I>>Простого и качественного интерфейса, учета времени, интеграции с другими инструментами. LV>Redmine ничего так.
I>>Например было бы круто наложить историю фиксов на дерево проекта. Это дает возможность определить проблемные места. А с авт. учетом времени можно даже затраты на такое фиксировать. LV>Автоматический учет времени — если использовать Eclipse + Mylyn, думаю, должно быть доступно. Или простенькая программа с таймером и обновлением через JSON.
По отдельности это не интересно. Вот я нашел проблему в коде и хочу узнать, сколько времени было затрачено на её решение. Как это сделать ?
I>>Наприемер смотрим, что файла в каком то фолдере модифицируются чуть не по любой причне и это занимает в среднем 2 раза в неделю и каждый раз на баг уходит от нескольких часов, при этом в цепочку вовлекается 5-6 человек (реальное положение дел). LV>Имеется ввиду интеграция с системой управления версий?
Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится.
Здравствуйте, Ikemefula, Вы писали: I>По отдельности это не интересно. Вот я нашел проблему в коде и хочу узнать, сколько времени было затрачено на её решение. Как это сделать ?
Не понимаю. Если есть проблема в коде, значит она еще не решена. И время потрачено не было. Или что? Если разработчик ведет time log, можно по issue посмотреть, сколько время ушло.
I>>>Наприемер смотрим, что файла в каком то фолдере модифицируются чуть не по любой причне и это занимает в среднем 2 раза в неделю и каждый раз на баг уходит от нескольких часов, при этом в цепочку вовлекается 5-6 человек (реальное положение дел). I>Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится.
Если я хочу посмотреть кто работал над файлом, мне тут поможет только самам CVS и ее лог. Вы предлагаете полноценного клиента встроить в issue tracking?
В mylyn есть такое понятие, как "контекст". Посмотрите, может это именно то, что вам нужно.
Здравствуйте, LeonidV, Вы писали:
I>>По отдельности это не интересно. Вот я нашел проблему в коде и хочу узнать, сколько времени было затрачено на её решение. Как это сделать ? LV>Не понимаю. Если есть проблема в коде, значит она еще не решена. И время потрачено не было. Или что? Если разработчик ведет time log, можно по issue посмотреть, сколько время ушло.
Если проблема есть, то время/бюджет уже тратится. Например все фиксы занимают день-два когда нужно 5 минут.
I>>Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится. LV>Если я хочу посмотреть кто работал над файлом, мне тут поможет только самам CVS и ее лог. Вы предлагаете полноценного клиента встроить в issue tracking?
Еще раз. Девелопер заимплементил фичу. Другие девелоперы в среднем 2-3 раза в неделю в течение года фиксили баги связаные с этой фичей.
Нужен инструмент, который поможет задетектить проблему как можно раньше.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, LeonidV, Вы писали:
I>>>По отдельности это не интересно. Вот я нашел проблему в коде и хочу узнать, сколько времени было затрачено на её решение. Как это сделать ? LV>>Не понимаю. Если есть проблема в коде, значит она еще не решена. И время потрачено не было. Или что? Если разработчик ведет time log, можно по issue посмотреть, сколько время ушло.
I>Если проблема есть, то время/бюджет уже тратится. Например все фиксы занимают день-два когда нужно 5 минут.
Как система управления задачами сможет это определять?
I>Еще раз. Девелопер заимплементил фичу. Другие девелоперы в среднем 2-3 раза в неделю в течение года фиксили баги связаные с этой фичей. I>Нужен инструмент, который поможет задетектить проблему как можно раньше.
И тут тоже — какой алгоритм определения проблемы у системы?
Я могу придумать два организационных варианта решения задачи. С помощью трассирования на уровне issue (ставим related to #XXX). Либо находить какой-то часто изменяемый файл и по комментария на добавления находим номер issue, для которой он был создан. Еще вариант — добавить в документацию исходных кодов (в javadoc, в случае java) свой тэг, который будет сразу ссылаться на issue tracker.
Здравствуйте, LeonidV, Вы писали:
I>>Если проблема есть, то время/бюджет уже тратится. Например все фиксы занимают день-два когда нужно 5 минут. LV>Как система управления задачами сможет это определять?
Это определяет человек, а от трекера требуется поддержка всяких фич. Нечто похожее есть в TFS но я ума не приложу, как собрать эту инфу
LV>Я могу придумать два организационных варианта решения задачи.
I>>>Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится. LV>>Если я хочу посмотреть кто работал над файлом, мне тут поможет только самам CVS и ее лог. Вы предлагаете полноценного клиента встроить в issue tracking?
I>Еще раз. Девелопер заимплементил фичу. Другие девелоперы в среднем 2-3 раза в неделю в течение года фиксили баги связаные с этой фичей. I>Нужен инструмент, который поможет задетектить проблему как можно раньше.
Есть интегрированная система, MKS Integrity. Там можно из Issue сразу посмотреть список файлов, коммитов, изменений кода, относящихся к нему.
А вообще, можно взять Redmine + SVN. Если заставлять девелоперов в комменте к коммиту указывать номер Issue, то Redmine будет это подцеплять и тоже показывать связку между issues и кодом.
То есть, совершенно необязательно велосипед изобретать.
Кто заставляет-то? Вот у нас на вендовом сервере, например, стоит JIRA. Java/Apache/Tomcat. И никакого зоопарка. 
