---

Доступная сертификация Scrum-мастера: пошаговый план

Мы с гордостью сообщаем, что эта статья была опубликована...
ЗДЕСЬ, в LinkedIn >>>

С тех пор как подход Scrum стал одним из лучших способов разработки и поставки программного обеспечения, у всех, похоже, появилась одна цель.

Проснуться утром, открыть ноутбук и с радостным спокойствием осознать, что у вас есть нечто подобное:

Сертификация Scrum-мастера.

Ведь это мечта, верно?

Создавать отличное программное обеспечение для работодателей и клиентов.

Построить замечательную карьеру благодаря навыкам и знаниям процесса Scrum и своей сертификации Scrum-мастера.

Для большинства людей сертификация Scrum-мастера становится отправной точкой знакомства со Scrum.

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

Доступно, быстро, онлайн и без лишних хлопот!

Всего за четыре простых шага вы можете стать выдающимся специалистом по Scrum, получив сертификацию Scrum-мастера.

Моя цель — показать, как Scrum может поддержать вашу карьеру и повысить профессиональную эффективность, а также почему стоит развивать навыки и способности Scrum-мастера уже сейчас, не откладывая.

Определение: что такое сертификация Scrum-мастера?

Лучшее определение того, что представляет собой сертификации Scrum-мастера , можно найти на сайте International Scrum Institute™— Scrum Master Accredited Certification™.

Сертификация Scrum-мастера — это подтверждение вашей компетентности в процессе разработки и поставки программного обеспечения Scrum. Сертификация Scrum-мастера признаёт продемонстрированные вами знания и высокий уровень владения Scrum по итогам формального теста с выбором ответа.

К настоящему времени процесс разработки Scrum принёс огромную пользу миллионам специалистов. Поэтому нет причин, по которым вы не могли бы присоединиться к успешным людям, развившим карьеру и навыки с помощью Scrum.

Если вы ещё сомневаетесь, уверяю вас: сегодня уже трудно представить развивающуюся карьеру без сертификации Scrum-мастера. Это не зависит от вашей роли, должности и опыта в сфере информационных технологий (ИТ) .

Чтобы понять, что такое Scrum, как он работает, и получить сертификацию Scrum-мастера, теперь даже не обязательно быть ИТ-специалистом.

Чем бы вы ни зарабатывали на жизнь и относились ли вы к ИТ-подразделению, есть неоспоримый факт. Ваши задачи и профессиональная деловая ценность для организации зависят от ИТ, программного обеспечения и гибкого процесса и принципов Scrum.

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

Вы можете только начинать карьеру или быть опытным ИТ-специалистом — это не играет роли. Вам нужна сертификация Scrum-мастера.

Ваша роль может включать управление людьми и функциональными направлениями, а может и не включать. Это тоже не имеет значения: сертификация Scrum-мастера нужна вам в любом случае.

Ваша должность может называться так:

• бизнес-аналитик,
• архитектор программного обеспечения,
• архитектор предприятия,
• проектировщик программного обеспечения
• дизайнер пользовательского опыта (UX),
• дизайнер пользовательского интерфейса (UI),
• разработчик программного обеспечения,
• руководитель разработки программного обеспечения,
• инженер по тестированию,
• специалист по автоматизации тестирования,
• руководитель тестирования,
• специалист по эксплуатации ИТ-систем,
• администратор Unix/Linux,
• инженер по информационной безопасности (InfoSec),
• инженер ИТ-сетей,
• администратор баз данных (DBA),
• руководитель проекта,
• руководитель программы,
• менеджер продукта,
• лидер команды, менеджер, директор или высший руководитель,
• либо иначе — я мог не перечислить вашу должность.

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

3 источника хаоса и разочарования до внедрения гибкого процесса Scrum и сертификаций Scrum-мастеров

Чтобы лучше понять влияние Scrum на наши инженерные практики и бизнес, стоит взглянуть на один день из жизни — или на один программный проект.

Поэтому я хочу кратко рассказать о проекте из прошлого, ещё до того, как мы внедрили Scrum для разработки и поставки программного обеспечения в наших организациях.

За несколько дней до написания этих строк я обедала с бывшим коллегой, с которым мы работали почти 20 лет назад. Этот человек, Маркус, получил сертификации Scrum-мастера и Владельца продукта Scrum в International Scrum Institute™.

Сейчас он работает Scrum-мастером в одной из ведущих компаний, разрабатывающих программное обеспечение для гибкого управления проектами.

В качестве Scrum-мастера Маркус поддерживает гибкую Scrum-команду, участники которой географически распределены по всему миру.

