Рабочий процесс

Использование рабочих процессов для удовольствия и прибыли

Все ненавидят «процесс», но давайте посмотрим правде в глаза: без налаженного рабочего процесса вы никуда не пойдете быстро.

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

Начните просто, начните сейчас

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

• СДЕЛАТЬ

    Работа, которая еще не началась

• В ХОДЕ ВЫПОЛНЕНИЯ

Работа, которую активно изучает команда.

• ОБЗОР КОДА

Работа, которая завершена, но ожидает рассмотрения.

• СДЕЛАНО

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

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

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

• В ожидании QA (оценки качества)

Работа, которая была выполнена, но все еще ожидает обзора тестеровщиком (подробнее см. Нашу статью о Agile тестировании).

• ГОТОВ К СЛИЯНИЮ

Код, который был рассмотрен и готов к слиянию с основной веткой или веткой релиза.

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

Обсудите каждую болевую точку в ретроспективе команды и имейте в виду, что у каждой команды будут немного разные значения, основанные на их проекте, технологическом стеке и методе, в котором они хотели бы работать. Вот почему важно выбрать трекер задач, который имеет гибкую конфигурацию рабочего процесса. Слишком много команд ставят под угрозу свой стиль работы, чтобы соответствовать определенному набору инструментов, что разочаровывает всех. Таким образом, члены команды начинают избегать использования этого инструмента в целом, усугубляя разочарование по всей команде и в целом сеять хаос. А когда боевой дух падает, производительность страдает. Это двойной удар, которого мы все хотим избежать! Команды, которые плохо знакомы с Agile или не имеют межфункциональных навыков, часто заканчивают «мини-водопадами» (waterfalls) в своем рабочем процессе. Например, дизайн запускает рабочий элемент с макетом. Разработка делает реализацию. Тест подтверждает качество. Каждый статус блокируется до завершения предыдущего состояния. Звучит знакомо? Это водопад. Но мы можем сделать намного лучше с Agile рабочими процессами, чтобы разблокировать команду и упростить разработку.

Оптимизируйте рабочий процесс

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

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

• Какую работу выполнила команда?
• Увеличивается ли отставание в работе или идет в ногу с командой?
• Сколько элементов в каждом статусе?
• Есть ли какие-то узкие места, которые замедляют команду?
• Сколько времени занимает выполнение среднего задания?
• Сколько рабочих элементов не прошло наши стандарты качества с первого раза?

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

Вызовы масштабирования рабочего процесса

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

Agile команды, которые работают вместе, могут получить выгоду от совместного использования одного и того же рабочего процесса. Использование одного и того же рабочего процесса может облегчить переход работы между Agile группами, поскольку они используют одни и те же соглашения для определения и выполнения работы. Создание общего процесса обычно подразумевает взаимную отдачу от обеих команд. Это хорошо! Они будут учиться друг у друга и в итоге получат лучший рабочий процесс.

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

По материалам Agile Coach "Workflow"