У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
Здравствуйте, kinetek, Вы писали:
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
А я за менеджера — жизнь настолько разнообразна, что хотя бы в тестовой системе то все должно быть ништяк
Здравствуйте, kinetek, Вы писали:
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
Если баг блокирует процесс тестирования\разработки то почему-бы и не дать ему приоритет Blocker?
У нас приоритет не зависит от того на каком колокейшене найден баг.
Вобщем я поддерживаю менеджера.
А каким образом тестеров тогда мотивировать работать над тестовой системой если они будут находить баги за день до релиза и создавать запросы с наивысшим приоритетом? А если в это же время в продакшене что-то полетит? А ведь SLA в данном случае одинаковый будет, а поддержке нужно укладываться в лимиты.
Здравствуйте, kinetek, Вы писали:
K>Т.е. на ваш взгляд и продакшн система и тестовая должны иметь одинаковый приоритет? Пока новый релиз тестируется продакшн сервер работает.
При прочих равных — продакшн важнее. Вот и всё. Научитесь правильно ставить severity , а не заводить Blocker из-за опечатки в окошке about .
Здравствуйте, kinetek, Вы писали:
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
А проблема-то в чем заключается? И кем в данной ситуации выступает автор поста — менеджером более низкого звена, разработчиком или тестировщиком?
Здравствуйте, kinetek, Вы писали:
K>Уважаемые Коллеги,
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
Думаю, все зависит от системы, которую вы разрабатываете и от дефектов, которые обнаруживаете.
Частично я согласен с менеджером, вот почему: если уже на тестовой системе обнаружены дефекты архитектуры, то у них я бы поставил наивысший приоритет. Смысл их откладывать, если придется переделывать?
если обнаружен дефект в коде, который ушел на продакшн (пропустили дефект) и занимается там важными вычислениями — высокий приоритет.
Если дефект в новой фиче, который нет в продакшене — приоритет ниже.
Если обнаружены дефекты пользовательского интерфейса — приоритет ниже.
Здравствуйте, kinetek, Вы писали:
K>Уважаемые Коллеги,
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
Здравый смысл подсказывает, что если все имеет наивысший приоритет, то смысла в приоритетах нету.
В такой ситуации будут созданы негласные приоритеты типа "баги, про которые знает Иван Иваныч надо править в первую очередь",
что не есть хорошо.
Здравствуйте, Rustavelli, Вы писали:
R>Здравствуйте, kinetek, Вы писали:
K>>Уважаемые Коллеги,
K>>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
R>Думаю, все зависит от системы, которую вы разрабатываете и от дефектов, которые обнаруживаете. R>Частично я согласен с менеджером, вот почему: если уже на тестовой системе обнаружены дефекты архитектуры, то у них я бы поставил наивысший приоритет. Смысл их откладывать, если придется переделывать?
Вот как раз в случаях дефектов архитектуры нет смысла пороть горячку.
Дефекты архитектуры это не то же самое, что баги.
С дефектами архитектуры вполне можно иметь работоспособную систему, которой вполне будут довольны пользователи.
Проблема плохой архитектуры — это существенные издержки при измении системы.
Менять архитектуру по последних этапах проекта точно не стоит.
Здравствуйте, kinetek, Вы писали:
K>Уважаемые Коллеги,
K>У меня тут небольшая междуусобица с корпоративным менеджментом, который утверждает что при наличии проблем даже на тестовых системах, необходимо создавать тикеты наивысшего приоритета. Я категорически против этой практики и пытаюсь собрать как можно большее количество информации в защиту своего мнения. Не могли бы вы ткнуть носом в источник который бы мог предоставить мне весомые аргументы?
Откройте для себя мир волшебной разницы между severity и priority. Если какой-то баг по всем признакам
