Что такое реалистичный (но быстрый) график бета-версий?

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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