Каков реалистичный (но быстрый) график бета-тестирования версий?[закрыто]

Question

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

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

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

Я думаю, что могут разыграться следующие сценарии:

1. Двухнедельный цикл.У нас есть избранная группа пользователей, скажем, от трех до пяти сайтов, и по мере того, как они сталкиваются с ошибками, мы их исправляем.Я думаю, что время этого цикла абсурдно быстро, но я уже чувствую, что именно так и захотят действовать Власть Имущие.При таком подходе мы привязываем продукт к определенной сборке, и любые накапливающиеся ошибки мы исправляем в следующем выпуске (который может быть выпущен пятьюдесятью сборками позже).
2. Шестинедельный цикл.У нас есть та же избранная группа пользователей, но эта группа может расти, и по мере ее роста мы действуем, как в шаге 1.Не так быстро, как 1, но, безусловно, более осторожно.Проблема в том, что у пользователей может сложиться впечатление, что продукт чрезмерно глючит (если они столкнутся с ошибками), и они не смогут избавиться от этого впечатления, пока мы не выпустим другую версию, после чего им может быть уже все равно.Поскольку в аппаратном обеспечении есть проблема, о которой я упоминал ранее, это впечатление неисправности может просто вылиться в легкое ворчание, а не в потерю продаж.Однако каждая новая бета-версия будет проходить гораздо более тщательную проверку, чем предыдущая.
3. Как только ошибки будут исправлены, передавайте исправленные версии в руки пользователей.У нас есть сервер сборки, у нас есть несколько тестировщиков, и мы довольно быстро реагируем (можно даже сказать, "проворно").Есть ли недостатки в том, чтобы просто выдавать исправления ошибок так быстро, как мы исправляем ошибку, при условии, что исправление не нарушает какое-то другое поведение, необходимое программному обеспечению?Если бы мы использовали этот подход, делали бы мы циклы или просто бета-"период"?

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

Answer 1

В нашем случае мы позволяем отзывам клиентов определять наш цикл.После выпуска начальной бета-версии мы прислушиваемся к отзывам.Иногда возникает катастрофическая ошибка, и мы останавливаем запуск бета-версии, исправляем ее и затем возобновляем.В других случаях мы собираем ошибки, основываясь на важности клиента, а затем выпускаем обновление, как только жалобы утихают.В конечном счете, восприятие клиента - это то, что здесь важнее всего (в отношении скорости), и поэтому сбалансировать их жалобы с тем, чего хочет руководство, является сложным аспектом.В нашем случае мы обычно выбираем где-то в пределах 2-4 недель, в зависимости от того, сколько и насколько срочны ошибки.

Answer 2

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

Я не знаю точных особенностей вашего приложения, но я бы подумал, что вашим клиентам будет проще придерживаться установленного графика выпуска.Когда клиент действительно обнаруживает проблему с высоким приоритетом, приятно слышать, что решение найдено и оно появится в следующем выпуске через 2 недели или даже 6 недель, если до этого не осталось месяцев."Исправление", если оно не является чрезмерно детализированным, может вызвать больше проблем, чем оно решает, поскольку у клиентов странные и сильно отличающиеся базы кода, что создаст проблемы, которые трудно воспроизвести.

Answer 3

Пойдите с номером 1.Без сомнения, это, наверное, лучший выход.# 2, очевидно, не идеален из-за длительного времени цикла.№ 3 заманчив и доставит вам в значительной степени невероятное количество неприятностей.Вот причина, почему:если вы развертываете исправления для тех, кто в них нуждается, по мере необходимости, вы полностью теряете какую-либо рациональную схему управления версиями, и отслеживать, у какого клиента какие исправления и какие версии, в лучшем случае сложно.

Answer 4

Я видел графики выпусков по одному.Планируется первый релиз, более масштабный, включающий функции, возможно, через 6-8 недель, а иногда и больше.Второй - плановый ремонт с интервалом в 2 недели.Итак, каждые 10-12 недель у вас выходит по 2 релиза.