software standart workflow steps?

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

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

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

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

Жесть!

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

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

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

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

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

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

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

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

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

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

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