Скачал evaluation этого замечательного тула - первого совмещенного issue-трекера и PM Tool, из тех, что мне попадались. Уже можно кое-что сказать. Буду сравнивать с JIRA
( Read more... )
Re: интегрированный pm + issue trackinggapertonMay 1 2008, 09:07:45 UTC
> Ну, вы в первом посте написали, что project management функциональность JIRA даже с GreenHooper не дотягивает до MS Project :-) Почему тогда GreenHooper - это правильно, а простенький build server или wiki в Polaris - нет ? Ведь в обоих случаях к issue tracker-у прилепляется какая-то несвойственная им функциональность, заведомо недотягивающая до уровня аналогичных отдельных продуктов.
Потому, что MS Project и подобные совершенно не пригоден для планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - вполне пригодна. Вы можете считать это свойственной функциональностью для трекера или несвойственной - ваше дело. Но людям это требуется, потому что у них в трекерах проходят задачи для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Наличие wiki и build server в трекере - не принципиально, его можно и сбоку пустить. А вот планирование, элементами которого и являются issue, "сбоку" не запустишь.
> А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
Совершенно базовой функциональности, говорите? Как я могу добавить закладки для кастомных полей issue? Хочу чтоб выбрасывался отдельный экран на переход состояния - где это у вас? Кастом-поля "для всего" у меня в JIRA есть. А насчет задач - есть, например, еще и понятие Releases и куча специальных отчетов для их планирования и проведения Triage. Чего у вас нет, и надо как-то выдумывать самому и на коленке собирать.
Мы с вами общались достаточно подробно, вообще-то. У вас тулза "из коробки" не умеет практически ничего, ее надо допиливать и "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Re: интегрированный pm + issue trackingmaximkrMay 1 2008, 09:57:27 UTC
> Потому, что MS Project и подобные совершенно не пригоден для > планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - > вполне пригодна. Вы можете считать это свойственной > функциональностью для трекера или несвойственной - ваше дело. Но > людям это требуется, потому что у них в трекерах проходят задачи > для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Боюсь, я тут аргументированно спорить не смогу - мы планированием практически не занимались. В качестве внешней тулзы для планирования релизов клиенты хотят видеть скорее MS Project, чем GreenHooper от Atlassin, может быть это дело привычки, не знаю. Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски. Если строительство дома планировать в MS Project с типичной для issue tracker-а детальностью типа "Вася 15 минут мешает раствор, Петя в это время крутит шуруп N2 и N4", то тоже ничего хорошего не выйдет. Ну,в общем мы это тоже обсуждали :-)
> Мы с вами общались достаточно подробно, вообще-то. У вас тулза > "из коробки" не умеет практически ничего, ее надо допиливать и > "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Ну, у нас есть примеры конфигураций, там есть и ITIL, и управление требованиями, и классический bug tracking. У нас же "допиливание" - это не правка XML-конфигов и переписывание исходников, это на 95% настройка мышкой через web-интерфейс, документированное, с flash-мультиками.
А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака: http://en.wikipedia.org/wiki/Business_Process_Management
Re: интегрированный pm + issue trackinggapertonMay 3 2008, 11:55:36 UTC
> Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
А я вот планированием занимаюсь профессионально, Максим. Дефекты и фичреквесты, которые проходят именно в issue tracker, и из которых релиз может процентов на 60-80 состоять, мне тоже прикажете в MS Project учитывать, да?
> просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
Спасибо за дельный совет по планированию :). В прошлый раз вы, помнится, пытались меня убедить, что планировать вообще невозможно, приводя в доказательство блог-пост какого-то идиота, который основываясь на школьных знаниях теории вероятности рассуждая о планировании, пытался опровергнуть центральную предельную теорему.
Короче, Максим - не хотите делать - это ваше дело, вы управляете своими приоритетами и позиционированием как считаете правильным - это ваш бизнес и ваша обязанность. Убеждать в чем-то я вас не собираюсь, вам виднее. Только не надо меня убеждать, что мне нужно и как надо планировать, хорошо? :) Это виднее мне.
И еще один момент. Нормальная продажа от впаривания отличается тем, что вы честно признаете как сильные так и слабые стороны вашего продукта при сравнении с конкурентами, и не пытаетесь скрыть их от своих клиентов. Ваши сравнения с JIRA при всем желании нельзя назвать объективными - это бьет прежде всего по вам. Ну по крайней мере мне так кажется - вам опять же виднее.
> А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
У меня другие данные. По моим данным, если вы автоматизируете бардак, то получите в лучшем случае автоматизированный бардак, а в худшем - вообще ничего не получите, потому что бардак трудно описать системно в виде требований . При внедрении системы практически всегда перетряхивают существующие бизнес-процессы сразу, за редкими исключениями. Но это неважно.
Важно то, и это глупо отрицать, что JIRA для целей управления разработкой софта юзабельнее и функциональнее, чем ваше решение "из коробки". А если чего нет из коробки, то многое решается доставкой плагинов - чего у вас опять же нет.
Если вы оказываете сервис по настройке (а вы оказываете - у вас другая бизнес модель, не такая как у Atlassian), то вам наоборот - неважно, насколько у вас система готова к работе из коробки. Скорее наоборот. Но тогда не надо мерятся с Atlassian - это продуктовая а не сервисная компания. Сервис там партнеры оказывают.
Re: интегрированный pm + issue trackingmaximkrMay 3 2008, 15:29:35 UTC
> А я вот планированием занимаюсь профессионально, Максим. Дефекты > и фичреквесты, которые проходят именно в issue tracker, и из > которых релиз может процентов на 60-80 состоять, мне тоже > прикажете в MS Project учитывать, да?
Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Т.е. в нашем случае issue tracker - это средство для огранизации внутренней работы, а ms project - средство для общения с клиентом. Но наш случай не единственный, в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры. А кто-то еще может считать, что и project management, и issue tracking должны использоваться внутри команды для планирования, а клиенту прогнозы нужно сообщать обычным письмом, например.
Какой путь самый правильный - я не знаю, наверное, каждый выбирает что ему ближе.
> И еще один момент. Нормальная продажа от впаривания отличается > тем, что вы честно признаете как сильные так и слабые стороны > вашего продукта при сравнении с конкурентами, и не пытаетесь > скрыть их от своих клиентов. Ваши сравнения с JIRA при всем > желании нельзя назвать объективными - это бьет прежде всего по > вам. Ну по крайней мере мне так кажется - вам опять же виднее.
Да, честно признаю: 1) У нас продукт более сложный, а интерфес - не интуитивный. 2) У нас меньше клиентов и меньше community. 3) У нас хуже интеграция прямо из коробки.
> Важно то, и это глупо отрицать, что JIRA для целей управления > разработкой софта юзабельнее и функциональнее, чем ваше решение > "из коробки". А если чего нет из коробки, то многое решается > доставкой плагинов - чего у вас опять же нет.
А я и не отрицаю - стандартная конфигурация JIRA "богаче" стандартной конфигурации TrackStudio.
Re: интегрированный pm + issue trackinggapertonMay 3 2008, 20:43:32 UTC
> Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Заносите, Максим - флаг Вам в руки :). Электричку навстречу вы себе сами при таком подходе обеспечите. Интересно, вот почему вы сами не пользуетесь Project, и планирования не ведете, а мне рассказываете, как мне надо делать? :)
> ...в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
Утешайте себя этим, Максим. :) Долго еще будете сказки рассказывать, как в Atlassian ружья кирпичом чистят? Блин, вам от этого ни жарко ни холодно, продукт ваш от этого лучше не станет, а JIRA не станет хуже - зачем вы это повторяете все время? Давайте и я вам в третий раз повторю, что для JIRA есть плагин GreenHooper, плагин для проведения Triage, и двухсторонняя интеграция с MS Project. Которые превращают JIRA в зрелое решение для планирования. У вас нет ничего подобного даже близко. При этом как там они сами в Atlassian планируют - да пусть хоть на заднице себе маркерами рисуют, мне все равно, честно :).
> Да, честно признаю: > 1) У нас продукт более сложный, а интерфес - не интуитивный. Это вы себе льстите. Продукт ваш существенно проще JIRA, он обладает только базовой функциональностью трекера по сути. JIRA по сравнению с вашим продуктом просто злобнонавороченный монстр. А вот что интерфейс у вас не интуитивный - это вы зря. Он вполне интуитивный, я сразу разобрался. Он, как бы это сказать помягче, простоват. Видно, что сил на него раз в 10 меньше затрачено, чем на интерфейс JIRA.
> 2) У нас меньше клиентов и меньше community. Ну это никакого отношения к качеству продукта не имеет. Это следствие, а не причина.
> 3) У нас хуже интеграция прямо из коробки. Ой, если бы только это, то и проблем бы никаких не было. Я бы вам эту интеграцию тупо заказал, а вы бы мне ее сделали.
Плохо у вас получается быть честным. Ну да ладно. Вам виднее. Главное - классно вы Atlassian со сравнением развели. Зря они, дурачки, отвечать начали на своем сайте. Бесплатную рекламу вам сделали.
Потому, что MS Project и подобные совершенно не пригоден для планирования выпуска релизов, Максим. А вот JIRA c GreenHooper - вполне пригодна. Вы можете считать это свойственной функциональностью для трекера или несвойственной - ваше дело. Но людям это требуется, потому что у них в трекерах проходят задачи для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Наличие wiki и build server в трекере - не принципиально, его можно и сбоку пустить. А вот планирование, элементами которого и являются issue, "сбоку" не запустишь.
> А можно подробности ? Вот смотрю на список most popular issues - людям в JIRA не хватает совершенно базовой для issue tracking функциональности, не имеющей отношения к wiki или планированию (field level security, time zone для пользователей, кастом-полей для всего, неограниченной вложенность задач), а у нас все это есть.
Совершенно базовой функциональности, говорите? Как я могу добавить закладки для кастомных полей issue? Хочу чтоб выбрасывался отдельный экран на переход состояния - где это у вас? Кастом-поля "для всего" у меня в JIRA есть. А насчет задач - есть, например, еще и понятие Releases и куча специальных отчетов для их планирования и проведения Triage. Чего у вас нет, и надо как-то выдумывать самому и на коленке собирать.
Мы с вами общались достаточно подробно, вообще-то. У вас тулза "из коробки" не умеет практически ничего, ее надо допиливать и "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Reply
> планирования выпуска релизов, Максим. А вот JIRA c GreenHooper -
> вполне пригодна. Вы можете считать это свойственной
> функциональностью для трекера или несвойственной - ваше дело. Но
> людям это требуется, потому что у них в трекерах проходят задачи
> для этих релизов - именно поэтому и JIRA и Polarian это умеют.
Боюсь, я тут аргументированно спорить не смогу - мы планированием практически не занимались. В качестве внешней тулзы для планирования релизов клиенты хотят видеть скорее MS Project, чем GreenHooper от Atlassin, может быть это дело привычки, не знаю.
Каких-то принципиальных проблем с планированием релизов в MS Project я тоже не вижу (чисто теоретически, мы им не пользуемся) - просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски. Если строительство дома планировать в MS Project с типичной для issue tracker-а детальностью типа "Вася 15 минут мешает раствор, Петя в это время крутит шуруп N2 и N4", то тоже ничего хорошего не выйдет.
Ну,в общем мы это тоже обсуждали :-)
> Мы с вами общались достаточно подробно, вообще-то. У вас тулза
> "из коробки" не умеет практически ничего, ее надо допиливать и
> "внедрять". JIRA - поддерживает все основные юз-кейсы из коробки.
Ну, у нас есть примеры конфигураций, там есть и ITIL, и управление требованиями, и классический bug tracking. У нас же "допиливание" - это не правка XML-конфигов и переписывание исходников, это на 95% настройка мышкой через web-интерфейс, документированное, с flash-мультиками.
А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
http://en.wikipedia.org/wiki/Business_Process_Management
Reply
А я вот планированием занимаюсь профессионально, Максим. Дефекты и фичреквесты, которые проходят именно в issue tracker, и из которых релиз может процентов на 60-80 состоять, мне тоже прикажете в MS Project учитывать, да?
> просто не нужно детализировать список работ в MS Project до уровня отдельных задач на 15-20 минут, это должны быть гораздо более крупные куски.
Спасибо за дельный совет по планированию :). В прошлый раз вы, помнится, пытались меня убедить, что планировать вообще невозможно, приводя в доказательство блог-пост какого-то идиота, который основываясь на школьных знаниях теории вероятности рассуждая о планировании, пытался опровергнуть центральную предельную теорему.
Короче, Максим - не хотите делать - это ваше дело, вы управляете своими приоритетами и позиционированием как считаете правильным - это ваш бизнес и ваша обязанность. Убеждать в чем-то я вас не собираюсь, вам виднее. Только не надо меня убеждать, что мне нужно и как надо планировать, хорошо? :) Это виднее мне.
И еще один момент. Нормальная продажа от впаривания отличается тем, что вы честно признаете как сильные так и слабые стороны вашего продукта при сравнении с конкурентами, и не пытаетесь скрыть их от своих клиентов. Ваши сравнения с JIRA при всем желании нельзя назвать объективными - это бьет прежде всего по вам. Ну по крайней мере мне так кажется - вам опять же виднее.
> А от допиливания я не знаю куда деться - сам подход business process management подразумевает, что система сначала настраивается под имеющийся бардак, потом анализируется и меняется в сторону уменьшения бардака:
У меня другие данные. По моим данным, если вы автоматизируете бардак, то получите в лучшем случае автоматизированный бардак, а в худшем - вообще ничего не получите, потому что бардак трудно описать системно в виде требований . При внедрении системы практически всегда перетряхивают существующие бизнес-процессы сразу, за редкими исключениями. Но это неважно.
Важно то, и это глупо отрицать, что JIRA для целей управления разработкой софта юзабельнее и функциональнее, чем ваше решение "из коробки". А если чего нет из коробки, то многое решается доставкой плагинов - чего у вас опять же нет.
Если вы оказываете сервис по настройке (а вы оказываете - у вас другая бизнес модель, не такая как у Atlassian), то вам наоборот - неважно, насколько у вас система готова к работе из коробки. Скорее наоборот. Но тогда не надо мерятся с Atlassian - это продуктовая а не сервисная компания. Сервис там партнеры оказывают.
Reply
> и фичреквесты, которые проходят именно в issue tracker, и из
> которых релиз может процентов на 60-80 состоять, мне тоже
> прикажете в MS Project учитывать, да?
Не стоит, это явно плохая идея. Скорее, на основе информации в issue tracker-е, информации о том, кто именно уже тестировал этот модуль, насколько он важен для пользователя и т.п. можно сделать оценку (в голове) и занести ее в MS Project.
Т.е. в нашем случае issue tracker - это средство для огранизации внутренней работы, а ms project - средство для общения с клиентом.
Но наш случай не единственный, в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
А кто-то еще может считать, что и project management, и issue tracking должны использоваться внутри команды для планирования, а клиенту прогнозы нужно сообщать обычным письмом, например.
Какой путь самый правильный - я не знаю, наверное, каждый выбирает что ему ближе.
> И еще один момент. Нормальная продажа от впаривания отличается
> тем, что вы честно признаете как сильные так и слабые стороны
> вашего продукта при сравнении с конкурентами, и не пытаетесь
> скрыть их от своих клиентов. Ваши сравнения с JIRA при всем
> желании нельзя назвать объективными - это бьет прежде всего по
> вам. Ну по крайней мере мне так кажется - вам опять же виднее.
Да, честно признаю:
1) У нас продукт более сложный, а интерфес - не интуитивный.
2) У нас меньше клиентов и меньше community.
3) У нас хуже интеграция прямо из коробки.
Собственно, Atlassian написали свое сравнение, ссылка на него и обсуждение тут:
http://maximkr.livejournal.com/9378.html
> Важно то, и это глупо отрицать, что JIRA для целей управления
> разработкой софта юзабельнее и функциональнее, чем ваше решение
> "из коробки". А если чего нет из коробки, то многое решается
> доставкой плагинов - чего у вас опять же нет.
А я и не отрицаю - стандартная конфигурация JIRA "богаче" стандартной конфигурации TrackStudio.
Reply
Заносите, Максим - флаг Вам в руки :). Электричку навстречу вы себе сами при таком подходе обеспечите. Интересно, вот почему вы сами не пользуетесь Project, и планирования не ведете, а мне рассказываете, как мне надо делать? :)
> ...в Atlassian, например, считают, что issue tracker стоит использовать для общения с клиентами, а внутри организации можно использовать доску, распечатки и фломастеры.
Утешайте себя этим, Максим. :) Долго еще будете сказки рассказывать, как в Atlassian ружья кирпичом чистят? Блин, вам от этого ни жарко ни холодно, продукт ваш от этого лучше не станет, а JIRA не станет хуже - зачем вы это повторяете все время? Давайте и я вам в третий раз повторю, что для JIRA есть плагин GreenHooper, плагин для проведения Triage, и двухсторонняя интеграция с MS Project. Которые превращают JIRA в зрелое решение для планирования. У вас нет ничего подобного даже близко. При этом как там они сами в Atlassian планируют - да пусть хоть на заднице себе маркерами рисуют, мне все равно, честно :).
> Да, честно признаю:
> 1) У нас продукт более сложный, а интерфес - не интуитивный.
Это вы себе льстите. Продукт ваш существенно проще JIRA, он обладает только базовой функциональностью трекера по сути. JIRA по сравнению с вашим продуктом просто злобнонавороченный монстр. А вот что интерфейс у вас не интуитивный - это вы зря. Он вполне интуитивный, я сразу разобрался. Он, как бы это сказать помягче, простоват. Видно, что сил на него раз в 10 меньше затрачено, чем на интерфейс JIRA.
> 2) У нас меньше клиентов и меньше community.
Ну это никакого отношения к качеству продукта не имеет. Это следствие, а не причина.
> 3) У нас хуже интеграция прямо из коробки.
Ой, если бы только это, то и проблем бы никаких не было. Я бы вам эту интеграцию тупо заказал, а вы бы мне ее сделали.
Плохо у вас получается быть честным. Ну да ладно. Вам виднее. Главное - классно вы Atlassian со сравнением развели. Зря они, дурачки, отвечать начали на своем сайте. Бесплатную рекламу вам сделали.
Reply
Leave a comment