Скрам–мастер также обеспечивает устранение любых препятствий на пути прогресса, чтобы команда могла сосредоточиться на своих областях ответственности. Скрам мастер обучает команду и помогает ей как коуч, поддерживает. Он помогает увидеть точки роста в процессах внутри команды. Также определяет узкие места в эффективности работы команды. Скрам мастер помогает увидеть надвигающиеся конфликты, в том числе определяет токсичных ребят в команде (доносит как с этим работать, чтобы это не приносило негативный опыт участникам команды). Наиболее эффективно Scrum можно использовать в стартапах, когда нужно постоянно улучшать продукты компании на основании обратной связи клиентов, а улучшения должны быть регулярными и заметными.
При использовании Kanban, например, участники команды ограничивают количество задач в колонках “В процессе” или “Выполняются” для избегания перегрузки и выявления узких мест. Kanban более гибок, чем большинство других agile-фреймворков, потому что вы можете добавлять или менять приоритеты задач в любое время. Kanban подходит для команд, которым необходимо быстро реагировать на входящие запросы или у которых быстро изменяются требования к продукту. Владелец Продукта отвечает за формирование видения совершенного и при этом реализуемого продукта. В его обязанности также входит курирование и приоритизация Бэклога Продукта. Около 50% времени Владелец Продукта проводит с клиентами и заинтересованными лицами, остальные 50% работает совместно с командой.
Если вы только начинаете изучать методологию Agile, то можете пропустить этот раздел и перейти к более практическим советам, но лишь на некоторое время. Чтобы понять, почему люди делают то, что делают, вам потребуется понять основы. Главный документ, описывающий как работать по этому подходу, — Scrum Guide. Проходят стендапы утром, либо днем, если есть разница во времени между офисами.
Scrum Group (скрам Команда)
SAFe оставляет меньше места для экспериментов внутри команд, поэтому некоторые практики Agile считают его только частично Agile, а другие считают его противоречащим Agile. Он хорошо работает для организаций с множеством автономных команд, которые уже используют процесс Scrum и сотрудничают над одним большим продуктом или доставкой. Подход Lean не является гибким фреймворком, и вам не нужно выбирать между подходом Lean или Agile для вашей организации.
Технический долг – это цена, которую команда платит за создание более простых и быстрых решений сейчас вместо более надежного подхода, который займет больше времени для завершения. Технический долг представляет собой дополнительную работу, которую придется выполнить в будущем после выбора более простого решения. Обычно такой долг проявляется через ошибки, которые команде нужно исправить позже, или через архитектуру, product backlog пример которая не масштабируется. Ранее Scrum Guide относился к командам Scrum как «самоорганизующиеся», что означает, что они могут выбирать только способы выполнения своей работы. В 2020 году Scrum Guide был обновлен, чтобы вместо этого использовать термин «самоуправляемые». Скрам не вводит сложных схем взаимодействия, не диктует, каким именно должен быть ваш процесс разработки, и что именно нужно делать людям.
Кейс Внедрения Методики Scrum В Геймдеве
Для этого он проводит регулярные встречи со всеми участниками проекта и убеждается, что все понимают, как они должны эффективно работать вместе. Бэклог помогает команде понять, что является важным, и создает прозрачность относительно следующих работ. Бэклог определяет и приоритизирует все индивидуальные усилия, необходимые для достижения различных целей и вех. За составление бэклога продукта отвечает Владелец продукта. Ограничение числа элементов, над которыми команда одновременно может работать, является одним из примеров. Другим примером является сама доска Канбан, которая помогает визуализировать рабочий процесс команды, чтобы легко обнаружить узкие места и избыточную сложность в рабочем процессе.
Все члены команды сначала предлагают темы для обсуждения, обычно записывая свои мысли на карточках для размышлений. Затем они объединяют их в общие темы, и вся команда голосует за то, какие из них они хотят обсудить. Скрам-мастер защищает команду, помогая решать проблемы и устраняя препятствия, находящиеся вне его контроля.
Устранение препятствий является одной из основных обязанностей Scrum-мастера и общей целью ретроспективных встреч. Даже в Agile рабочих средах оценки иногда рассматриваются как обязательства или сроки. И некоторые в Agile-сообществе считают, что все оценки являются формой ресурсов, поскольку они не создают ценности для клиента. Это мнение привело к движению #NoEstimates, которое призывает отказаться от оценок полностью.
Sos (scrum О Scrum’ах)
Приемочные тесты должны проводиться заказчиком или конечным пользователем. Вместо этого они определяют, построила ли команда то, что ожидал получить заказчик. Наиболее отличительные ценности и технические практики, которые делают XP отличным от Scrum, включают парное программирование, разработку через тестирование и непрерывную интеграцию.
Это хороший вариант для организаций, которые считают Scaled Agile Framework Enterprise (SAFe) слишком громоздким, а другие масштабируемые фреймворки — слишком легкими. Инвесторы, разработчики и пользователи должны иметь возможностьподдерживать постоянный ритм бесконечно. Agile помогает наладить такойустойчивый процесс разработки. Скрам основывается на эмпирическом управлении процессами, а не на детерминированном.
Эмпиризм означает, что процесс адаптируется к данным, получаемым в ходе работы. Очевидно, процесс с эмпирическим управлением всегда дороже, чем обычный процесс с детерминированным управлением. Поэтому детерминированный подход применяется всегда, когда механизмы процесса достаточно хорошо понятны. Если же механизмы плохо известны, детерминированный подход не приводит к продукту с необходимым соотношением «цена / качество» с первого раза, и продукт приходится переделывать. В частности, в Скраме отсутствуют конкретные рекомендации по техникам проведения скрам-мероприятий. Например, до 2020 года в Руководстве по Скраму в качестве примера приводился конкретный формат проведения мероприятия «Ежедневный Скрам» (с ответами каждого участника на three вопроса).
Кросс-функциональная Команда (cross-functional Team)
SAFe более детализирован, чем другие фреймворки, и предлагает решение для вызова масштабирования процессов Agile. Он объединяет элементы Agile, Lean-управления и системного мышления в модули. Команда, в которой все необходимые навыки для выполнения работы сосредоточены внутри группы. Такой состав снижает узкие места, вызванные зависимостью от других команд.
- В ней описаны процессы Scrum, роли в команде, встречи и события.
- Он зависит от обратной связи, от ситуации на рынке и множества других факторов.
- Если этого не делать, то из-за рыночных изменений либо новой информации некоторые задачи могут стать неактуальными.
- График увеличения лучше визуализирует изменения объема работ по сравнению с графиком снижения остатка.
- Это непрерывный процесс, в котором сотрудничают владелец продукта и разработчики.
- Предположим, что вы оцениваете свои истории по шкале от 1 до 50.
Если этого не делать, то из-за рыночных изменений либо новой информации некоторые задачи могут стать неактуальными. По окончании спринта вся команда совместно просматривает и изучает результат (инкремент). Разработчики демонстрируют продукт заинтересованным лицам. Владелец продукта определяет, возможно ли запускать созданный продукт.
Scrum-митинг, Или Стендап
PO фокусируется только на бэклоге продукта и работе с командой разработчиков, чтобы воплотить видение продукта в реальность. Согласно руководству по Scrum, «если элемент бэклога продукта не соответствует определению готовности, он не может быть выпущен или даже представлен на обзоре спринта. Вместо этого он возвращается в бэклог продукта для дальнейшего рассмотрения». В LeSS многочисленные agile-команды работают как единое целое, чтобы создать совместный поставляемый продукт. В LeSS каждая команда отвечает за свою отдельную часть продукта, но приложение выпускается вместе в одной общей поставке в конце каждого Спринта. Команда, имеющая все необходимые навыки, чтобы выполнять работу и не зависеть от тех, кто не является частью команды.
Когда вы работаете с одним из них, вы почти наверняка используете принципы и практики и другого также. «Поток – это движение и доставка ценности для клиента через процесс. В интеллектуальной работе наша основная цель — доставка ценности клиенту. Поэтому логично, что весь наш процесс должен быть ориентирован на оптимизацию потока». Метафизический термин, подобный “менталитет”, легко вызывает скептицизм, особенно в мире менеджеров, которые привыкли к конкретным планам, числам и структурам. Однако, внедрение гибких процессов без гибкого менталитета может привести команду к провалу, именно поэтому некоторые гибкие подходы терпят неудачу.
Помимо распределения ролей, важно, чтобы все участники команды были на одной волне и работали в направлении общей цели. Scrum, как и другие гибкие методологии, не терпит жесткого вертикального управления. Он напрямую взаимодействует с заказчиком, формулирует и ставит задачи.
Спринты — это двух-четырехнедельные циклы работы, в течение которых Agile-команды завершают элементы в Журнале Спринта, чтобы создать Инкремент продукта и получить отзывы заинтересованных сторон. Каждый спринт включает в себя несколько мероприятий, часто называемых «церемониями», которые устраняют необходимость в других встречах, добавляя ритм и структуру в рабочий процесс. Термины «Владелец продукта» и «Менеджер продукта» иногда путают, потому что в крупных организациях могут использоваться оба термина. В этом случае роль владельца продукта отчитывается перед менеджером по продукту (PM). Затем PM обычно управляет видением, потребностями клиентов и бизнеса.
Команды могут использовать баллы истории во время грумминга бэклога или встреч по оценке, чтобы получить более ясное представление о том, сколько работы они могут выполнить в каждом спринте. Препятствие – это то, что блокирует или замедляет прогресс команды в Agile. Это может быть ненужное совещание, техническая проблема или недостаток в предоставлении команде полномочий для принятия решений. Препятствием является буквально любое препятствие для работы команды. Команды используют эпики в Product Backlog, чтобы отслеживать более крупные, часто высокоуровневые идеи. Когда команды готовы к более детальной проработке, они разбивают эпики на более мелкие пользовательские истории, которые могут быть выполнены в рамках одной итерации.
Обеспечивает неизменность содержания работ внутри отдельного спринта. Об этом узнали создатели метода Scrum и написали книгу «Agile Project Management with Scrum». В ней они описали кейсы разных компаний, которые переходили на Скрам.