За обедом Маркус признал, что распределённые гибкие Scrum-команды сталкиваются со множеством типичных трудностей. Среди проблем своего программного проекта он особо отметил:

• Различия в стилях работы участников Scrum-команды,
• Разницу часовых поясов,
• Культурную несогласованность и
• Языковые ограничения.

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

Слова Маркуса стали весомым свидетельством в пользу Scrum со стороны очень успешного и опытного руководителя, Scrum-мастера и Владельца продукта.

Спасибо, Маркус!

Затем я рассказала ему об одном своём проекте до знакомства со Scrum. Уверена, многие Scrum-мастера узнают в этом опыте собственные проекты до получения сертификации.

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

В то время это был довольно сложный ИТ-проект, требовавший нескольких взаимозависимых аппаратных и программных команд. Нам пришлось выполнить огромный объём исследований и разработок (R&D) для создания полностью работоспособной аппаратно-программной системы.

Помните: это было ещё до появления минимально жизнеспособный продукт (MVP) » для экспериментов, создания, обучения и новых экспериментов.

Если вам интересно узнать, как создавать MVP в гибком подходе, прочитайте эту статью от Cleevio: она поможет лучше понять этот сложный процесс.

Без Scrum создание такой сложной инфраструктуры из множества аппаратных и программных компонентов было настоящим испытанием.

Вот три серьёзные проблемы, с которыми мы сталкивались, когда в командах не было ни Scrum-мастеров, ни обладателей соответствующей сертификации.

1-й источник хаоса и разочарования без сертификации Scrum-мастера: нам приходилось планировать весь проект прежде, чем мы понимали его суть

Без Scrum наши команды создавали и поставляли совершенно неподходящие программные и аппаратные продукты, не отвечавшие требованиям клиента.

Бывало, что сторонние компании навязывали нам, как следует создавать программные продукты и услуги.

Модель зрелости возможностей (CMM), ISO 9001:2008 и другие производные подходы пытались помочь компаниям правильно создавать нужное программное обеспечение.

Насколько успешно это получалось — за рамками статьи. Она посвящена процессу Scrum и достоинствам сертификации Scrum-мастера, а не представлению стандартов управления качеством и совершенствования процессов как отживших альтернатив Scrum.

Однако добавлю: до Scrum эти подходы к совершенствованию внедрялись в проектах поэтапно. Мы применяли поэтапный инженерный подход, называвшийся каскадной моделью разработки программного обеспечения.

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

Затем мы проектировали реализацию требований, разрабатывали её, тестировали (проверяли) и сопровождали в рабочей среде. Так мы доходили до конца жизненного цикла разработки.

Но реальность оказалась иной!

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

Такова была жизнь до Scrum.

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

В итоге страдал не только продукт: моральный дух сотрудников и приверженность миссии организации также были полностью подорваны.

2-й источник хаоса и разочарования без сертификации Scrum-мастера: отсутствие приверженности, управления изменениями и дисциплины совместной работы разных команд

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

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

Поэтому руководители разработки и другие внутренние и внешние заинтересованные стороны стремились установить фиксированный срок поставки и легко контролировать продвижение фаз разработки.

Они наказывали людей за отклонения от плана и надеялись исправить возникающие проблемы до запланированного завершения проекта.

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

Можете предположить причину такого изолированного мышления вместо внимания к бизнес-миссии и профессиональной (деловой) зрелости сотрудников?

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

Руководство формирует организационную структуру, объединяя сотрудников со схожими функциональными и техническими навыками в одинаковые или, в лучшем случае, соседние изолированные подразделения.

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

Одно подразделение для C++-разработчиков, другое для администраторов баз данных, третье — совершенно отдельное обеспечение качества за границей, и так далее. Попробуйте разберитесь!

Главная трудность матричной структуры состояла в следующем: для реализации программного проекта без Scrum и Scrum-мастеров руководителям проектов приходилось временно заимствовать сотрудников из подразделений.

Эти сотрудники даже физически не находились рядом со своими проектными командами, оставаясь в помещениях своих центров компетенций.

После завершения проектов временные команды распускались, а участники переходили к новым поручениям в других проектах.

Поэтому целевая бизнес-ценность текущих проектов никогда не была главным приоритетом независимых подразделений.

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

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

Статья McKinsey & Company в McKinsey Quarterly также ясно показала эту иллюзию оптимизации затрат за пределами матричной организации.

В исходной статье приводится оценка Gartner мировых ежегодных тратили 600 миллиардов долларов США на восстановление ИТ-систем из-за незапланированных работ сопровождения и дефектов.

