Каков самый эффективный способ для разработчика переключиться между задачами?
Я ищу описание типа рабочего процесса серии шагов, которые Вы выполняете для переключения от одной задачи разработки программного обеспечения до другого. Если шаг включает инструмент, укажите, какой инструмент и как он используется. Цель рабочего процесса состоит в том, чтобы иметь самый гладкий переход от задачи № 1 до задачи № 2 и назад к задаче № 1.
Рассмотрите этот сценарий...
- Вы реализуете новую пользовательскую историю и, в то время как Вы сделали успехи до сих пор сегодня, она не совсем сделана, и Вы еще не реализовали свои тесты.
- Ваш вывод прибывает к Вам с высокоприоритетной ошибкой, это блокирует Вашу тестовую команду. Необходимо остановить то, что Вы делаете и зафиксировали ошибку. Ошибка находится в сборке от три дня назад, которая является новой сборкой, которую взяла тестовая команда.
Можно исправить ошибку в новой версии источников, но это должно быть стабильной версией и не может включать неполную функцию, Вы в настоящее время продолжаете работать.
6 ответов
Я бы сказал, что шаги, которые вам нужно предпринять в описываемом вами сценарии, на 100% зависят от среды разработки и инструментов, которые вы настроили.
Используя Perforce для управления версиями исходного кода, мы создали систему ветвления, в которой выпуски отделены от работ по разработке, а все ветки разработки происходят из одной ветки «принятия». Каждая ветвь используется для одной задачи или для набора очень тесно связанных задач. Никакие другие проблемы не могут быть решены в ветви, пока изменения не будут интегрированы до ветви принятия.
Да, это означает, что у нас много филиалов. Да, мы много синхронизируем (приемка до рабочей ветви) и интеграция (рабочая ветвь до принятия). Но его ценность неисчислима, когда дело доходит до легкого переключения с одной задачи на другую, возврата к тестовой сборке, выявления двух проблем, кусающих друг друга и т. Д.
После того, как разработка сделала свое дело (включая их собственные тесты), проблема проверяется командой QA. Сначала изолированно в своей ветке. После этого он интегрируется в ветвь принятия, и выполняется регрессионный тест, чтобы найти любые проблемы с независимыми проблемами, которые кусают друг друга.Когда все проблемы для выпуска интегрированы в приемку, команда QA выполняет полный регрессионный тест и тест новой функциональности.
Таким образом, ветвь принятия всегда является «последним» этапом разработки приложения.
В этой настройке сценарий, который вы описываете, будет разыгрываться следующим образом:
Оставить мою текущую задачу как есть, возможно, проверить все незавершенные изменения, чтобы не потерять их при сбое моего компьютера. Если это означает нарушение ежедневной сборки этой ветки, я бы не стал проверять, если это не легко исправить ошибки компиляции. (Обратите внимание, что у нас есть много приложений в нашем наборе приложений, и хотя мои изменения могут компилироваться в приложении, над которым я работаю, они все равно могут нарушать компиляцию других приложений в нашем наборе). Наше правило: каждая отправка может нарушить функциональность, но не должен нарушать процесс сборки.
Найдите «пустую» ветку - ветку, которая в настоящее время не используется для каких-либо разработок, или, если все ветки заняты, создайте новую.
Принудительно синхронизировать ветвь приема и выбранную рабочую ветвь, чтобы на моем компьютере гарантированно было последнее состояние для обеих ветвей.
Синхронизировать (при необходимости принудительно) последнее состояние приемной ветви с рабочей ветвью, чтобы выбранная рабочая ветвь была такой же, как и принимающая ветвь.
Откройте набор приложений этой ветви в среде IDE, отладьте и решите. Отправьте в рабочую ветку.
Скажите QA взглянуть на это в рабочей ветке. Если они удовлетворены этим, интегрируйте изменения до принятия, чтобы они могли продолжить свой тест.
Верните IDE для работы с набором приложений в ветке, над которой я работал раньше.
Промыть и повторить.
Переключение задач - это дело мозга. Я не думаю, что для вас есть инструмент. Если есть, мне тоже интересно.
У каждого человека свой способ подготовки, некоторые вообще не готовятся, а занимаются чем-то другим, например, снэпом, некоторым требуется больше времени и т. Д. Это зависит от мужчины / женщины.
Конечно, вы можете попытаться создать некоторые мысленные вехи (сделать заметку, разместить напоминание и т. Д.), Чтобы вернуться к ним, когда вернетесь к задаче, но это опять же зависит от других факторов (как долго происходило переключение задач, как тишина в офисе, знакомство с задачей, фазы луны и т. д.).
Я считаю, что наиболее эффективный способ переключения между задачами для разработчика - субъективный. Между тем, читали ли вы Переключения человеческих задач, считающиеся вредными от Джоэла Спольски?
Я записываю каждый файл, над которым я работаю, в элементе Task / Todo с напоминанием примерно через каждые 2 часа. количество времени, которое я буду вдали от него. Затем я сохраняю и закрываю каждый из этих файлов, чтобы они не отвлекали меня / устраняли беспорядок / создавали место для новой задачи на моем рабочем столе. Я помню блоху, поэтому мне нужна вся помощь.
Учитывая ваш сценарий,
вы можете проверить стабильную версию исходников в другой рабочей копии, исправить ошибку, зафиксировать.
Когда вы вернетесь к незавершенной работе, сделайте обновление и продолжайте работу.
Когда вы работаете над чем-то, у вас обычно есть несколько идей, несколько вещей, которые вы планируете сделать, некоторые вещи, которые непонятны и должны быть решены позже. Он имеет тенденцию теряться, когда вы переключаетесь на другую задачу.
Я счел полезным их где-нибудь записать - сделать снимок мозга. Позже его легче восстановить и быстрее вернуться к исходной задаче.