Этот год начался с обновления линейки тренингов в соответствии с новой редакцией Руководства. Про одно из таких изменений хочется рассказать поподробнее. Тренинг Professional Scrum Foundations (PSF) теперь называется Applying Professional Scrum (APS).
На мой взгляд, это название, действительно, более удачное и лучше отображает суть тренинга — помочь участникам понять, как применять сухую теорию Скрама в окружении, приближенному к реальному. Теория, которая подаётся в развёрнутом виде тут же применяется на практике. Участники “пробегают” несколько спринтов, набивают собственные “шишки” и проводят работу над ошибками. Всё это происходит в безопасном окружении.
Остался и приятный бонус — после тренинга есть возможность проверить свои знания при помощи тестирования — всем участникам предоставляется попытка сдать экзамен и получить международный сертификат PSM I (Professional Scrum Master I).
Если вы хотите укрепить свои знания и попрактиковаться в Скраме у вас есть возможность это сделать. 22-23 марта мы проведем этот тренинг в online-формате. Более подробное описание и программа тренинга доступна по ссылке.
Команда в целом должна содержать все компетенции, необходимые для поставки продукта.
… Скрам-команда организует свои усилия в области развития, она выбирает членов команды, или оценивает, как вырастить командный набор навыков.
✥ ✥ ✥
Скрам-команда не может работать автономно, потому что у нее нет всех навыков, необходимых для выполнения сложной цепочки задач. Из-за зависимости от навыков людей за пределами команды, команда не может взять на себя ответственность за выполнение своих задач. Это снижает влияние команды на время, необходимое для завершения, и может снизить качество конечного результата. Основные принципы бережливого производства, заключающиеся в устойчивости и сокращении переделок, зависят от коротких циклов обратной связи. Комплексная разработка требует включения людей с множеством талантов таких, как человеческий фактор, инженерное совершенство и обеспечение качества. Редко можно найти все эти таланты у членов одной команды, не говоря уже о каком-либо отдельном человеке. Команды часто организуются вокруг зон компетенций: рыбак рыбака видит издалека. Иногда это называется функциональной организацией. Тем не менее, координировать эти функции вне границ команды дорого, потому что эффективная коммуникация происходит между теми, кто разделяет контекст текущей работы, и обычно это члены команды.
Комплексный продукт может потребовать от команды освоения многочисленных навыков для разработки Done функциональности (см. Definition of Done). Когда работа требует дополнительного человека для каждого необходимого навыка, команда становится слишком большой, чтобы быть эффективной. У вас может возникнуть соблазн не расширять набор навыков в команде, а вместо этого ввести внешние зависимости. С другой стороны, вы можете поручить работу команде, чтобы они могли развить и изучить требуемые навыки. Но обучение требует времени.
Локальное обучение может стать локальной оптимизацией, когда группа специалистов разрабатывает практики и процессы, оптимизирующие их работу. Специализация, локальные практики и процессы могут быть источниками эффективности в организации, но также могут создавать проблемы на границе группы. Для решения этих проблем организация может определить «контракты», описывающие, как работать друг с другом (например, запросы на обслуживание). Такие контракты могут определять характер работы, которую организация готова выполнять, а также ожидаемую продолжительность ответов на запросы. Любому нуждающемуся в групповой специализации пришлось бы использовать эти контракты. Однако это может замедлить разработку продукта в целом, даже если повысит эффективность отдела локально. Опять же, может возникнуть необходимость в дополнительных координационных группах внутри организации для управления этими пограничными контрактами, для согласования исключений или обеспечения понимания всеми сторонами того, что требуется, а также для обеспечения того, чтобы каждая группа выполняла свои обязательства перед другими командами — и перед заказчиком, в соответствии с обязательствами по этим контрактам.
Новые продукты или новые версии существующих продуктов создают новый мир для пользователей. Поскольку вы не можете заранее знать, каким будет этот новый мир, вы должны сосредоточиться на обучении и экспериментировании по мере развития продукта. Команда должна извлечь уроки из опыта использования каждого инкремента реальными потребителями, а не действовать в соответствии с заранее разработанным планом. И команда должна интегрировать эти уроки в процесс разработки продукта. Все признают преимущества локального потока, автономии и контроля, которые возникают в результате индивидуальной работы на этапе процесса или в функциональной области. Однако такая структура работы уводит всех (кроме человека, выполняющего последний шаг) от конечного пользователя и общих идей, которые приходят в результате взаимодействия на этой границе. Это может привести к неоптимальной локальной оптимизации функций сквозь весь процесс разработки продукта.
Поэтому:
Каждая Скрам-команда должна включать в себя все компетенции, необходимые для реализации Done функциональности.
Хорошая практика обращать внимание на охват набора навыков при первоначальном создании команды, но, что более важно, чтобы члены этой команды разделяли энтузиазм по поводу Видения и чтобы у них был опыт изучения нового. Поскольку со временем все меняется, маловероятно, что команда с самого начала сможет предвидеть все свои долгосрочные потребности в навыках.
Тогда все участники команды имеют все возможности для изучения вторичных навыков. Они могут свормиться (см. Swarming: One-Piece Continuous Flow) работая над Элементами Бэклога Продукта (PBIs), который увеличивает возможности для обучения и оптимизирует поток, чтобы помочь быстро получить Done функциональность. Развитие вторичных навыков делает команду более гибкой, так что любой член может заменить другого, который стал недоступен. Команда всегда прогрессирует и автономна.
Скрам ничего не говорит о том, что делать с недостатком компетенции. Пусть преобладает здравый смысл; например, попросите помощи у другой команды или заключите субподряд на большие объемы работы, которые могут удивить команду. Это понятно, если команда нуждается в такой помощи время от времени. Но если команда обнаруживает, что часто зависит от внешней помощи, ей следует рассматривать это как препятствие и принимать меры (такие как обучение, реорганизация или найм) для исправления ситуации.
Например, команда программистов может обнаружить, что создает продукт в области за пределами их основной экспертизы, такой как фармацевтика или аэрокосмическая промышленность. Заманчиво назначить человека в команду для каждой из недостаточно представленных компетенций, возможно, проконсультировавшись с внешним экспертом в предметной области. Однако представитель группы может не знать, чего они не знают, и может даже не понимать, какие вопросы задать экспертам в предметной области. Большинство экспертов в предметной области несут в себе знания, как неявные, поэтому они не в состоянии восстановить правильные идеи, чтобы поддержать разработчика программного обеспечения в правильной реализации.
Крайне важно, чтобы члены команды понимали важность рассмотрения предметной области для реализации и хорошо знали как бизнес, так и пространство решений. В недавней статье Джесси Уотсон из Amazon отметил, что крайне важно, чтобы оба этих фактора сосуществовали «в одном черепе». Лучше привлечь эксперта к команде и расшарить знания с помощью перекрестного обучения. Но помните о малых командах: добавление специалистов может привести к тому, что команда вырастет до такой степени, что совместная работа сведется практически к нулю.
Эти команды естественно действуют как “фиче-команды” (см. Conway’s Law) потому что большинство PBIs — фичи: ориентированные на рынок приносящие прибыль элементы. Если кросс-функциональные команды разрабатывают продукт, передачи естественным образом исчезают из Потока Создания Ценности: команда самостоятельно может разработать любую функциональность без помощи извне или вмешательства. Вовлечение нескольких команд приводит к задержкам циклов обратной связи, увеличивает потери (muda) из-за переделки и создает несогласованность (mura) между этапами разработки в Потоке Создания Ценности.
Опубликованное в Harvard Business Review исследование двух корпораций, одна из которых функциональная, а другая продуктовая, говорит о том, что кросс-функциональные группы предоставляет лучшие возможности обоих организационных структур (см. «Организационный выбор: продукт против функции» в (см. “Organizational Choice: Product vs. Functionˮ).
Set-Based Design техника, которая позволяет разработчикам заниматься многими дисциплинами и областями, которые могут иметь отношение к бизнесу, даже если они в конечном итоге не будут использоваться в текущем продукте. Такая практика расширяет базу знаний команды и организации и снижает вероятность того, что команда будет удивлена необходимостью освоить новую дисциплину. По мере того, как команда интегрирует новые уроки, будут появляться новые продуктовые идеи.
Изменения будут происходить быстро (и нужно позволить, чтобы они пошли быстро). Изменения будут скорее нормой, чем исключением. Для этого требуются небольшие организации, в которых все знают, что происходит: организации, способные принимать изменения, работать в разных специализациях, регулярно приносить пользу и, если не считать другого термина, гибкими.
Игра
Соберите несколько небольших команд, которые будут соревноваться в игре за создание бумажных самолетиков и управление ими. Каждый член команды может делать только одну складку за раз, а затем должен переключиться на работу в другой плоскости. Никакой самолет не может иметь более 15 складок. Он должен быть не менее 15 сантиметров в длину и 8 сантиметров в ширину. У него должен быть тупой кончик шириной не менее 2 сантиметров. Чтобы квалифицироваться как качественный продукт, самолет должен пролететь 3 метра по горизонтали, когда испытатель его проверяет. Тестер может проверить каждый самолет только один раз.
Попробуйте игру, и примените Скрам-паттерны (Swarming), чтобы оптимизировать количество качественных самолетов произведенных в одноминутный Спринт.
В обновленном Руководстве по Скраму (2020) к артефактам добавлено три пункта приверженности. Их задача — улучшить качество артефактов для повышения прозрачности. В случае с Product Backlog приверженность относится к Product Goal.
По сути, Product Goal наделяет Бэклог Продукта контекстом. Определить ее, можно ответив на вопрос: «почему мы выполняем всю эту работу?». Можно использовать ее в качестве краткой презентации на тему: «Над чем сейчас работает Скрам-команда?». Слово «Цель» выбрано не случайно, оно описывает:
то, к чему мы стремимся, и
то, что можно измерить по достижении.
В Руководстве по Скраму нет рекомендаций по подробному формированию Product Goal, поэтому Скрам-командам дается определенная свобода действий. Например, одни Скрам-команды могут работать над квартальной и очень конкретной Product Goal, а другие — выбрать амбициозную и комплексную цель. При определении Product Goal самое важное — это контекст.
В этой короткой статье я перечисляю основные изменения в новой версии Руководство по Скраму 2020. Если у вас нет времени, чтобы тщательно изучить руководство, эта статья для вас. Руководство доступно с 18 ноября в английской и русской версиях.
Цель изменений
Авторы Скрама утверждают, что главный мотив изменений — сделать Скрам менее предписывающим, более бережливым (lean) и более гармонично вписывающимся в разные контексты, особенно за пределами разработки программного обеспечения (ПО). И, знаете, Руководство значительно похудело. Теперь оно насчитывает лишь 13 страниц.
Перечень основных изменений
Одна Скрам-команда, сфокусированная на одном продукте. Концепция отдельной команды внутри команды (Development Team), которая привела к поведению взаимоотношений «прокси» и «мы/они» между Product Owner и командой разработчиков, устранена. Теперь есть только Скрам-команда, сфокусированная на общей цели, с тремя разными зонами ответственности: Product Owner, Scrum Master и Developers. То-есть, теперь мы говорим не о ролях, а зонах ответственности (accountabilities) внутри одной системы. Как следствие, Скрам-команда коллаборативно отвечает за достижение Цели Спринта, за соблюдение определения готовности (Definition of Done) и т.д.
Добавление Product Goal. Добавлена концепция Product Goal, которая фокусирует Скрам-команду на достижение более широкой цели. Каждый Спринт должен приближать продукт к итоговой Product Goal. Чем может быть эта Product Goal? В зависимости от контекста, это может быть миссия, видение продукта или же тактическая квартальная цель. Руководство специально использует нейтральный термин, чтобы дать вам возможность наилучшим образом определиться в вашем контексте.
Место для Sprint Goal, определения готовности (DoD) и Product Goal. Предыдущие Руководства по Скраму описывали Sprint Goal и определение готовности (DoD), но они не были официальными артефактами и относились к правилам Скрама. Теперь каждый из трех артефактов содержит «приверженность». Для Product Backlog есть Product Goal, для Sprint Backlog есть Sprint Goal, для Increment есть определение готовности (DoD) (теперь без кавычек). Они существуют, чтобы обеспечить прозрачность и сфокусировать на прогрессе по каждому артефакту.
Самоуправление вместо самоорганизации. В предыдущей версии команды назывались самоорганизующимися. Команда сама решала, кто и как будет выполнять работу. Версия 2020 года фокусируется на Скрам-команде, и подчеркивает важность самоуправления. Благодаря тому, что представитель бизнеса (Владелец Продукта) является частью системы, Скрам-команда может определять не только кто и как организовывает работу, но и направление движения.
Три вопроса события Sprint Planning. В версии 2017 были описаны два вопроса Sprint Planning: «Что» и «Как». В Руководстве по Scrum 2020 года особое внимание уделяется третьему вопросу — «Почему» — относящемуся к Sprint Goal.
Исчезли вопросы из Ежедневного Скрама. Описание Ежедневного Скрама значительно сократилось. Ушли рекомендуемые вопросы: кто, что делал и т.д. Теперь разработчики сами решают как наилучшим образом инспектировать прогресс к Цели Спринта.
Один Владелец Продукта/Бэклог Продукта в независимости от количества команд. Если раньше и могли бы различные трактовки того, как правильно масштабироваться и сколько может быть Владельцев Продуктов и Бэклогов Продуктов, то теперь спор завершен. Руководство 2020 года явным образом говорит о том, что в случае, когда много Скрам-команда разрабатывают один продукт, то у них один и тот же Владелец Продукта/Бэклог Продукта.
Скрам основан на lean. В предыдущих руководствах утверждалось, что Скрам основан на принципах эмпиризма. Теперь к ним добавлены принципы бережливого мышления (lean). Лично я очень рад этому, потому что всегда утверждал, что Скрам основан на идеях Toyota Production System (TPS).
Отсутствуют обязательные атрибуты у элементов Бэклога Продукта (PBI). Версия 2017 требовала от нас четыре атрибута у каждого PBI: description, order, estimation, value. Теперь они могут отличаться в зависимости от уникального контекста, в котором разрабатывается продукт.
Исчезло ограничение в 10% на Product Backlog Refinement (PBR). Уточнение Бэклога продукта остается ongoing activity и упоминается несколько раз в тексте, но ограничение по времени отсутствует, потому что может отличаться в различных контекстах.
Исчезли кавычки с “Ready”. Элементы Бэклога Продукта (PBI) называются готовыми к выбору в Спринт, если они могут выполнены за Спринт. При этом слово ready осталось, но кавычки растворились.
Надеюсь, эта статья была полезной для вас. Все же, рекомендую ознакомиться лично с Руководством по Скраму 2020 лично. Удачного вам использования Скрама в ближайшие годы!
Сегодня я размещаю перевод статьи, над которым мы работали вместе с Артемом Кротовым по очень важной теме в разработке программного обеспечения — теме унаследованного (legacy) кода. Это глава из «белой» книги Крейга Лармана и Баса Водди Practices for Scaling Lean & Agile Development, перевод размещён с разрешения авторов.
Текст который вы найдете ниже в посте написан 10 лет назад, и на мой взгляд, со временем актуальность материала только увеличивается.
Это описание воркшопа, который я провел на конференции LeSS в Амстердаме.
Можете использовать этот воркшоп для всестороннего обсуждения своей новой группы LeSS или для внесения изменений в процесс внедрения LeSS. Во время стандартного воркшопа можете использовать начальную ситуацию, о которой я писал в своих статьях о копипаст-мастшабировании здесь и здесь. Теперь я называю такую ситуацию MeSS (от англ. mess — «беспорядок»), поэтому ваша задача — перейти от беспорядка к LeSS (From MeSS to LeSS). В контексте своей организации начните с оценки текущей ситуации.
Оригинальная концепция Скрама — потенциально готовый к релизу инкремент каждый Спринт — звучит хорошо. Кто же откажется от высокоэффективных Скрам-команд, способных быстро поставлять ценность на рынок? Другое дело, что обычно затем я слышу: “Скрам не работает в моей организации, потому что…” и следует список оправдания, почему изменения невозможны.
Существует множество других Аджайл-подходов: Extreme Programming (XP), Scrum, Nexus, Kanban, LeSS, Crystal Clear, Lean Startup, Management 3.0. В своей коучинговой практике я отдаю предпочтение фреймворкам Скрам и LeSS, но больше всего ценю ценности и принципы, стоящие за ними. Со-создатель Скрама Кен Швабер считает о том, что Скрам может быть заменен лучшим подходом, если тот будет основан на четырех принципах: самоорганизации, эмпиризме, коллективном интеллекте и прозрачности.
Наблюдаю, что организации переполнены поверхностными Agile / Lean инициативами. Наверняка и вы сами сталкивались со ScrumButs, FlaccidScrum, Copy Paste Scrum, фейковым Канбаном. Люди склонны обвинять инструменты и фреймворки / методы, но, по моим наблюдениям, это проблема реализации. Есть исследование, подтверждающие это мнение.
Неспособность большинства организаций в полной мере воспользоваться преимуществами инноваций имеет мало общего с конкретным инструментом совершенствования, который они выбирают. Вместо этого проблема заключается в том, как внедрение новой программы совершенствования взаимодействует с физическими, экономическими, социальными и психологическими структурами, в которых происходит ее реализация. Другими словами, это не просто инструментальная проблема, это системная проблема, которая создается взаимодействием инструментов, оборудования, сотрудников и менеджеров. (Nobody Ever Gets Credit for Fixing Problems that Never Happened, Nelson P. Repenning, John D. Sterman)
… когда каждый просто страстно делает свое дело, то все работает хорошо. Однако по мере роста организации и продукта, растет объем информации, которую командам нужно осваивать, которой нужно управлять и делиться для выполнения своей работы. Решения становятся все более чувствительными к контексту (как на командном команды, так и на продуктовом уровне). По мере взросления организации возрастает комплексность и напрашивается создание структуры. Вы ищете организационную структуру, которая позволит оптимизировать способность команды выполнять задачи для создания Величайшей Ценности.
Trinity Cathedral/Charlie Comella Community Garden uses different garden beds to divide their work. Each bed grows one or more types of plant that are combined to produce the meals for the community.
… Ваш продукт пользуется успехом на рынке, и все больше и больше людей используют его. Новые пользовательские сегменты возникают со спросом на новые функции. Скрам-команде по-прежнему необходимо доставлять продукт в соответствии с темпом рынка. Все команды стремятся к тому, чтобы иметь возможность доставить любой Элемент Бэклога Продукта (PBI), но команды собираются внедрить новый домен и поэтому начинают приближаться к пределам того, что могут освоить.
✥ ✥ ✥
Когда бизнес не может удовлетворять растущее число пользовательских сегментов, разделив продукты, а скорее должен разрабатывать единый продукт, который обслуживает все рынки, во многих случаях одна Скрам-команда не может быстро развить необходимое глубокое понимание всех этих клиентских сегментов.
В предыдущей статье мы рассмотрели полезную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д. Давайте посмотрим на ее применение в командном контексте.
POSIWID на командном уровне
Чтобы взять на вооружение POSIWID («Purpose Of the System Is What It Does»), нужно ответить последовательно на несколько вопросов:
Какая заявляемая цель системы?
Как ведет себя система?
Что говорит поведение системы о цели системы?
Есть ли соответствие между заявленной и фактической целью?
Если это не так, как выглядит структура системы?
Как мы можем изменить структуру системы, чтобы получить новое поведение?
Проиллюстрируем алгоритм на примере команды, с которой мы работали некоторое время назад.