Теперь ненадолго представим, как происходили управление изменениями и устранение препятствий в программных проектах. Как это происходило при каскадной модели, матричной организации и отсутствии процесса Scrum.

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

Поэтому изменения в программном проекте стали синонимом задержек. Обычно они вызывали эффект домино с каскадом опозданий. Командам требовался кто-то, на кого можно было возложить вину за дефекты и препятствия.

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

Кроме того, они продолжали накапливать технический долг пассивно пытаясь справляться с проблемами.

3-й источник хаоса и разочарования без сертификации Scrum-мастера: авторитарные решения отменяли демократические

Стив Джобс однажды сказал:

«Нет смысла нанимать умных людей и указывать им, что делать. Мы нанимаем умных людей, чтобы они говорили нам, что делать».

Однако это полная противоположность тому, как большинство руководителей обычно принимали решения до эпохи Scrum.

До внедрения Scrum в наших организациях авторитарные решения руководителей подавляли коллективный разум команд.

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

Чем дальше решение переносилось от затрагиваемых им центров работы (команд), тем труднее было принять верное решение по важнейшему для дела вопросу.

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

Эти авторитарные решения , навязанные сверху, заставляли сотрудников чувствовать себя недооценёнными. Они полностью мешали организациям создавать творческие новаторские решения конкурентных бизнес- и программных задач.

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

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

Что такое Scrum?

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

Но и для тех, кто ищет более продвинутое, всё ещё практическое руководство для быстрого изучения Scrum, у нас кое-что есть. Предлагаю вам скачать наше руководство по Scrum по этой ссылке.

Что такое Scrum? Если не усложнять, его можно определить так:

Scrum — лёгкий фреймворк создания ценности посредством адаптивных решений сложных проблем. Итерационная и инкрементальная разработка программного обеспечения — одна из важных областей его применения.

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

Многие в ИТ-индустрии считают, что термин «Scrum» появился в начале 2000-х годов параллельно новым тенденциям гибкой разработки и поставки программного обеспечения. Это неверная информация!

В январе 1986 года Harvard Business Review опубликовал статью о подходе к разработке продуктов, предшествовавшем более позднему фреймворку Scrum. Авторы — Хиротака Такэути и Икудзиро Нонака, название — The New New Product Development Game. (Да, слово New повторяется дважды)

Посмотрите "The New New Product Development Game" , чтобы узнать, с чего началась история Scrum!

Когда в ИТ-индустрии говорят о Scrum, рядом с этим названием нередко звучит «Agile Scrum». Из-за этого некоторые начали искать различия между терминами «Agile Scrum» и «Scrum».

Есть хорошая новость: «Agile Scrum» и «Scrum» обозначают одно и то же — процесс разработки программного обеспечения Scrum. Почему же перед Scrum иногда ставят слово Agile?

Потому что Scrum полностью принял и встроил в себя Манифест Agile (Манифест гибкой разработки программного обеспечения) в свой основной процесс, принципы и базовую философию. Поэтому, прежде чем углубляться в технические детали Scrum, лучше разберёмся в Манифесте Agile и ценностях процесса.

Манифест Agile (Манифест гибкой разработки программного обеспечения)

Ценности Agile-манифеста:

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

Хотя элементы справа по-прежнему обладают значительной ценностью, Манифест Agile выше ценит элементы слева и отдаёт им приоритет.

Элементы, которым Agile-манифест отдаёт предпочтение, тщательно проверены временем и выбраны для того, чтобы:

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

Ценности Scrum

Я уже упоминала: Scrum — не только процесс разработки программного обеспечения. В его основе также лежит прочный набор принципов.

Эти принципы можно применять в большинстве профессиональных сфер бизнеса.

Чтобы добиться большого успеха со Scrum, недостаточно получить сертификацию Scrum-мастера. Необходимо твёрдо понимать ценности Scrum.

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

Смелость

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

Их задача — создавать наилучшие продукты и услуги в своей области бизнеса и ИТ. Чтобы превосходить посредственный уровень, рано или поздно Scrum-команда сталкивается с трудными решениями, которые не порадуют всех заинтересованных сторон в её окружении.

Чтобы справляться с этим, всем участникам команды необходимо помнить, чему они научились при подготовке к сертификации Scrum-мастера.

Они должны помнить о смелости и учиться смело принимать решения и действовать.

Сфокусированность

Когда в Scrum вы слышите о ценности сосредоточенности, думайте о двух вещах:

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

В каждый момент вся Scrum-команда, включая Scrum-мастера и Владельца продукта, должна отвечать на один важнейший вопрос. Вот он: «Какие самые важные дела нам следует выполнять сейчас, чтобы оправдать причины, по которым работодатель нас нанял?»

