Неправильное использование термина "Code Freeze"
Мне просто любопытно, считает ли сообщество приемлемым использование термина "замораживание кода" в ситуациях, когда мы прекращаем разработку, за исключением тестирования и исправления ошибок.
Ситуация развития
Мы только что завершили наш третий и последний спринт, за которым последуют "заморозка кода" и 2 недели тестирования Q/A. Это большой релиз, и некоторые компоненты разработки превзошли все три спринта. Исторически, даже если мы называем это "Замораживанием кода", мы по-прежнему фиксируем код для исправления ошибок.
проблема
В каждом выпуске я пытаюсь исправить своего менеджера и коллег, которые мы должны называть "Feature Freeze", потому что совершенно очевидно, что мы собираемся найти ошибки и зафиксировать код, чтобы исправить их, как только мы начнем тяжелое тестирование. Но они все еще продолжают называть это "заморозкой кода". Иногда мы все еще знаем ошибки и объявляем "Замораживание кода".
Определение Википедии, кажется, согласится со мной здесь
Анализ
Я подозреваю, что называть эти ситуации "заморозкой кода" - это своего рода преднамеренное двойное мышление, чтобы обеспечить ложную уверенность заинтересованных сторон. Или мы притворяемся, что оказались в ситуации "замораживания кода", потому что согласно Scrum после каждого спринта у нас должно быть готовое программное обеспечение, и мы ожидаем, что будем следовать за Scrum. Поэтому мы должны называть это тем, что ожидает Scrum, а не тем, что есть на самом деле.
Заключение
Я закончил анализировать это? Я просто считаю, что это нездорово игнорировать реалии ситуаций, и я должен либо отказаться от этого, называя это тем, чем не является, либо решить проблему с корнем. У кого-нибудь еще был подобный опыт с Code Freezes?
9 ответов
Мы используем термин "Feature Complete". Все функции закодированы и функциональны, но мы собираемся пройти тестовый прогон, чтобы подтвердить, что ошибок нет. Если есть ошибки, мы их найдем, исправим и проведем повторное тестирование. После того, как мы удовлетворены результатом, мы находимся в состоянии "завершить код".
Я закончил анализировать это?
Да.
Ну, наверное. Реально, вы должны дважды подумать, прежде чем вносить какие-либо изменения в код после замораживания. Ошибки должны пройти некоторый тест серьезности, особенно если исправление требует потенциально опасных изменений в кодовой базе или делает недействительным выполненное тестирование. Если ты этого не делаешь, то да, ты просто обманываешь себя.
Но если вы не собираетесь исправлять ошибки, то заморозить код бессмысленно: просто соберите и отправьте его.
В конечном счете, важно то, что вы все понимаете, что означает ярлык, а не сам ярлык. Один большой счастливый Шалтай-Болтай...
Я работал над проектом (водопад), в котором у нас была функция замораживания и замораживания кода.
Функция замораживания означает начало периода исправления ошибок. Также была создана новая ветка для новой версии, чтобы мы могли реализовывать функции, то есть с этого момента компания начинает работать над новой версией. Новые функции не реализованы, исправлены только ошибки.
Замораживание кода происходит, когда QA считает, что продукт находится в выпусковом состоянии (т.е. они не знают о каких-либо серьезных ошибках). Перед заключительным циклом тестирования объявляется заморозка кода (помните, что цикл тестирования может занять неделю). Если тест пройден успешно, он становится выпущенным продуктом. Если это не удается, то новые ошибки исправляются. Эти проверки контролируются архитекторами и менеджерами, и риск каждой линии практически документирован. Затем тестовый цикл запускается снова.
Сводка: после зависания функции вы можете проверить только исправления. После замораживания кода вы можете зарегистрироваться только в исключительных случаях.
Некоторые люди, которые используют адаптивные и гибкие методологии разработки, такие как scrum, могут не понимать, во что вы ввязались.
Причиной гибкой инженерии является предоставление вашим клиентам того, что можно использовать сейчас, и постепенное наращивание его удобства и функциональности.
- Если ваш проект планируется завершить через 18 месяцев, но если бы вы могли использовать что-то более полезное каждые 2 месяца - почему бы не выпускать функции каждые два месяца, а не ждать до 18-летнего великого святого дня, так как в любом случае проект будет длиться 18 месяцев,
- Требования ваших клиентов могут измениться, поэтому предоставление вашим клиентам возможности часто менять свое мнение, пока еще не слишком поздно, приводит к восторженным клиентам.
- Кто-то может выпустить модуль с открытым исходным кодом одного из ваших модулей через 10 месяцев, и тогда вам не нужно больше ничего делать, кроме как интегрировать этот модуль.
Таким образом, скраммеры, или, по крайней мере, мастера скрамов и / или менеджеры / архитекторы проектов требуют динамики схватки для модульности... модульность не достаточно хороша; но гранулируйте проект.
Вы должны детализировать свои модули до нужного размера и предоставить спецификации интерфейса контракта для каждого, чтобы изменения внутри модуля управлялись внутри модуля. Если ваш модуль сам по себе или из-за зависимости других модулей не может удовлетворить контрактный интерфейс, вам необходимо заморозить код, чтобы позволить вам транслировать контрактный интерфейс версии 1, чтобы другие группы могли продолжить работу, хотя и с меньшими, чем ожидалось, возможностями в следующем общем выпуске продукта.
Замораживание кода - это замораживание кода.
Если ваш код зависает с частыми задержками оттаивания, ваш scrum master и архитектор продукта не общаются или не выполняют свою работу должным образом. Возможно, нет смысла пытаться убедить ваше руководство в том, что оно использует какую-то отраслевую причуду, называемую гибким программированием. Или же руководству необходимо нанять архитектора и мастера, которые могут разработать и детализировать проект в соответствии с навыками команды, а также ожиданиями клиентов и технологическими ограничениями проекта.
Я думаю, что есть элементы управления и их Scrum Master, которые не понимают, насколько важен хороший архитектор даже для среды Scrum, и отказываются нанимать их. Хороший архитектор, который умеет слушать и работать с командой, неоценим для процесса разработки, потому что он / она должен постоянно адаптировать архитектуру к изменяющимся гранулярностям и ожиданиям.
Я также думаю, что есть элементы управления и их владелец Scrum, которые принадлежат к другому спектру вселенной программирования из-за неудачного опыта с более длинными циклами разработки, такими как водопад, которые, следовательно, думают, что Scrum предназначен для производства продукта в течение месяца и, следовательно, тщательного расследования. в кросс-модули эффектов не является действительно необходимым. Они садятся, смачивают пальцы в воздухе и выступают с отличным спринтом.
Если ваша команда испытывает частые оттаивания кода, вам, ребята, может понадобиться заморозить код всего вашего проекта и переосмыслить свою стратегию и понять, что причина в вашем отказе определить контракты модулей, которые соответствуют гранулярности модулей. Или вы, ребята, вообще определяете контракты модулей для того, чтобы возможности застрявшего модуля в настоящее время могли быть разорваны, чтобы позволить другим командам или модулям продолжить работу.
У вас, ребята, есть стратегия UML, которая помогает обнаружить предполагаемые функции релиза проекта и позволяет вам увидеть эффекты неактивного модуля, а затем посмотреть, какой модуль должен быть сфокусирован для достижения желаемого уровня выпуска продукта? Вы посещаете матчи и спринты, и у вас нет изображения UML, которое бы показывало, насколько вы продвинуты или отстали, так что вы просто бодрствуете радостно или слепо? Или ваш мастер схватки скажет "да" или "нет", хм... этот модуль кажется важным - фактически не имея четкого представления о том, какие модули являются наиболее гибкими по отношению к выпуску продукта.
Замораживание кода выпуска продукта достигается путем постепенного замораживания модулей. Как только модуль завершен, выполняется тестирование продукта, чтобы убедиться, что модуль удовлетворяет своему контракту и что модуль заморожен, чтобы сказать версию 2.1. Несмотря на то, что работа над этим модулем для 2.2 продолжается, проект в целом должен зависеть не от 2.2, а от 2.1. Стратегия заключается в том, чтобы минимизировать количество модулей, чьи контракты необходимо разморозить, когда тестируется выпуск продукта, и должен ли выпуск продукта сокращать его возможности. Если прогрессивная модульная заморозка не помогает вашей команде разработчиков... либо продукт настолько сложен, и ваше руководство недооценивает количество итераций для достижения надлежащего выпуска, либо модульная архитектура и стратегия требуют серьезного переосмысления.
Я думаю, на самом деле, что они более правильны в своей интерпретации. Замораживание функций, для меня, было бы остановкой для введения новых функций, но функции, которые в настоящее время находятся в стадии разработки, могут продолжаться до конца, или вы можете запланировать некоторую работу по рефакторингу, чтобы удалить технические долги без создания новых функций. Замораживание кода останавливает все новые разработки, в том числе рефакторинг. Единственный разрешенный код - это исправление ошибок, обнаруженных во время QA. Последнее похоже на то, что делает ваша команда.
В своем комментарии вы упомянули слово "спринт". Это говорит о том, что вы можете использовать методологию Scrum(или любую другую Agile). В Scrum вы вряд ли что-нибудь "заморозите":) Гибкость, идентификация рисков и снижение рисков, и, прежде всего, с точки зрения разработки, непрерывная интеграция очень важна для Scrum.
Учитывая это, команда должна быть межфункциональной, и код будет постоянно интегрирован. В результате у вас может не быть таких вещей, как "заморозка кода". У вас просто есть выпускаемый продукт в конце спринта. Он должен был постоянно тестироваться, и вы уже должны были получать отчеты об ошибках, которые вы должны были уже исправить.
Ну, это теория. Тем не менее, хорошие команды Scrum не слишком далеки от теории, так как Scrum в основном о принципах. Там не так уж много правил.
Лично я не буду слишком расстраиваться из-за терминологии, но намерений, стоящих за этим термином. Скорее всего, этот термин используется для обозначения этапа в SDLC в вашей организации. Говоря строго, как в Scrum, у него нет фазы исправления ошибок. В случае, если вы посвящаете один или несколько спринтов для исправления ошибок, этот термин может означать: "в спринт не будут включены никакие функциональные ошибки, а только исправления ошибок". Это может быть легко решено на совещании (ях) по планированию спринта (и предварительному планированию), и команде даже не нужно беспокоиться о терминологии. Более того, эта терминология / намерение даже не должны выходить за рамки Владельца продукта.
Да, это продумано. Да, это неправильно.
Если код не сломан / не запутан, вы бы его не трогали, а если это так, то вы это исправите. Это точно такая же ситуация, как если бы вы не были в заморозке кода. Да, это "замораживание требований" или "разрыв интеграции", которые являются анти-паттернами. Это точка, в которой следует прекратить включать новые функции в следующий выпуск, что ценно в аспекте продаж / маркетинга / поддержки клиентов. Но они должны, вероятно, назвать это "предварительным выпуском".
Что должно произойти, так это то, что в системе управления версиями всегда есть несколько высвобождаемых версий системы, и компания выбирает одну для отправки.
скудное имя для "замораживания кода" - "трата".
Хотя "замораживание кода" может иметь затуманенное значение и, как уже упоминалось, более уместно "замораживание возможностей" при рассмотрении отдельных проектов / выпусков, оно ДОЛЖНО иметь место в более широком интегрированном развертывании, где другая организация отвечает за упаковку и / или развертывание нескольких выпусков программного обеспечения от различных команд. "Code Freeze" дает им время, чтобы убедиться, что среды выстроены в линию и все пакеты учтены. "Замораживание кода" также означает, что ничего, кроме изменений "показа остановки", не происходит. Все остальное будет обработано в следующем техническом выпуске.
В идеальном мире тестирование по сценарию завершилось бы до этого момента, и было бы достаточно времени для развертывания всех последних исправлений и повторного тестирования. Я еще не видел, чтобы это произошло в любой "Globo-Corp". (Бизнес) тестеры тестируют до и даже после развертывания, и "замораживание кода" становится для них сигналом к наращиванию усилий и регистрации всего, на чем они сидели. В некоторых случаях это является сигналом для начала тестирования.
Действительно, "Замораживание кода" - это просто бизнес, говорят "Здесь будут Тайгеры".;-)
Когда мы замораживаем код, репо блокируется, мы надеемся, что исправлены все ошибки, которые вы намеревались исправить, и вы тестируете весь следующий этап тестирования перед переходом и сборкой в производство. если на эту итерацию намечены какие-либо выдающиеся ошибки, то лиды будут дышать вам на шею до тех пор, пока они не закроются, или будут признаны некритическими и оттолкнут назад итерацию. так что, да, это действительно заморожено.