Как мне кажется, в нынешнем мире программного обеспечения появилась доминирующая политика выпуска релизов/версий продукта. Эта политика основана не на факте появления новых возможностей или исправления ошибок, а просто на временных интервалах. А новые возможности и исправления ошибок просто вписываются в график релизов. То есть фраза «когда выйдет новая версия, то мы…» трансформируется в «когда такого-то числа выйдет следующая версия, то мы…».
Данный подход удобен всем. Разработчики в этом случае могу спокойно планировать свои спринты, распределяя по ним план развития продукта, а клиенты могут посмотреть на план этот развития (например, мы его публикуем на сайте поддержки) и понять, что и когда им ждать. Их планирование также упрощается.
Есть тут небольшая загвоздка – это исправление ошибок. Оценить время исправления коварного бага порой не так просто. Хорошо, что такие случаи, скорее всего исключения, так как если они становятся правилом, то возникает вопрос просто о качестве софта в целом.
Мы выпускаем релизы каждый месяц. Мне, как так называемому branch owner’у (я не очень люблю использовать английские слова, но вот «ответственный за версию» как-то уж очень коряво звучит), гораздо проще составлять списки патчей для включения в релиз и планировать окна тестирования, когда дата выпуска всегда постоянна. Конечно, интервал релизов подобран так, чтобы не приходилось выпускать пустые релизы без каких-либо патчей.
И каковы ваши наблюдения на этот счет?
воскресенье, 17 мая 2009 г.
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
"в нынешнем мире программного обеспечения появилась доминирующая политика выпуска релизов ... на временных интервалах"
ОтветитьУдалитьНе у всех, не у всех, далеко не у всех.
"Мы выпускаем релизы каждый месяц."
Вау, я серьезно.
У долгоиграющих проектов с вытекающим из этого факта активным супортом - это очень разумная и удобная политика.
ОтветитьУдалитьА по поводу релизов -- да. Месяц - это отличное время, что бы разобраться с пятком багов, обновить документацию, перетащить пару фич из разработки и т.д. Для нас этот период пока оптимален.
Для коммерческих долгоиграющих проектов, которые не зависят, либо минимально зависят от каких-либо других сторонних проектов, это очень разумная политика, согласен, а периоды каждый под свой проект подстраивает.
ОтветитьУдалитьУ нас есть разделение - maintenance релизы и релизы нового продукта. Если первые делаются не по времени, а по готовности (исправлено X критических багов, стоит выпустить версию 1.01 и т.п.), то вторые - по времени. Но не раз в месяц, а раз в год. Год - достаточное время на то, чтобы наделать новых фич :)
ОтветитьУдалитьУ нас период выпуска релиза - около половины года.
ОтветитьУдалить>Мы выпускаем релизы каждый месяц.
А не слишком ли быстро растет нумерация релизов? Мне кажется, что это сложно для программиста вспомнить что вошло в релиз, который был месяцев 7 назад.
bishop: У нас похожая схема. Под релизами я имел ввиду именно maintenance, то есть багфиксы в основном, хотя иногда и новый функционал добавляется, если он не ломает обратную совместимость. Обратная же совместимость может быть нарушена только в новой версии/поколении, которая официально анонсируется раз в год.
ОтветитьУдалитьsanchosz: Программисту не надо это вспоминать. Каждые релиз сопровождается автоматической генерацией change-листа и списком версионных зависимостей между компонентами, чтобы можно быть автоматически воссоздать полную среду, работая в которой, клиент обраружил проблему.