В Scrum предусмотрено несколько событий (ритуалов), поддерживающих разумную расстановку приоритетов пользовательских историй и задач. Приоритизации историй и связанных с ними задач следует уделять постоянное внимание.

Так мы обеспечиваем работу команды над нужными вещами в правильном порядке. Формальные события Scrum и связанные практики уточнения помогают проверять сосредоточенность и адаптировать работу:

• Встреча по уточнению бэклога Scrum: Уточнение проясняет, дробит и оценивает размер будущих элементов Бэклога продукта, а также помогает определить их порядок. Встреча — один из вариантов организации этой непрерывной деятельности.
• Планирование Спринта: Эти встречи помогают видеть зависимости и правильный порядок работы для поставки историй.
• Ежедневный Scrum: Ежедневный Scrum (ежедневная встреча стоя) помогает задать тон предстоящему рабочему дню. Необходимо направлять внимание туда, где оно нужнее всего.
• Обзор Спринта: Обзор Спринта косвенно показывает, на чём команде нужно сосредоточиться, чтобы будущие обзоры были успешнее.
• Ретроспектива Спринта: Эти встречи помогают команде определить, какие стороны инженерного процесса следует улучшить в первую очередь.

В этом разделе я рассмотрела ритуалы Scrum только с точки зрения сосредоточенности. Подробнее о событиях Scrum можно прочитать далее в статье.

Теперь вам должно быть очевидно, насколько важны для Scrum приоритизация и сосредоточенность.

Приверженность

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

В мире разработки Scrum многие понимают приверженность как согласие и обязательство выполнить цели результатов поставки определённого Спринта.

Хотя такое понимание вполне логично, оно не лишено недостатков. Говоря о приверженности как ценности Scrum, автор использует слово «одержимость», подчёркивая самоотдачу. По определению Scrum приверженность относится к целям команды и взаимной поддержке; она не требует переработок или уверенности в выполнении каждого спрогнозированного элемента.

Для успеха в разработке, жизни и бизнесе необходимо быть увлечённым своими целями до одержимости. Поэтому в контексте Scrum нужно быть одержимым созданием замечательного программного обеспечения, которое решает проблемы ваших клиентов.

Почему приверженность и связанная с ней одержимость целями Scrum так важны? Без увлечённости миссией команды создавать и поставлять потрясающее программное обеспечение при каждом нетривиальном препятствии работа будет замедляться и останавливаться.

Тогда Scrum-мастер и команда начнут искать объяснения, оправдывая перед Владельцем продукта невозможность достижения целей Спринта. Если ваша цель — стать командой выше среднего уровня, оправданиям больше не должно быть места.

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

Уважение

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

Это уважение не ограничивается командой. Каждая внутренняя и внешняя заинтересованная сторона бизнеса и ИТ, взаимодействующая с командой, пользуется полным уважением и радушным приёмом.

Опытным участникам следует быть внимательными, чтобы не подавлять желание менее опытных коллег вносить свой вклад.

Особенно важно правильно принимать противоположные мнения, с которыми не согласно большинство группы, и отвечать на них.

Открытость

Открытость часто отличает среднюю Scrum-команду от высокоэффективной. Способность команды к открытости можно сравнить с огромным потенциалом группы людей с открытым мышлением.

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

Единственное условие — прозрачность и стремление внести вклад в общую миссию команды.

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

Благодаря открытости и смелости группа разработки Scrum не боится ошибок. Она воспринимает свои ошибки и не самые удачные результаты как важные возможности существенно повысить общую продуктивность и качество работы.

Основные компоненты Scrum

Scrum-команда состоит из одного Владельца продукта, одного Scrum-мастера и Разработчиков с тремя отдельными областями ответственности. Прежняя формулировка статьи «участник Scrum-команды» обозначает группу разработки, а не четвёртую область ответственности и не отдельную полную Scrum-команду.

Помимо других программ для студентов по всему миру, International Scrum Institute™ предлагает три основные программы обучения и сертификации для этих трёх ролей.

Эти программы: Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™)и Scrum Team Member Accredited Certification™ (STMAC™).

В правильно устроенной организации Scrum должны быть люди со всеми тремя наборами навыков. Это особенно важно для успеха разработки по Scrum.

Каждая область ответственности Scrum должна выполняться. Обязанности остаются различными; Владелец продукта или Scrum-мастер может также участвовать как Разработчик в работе Бэклога Спринта, не теряя обязанностей другой своей роли.

Несколько Scrum-команд, работающих над одним продуктом, имеют общих Владельца продукта, Цель продукта и Бэклог продукта. Каждой команде нужна ответственность Scrum-мастера и эффективная поддержка; Scrum не предписывает, что один человек может поддерживать только одну команду.

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

