Как сделать эффективный обзор кода во время выпуска лихорадки?

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

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

Ответ здесь заключается в том, чтобы общаться.

1. Сообщите техническому / командному руководителю о проблеме
2. Поговорите с QA о потенциальном воздействии
3. Скажите руководству проекта (кто стоит за вами), что может быть проблема, которая вызывает задержку выпуска, и вы вернетесь с ними как можно скорее (в течение нескольких минут или часов)
4. Оцените, является ли этот выпуск пробкой для выпуска

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

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

Скорее всего, менеджмент не будет рад по поводу шоу-пробки в конце игры, но не захочет, чтобы его выпустили в производство.

Общайтесь, и пусть руководство сделает звонок.

Не просто сообщайте о проблеме, документируйте ее

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

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

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

Определить риск и влияние

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

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

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

Когда ваш следующий релиз?

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

Если есть вероятность, что решение вашей проблемы будет «деприоритизировано» (то есть пренебрегано в пользу следующего блестящего улучшения), то это еще одна причина, чтобы документировать проблему как можно скорее после того, как вы ее обнаружите: если эффективно «начинает» часы »по вопросу.

В этом случае просто сообщите всем, и пусть они решают. Это, вероятно, не первая ошибка, которую вы выпустили.

Последний срок - завтра, но вы попадаете в эту ситуацию:

менеджер проекта стоит над вашим плечом и прижимает вас, чтобы наконец сделать сборку

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

Представьте этот сценарий тому, кто ведет эту вещь.

• Определите, какие типы проблем должны быть представлены.
• Определите варианты.
• Кто принимает решение
• Когда все это должно быть решено? Это, вероятно, будет относительно даты выпуска.

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

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

В такой ситуации вы можете быть совершенно уверены, что некоторые критические ошибки пройдут.

Вы можете оказаться в счастливой ситуации, например, отправив заявку в Apple App Store, где у вас есть несколько дней, чтобы отказаться от новой версии. Но если ваш код будет доставлен клиентам, это может привести к катастрофе. В следующий раз, надеюсь, ваш менеджер планирует лучше.

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

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

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

Вот несколько советов, чтобы смягчить проблему:

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