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

Question

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

Рассмотрим этот сценарий ...

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

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

Answer 1

Alt + Tab - как мы это делаем.

Answer 2

Переключение задач - дело мозга. Я не думаю, что есть инструмент, чтобы сделать это для вас. Если есть, мне тоже интересно.

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

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

Наиболее эффективный способ для разработчика переключаться между задачами, на мой взгляд, субъективен. Между тем, вы читали Переключатели заданий, которые считаются вредными от Джоэла Спольски?

Answer 3

Я бы сказал, что шаги, которые необходимо предпринять в описываемом вами сценарии, на 100% зависят от среды разработки и инструментов, которые вы настроили.

Используя Perforce для контроля версий исходного кода, мы настроиливетвящаяся система, в которой выпуски отделены от работы по разработке, а все ветви разработки происходят из одной «приемочной» ветви.Каждая ветвь используется для одной проблемы или для набора очень тесно связанных проблем.Никакие другие проблемы не могут быть решены в ветви, пока изменения не будут интегрированы в ветку принятия.

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

После того, как разработка сделала свое дело (включая свою собственную)тесты), проблема проверяется командой QA.Сначала в изоляции в собственной ветке.После этого он интегрируется в ветку принятия и проводится регрессионный тест, чтобы найти любые проблемы с независимыми проблемами, кусающими друг друга.Когда все проблемы для выпуска, таким образом, интегрированы в принятие, команда QA выполняет полный регресс и новый тест функциональности.

Таким образом, ветвь принятия всегда является "последним" состоянием разработки приложения.

В этой настройке сценарий, который вы описываете, будет проигрываться следующим образом:

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

• Найти «пустую» ветвь - ветвь, которая в настоящее время не используется для какой-либо разработки, или, если все ветки заняты, создать новуюone.

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

• Синхронизируйте (принудительно при необходимости) последнее состояние ветви принятия с рабочей ветвью, чтобы выбранная рабочая ветвь совпадала с веткой принятия.

• Откройте набор приложений этой ветви вIDE, отладить и решить.Отправьте в рабочую ветвь.

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

• Верните IDE обратно для работы над набором приложений в той ветви, над которой я работал ранее..

• Сполосните и повторите.

Answer 4

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

Answer 5

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

Answer 6

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

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