Поговорим об этих трёх ролях.

Три роли Scrum: Владелец продукта

Владелец продукта Scrum упорядочивает Бэклог продукта для максимизации ценности и совместно с заинтересованными сторонами принимает решения о продукте и выпусках. Разработчики выбирают работу, которую прогнозируют выполнить в Спринте; организация выпусков зависит от контекста продукта. Владелец продукта представляет функциональные и нефункциональные потребности конечных пользователей.

Его роль намного шире традиционных ролей руководителя проекта, руководителя программы или менеджера продукта.

Эта роль объединяет задачи управления продуктом и проектом и тесно связана с разработкой и поставкой программного обеспечения.

Основные задачи Владельца продукта Scrum:

• Управлять требованиями проекта и уточнять их,
• Направлять выпуски и обеспечивать отдачу от инвестиций (ROI),
• Тесно работать со Scrum-командой,
• Управлять взаимодействием с заинтересованными сторонами.

Три роли Scrum: участник команды

Scrum-команда реализует программное обеспечение. Разработчики выбирают объём работы, который, по их прогнозу, они могут завершить за Спринт. Спринт — событие фиксированной продолжительности; созданный за него пригодный к использованию результат продукта — Инкремент, соответствующий Определению готовности.

Высокоэффективная Scrum-команда обычно обладает большинством инженерных навыков. Разработчики, архитекторы, тестировщики, администраторы баз данных и представители других ролей работают вместе.

Вместе они создают и поставляют отличное программное обеспечение, за которое платит клиент.

Участники Scrum-команды больше не принадлежат функциональным подразделениям матричной организации. Разработчики больше не относятся к центру компетенций разработки, тестировщики — к центру компетенций тестирования и так далее.

Независимо от прежнего положения в организации участники принадлежат конкретному Scrum-проекту. Теперь их задача — создавать наилучшее программное обеспечение, реализующее требования Владельца продукта.

Характеристики Scrum-команд:

• Наделённые полномочиями,
• Автономные,
• Кросс-функциональные,
• Самоорганизующиеся,
• Небольшие,
• С достаточно доступными участниками (полная занятость в команде — распространённый организационный выбор),
• Способные тесно сотрудничать как в одном месте, так и распределённо,
• Один за всех, все за одного.

Три роли Scrum: Scrum-мастер

Scrum-мастер помогает всем участникам Scrum-проекта и внешним заинтересованным сторонам правильно понимать и применять Scrum. Он поддерживает успешное выполнение процесса командой и помогает непрерывно повышать производительность и результативность.

Роль Scrum-мастера — утвердить процесс Scrum, новый способ мышления и действий.

Кроме того, Scrum-мастер выступает проводником изменений. Он помогает команде развивать новые нормы и стандарты и остаётся доступным для неё; физическая близость может помогать, но не является требованием Scrum.

Основные обязанности Scrum-мастера:

• Утверждать Scrum в своей деловой и ИТ-среде,
• Помогать команде понимать ценности Scrum и жить в соответствии с ними,
• Обеспечивать тесное сотрудничество Владельца продукта и команды,
• Устранять препятствия,
• Руководить через служение,
• Поддерживать эффективные события Scrum и при необходимости содействовать их проведению, сохраняя за Разработчиками владение Ежедневным Scrum.

Бэклог продукта (бэклог Scrum)

Бэклог продукта (бэклог Scrum), или бэклог продукта Scrum — центральный элемент управления всеми известными требованиями Scrum-проекта.

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

Бэклог продукта содержит запросы на функции и их высокоуровневые пользовательские истории. Также он может включать предварительные или вспомогательные требования, например создание сред разработки и тестирования. В нём находятся и другие пользовательские истории: для исправления известных ошибок, уменьшения технического долга или улучшения функций.

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

Это обязанность Scrum-команды. Она определяет и документирует необходимые задачи в бэклогах Спринтов. Учтите: Бэклог продукта и Бэклог Спринта — отдельные артефакты, но не обязательно физически разные документы или инструменты, хотя записи Бэклога продукта определяют содержание Бэклога Спринта.

Бэклог продукта — живой документ. Как программное обеспечение улучшается инкрементально, так и Бэклог продукта меняется по мере обучения команды: элементы добавляются, удаляются и переупорядочиваются. Scrum сам по себе не требует отдельного процесса управления изменениями. Владелец продукта создаёт первые версии Бэклога продукта на основе наилучшего первоначального понимания продукта.

