Неправильный термин "замораживание кода"

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

Ситуация развития

Мы заканчиваем наш третий и последний спринт, за которым последует "замораживание кода" и 2 недели тестирования Q/A. Это большой релиз, а разработка некоторых компонентов превзошла все три спринта. Исторически, хотя мы называем это "Кодовое замораживание", мы по-прежнему совершаем код для исправления ошибок.

Проблема

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

Похоже, что определение Википедии согласен со мной здесь

Анализ

Я подозреваю, что при вызове этих ситуаций "Кодовое замораживание" является своего рода умышленным Double Think, чтобы обеспечить ложную уверенность держателям ставок. Или мы притворяемся, что находимся в ситуации "замораживания кода", потому что, согласно Scrum после каждого спринта, у нас должен быть shippable часть программного обеспечения, и мы ожидаем, что мы следим за Scrum. Поэтому мы должны назвать это тем, что ожидает Scrum, а не то, что оно есть на самом деле.

Заключение

Разве я это анализирую? Я просто считаю, что это нездорово игнорировать реальности ситуаций и должно либо отказаться от него, назвав его чем-то, либо не устранить проблему с корнем. Имеет ли кто-нибудь другой опыт с Code Freezes?

Ответ 1

Мы используем термин "Feature Complete". Все функции закодированы и функциональны, но мы направляемся в тестовый проход, чтобы подтвердить, что ошибок нет. Если есть ошибки, мы их найдем, исправим и повторим. После того, как мы удовлетворены результатом, мы "Code Complete".

Ответ 2

Могу ли я анализировать это?

Да.

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

Но если вы не собираетесь исправлять ошибки, то замораживание кода просто бессмысленно: просто создайте и отправьте его.

В конечном счете важно то, что вы все понимаете, что подразумевается под ярлыком, а не сам ярлык. Один большой счастливый Шалтай-Болтай...

Ответ 3

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

Ответ 4

Некоторые люди, которые попадают в адаптивные и гибкие инженерные методологии, такие как scrum, могут не понимать, к чему вы пришли.

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

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

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

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

Замораживание кода - это замораживание кода.

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

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

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

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

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

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

Ответ 5

Да, это завышено. Да, это неправильно.

Если код не сломан/беспорядочен, вы его не трогаете, и если это произойдет, вы его исправите. Это точно такая же ситуация, как если бы вы не находились в режиме замораживания кода. Да, это "замораживание требований" или "разрыв интеграции", которые являются анти-шаблонами. Это точка, в которой можно прекратить включение новых функций в следующий выпуск, что является ценным в аспекте продаж/маркетинга/customersupport. Но они должны, вероятно, назвать это "предварительным".

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

Имя Lean для "замораживания кода" - "отходы".

Ответ 6

Я работал над проектом (водопад), в котором у нас была функция замораживания и блокировка кода.

Функция замораживания означает начало периода исправления. Также была создана новая ветвь для новой версии, чтобы мы могли реализовывать функции, то есть это тот момент, когда компания начинает работать над новой версией. Никаких новых функций не реализовано, исправлены только ошибки.

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

Сводка: после замораживания функции вы можете только проверить исправления. После замораживания кода вы можете зарегистрироваться только в исключительных случаях.

Ответ 7

В своем комментарии вы упомянули слово "спринт". Это говорит мне, что вы можете использовать методологию Scrum (или любую другую Agile). В Scrum вы почти ничего не "замораживаете":) Гибкость, идентификация рисков и смягчение их последствий, и прежде всего, с точки зрения инженерии, непрерывная интеграция имеет большое значение в Scrum.

Учитывая это, команда должна быть кросс-функциональной, и код будет постоянно интегрирован. В результате у вас могут не быть таких вещей, как "замораживание кода". У вас есть только готовый продукт в конце спринта. Он должен был быть протестирован непрерывно, и вы должны были уже получить отчеты об ошибках, которые вы должны были исправлять уже.

Ну, это теория. Тем не менее, хорошие команды схватки не слишком далеки от теории, так как схватка в основном связана с принципами. Существует не так уж много правил.

Я лично не разорву слишком много волос по терминологии, но намерение этого термина. Скорее всего, этот термин используется для определения этапа в SDLC в вашей организации. Говоря строго по Scrum, он не имеет фазы исправления ошибок. В случае, если вы посвящаете один или несколько спринтов для исправления ошибок, этот термин может означать: "в спринте не будет включено отставание функций, но только исправления ошибок". Это можно легко обработать на совещании по планированию (и предпланировании) спринта, и команде даже не нужно беспокоиться о терминологии. Более того, эта терминология/намерение даже не должна выходить за рамки продукта.

Ответ 8

Хотя "Кодовое замораживание" может иметь омрачающее значение и, как уже упоминалось, более метко "Блокировка функций" при рассмотрении отдельных проектов/выпусков, он имеет место в более крупном интегрированном развертывании, где ответственен другой объект для упаковки и/или развертывания нескольких выпусков программного обеспечения от различных команд. "Кодовое замораживание" дает им время, чтобы убедиться, что среды выстроились в очередь и все пакеты учтены. "Кодовое замораживание" также означает, что ничего не происходит, кроме изменений "show stopping". Все остальное будет обработано в следующей версии обслуживания.

В идеальном мире тестовое тестирование завершилось бы до этого момента, и было бы время для развертывания любых последних исправлений и повторного тестирования. Я еще не видел, чтобы это произошло на любом "глобо-корпусе". Тестировщики (бизнес) тестируют до и даже после развертывания, а "Кодовое замораживание" становится сигналом для них, чтобы активизировать свои усилия и регистрировать все, что они сидели. В некоторых случаях это сигнал для тестирования START.

Действительно, "Кодовое замораживание" - это просто бизнес, говорящий "Здесь есть Tygers".; -)

Ответ 9

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