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

[Torja]

Всем привет. У меня тут катастрофа на работе, тупые менеджеры которые только умеют командовать но нифига не шарят в Software development lifecycles, решили упростить Issue tracking system, так как им там ничего не понятно.

В итоге сначалa избавились от статуса "Cancel" что я с трудом пережила (остался "Close"), теперь покушаются на "Reopen"!!!!

Помогите найти такую вещь в тырнете на английском пожалуйста -> software standart workflow steps

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

[astenix]

Жесть!

[barancev]

Могу предположить, что если Вы найдёте некий "стандарт" -- они запросто смогут проигнорировать его, "так как им там ничего не понятно" :)

[Alfa]

В итоге сначалa избавились от статуса "Cancel" что я с трудом пережила (остался "Close"), теперь покушаются на "Reopen"!!!!

Чисто из спортивного интереса. Не могли бы Вы написать, что было и что хотят сделать?

[Freiman]

Есть 2 типа workflow - возвратный и невозвратный.
В возвратном - если баг вдруг снова вылез в другой версии, то вы делаете reopen существующему тикету.
В невозвратном - создаете новый тикет на новую версию.
Ничего страшного в том, Reopen исчезнет, нет - я сейчас работаю по такому же workflow, и все нормально - и даже удобнее.

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

Возможно, статус Cancel по каким-то причинам также посчитали лишним - например, все задачи/баги должны быть закрытыми с указанием причины ("не баг", "не воспроизводится", "проблема в конфигурации" итп), а не отменены по непонятной причине.

[Boltick]

Есть 2 типа workflow - возвратный и невозвратный.
В возвратном - если баг вдруг снова вылез в другой версии, то вы делаете reopen существующему тикету.
В невозвратном - создаете новый тикет на новую версию.
Ничего страшного в том, Reopen исчезнет, нет - я сейчас работаю по такому же workflow, и все нормально - и даже удобнее.

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

На счет Reopen и т.д.
Всю свою несознательную жизнь был за то, чтобы закрытые (Closed) баги нельзя было переоткрывать! При этом статус Reopen применяется в случае если бага со статусом Fixed (но не Closed) воспроизводится, т.к. не до конца пофикшена.

Возможно, статус Cancel по каким-то причинам также посчитали лишним - например, все задачи/баги должны быть закрытыми с указанием причины ("не баг", "не воспроизводится", "проблема в конфигурации" итп), а не отменены по непонятной причине.

Кстати да, если мне не изменяет память в той же JIRA есть Статус, а есть Resolution. Может эти самые менеджеры, хотят именно таких изменений?


Torja, а есть ли у Вас графическая интерпретация того воркфлог/lifecycle, который хочет внедрить ваше руководство??? - чисто ради интереса взглянул бы...

[Freiman]

На счет Reopen и т.д.
Всю свою несознательную жизнь был за то, чтобы закрытые (Closed) баги нельзя было переоткрывать! При этом статус Reopen применяется в случае если бага со статусом Fixed (но не Closed) воспроизводится, т.к. не до конца пофикшена.

А у нас даже если не пофикшено или пофикшено не полностью, то старый закрывается с комментом "not fixed" и создается новый баг (между собой тикеты автоматически линкуются, можно посмотреть историю бага).

[Clauster]

Ага, все кругом пи...сы, а я Д'артаньян.
Сначала научитесь различать ЖЦ ПО от ЖЦ запроса на изменение (в частном случае бага). Кстати, вы о чем конкретно, о багах или запросах на изменение? Потом подтяните русский и английский, для карьеры не помешает.
Единого стандарта нет. Ищите по словам change request management, bug workflow или типа того, если вас ещё в гугле и википедии не забанили.

[Boltick]

Ага, все кругом пи...сы, а я Д'артаньян.
Сначала научитесь различать ЖЦ ПО от ЖЦ запроса на изменение (в частном случае бага). Кстати, вы о чем конкретно, о багах или запросах на изменение? Потом подтяните русский и английский, для карьеры не помешает.
Единого стандарта нет. Ищите по словам change request management, bug workflow или типа того, если вас ещё в гугле и википедии не забанили.

Добрый вы, товарищ Clauster.
Дельные советы даете... :)

[Torja]

В итоге сначалa избавились от статуса "Cancel" что я с трудом пережила (остался "Close"), теперь покушаются на "Reopen"!!!!

Чисто из спортивного интереса. Не могли бы Вы написать, что было и что хотят сделать?

извените не буду рисовать диаграмму, были такие степы:

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

без возможности reopen from Closed

[Torja]