Внимательно наблюдая за развитием продукта от Спринта к Спринту и всё лучше понимая требования клиентов, он добавляет, удаляет и уточняет требования в Бэклоге продукта.

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

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

Спринты

В Scrum вся деятельность по реализации требований происходит во время Спринтов. Спринты — это циклы работы по созданию готовых к поставке Инкрементов программного продукта или услуги. Спринты также иногда называют итерациями.

Спринты можно представить как микропроекты. Как подсказывает название, Спринт недолог: он длится месяц или меньше. Четырёхнедельные Спринты — распространённый пример, а не точная максимальная календарная длительность по Scrum.

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

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

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

Ежедневный Scrum (встреча Ежедневного Scrum) проходит каждый рабочий день Спринта в одно время и в одном месте. Разработчики используют его для проверки продвижения к Цели Спринта и адаптации плана на следующий день. Участники команды также могут попросить Scrum-мастера помочь устранить препятствия, способные замедлить или заблокировать ход Спринта.

Команда завершает Спринт Обзором и Ретроспективой Спринта. Обзор Спринта позволяет команде и ключевым заинтересованным сторонам проверить результат Спринта и продвижение к Цели продукта, а затем обсудить будущие изменения. Это рабочая сессия, а не этап приёмки Владельцем продукта.

На встрече « Встреча по ретроспективе Спринта, команда анализирует совместную работу, применение Scrum и возможности совершенствования.

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

Проверка и адаптация в Scrum

Проверка и адаптация в Scrum — понятная концепция, которую труднее всего правильно реализовать и освоить.

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

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

Так появилась ката совершенствования Toyota, которая даёт полезное сравнение с проверкой и адаптацией в Scrum. Эти подходы близки по цели, но ката совершенствования Toyota — не просто другое название эмпирических основ Scrum. Согласно концепции «проверяй и адаптируй» в Scrum:

• Шаг 1. Проверяйте: Мы стараемся понять текущее состояние проекта на имеющемся уровне знаний и понимания.
• Шаг 2. Адаптируйте: Мы определяем направление и видение следующих шагов проекта, затем разрабатываем стратегию и воплощаем её.
• Шаг 3. Учитесь: Мы внимательно наблюдаем, учимся и обучаем друг друга в процессе. Постоянно фиксируем, что работает, а что нет.
• Шаг 4. Начинайте заново: Вернитесь к шагу 1.

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

• Шаг 1. Проверяйте аналогичен Обзору и Ретроспективе Спринта.
• Шаг 2. Адаптируйте аналогичен Планированию Спринта.
• Шаг 3. Учитесь аналогичен Ежедневному Scrum.
• Шаг 4. Начинайте заново аналогичен завершению одного Спринта и началу следующего.

Самоорганизация

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

Самоорганизация в Scrum очень дисциплинированна.

Бэклог Спринта и Ежедневные Scrum-встречи поддерживают самоуправление. А диаграмма сгорания Спринта — один из необязательных способов сделать прогресс видимым.

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

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

В Scrum такие процессы включают, помимо прочего, планирование, оценку, реализацию, отчётность и обзор работы, за которую команда отвечает совместно.

События Scrum и постоянное уточнение бэклога

Событие Scrum 1. Планирование Спринта: зачем, что и как

На встрече « Планирование Спринта, команда создаёт выполнимый Бэклог Спринта, определяющий требования, которые она реализует за Спринт.

Обязанности разных ролей на Планировании Спринта:

• Владелец продукта предлагает, почему Спринт может быть ценным. Вся команда совместно формирует Цель Спринта, а Разработчики выбирают элементы Бэклога продукта, которые, по прогнозу, смогут завершить.
• Команда определяет необходимые задачи и их оценки. Разработчики решают, какие и сколько элементов они прогнозируют завершить в Спринте, учитывая прошлые результаты, доступные возможности и Определение готовности.
• Scrum-мастер модерирует встречу, обеспечивая сохранение самоорганизации и автономного принятия решений командой.

Участие Владельца продукта в Планировании Спринта обязательно. Так он может отвечать на вопросы команды и прояснять требования и критерии приёмки.

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

Событие Scrum 2. Ежедневный Scrum (ежедневная встреча стоя)

Этот Ежедневный Scrum — встреча продолжительностью не более 15 минут. Она проходит каждый рабочий день в одно время и в одном месте. Лучше проводить Ежедневный Scrum с прямым доступом к Бэклогу Спринта и диаграмме сгорания Спринта. Тогда Scrum-команда может вести встречу на основе фактов и прогресса, видимых всем участникам.

Ежедневный Scrum направлен на поддержку самоорганизации Scrum-команды и систематическое выявление препятствий.

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

