scrum of scrums что это
Описание Scrum of Scrums
Понятие Scrum of Scrums актуально для компаний, в которой находятся несколько команд разработки, и они работают над одним проектом. В статье про Sprint Backlog есть описание, как команды распределяют между собой обязанности и их выполняют. Контроль за тем, чтобы не было никаких проблем с выполнением, несет Scrum Master, а сама Development Team в свою очередь несет ответственность перед Product Owner, чтобы все задачи выполнялись.
Ведя свою команду к цели спринта, можно успешно достигнуть её, но при этом упустить, что происходит на уровне продукта. А ведь порой из-за этого нарушается целостность всей разработки.
Представьте, что вы едете на автомобиле в сторону цели, параллельно едет ещё одна команда, но между вами находится преграда, и вы понятия не имеете, как движутся соседи. Если представить, что обе команды везут некий груз и успех всей поездки зависит от того, обе ли команды довезли его в сохранности, то их взаимодействие просто необходимо.
Подобные встречи могут касаться вопросов взаимной интеграции или разговора о проделанной работе и ближайших планах. Одним из важных плюсов таких встреч является то, что со стороны можно увидеть те проблемы, которые не видно вблизи.
Sprint Backlog
Пожалуй основной процесс в методологии Scrum, остановка которого и может произойти. Во время Sprint происходит вся работа Development Team, Scrum Master и Product Owner.
Scrum Master
Главный помощник для своих скрам команд. Исправляет все возникающие проблемы, следит за эффективностью и улучшает её постоянно. Scrum Master один из самых важных персон в методологии Scrum. В Scrum-of-scrums это еще и связующее звено.
Development Team
Product Owner
Владельцу продукта надо знать как работает команда и что её предлагать в первую очередь на реализацию. Правильные действия Product Owner способствуют не возникновению остановки спринта.
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Scrum of scrums
Просмотр тем
Развитие — это не то же самое, что масштабирование
Попытка решить проблему, постоянно включая в процесс новых людей, только усложняет ситуацию. Но если по мере роста вы находите новые, более эффективные способы решения проблем, это называется масштабированием.
На протяжении нескольких десятилетий Руководство по scrum служило общим ориентиром, с помощью которого команды и компании решали такие проблемы. Однако когда scrum выходит за пределы отдельных команд, требуется иной подход. Для таких случаев была создана технология Scrum of Scrums, иногда называемая SoS.
История Scrum of scrums
Технология Scrum of Scrums была впервые применена в 1996 г. Джеффом Сазерлендом и Кеном Швабером, пионерами методики scrum. Сазерленду и Шваберу нужно было придумать, как координировать восемь бизнес-единиц, имеющих по несколько линеек продуктов, и синхронизировать работу отдельных команд. Для достижения этой цели они попытались масштабировать scrum-команды. Вдохновившись этим опытом, в 2001 г. Сазерленд опубликовал статью под названием «Масштабирование agile-подхода возможно: внедрение и переосмысление подхода SCRUM в пяти компаниях». В этом тексте и был впервые публично упомянут Scrum of Scrums.
С этого момента метод Scrum of Scrums стал набирать популярность в контексте agile-масштабирования. Он включен в Руководство Scrum@Scale, и на него ссылаются другие масштабируемые agile-платформы как на структуру, помогающую командам осуществлять масштабирование.
Если вам сложно справиться со Scrum на уровне отдельной команды, вы не сможете применить эту методику для группы команд. Перед тем как приступить к масштабированию, остановите все процессы и разрешите трудности, с которыми столкнулась ваша команда.
Что такое Scrum of scrums?
Scrum of Scrums — это масштабируемая agile-платформа, предлагающая способ объединения нескольких команд, которые должны работать вместе для поставки сложных решений.
С ее помощью команды разрабатывают и выпускают комплексные продукты, при любом масштабе опираясь на принципы прозрачности, контроля и адаптивности. Использование этой платформы особенно эффективно, когда высокопроизводительная команда scrum сообща и слаженно работает над общей целью с доверием и уважением ко всем участникам.
В этих условиях критичен размер команды. Согласно исследованиям Хэкмена и Видмара, теоретический «идеальный размер команды» составляет 4,6 человека. Слишком маленькие или слишком большие команды испытывают трудности при создании комплексных продуктов.
Помните закон Брука из книги «Мифический человеко-месяц»? Согласно этому закону, если проект по разработке ПО не укладывается в срок, добавление рабочей силы часто затягивает его еще больше.
Чем больше команда, тем сложнее каналы связи между ее участниками, что осложняет их взаимопонимание и работу над общей целью.
Поэтому разделение слишком большой команды на две или три небольших будет способствовать развитию более личных взаимоотношений и достижению желаемых результатов.
Разделять команды следует очень аккуратно! Необходимо выдержать баланс навыков в командах, перестроить сложившиеся способы взаимодействия и грамотно распределить рабочие обязанности. В этом процессе могут возникнуть неожиданные зависимости и новые узкие места, затрудняющие достижение результата. Преодолеть эти трудности поможет четкая фокусировка на ретроспективах и приоритетная работа над историями, направленными на улучшение.
При наличии нескольких команд, работающих на общий результат, необходима их координация. Это и послужило причиной создания Scrum of scrums.
Назначение Scrum of scrums
Scrum of Scrums — это виртуальная команда, состоящая из представителей исходных команд поставки, каждый из которых ссылается на свою команду. По сравнению с обычными организационными иерархиями или командами, созданными на основе проекта, командная структура с такой организацией взаимосвязей позволяет сократить пути коммуникации. Это обеспечивает координацию в небольших независимых командах. В командах, применяющих Scrum of Scrums, не только координируется процесс поставки, но и обеспечивается создание полностью интегрированного продукта в конце каждого спринта. Таким образом, команда Scrum of Scrums работает как команда по выпуску релизов и отвечает за поставку ценности клиентам.
Как правило, организации используют этот подход на первом этапе работы, чтобы осуществить agile-масштабирование и организовать поставку крупных и комплексных продуктов.
Scrum of scrums: масштабируемая структура
Вновь сформированная команда Scrum of Scrums применяет практически те же самые методы, участвует в тех же самых событиях и имеет те же самые роли, что и обычная scrum-команда. Чтобы в конце каждого спринта получать интегрированный и потенциально готовый к выпуску продукт, могут потребоваться дополнительные роли, например, архитектора или руководителя отдела контроля качества.
Например, есть роль главного владельца продукта. Главный владелец продукта курирует команду владельцев продукта и участвует в формировании общей концепции продукта.
Для этой роли не требуется назначать специального сотрудника, и ее носитель отвечает за те же задачи, что и владелец продукта, только в соответствующем масштабе.
Другая новая роль — мастер Scrum of Scrums. Исполнитель этой роли отвечает за ведение открытых для других команд бэклогов достижений и проблем, участвует в приоритизации проблем или их устранении и занимается постоянным повышением эффективности Scrum of Scrums.
Для этих новых ролей проводится ежедневное 15-минутное scrum-собрание для изучения, корректировки и решения проблем. Представители команд и (или) владельцы продукта обсуждают проблемы команды, риски на пути к цели спринта, зависимости от других команд и обнаруженные улучшения, которые могут быть полезны для других команд.
Заключение и выводы
Scrum of Scrums широко используется, в том числе как основной способ масштабирования scrum. Важным условием масштабирования является верно подобранная структура команды и наличие у нее времени и ресурсов для поэтапного развития в соответствии с моделью Такмена (формирование, конфликт, нормализация и функционирование).
Существует несколько факторов, которые целесообразно учитывать готовым командам.
Честно говоря, при agile-подходе не существует единственно верного способа масштабирования. Однако множество организаций добились больших успехов в создании процессов, команд и концепций работы, используя платформы для масштабирования Agile. Подробнее о самых популярных масштабируемых agile-платформах см. в разделе «Agile-подход при любом масштабе» руководства «Тренер по Agile».
Управление зависимостями в сложной Agile-среде
Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.
1 Введение
В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.
Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.
2 Структура команды
Разработка продукта в salesforce.com состоит из трех подразделений: Applications, Platform и Core Infrastructure. Эти три подразделения суммарно содержат более 30 Scrum-команд. В каждой Scrum-команде есть разработчики, тестировщики и Product Owner, а также Scrum Master (обычно это руководитель разработчиков или тестировщиков либо Program Manager). Для сложных фич Scrum-команды также привлекают представителей других функциональных команд, например System Testing, Documentation, UI Design, Usability, Technology Operations, Release Engineering.
Обычно все Scrum-команды работают над одним и тем же релизом в одной и той же ветке кода. Наши продукты связаны между собой, поэтому фичи разных команд могут очень тесно переплетаться — как функционально, так и технически. С точки зрения технической реализации многие команды используют общий код. С точки зрения функциональности команды, работающие над фичами для одного и того же конечного пользователя, должны тесно сотрудничать, чтоб создать гармоничный и согласованный user experience.
3 Почему управлять зависимостями трудно?
Когда столько команд работают над одним релизом, внедряя общие фичи и меняя общий код, невозможно предвидеть все проблемы, неожиданности, изменения, провалы и успехи, которые встретятся в процессе разработки. Такая непредсказуемость — одна из причин, почему управлять зависимостями так трудно. Далее в этом разделе мы отметим еще несколько причин. Любые решения должны быть направлены на эти основополагающие конфликты и вызовы.
3.1 Сложность системы
Выявление зависимостей — первый шаг к управлению ими. Подобно многим зрелым продуктам, системы salesforce.com слишком сложны, чтобы один человек или команда были способны знать и помнить все взаимосвязи. Чтобы выявить и осознать зависимости, нам все чаще приходится полагаться на коллективные знания множества людей. Крайне важно объединять такие знания и связывать людей, обладающих информацией, с людьми, нуждающимися в ней. Ключевую роль в определении зависимостей и последствий предлагаемых изменений играют эксперты с широким пониманием системы. Однако по мере роста и усложнения системы трудно избежать специализации и дробления знаний. К тому же при текущем количестве изменений нецелесообразно просить экспертов проверять детали каждой новой фичи. Нужен способ выявлять изменения, с высокой вероятностью влияющие на (или зависящие от) работу других команд, чтобы уделить таким изменениям особое внимание. Конечно, сделать это не так просто, поскольку порой сравнительно небольшие изменения серьёзно влияют на всю систему.
3.2 Конфликт приоритетов
Зависимости могут приводить к конфликтам между командами. Если одна команда хочет, чтоб другая команда что-то сделала, то Product Owner’ы этих команд обсуждают и определяют приоритет этой работы. Если по итогам обсуждения удается договориться о сроках выполнения, то в дальнейшем управлять этой зависимостью довольно просто. Если внятное соглашение не достигнуто, или если приоритет работы все еще низок, то неопределённость и уровень рисков вокруг данной зависимости возрастают.
Также конфликты возникают, когда одна команда вносит изменение, добавляющее работу другой команде. Например, когда одна команда изменяет архитектуру, так что остальным надо приспособиться к этим изменениям. Изменение не всегда приносит очевидную пользу другим командам, так что иногда люди обижаются и возмущаются появлением дополнительной работы, особенно когда она появляется внезапно. Мы стараемся выявлять такие зависимости на ранних этапах, но некоторые из них неизбежно появляются позже — вследствие уже внесенных изменений либо после пересмотра приоритетов.
3.3 Изменения в планах
Одно из преимуществ Scrum — возможность менять приоритеты команды для каждого спринта. Однако, это усложняет работу с зависимостями. Нельзя просто выявить и продумать все зависимости в самом начале релиз-цикла. Анализ взаимосвязей скорее похож на непрерывный постоянный процесс. По мере работы зависимости появляются и исчезают, пока команды уточняют детали того, что должно быть сделано. Поэтому процесс управления такими зависимостями должен быть динамичным и активным.
3.4 Короткие и пересекающиеся релиз-циклы
В коротких релиз-циклах меньше времени на координацию между командами, поэтому взаимосвязи и их влияние нужно выявлять на ранних этапах. В salesforce.com релиз-циклы пересекаются, в том смысле, что планирование нового релиза начинается до завершения предыдущего. Это сделано намерено, поскольку некоторые команды уже освободились и могут начинать работу над новым релизом. Однако остальные команды могут запаздывать с планированием и пропускать обсуждение зависимостей для следующего релиза. Это серьёзная проблема, учитывая важность коллективного знания для прояснения взаимосвязей.
4 Специальные подходы
В этом разделе мы обсудим конкретные подходы, которые мы используем, чтобы управлять зависимостями и справляться с вышеперечисленными проблемами. Общие стратегии, используемые в этих подходах:
4.1 Старт релиза
Примерно за месяц до выпуска текущего мажорного релиза мы устраиваем стартовое собрание для следующего релиза. На собрании присутствуют все сотрудники компании. Вице-президенты бизнес-подразделений рассказывают в общих чертах, над какими фичами планирует работать каждая команда в новом релизе. Это собрание заметно помогает управлять взаимосвязями. Прежде всего, оно побуждает команды подготовить их начальные планы на релиз к намеченной дате. Если у какой-то команды остается незавершенная работа из текущего релиза, то эта команда начинает задерживать планирование следующего релиза; в этом случае собрание помогает выполнить планирование к сроку. Трудно выявлять зависимости и обсуждать обязательства с командой, которая понятия не имеет, что она будет делать. Стартовое собрание служит точкой синхронизации команд и помогает обеспечить продуктивное обсуждение межкомандных взаимосвязей.
Кроме того, после собрания планы команды на релиз становятся общеизвестными. Мы стремимся добиться высокой осведомленности о том, чем занимаются все команды, поскольку верим, что это заставляет людей обдумывать и обсуждать взаимосвязи. В стартовом собрании участвуют все руководители R&D, что помогает привлечь людей и сосредоточить внимание на планировании релиза. Высокий уровень участия помогает согласовать ожидания и информировать правление о планах на релиз.
Конечно, планы могу меняться и меняются в процессе работы. Не так давно мы начали проводить обзор обновленной презентации стартового собрания во время ежемесячных обзоров спринтов. Обновленная презентация показывает, какие фичи были исключены или добавлены, и очень помогает поддерживать ясность и публичность планов в течение релиза.
4.2 Сессия выявления взаимосвязей
Приготовив начальные планы на релиз, команды могут более предметно обсуждать взаимосвязи, и множество таких обсуждений возникает спонтанно. В дополнение к этому мы сочли весьма ценным проведение более формальной сессии выявления взаимосвязей, когда совместно работают представители всех команд. Полезней всего проводить такую сессию незадолго до стартового собрания релиза, чтобы повысить качество планов, анонсируемых на этом собрании.
Сессия выявления взаимосвязей устроена довольно просто. Представители (чаще всего Scrum Master или Product Owner) всех Scrum-команд собираются в комнате с большой доской. В первой части сессии все участники одновременно рисуют на доске две диаграммы зависимостей между командами. Одна диаграмма изображает команды, которым нужно, чтоб другая команда сделала что-то для них. Вторая диаграмма изображает команды, делающие нечто, что повлияет на работу других команд. Мы используем несколько простых правил для этих диаграмм:
За очень короткое время мы создаем полную картину взаимосвязей в релизе. На рис. 1 показан типичный результат сессии после приведения в более читабельный вид. Сразу выявляются горячие точки (то есть команды с большим количеством зависимостей). Также видны команды, имеющие несогласованные зависимости. Такие команды больше всех рискуют не достичь своих планов, пока их взаимосвязи не согласованы.
Рис.1. Пример диаграммы межкомандных зависимостей
4.3 Открытые обсуждения
С недавних пор в течение недели после стартового собрания мы проводим открытые встречи, главная цель которых — создать площадку для обсуждения вопросов и проблем, связанных с планами команды на релиз. Мы просим, чтоб на этих встречах был хотя бы один представитель от каждой Scrum-команды, в остальном они необязательны для посещения. Обычно в начале открытой встречи участники предлагают темы для обсуждения. Далее в течение 45 минут проходят обсуждения тем в группах, а затем группы рассказывают остальным о результатах обсуждения. Чаще всего участники хотят узнать детали новой и полезной функциональности, а также об изменениях, которых повлияют на другие команды. Участники открытых встреч отметили поучительность таких обсуждений, кроме того людям оказалось интересно общаться с коллегами из других команд, с которыми они не взаимодействуют в обычной работе. Открытые встречи пока что новый формат для нас, так что мы пробуем разные варианты, чтоб понять, что работает лучше, например:
4.4 Обзор дизайна
Основная цель собраний по обзору дизайна функциональности — повысить общий уровень качества и удобства наших продуктов, с помощью:
Существует два основных типа таких собраний. На ранних этапах релиз-цикла участники фокусируются на концепциях дизайна и стремятся достичь согласованности и эффективного взаимодействия между существующими и новыми фичами. На этой стадии в собраниях обычно участвуют Product Owner’ы и дизайнеры пользовательского интерфейса (UI), и изредка представители других функциональных команд, таких как разработка и QA.
Примерно в середине релиз-цикла состав участников меняется: теперь это в основном представители QA и отчасти разработки, а обсуждения сосредоточены на деталях реализации. Эти встречи обеспечивают понимание и ясность относительно:
4.5 Виртуальная команда архитектуры
Виртуальная команда архитектуры (Virtual Architecture Team, VAT) — «виртуальна», поскольку включает в себя разработчиков из всех Scrum-команд. Члены команды работают в VAT без отрыва от основных обязанностей в рамках Scrum-команды из бизнес-подразделений Applications, Platform или Core Infrastructure.
VAT отвечает за поддержку и развитие архитектуры нашего ПО. Команда определяет дорожную карту (road map) развития архитектуры, проводит обзор серьезных изменений с точки зрения архитектуры, определяет стандарты кодирования, чтобы обеспечить совместимость и поддерживаемость кода.
VAT управляет бэклогом важных архитектурных проектов и необходимого рефакторинга. По мере развития продукта нам приходится перепроектировать фичи и избавляться от старого неоптимального кода. Порой разработчики не хотят менять уже работающие программы, даже когда они понимают, что код программы оставляет желать лучшего. Product Owner’ы предпочитают видеть, как разрабатываются новые фичи, а не как переделывается нечто уже работающее. Чтобы противостоять таким настроениям, каждое наше бизнес-подразделение обязано запланировать не меньше 20% времени в каждом релизе на изменения рекомендованные VAT.
VAT собирается дважды в неделю на два часа для обзора технической реализации продуктов и фич, создаваемых Scrum-командами. Команды, работающие над наиболее сложными фичами релиза обязаны представить их VAT. VAT дает Scrum-команде обратную связь о том, как их технические решения затронут остальные команды, и какие разработки других команд могут повлиять на фичу. VAT сосредоточена прежде всего на технической реализации, особенно на аспектах масштабируемости и производительности. Если дизайн фичи требует серьезных изменений, то Scrum-команда обязана повторно представить фичу в том же релиз-цикле и показать VAT, как они изменили свой дизайн.
4.6 Непрерывная интеграция
Наша веб-инфраструктура автоматизированной сборки, тестирования и сортировки (triage) обеспечивает непрерывную интеграцию билд-системы и позволяет отслеживать состояние каждой строчки кода. Эта инфраструктура — ключевой аспект, позволяющий всем разработчикам и QA инженерам работать с общей базой кода.
Главный набор тестов построенный на расширении JUnit дает возможность создавать функциональные тесты с помощью API Force.com. Кроме того, у нас есть фреймворк для тестирования пользовательского интерфейса, использующий Selenium для автоматизации тест кейсов, которые нужно выполнять через UI.
Вот несколько фундаментальных принципов, определяющих наш подход к автоматизации:
4.7 Scrum-of-Scrums
В каждом бизнес-подразделении еженедельно проводится собрание Scrum-of-Scrums, существует и » Scrum-of-Scrum-of-Scrums». Иногда мы организуем дополнительный Scrum-of-Scrums для группы команд, тесно взаимодействующих при работе над общей целью. Мы опробовали несколько различных форматов проведения Scrum-of-Scrums. Мы начали со стандартного формата «4 вопроса», когда команды сообщали, что они сделали, что собираются делать, что их блокирует, и делают ли они что-то влияющее на работу других команд. Поначалу это работало, но вскоре стало утомительным и скучным из-за большого количества команд. Тогда мы перешли к более открытому формату самоорганизации, когда участники предлагали темы для обсуждения, выписывая их на доске в начале собрания. Это заставило участников взять на себя ответственность за содержание митинга и привело к более продуктивным обсуждениям. Вопрос межкомандных зависимостей часто поднимается во время Scrum-of-Scrums, особенно на ранних стадиях разработки. Сессия распознавания взаимосвязей проводится во время Scrum-of-Scrums, и в последующие две-три недели на этом собрании часто обсуждаются изменения в межкомандных зависимостях.
4.8 Отчеты о состоянии
Когда команда переходит на Scrum, письменные отчеты часто становятся не нужны, поскольку ясность состояния теперь обеспечивается за счет других вещей (обзоры спринтов, burndown chart, ежедневные стендап-митинги). Когда мы перешли на Scrum, то решили сохранить облегченные еженедельные отчеты о статусе, которые готовит каждый Scrum мастер. Это выглядело избыточно пока мы использовали формат «4 вопроса» для Scrum-of-Scrums. Однако при нынешнем открытом формате Scrum-of-Scrums еженедельные отчеты стали важным дополнением к этому собранию. Мы не обсуждаем состояние каждой команды во время Scrum-of-Scrums, если только это не вынесено как отдельный вопрос, однако этот статус всегда доступен в еженедельном отчете. В отчете обозначены все зависимости, блокеры и риски. Конечно, такие отчеты требуют немного дополнительных усилий от Scrum мастеров, но ясность, которую они обеспечивают, оправдывает затраты на их создание.