Есть некий продукт. Объем исходного кода на данный момент около 150т. строк (С++), плюс 35т строк в CustomActions инсталяторов, плюс ХЗ сколько в WIX, плюс гайды (два языка, гайд по установке, администрированию (2 шт), использованию), Плюс Хз сколько на плагины.
Полный цикл тестирования продукта занимает неделю. (проверка около 1000 test-case-ов, на 2000, XP, Win2003 с разными SP)
Билды выходят как правило каждый день.
Беспокоит непереодичность выпуска версий. Т.е. мы или поправили некоторое количество критичных багов, или реализовали полезный функционал, и в какой-то момент говорим "все, начинаем стабилизировать версию, новые фичи не добавляем. Только правим баги." После этого, тестеры начинают полностью гонять систему (не поломалось ли чего). до этого, они как правило тестируют только те части, которые правились, плюс смежные с ними.
Короче, хочется ввести понятие итерации. Т.е., есть список фич которые мы решили реализовать и багов, которые мы решили побороть. Из них выбираем самые приоритетные с тем расчетом, что бы все было готово через 3 недели. Еще неделю берем на полное тестирование. Итого, раз в месяц у нас будут выходить новые версии. Меня смущает именно этот месяц. Почему новые версии обязательно надо выпускать раз в месяц. Каждый день мы их выпускать не сможем. Раз в год выпускать — тогда лучше вообще ничего не делать. Да и вообще, нет у меня пока четкого понимания, как это лучше всего организовать.
Сразу определимся — описанное ниже (релизы раз в месяц) — это данность (as is) или же вы пытаесь промоделировать и установить эту самую периодичность (to be)? Ниже напишу с точки зрения to be, т.е. как мне это видится.
LD>Есть некий продукт. LD>... LD>Полный цикл тестирования продукта занимает неделю. (проверка около 1000 test-case-ов, на 2000, XP, Win2003 с разными SP)
ОК, много кода -> много тестов.
LD>Билды выходят как правило каждый день.
Уточнение — выходят каждый день... но при этом тесты гонятся неделю. У вас несколько тестовых команд, работающих параллельно? Или это просто ночные сборки, не всегда отправляемые на тесты?
LD>Беспокоит непереодичность выпуска версий. Т.е. мы или поправили некоторое количество критичных багов, или реализовали полезный функционал, и в какой-то момент говорим "все, начинаем стабилизировать версию, новые фичи не добавляем. Только правим баги." После этого, тестеры начинают полностью гонять систему (не поломалось ли чего). до этого, они как правило тестируют только те части, которые правились, плюс смежные с ними. LD>Короче, хочется ввести понятие итерации. Т.е., есть список фич которые мы решили реализовать и багов, которые мы решили побороть. Из них выбираем самые приоритетные с тем расчетом, что бы все было готово через 3 недели. Еще неделю берем на полное тестирование. Итого, раз в месяц у нас будут выходить новые версии. Меня смущает именно этот месяц. Почему новые версии обязательно надо выпускать раз в месяц.
Вопросы сразу:
1) Откуда взято 3 недели?
2) Насколько много багфиксов и новых фич выпускается еженедельно?
Стабилизация — это правильно, но ведь и фиксы должны доставляться в продукт как можно быстрее. Зачем ждать 3 недели? Допустим, в работе на ближайшие 2-3 недели у вас стоит пофиксить 20 багов и доимплементить 2 фичи. И баги, и фичи между собой приоритезированы. Шаги следующие:
— Фиксится первые несколько багов, из расчета сделать до конца очередной недели.
— В кончце недели просматривается статус фиксов и разрабатываемых фич.
— Если самая приоритетная фича готова — готовят код для интерации. Если вся фича не готова, а готова только часть, которая может быть заинтегрирована отдельно (фича при этом "выключена") — аналогично, готовится код для интеграции
— Делается релиз для тестеров с пофиксенными багами + выбранным кодом новой фичи (если есть).
— Релиз тестируется (неделя). Если всё нормально — новая протестированная кодовая база становится т.н. бэйзлайном (baseline) для дальнейшей разработки.
— К концу недели тестирования уже известно о новых готовых багфиксах + становится ясно, что надо пофиксать с прошлого релиза.
— далее — см. шаг первый.
В итоге:
— один шаг интеграции — неделя или около того, т.е. доставка фиксов в продукт происходит постоянно
— фичи интегрируются постоянно
— у разработчиков фич раз в неделю появляется свежий бэйзлайн для того, чтобы их разработа не тормозилась старыми багами.
Для больших фич подобные циклы можно делать отдельно, периодически синхронизируясь с основным потоком разработки.
LD> Да и вообще, нет у меня пока четкого понимания, как это лучше всего организовать.
Собсно, так и организуй
У нас модель разработки похожа, с той разницей, что интеграция происходит почти каждый день + много всего сверху навешано специфичного для нашего заказчика. Плюс, компонентов в продукте — несколько десятков... и команд по миру — с десяток . Но в целом — именно так и делается всё.
Конечно, при такой организации не обойтись без грамотного Configuration Management'а . Вот тут
Привет,
Скажу как руководитель компании по разработке (порядка 50 человек)
Имеем порядка 80 заказчиков (70 — продукт первого типа, 10 — продукт 2 типа)
Зарабатываем не на продажах ПО а на его сопровождении,
Как следствие постоянный поток заявок на доработки и внедрение нового функционала (на данном рынке уже 10 лет),
так вот — выпуск версий каждый месяц — это то что надо (так как каждый месяц по сути идут изменения в законодательной базе),
как раз все заявки подбиваются, идет тестирование, выпуск версии, и все опят по кругу,
главное четко придерживаться плана графика... ну и сопровожденцев иметь опытных,
тех которые смогут убедить клиента перенести свою заявку на следующую версию (просто по причине того что в план к программистам она уже не влазит)
На самом деле да, такие требования обычно ставятся бизнесом. Спросите у бизнеса сколько они хотят, и если скажут меньше месяца, то пытайтесь договорится на четыре недели У вас только тестинг занимает неделю, и еще нужна будет неделя на реакцию и на верификацию. Т.е. timeline в минимальном размере:
1 неделя
фича програмируется
2 неделя
фича тестируется
3 неделя
фича уходит на доработку
4 неделя
фича верифицируется и в конце недели выносится решение попадает ли фича в релиз или же нет...
Здравствуйте, Aquary, Вы писали:
A>Сразу определимся — описанное ниже (релизы раз в месяц) — это данность (as is) или же вы пытаесь промоделировать и установить эту самую периодичность (to be)? Ниже напишу с точки зрения to be, т.е. как мне это видится.
Релизы раз в месяц это даже не to be, а мысли по поводу. Хочется, чтобы выход версий был более прогнозируем.
A>ОК, много кода -> много тестов. Сервер у нас тестируется автоматически. Клиенты руками.
LD>>Билды выходят как правило каждый день. A>Уточнение — выходят каждый день... но при этом тесты гонятся неделю. У вас несколько тестовых команд, работающих параллельно? Или это просто ночные сборки, не всегда отправляемые на тесты?
Команда одна. Билды выходят каждый день. Например, разработчик поправил багу или сделал новую фичу. Он собирает билд и пишет письмо на команду, "версия вышла, исправлено то-то". Тестеры проверяют только его исправление. Это занимает несколько часов. В какой-то момент мы видим, что в критичных багов (или недоделаных фич) не осталось. После этого запускается полный цикл тестирования для проверки, что ничего не поломалось.
A>Вопросы сразу: A>1) Откуда взято 3 недели?
В месяце 4 недели. Одна неделя на полное тестирование. Итого, через три недели все должно быть готово. A>2) Насколько много багфиксов и новых фич выпускается еженедельно?
Сложно сказать. Таких оценок мы не делали.
A>Стабилизация — это правильно, но ведь и фиксы должны доставляться в продукт как можно быстрее. Зачем ждать 3 недели? Допустим, в работе на ближайшие 2-3 недели у вас стоит пофиксить 20 багов и доимплементить 2 фичи. И баги, и фичи между собой приоритезированы. Шаги следующие: A>- Фиксится первые несколько багов, из расчета сделать до конца очередной недели. A>- В кончце недели просматривается статус фиксов и разрабатываемых фич. A>- Если самая приоритетная фича готова — готовят код для интерации. Если вся фича не готова, а готова только часть, которая может быть заинтегрирована отдельно (фича при этом "выключена") — аналогично, готовится код для интеграции A>- Делается релиз для тестеров с пофиксенными багами + выбранным кодом новой фичи (если есть). A>- Релиз тестируется (неделя). Если всё нормально — новая протестированная кодовая база становится т.н. бэйзлайном (baseline) для дальнейшей разработки. A>- К концу недели тестирования уже известно о новых готовых багфиксах + становится ясно, что надо пофиксать с прошлого релиза. A>- далее — см. шаг первый.
Да, это было бы классно! Спасибо.
Здравствуйте, TihoTiho, Вы писали:
TT>так вот — выпуск версий каждый месяц — это то что надо (так как каждый месяц по сути идут изменения в законодательной базе),
Спасибо.
BG>1 неделя BG>фича програмируется BG>2 неделя BG>фича тестируется BG>3 неделя BG>фича уходит на доработку BG>4 неделя BG>фича верифицируется и в конце недели выносится решение попадает ли фича в релиз или же нет...
Кстати, да. Возможно, стоит именно такой график и ввести.
Здравствуйте, B0rG, Вы писали:
BG>У вас только тестинг занимает неделю, и еще нужна будет неделя на реакцию и на верификацию.
Ну ведь верификация + регрессионное тестирование может выдать баги разной серьезности и размера фикса. И пока исправишь абослютно все проблемы — может пройти больше недели. В общем, стаблизация фичи — это дело, которое нельзя оценить по ресурсам один раз и навсегда. Нужно прежде всего иметь подробные метрики по компании и проекту.
BG>1 неделя BG>фича програмируется BG>2 неделя BG>фича тестируется BG>3 неделя BG>фича уходит на доработку BG>4 неделя BG>фича верифицируется и в конце недели выносится решение попадает ли фича в релиз или же нет...
График подходит для одной фичи, но когда их делается несколько одновременно + стабилизация из предыдущего пункта + идет фикс появляющихся багов (я имею в виду баги от кода на пересечения разных фич)- подобная схема не совсем подходит, вернее сказать, сильно усложняется.
В общем, всё зависит от продукта, команды, количества интегрируемых фич и количества/качества находимых проблем. Я бы сказал — ваш и мой вариант — это две крайности к одной между которыми автору топика придется ходить в ходе анализа и апробирования
Здравствуйте, Lonely Dog, Вы писали:
BG>>1 неделя BG>>фича програмируется BG>>2 неделя BG>>фича тестируется BG>>3 неделя BG>>фича уходит на доработку BG>>4 неделя BG>>фича верифицируется и в конце недели выносится решение попадает ли фича в релиз или же нет... LD>Кстати, да. Возможно, стоит именно такой график и ввести.
В реальных боевых условиях понятно все намного сложнее, т.е. не обязательно неделю на верификацию туды сюды, и решение о релизе не обязательно на 4 неделю, и еще девелопмент стримов (бранчей) может быть несколько одновременно, соответственно тестинг и мерджинг становится нелинейной задачей, и процесс regression test увеличивается по времени.
Опять же зависит от того сколько людей, и есть ли свой собственный release team — т.е. люди, которые отвечают только за релиз (merge deploy build), т.е. когда в конце 4 недели появляется лист go/no go, то на 5 неделе, это отправляется к релизерам, а программеры и тестеры начинают работать уже над следующим релизом. Понятное дело, что "коробочный" релиз выпустится к концу недели номер 5, но когда процесс встанет на рельсы, то релизы пойдут 9, 13, 17, 21 недели.
в принципе в ветке много всего написали, но одно соображение выскажу — попробуйте разбить тестирование на этапы как это делается для промышленных систем. То бишь фича тестирование покрывает только новую функциональность (и часть функциональности "около" ваших изменений — регрессионное тестирование) и дает добро на интеграцию в релиз. Релизы выпускаются раз в неделю и проходят сначала через Sanity тестирование — проверяется минимальная функциональность высокого уровня и дается добро на выпуск релиза, если ошибок нет или они незначительны. Раз в месяц можно запускать самое полное тестирование (типа System test-а получается) на неделю, а когда начнется подготовка релиза к сдаче заказчику имеет смысл гонять регрессионные тесты для всех проблем найденных в течении подготовки новой версии (должна быть база ошибок из которой довольно легко выдернуть сценарии всех ошибок исправленных в этой версии).
Таким образом качество продукта будет высоким, а трудозатраты примерно теми же, что и с полным тестированием каждую неделю.
Здравствуйте, 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>Заранее спасибо.