Разработчики выбирают полезную структуру, ориентированную на Цель Спринта и выполнимый план. Следующие три вопроса — известный необязательный формат, а не предписанные актуальным Scrum вопросы.

• Ежедневный Scrum — вопрос №1. Какие действия я выполнил с предыдущего Ежедневного Scrum?
• Ежедневный Scrum — вопрос №2. Какие действия я планирую выполнить до следующего Ежедневного Scrum? Каков мой план действий?
• Ежедневный Scrum — вопрос №3. Возникли ли или ожидаются ли препятствия, способные замедлить или заблокировать мою работу?

Разработчики сами проводят свой Ежедневный Scrum. При необходимости Scrum-мастер помогает Разработчикам понять назначение события и повысить его эффективность. Оно по-прежнему длится 15 минут; формат трёх вопросов необязателен.

В цели Ежедневного Scrum не входят длительное принятие решений и решение проблем. Для согласования решений и устранения проблем команда может устраивать отдельные встречи по необходимости. Обычно такие обсуждения проходят сразу после Ежедневного Scrum.

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

Событие Scrum 3. Обзор Спринта

Этот Обзор Спринта проходит в конце Спринта. Некоторым командам подходит обзор продолжительностью от одного до двух часов; формальный максимум — четыре часа для месячного Спринта, а при более коротких Спринтах события обычно короче. В зависимости от программного обеспечения и инфраструктуры обзор проходит в переговорной, лаборатории или помещении команды.

Цель Обзора Спринта — рассмотреть готовый к поставке Инкремент продукта, созданный за Спринт, и обеспечить прозрачность процесса разработки.

Команда демонстрирует результаты. Команда и заинтересованные стороны обсуждают достижения и изменения в окружении, проверяют результаты и решают, что делать дальше. Обзор — не проверка соответствия фиксированному списку обещанных задач.

Обзор Спринта позволяет команде и заинтересованным сторонам проверить результаты продукта и адаптировать Бэклог продукта. Позже вся команда совместно формирует следующую Цель Спринта. Поэтому Обзор Спринта — формальное и практическое применение принципа «проверяй и адаптируй».

В Обзоре Спринта участвуют команда, Владелец продукта и Scrum-мастер. Также могут присоединиться другие заинтересованные стороны: конечные пользователи, клиенты и представители бизнеса.

Они могут оставить отзывы о продемонстрированном Инкременте продукта. Так команда получает прямые, неотфильтрованные мнения заинтересованных сторон, для которых она создаёт программное обеспечение.

Событие Scrum 4. Ретроспектива Спринта

Этот Встреча по ретроспективе Спринта следует за Обзором и завершает Спринт. Её максимальная продолжительность — три часа для месячного Спринта; для более коротких Спринтов она обычно короче.

Цель Ретроспективы Спринта — улучшить совместную работу участников и применение процесса Scrum.

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

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

• Внедрение практик гибкой разработки программного обеспечения, таких как экстремальное программирование (XP) или разработка через тестирование (TDD).
• Определение новых командных норм и принципов или
• Повышение доступности Владельца продукта.

Команда без исключений проводит Ретроспективу в конце каждого Спринта. Только так эти встречи позволяют систематически адаптировать и совершенствовать применение Scrum с учётом особенностей проекта.

Связанная практика: уточнение Бэклога продукта (груминг)

Scrum Встречи по уточнению бэклога (грумингу) направлены на поддержание актуальности Бэклога продукта. Поэтому бэклог продукта отражает лучшие знания и понимание Scrum-команды о текущем Scrum-проекте.

Уточнение может проходить по необходимости или в запланированных обсуждениях. Две 30-минутные встречи в неделю — лишь практический пример, а не обязательная частота или верхний предел. Владелец продукта и Разработчики сотрудничают, при необходимости привлекая Scrum-мастера и других участников.

На встречах по уточнению бэклога Scrum участники выполняют следующие действия:

• Добавляют новые пользовательские истории на основе вновь выявленных требований.
• Удаляют пользовательские истории, которые больше не нужны продукту.
• Уточняют оценки пользовательских историй.
• Обновляют приоритеты пользовательских историй.
• Разбивают огромные пользовательские истории на меньшие, удобные для работы истории и соответственно расставляют их приоритеты.

Четыре простых шага к сертификации Scrum-мастера

Получить сертификацию Scrum-мастера очень просто, быстро и полностью онлайн.

Благодаря International Scrum Institute™вы можете стать сертифицированным Scrum-мастером быстрее и доступнее, чем когда-либо.

