Что такое планы доставки?
По мере роста организаций разработки они должны реорганизовать в небольшие команды, которые могут эффективно управлять частью работы. Обычно эти команды имеют свои рабочие расписания, советы и другие процессы, которые соответствуют их уникальным потребностям в контексте более крупных целей организации. Со временем организации могут найти, что они пользуются преимуществами сети, консолидируя свои процессы вокруг согласованной платформы.
План доставки — это визуализация одного или нескольких рабочих расписаний. Он предназначен для того, чтобы давать командам и руководству общее представление о том, что каждая команда планирует создать и когда. Это позволяет принимать решения, которые оптимизируют инвестиции в рамках всей организации.
Команды должны регулярно проверять свои планы выполнения на соответствие расписаниям других команд. Эти проверки должны отвечать на следующие вопросы:
- Мы уверены, что сможем выполнить то, что обязались сделать, по текущему расписанию?
- Уверены ли мы в том, что команды, от которых мы зависят, будут доставлять то, что нам нужно по текущему расписанию?
- Есть ли забавы в нашем расписании, что мы могли бы заполнить работой?
- Имеются ли проблемы с зависимостями внутри команды или между командами?
Планы доставки добавляют ценность в любой момент жизненного цикла проекта. Поскольку они создаются динамически на основе невыполненной работы команд, они всегда актуальны и содержат самую свежую аналитику.
Присоединимся к веб-команде Tailspin в своем обсуждении.
Энди: У меня просто была отличная встреча с инженерным управлением. Я продемонстрировал результаты нашей работы в Azure Boards, и они загорелись идеей привлечения других команд.
Мара: Удивительный! Когда они начнут работать?
Энди: Это лучшая часть. У них уже есть! Вчера вечером руководитель проекта игрового двигателя создал команду с некоторыми спринтами и начал добавлять рабочие элементы. Я сегодня утром бегло посмотрел результат — выглядит очень неплохо. Позвольте мне показать вам, что они до.
Энди переходит к текущей спринт-доске игрового двигателя. Он и Мара просматривают рабочие предметы с большим интересом.
Энди: Хмм... Я просто заметил, что они не планируют развернуть свою бета-версию к концу этого спринта. Не планируется ли интегрировать нашу базу лидеров с бета-базой данных во время следующего спринта? Мы не можем сделать это, если они не отправят бета-версию.
Мара: Это хорошая точка. У нас есть зависимость от этой команды, чтобы производить эти доставить, чтобы мы могли производить один из наших собственных.
Энди: Это может действительно повредить нашей производительности следующий спринт. Я собираюсь дать им звонок, чтобы узнать, что происходит.
К сожалению, более сложные структуры команд могут привести к пробелам или задержкам в взаимодействии. Когда одна команда заблокирована, они могут не иметь возможности создавать то, что другая команда зависит от. Это не может быть основной проблемой для небольшой группы команд, которые имеют ежедневные встречи для всех заинтересованных. Однако, по мере того как команды масштабируется по размеру и расположению, это может стать неприменимым для всех, чтобы знать все, что происходит везде. На этом этапе организации необходимо переходить от модели только "отправки" (например, личные обращения или объявления по электронной почте) к модели "получения" (в которой команды могут просматривать и отслеживать расписания друг друга).
Энди: Хорошо, я просто говорил с ведущим разработчиком. Она сказала, что их команде заблокировали поставку бета-версии, пока арт-команда не вернется из Клиффчеллы.
Мара: Горный музыкальный фестиваль?
Энди: Да, очевидно, это важное мероприятие для дизайнерского сообщества, и вся команда просто выпадает из графика на целую неделю для участия в нем. Команда игрового двигателя довольно расстроена, потому что она поскользнула свое расписание на три недели. Если бы они знали, что это происходит, они бы убедились, чтобы получить артефакты, которые они нуждались в впереди времени. Они также извинились за то, что не дают нам знать раньше. Они не поняли, что мы будем ждать их бета-версии, чтобы отправить нашу часть.
Мара: По крайней мере, мы можем порадоваться, что разработчики игрового движка публикуют свои планы спринтов. Это помогло нам найти эту проблему зависимости достаточно рано, чтобы изменить наше расписание.
Энди: Я просто хочу, чтобы был способ увидеть эти потенциальные риски, которые будут более легко. Наши команды имеют так много зависимостей по всей компании, что мы не можем посещать каждое собрание и подписываться на каждую группу рассылки.
Мара: Мы должны создать план доставки, чтобы мы могли видеть наши команды спринты параллельно. Это поможет обеим командам легко определить влияние наших планов друг на друга.
Рекомендации по управлению несколькими командами Agile
Agile-подход в сочетании с использованием Azure DevOps может значительно повысить прозрачность и прогнозируемость проекта. Однако в проектах по-прежнему могут возникать традиционные проблемы, часто связанные с персоналом или передачей информации. Ниже приведены некоторые аспекты, которые следует учитывать при масштабировании ваших гибких усилий.
Создание доверия к вашим людям и процессам
Противники внедрения Agile на ранних этапах часто скептически относятся к способности этой методики улучшить работу команды. Важно, чтобы руководители мысли в организации создавали доверие, иллюстрируя, как средства и процессы создают результаты. Иногда эти результаты связаны с повышением эффективности работы, и их легко измерить. Однако не забудьте выделить команду побед, которые происходят, обходя потенциальные проблемы, такие как избегаемые скольжения расписания или проблемы качества. По мере того как сотрудники осознают выгоды от используемого процесса, у них появится больше энтузиазма.
Повышение уровня организации над командой (и отдельными)
Некоторые команды и отдельные лица получают территориальные права при предложении новых процессов или политик. Вместо того, чтобы обрамить новые политики как отрицательное отображение производительности конкретных команд или отдельных лиц, выделите, как новая прозрачность в организации сообщает всем о ожиданиях. Наличие одного места, где любой может проследить, как их работа связана с организацией, с ее целями приведет к тому, что важное значение их приверженности процессу.
Содействие культуре прозрачности
К сожалению, термин "прозрачность" имеет негативные коннотации. Никто не просит больше прозрачности, когда все идет здорово. Вместо этого прозрачность (или отсутствие их) часто обвиняется, когда команды борются. Несмотря на все возможности прозрачности, доступные для гибких команд, она по-прежнему зависит от честности отдельных лиц и команд. Подчеркнуть, что одна из причин прозрачности заключается в том, чтобы определить и устранить потенциальные проблемы, прежде чем это слишком поздно. Все понимают, что иногда люди бегают в обстоятельствах, которые не позволяют им встречать крайние сроки. Но если они не чувствуют себя в безопасности в сообщении разочаровывающих новостей до последнего возможного момента, он может иметь гораздо более разрушительное воздействие. Создание уровня комфорта с прозрачностью может начаться с благодарения людей за отчеты ожидаемых задержек как можно раньше.