Здравствуйте, Lonely Dog, Вы писали:

LD>Привет!

LD>Есть некий продукт. Объем исходного кода на данный момент около 150т. строк (С++), плюс 35т строк в CustomActions инсталяторов, плюс ХЗ сколько в WIX, плюс гайды (два языка, гайд по установке, администрированию (2 шт), использованию), Плюс Хз сколько на плагины.

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

LD>Полный цикл тестирования продукта занимает неделю. (проверка около 1000 test-case-ов, на 2000, XP, Win2003 с разными SP)
LD>Билды выходят как правило каждый день.
LD>Беспокоит непереодичность выпуска версий. Т.е. мы или поправили некоторое количество критичных багов, или реализовали полезный функционал, и в какой-то момент говорим "все, начинаем стабилизировать версию, новые фичи не добавляем. Только правим баги." После этого, тестеры начинают полностью гонять систему (не поломалось ли чего). до этого, они как правило тестируют только те части, которые правились, плюс смежные с ними.

А почему Вас это беспокоит? Из соображений что отсутствие переодичности вредит дисциплине разработки? Или пользователи\клиенты недовольны непереодичностью. Иногда фиксированная длина итерации вредит, если не соответствует "естественной" продолжительности разработки какой-нибудь фичи.

LD>Короче, хочется ввести понятие итерации. Т.е., есть список фич которые мы решили реализовать и багов, которые мы решили побороть. Из них выбираем самые приоритетные с тем расчетом, что бы все было готово через 3 недели. Еще неделю берем на полное тестирование. Итого, раз в месяц у нас будут выходить новые версии. Меня смущает именно этот месяц. Почему новые версии обязательно надо выпускать раз в месяц. Каждый день мы их выпускать не сможем. Раз в год выпускать — тогда лучше вообще ничего не делать. Да и вообще, нет у меня пока четкого понимания, как это лучше всего организовать.

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

Насчёт организации могу привести конкретный пример, без претензии на универсальность и применимость в вашем случае.
У нас две независимые ветки кода, которые переодически объединяются. Одна ветка для багов, которые надо срочно побороть. Релиз из неё раз в неделю. Тестировать легче, потомучто в эту ветку пускаются только мелкие изменения, преимущественно багфиксы. Вторая ветка для более крупных фич. Релиз оттуда каждые 6 недель. Из них 4 недели на разработку и 2 недели на тестирование и стабилизацию с codefreeze за 2 недели до релиза. Конкретные длины интервалов были выбраны из соображений потребности бизнеса — хотят наши пользователи новую версию каждую неделю. У Вас может получится целесообразным выбрать более длинные интервалы.

LD>Жду ваших комментариев.
LD>Заранее спасибо.