Четыре простых шага, чтобы получить сертификации Scrum-мастера без потери времени, денег и лишних хлопот, приведены ниже.

• Шаг №1. Зарегистрируйтесь онлайн

  Зарегистрируйтесь на сертификацию Scrum-мастера онлайн через страницу регистрации Scrum Master Accredited Certification™.

  После регистрации International Scrum Institute™ мгновенно предоставит вам код доступа к экзамену онлайн.

  По следующей ссылке вы можете зарегистрироваться на программу сертификации Scrum-мастера.

• Открыть изображение в полном размере ↗

  Шаг №2. Учитесь онлайн

  Готовьтесь к сертификации Scrum-мастера онлайн с помощью учебного руководства Scrum — The Scrum Framework™.

  The Scrum Framework™ создана как полностью практико-ориентированная книга. Её содержание поможет справляться с ежедневными трудностями в работе и карьере талантливого Scrum-мастера. Книга полна примеров и практических ситуаций из повседневной жизни самых успешных Scrum-мастеров.

  По следующей ссылке вы можете Запросите бесплатный экземпляр The Scrum Framework™.

• Шаг №3. Сдайте сертификационный тест Scrum-мастера онлайн

  Внимательно прочитав, изучив и усвоив руководство The Scrum Framework™, вы должны быть готовы! Теперь вы должны чувствовать полную уверенность в успешной сдаче сертификационного экзамена Scrum-мастера.

  По следующей ссылке вы можете Перейти к сертификационному экзамену Scrum-мастера.

• Шаг №4. Получите сертификацию Scrum-мастера

  После успешной сдачи экзамена мы немедленно предоставим вам сертификацию Scrum-мастера.

  Работодатели и клиенты могут проверить подлинность вашей сертификации с помощью инструмента проверки сертификатов Scrum для работодателей. По следующей ссылке вы можете открыть инструмент проверки сертификатов Scrum для работодателей.

Мои выводы о сертификации Scrum-мастера

Пора подвести итоги. Если вы не смогли прочитать каждое слово этого пошагового руководства, кратко изложу свои мысли. Вот мой взгляд на преимущества и недостатки сертификации Scrum-мастера.

Преимущества

Преимущества для сотрудников, независимых специалистов, коучей и преподавателей

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

Преимущества для организаций и работодателей

• Сертификации Scrum-мастера сократят затраты, повышая эффективность команд, деятельности и процессов.
• Сертификации Scrum-мастера помогут вам благодаря обученным и квалифицированным сотрудникам выигрывать проекты, которые иначе получить не удалось бы.
• Сертификации Scrum-мастера повысят удовлетворённость и вовлечённость сотрудников, поощряя их обучение и развитие навыков.
• Сертификации Scrum-мастера повысят качество результатов, удовлетворённость клиентов и в конечном счёте успешность и прибыльность организации.

Недостатки

• Сертификация Scrum-мастера не должна останавливать ваше обучение. Помните: получение сертификации — лишь первый шаг.

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

• Единого решения для всех организаций мира не существует. Scrum для разработки и поставки программного обеспечения — не исключение.

  Мы заметили общую черту большинства организаций, не сумевших получить от Scrum наилучшие результаты: они не адаптировали его к собственной деловой и ИТ-среде.

  Поэтому, следуя принципу «проверяй и адаптируй», не воспринимайте Scrum как рецепт со 100% гарантией успеха. Не недооценивайте свою способность адаптировать его к особенностям вашего бизнеса и ИТ. Именно этого от вас как оплачиваемого специалиста и ожидают: использовать Scrum для максимальной пропускной способности и лучших бизнес-результатов.

• Scrum не решил все проблемы наших ИТ-подразделений. Продолжайте развиваться с помощью новых процессов разработки и поставки программного обеспечения, таких как DevOps.

  Чтобы лучше понять известные недостатки Scrum и то, как с ними справляется DevOps, позже прочитайте эту замечательную статью: Каковы 6 главных различий между DevOps и Scrum?

В заключение: сертификация Scrum-мастера — отличный способ начать применять гибкие практики разработки и поставки программного обеспечения.

Согласно исследованию Gartner «Becoming a Better Scrum Master» опубликованной в 2019 году, прогноз статьи на 2023 год предполагал, что 92% компаний мира и 96% компаний США внедрят гибкие практики Scrum. Это прогноз, приведённый в исходной статье, а не измеренный текущий уровень распространения.

Поэтому лучшего времени, чем сейчас, не будет, чтобы

• Начните изучать Scrum бесплатно и
• Получите сертификацию Scrum-мастера по очень доступной цене International Scrum Institute™.

Остаётся лишь вопрос: когда вы начнёте?