Выполнять правила ведения рабочего процесса необходимо чтобы:
-
всегда иметь возможность узнать какие задачи в работе и какие задачи предстоит выполнить;
-
собирать статистику о результатах нашей работы для принятия управленческих решений в будущем.
Все приведённые здесь правила являются правилами «по-умолчанию». Для каждого конкретного проекта могут быть введены свои исключения, которые руководитель обязан донести до каждого участника проекта. Но если ни о каких исключениях в рабочем процессе не предупредили, нужно следовать нижеизложенным правилам.
Все рабочие задачи мы регистрируем в Trello. Рекомендуется изучить его стартовый гайд. Крайне полезно знать горячие клавиши системы, возможности поиска и фильтрации.
Одна Борда (Board) — один проект. В названии борды допустимы латинские символы, пробелы, цифры и тире.
Одна Карточка (Card) должна представлять одну конкретную задачу, которую нельзя или нет смысла разбивать на более мелкие. Задача карточки должна быть такой, чтобы её мог выполнить один Исполнитель (Member). Если для задачи нужно участие нескольких исполнителей, то следует разбить её на несколько карточек. За исключением проверяющего — его участие допустимо с любым другим исполнителем. Если в ходе работы стало понятно, что необходимо участие другого исполнителя, а часть работы уже сделана или ещё предстоит сделать текущему, то нужно создать для другого исполнителя отдельную карточку с уточнённой задачей.
У карточек следует указывать планируемое время на выполнение и время, которое было фактически потрачено на реализацию. Время указывается в часах. Планируемое время указывается в круглых скобках в начале названия карточки. Например, «(2) Разместить слепок старого сайта на поддомене» или «(?) Проверить весь код проекта». «?» ставится если невозможно указать точное время. Фактически затраченное время на выполнение задачи карточки обязательно указывается в квадратных скобках после названия карточки. Например, «(3) Добавить ручную сортировку авторов [4]».
Лэйблы (Label) красного, оранжевого, желтого цветов (#red, #orange, #yellow) используются для указания повышенного приоритета задачи.
Синий (#blue) лэйбл указывает на информационные карточки. Такие карточки предназначены для хранения информации о проекте полезной всем участникам. Данные о периодических работах над проектом, являются хорошим примером. К таким карточкам неприменимы правила для остальных карточек. Их рекомендуется хранить в колонке Hold (см. ниже).
Карточки в борде разбиты на Колонки (List), каждая из которых имеет своё назначение.
При итеративном подходе работа над задачами проекта разбивается на равные итерации — спринты (обычно неделя или две). Перед началом итерации выбираются задачи, которые планируется сделать в этот спринт и команда старается успеть их сделать за выделенное время.
В колонку Hold помещаются карточки задач, которые ещё нельзя брать в работу. Это могут быть задачи, по которым ещё требуются уточнения или иформационные карточки. Только руководитель или его уполномоченный может перемещать карточки этой колонки или удалять их.
В колонку Backlog помещаются карточки новых задач, которые готовы к тому, чтобы начать над ними работу. Из этой колонки выбираются задачи для работы в ближайшем спринте и переносятся в колонку Sprint. Если у карточки в этой колонке указан исполнитель, значит карточку в работу взять может только он.
Колонка Sprint содержит задачи, которые нужно выполнить в текущем спринте. В каждой карточке обязательно указан исполнитель. По завершению задачи карточки исполнитель указывает фактическое время выполнения задачи и переносит карточку в колонку Test для проверки. Любой участник может посмотреть все свои задачи в спринте по всем проектам вбив в поисковую строку команду:
is:open list:Sprint @me
В колонку Test помещаются карточки задач, которые нужно проверить. Тестировщик самостоятельно добавляется к карточке, которую начинает проверять. Если по результату проверки проблем не найдено, тестировщик переносит карточку в колонку Done. Если же найдены ошибки в реализации задачи, тестировщик пишет развёрнутый комментарий о найденных проблемах и возвращает карточку в Sprint. Из участников карточки он уже не уходит и, когда она снова будет перемещена в Test, должен будет её снова проверить.
Колонка Done содержит карточки с выполненными задачами. Руководитель проекта убирает карточку в архив, если его всё устраивает или возвращает её в работу в подходящую колонку, если нет.
Исправление багов — важная часть нашей работы и поддержания качества нашего продукта. На результат нашей работы мы даём гарантию в течении некоторого времени и обязуемся исправлять найденные проблемы в ПО, которые появились по нашей вине.
Но мы не должны бросать всю остальную работу, как только где-то появляется баг. Чтобы появившиеся баги не сломали всё планирование работы и не потерялись, у нас есть чёткий протокол фиксации и исправления багов.
Для регистрации найденных багов в борде проекта используется колонка Fix.
-
Найденный баг обязательно должен быть зафиксирован в колонке Fix новой карточкой любым участником;
-
Если в спринте проекта заложено время на исправление багов, то исполнитель должен начать работу по исправлению багов из колонки Fix, в рамках выделенных часов;
-
Если резерва на исправление багов нет или он кончился, нужно сообщить о появлении бага руководителю проекта, чтобы тот принял решение о приоритете его исправления. Если будет решено исправлять его сейчас, руководитель сам уберёт из спринта задачи с меньшим приоритетом и добавит карточку бага в спринт;
-
Допустимо начать исправление багов без согласования с руководителем даже если времени в спринте на это не выделено, если исполнитель уверен, что это не повлияет на другие его задачи в спринте. В этом случае вся ответственность за принятое решение ложится на исполнителя;
При водопадном подходе есть список задач, которые можно взять в работу и исполнители берут их в работу самостоятельно, согласно приоритету. Используются те же самые колонки, что и при итеративном подходе. Фактически различие в процессе состоит в том, что задачи из Backlog и Fix не накидываются руководителем в Sprint в начале каждого спринта, а переносятся исполнителем в тот момент, когда он сможет начать над ними работу.
-
все рабочие задачи, кроме борды Lichnoe:
is:open -board:lichnoe -
свои текущие задачи:
is:open list:Sprint @me -
задачи другого пользователя системы в спринте:
is:open list:Sprint @projkov -
задачи c указанным сроком:
is:open due:365 -
задачи без исполнителя, кроме тех, что в борде 'trello.com/b/w4r4VDBN/-' (борда с русским названием):
is:open -has:members -board:w4r4VDBN
В конце каждого дня каждый участник обязан отчитаться перед руководителем по времени, которое он потратил на рабочие проекты. Отчёт можно отправить или в чатике или по почте в простом текстовом формате: потраченное время и проект, на который оно потрачено.
Время можно учитывать или точно, используя таймер или программы по учёту времени, или примерно, когда день делится на 6 условных часов и работа по проектам примерно разделяются по ним. Смешивать эти два подхода категорически запрещено. Если решили перейти от примерного учёта времени к точному или наоборот необходимо уведомить об этом руководителя.
Так же следует указывать в отчёте если рабочее время ушло не на работу над одним из проектов.
Пример отчёта примерного учёта времени:
3 - Costa Bella
1 - Проектмаркетинг
1 - ревью R&D Парка
остальное время потратили на планирование
Пример отчёта точного ведения времени:
4:20 - Ledmaster
1:00 - сбор бэкапов
отлучался по личным делам на часок