Ага, все кругом пи...сы, а я Д'артаньян.
Сначала научитесь различать ЖЦ ПО от ЖЦ запроса на изменение (в частном случае бага). Кстати, вы о чем конкретно, о багах или запросах на изменение? Потом подтяните русский и английский, для карьеры не помешает.
Единого стандарта нет. Ищите по словам change request management, bug workflow или типа того, если вас ещё в гугле и википедии не забанили.

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

Open & Close наверно есть у всех :) а далее какой то примерный optional список, который может совпадать по смыслу у кампаний с похожей разработкой.

Разницу между ЖЦ ПО и ЖЦ я вижу.

[Vita]

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

Open & Close наверно есть у всех :) а далее какой то примерный optional список, который может совпадать по смыслу у кампаний с похожей разработкой.

Как бы сильно не обидели меня руководители, все же не стала бы их в форуме "тупыми" называть. Если работу упростить пытаются, может это не так уж и плохо.

А вот, когда 12-тая в декрет в отделе собралась, а объемы не убавляются. В отделе скоро будут только руководители, а руководить кем? Кто комплексы сопровождать будет, если и последние не выдержав прессинга и объемов, сбегут.
А мне кажется, все у Вас хорошо.

А может русский Вам не родной? Переводчик виноват?

[DrVal]

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

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

Например, у нас есть правило не переоткрывать заверифаенные баги, и это прошито в трекере (при этом ошибочные переводы resolved -> verified можно откатить). Т.е. если в какой-то сборке код работал, значит баг пофикшен.
А если баг вернулся, то это какая-то новая проблема.

Постарайтесь понять смысл вводимых изменений.

извените не буду рисовать диаграмму, были такие степы:

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

без возможности reopen from Closed

[Clauster]

Ага, все кругом пи...сы, а я Д'артаньян.
Сначала научитесь различать ЖЦ ПО от ЖЦ запроса на изменение (в частном случае бага). Кстати, вы о чем конкретно, о багах или запросах на изменение? Потом подтяните русский и английский, для карьеры не помешает.
Единого стандарта нет. Ищите по словам change request management, bug workflow или типа того, если вас ещё в гугле и википедии не забанили.

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

Open & Close наверно есть у всех :) а далее какой то примерный optional список, который может совпадать по смыслу у кампаний с похожей разработкой.

Разницу между ЖЦ ПО и ЖЦ я вижу.

Ну раз вы такая умная, то зачем на форум портала тупых менеджеров пришли?

[Clauster]

Ага, все кругом пи...сы, а я Д'артаньян.
Сначала научитесь различать ЖЦ ПО от ЖЦ запроса на изменение (в частном случае бага). Кстати, вы о чем конкретно, о багах или запросах на изменение? Потом подтяните русский и английский, для карьеры не помешает.
Единого стандарта нет. Ищите по словам change request management, bug workflow или типа того, если вас ещё в гугле и википедии не забанили.

Добрый вы, товарищ Clauster.
Дельные советы даете... :)

Согласен, можно было и мимо пройти :)

[Torja]

ха ха а где тут написанно что это форум менеджеров? Вопервых я возникаю по поводу работы менеджеров проекта, так как у нас вообще нет менеджеров для тест тима. Менеджерам проекта а в частности финансовому отделу вообще не понятно как работает JIRA, они просто хотят следить за тем почему у нас так много ошибок. А чтоб следить за этим им надо знать на какой стадии находится ошибка. Что такое процесс разработки ПО они вообще не понимают, и считают что Open i Close достаточно вообще

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

[Torja]

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

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

Например, у нас есть правило не переоткрывать заверифаенные баги, и это прошито в трекере (при этом ошибочные переводы resolved -> verified можно откатить). Т.е. если в какой-то сборке код работал, значит баг пофикшен.
А если баг вернулся, то это какая-то новая проблема.

Постарайтесь понять смысл вводимых изменений.

извените не буду рисовать диаграмму, были такие степы:

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

без возможности reopen from Closed

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

[barancev]

Менеджерам проекта а в частности финансовому отделу вообще не понятно как работает JIRA, они просто хотят следить за тем почему у нас так много ошибок.

Финансовый отдел хочет следить за JIRA? Ого!

[DrVal]

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

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

И для того, чтобы заробатывать деньги им достаточно 2-х статусов в JIRA.

Разрешить конфликт можно было бы созданием отчета в JIRA, который все статсы сведет к этим 2-м.

[Freiman]

Менеджерам проекта а в частности финансовому отделу вообще не понятно как работает JIRA, они просто хотят следить за тем почему у нас так много ошибок.

а зачем финансовому отделу Jira?
а почему у вас так много ошибок?