История Scrum в статьях и книгах
В 2020 году исполнилось 25 лет Scrum — самому популярному Agile-подходу. Сейчас он плотно аcсоциируется со Scrum Guide, но так было не всегда. Долгое время практикующие Scrum вынуждены были руководствоваться немногими книгами и статьями, каждая из которых вносила что-то свое в описание Scrum: свою механику, свое понимание ролей и мероприятий.
“You call us the creators of Scrum? That’s really bold.
I would call us the ‘parents’ of Scrum, because
many many many people have contributed.”
Ken Schwaber Scrum Guide Update 2017
Вдумайтесь в эти даты: в 1995 году произошла первая публичная презентация Scrum, а первый Scrum Guide появился лишь в 2010-м году, то есть 15 лет спустя. В этот промежуток времени в Scrum добавлялись новые роли, вводились новые мероприятия, менялось понимание того, кто такой заказчик, какова роль Scrum-мастера и многое другое.
Если почитать описание первых версий Scrum, то можно увидеть много удивительных и экзотичных, по современным меркам, вещей. Многие главы и абзацы книг, из которых сформировался подход, могут изрядно повеселить современных практиков Scrum.
Цель этой статьи — через призму книг, статей и других материалов проследить, как формировался Scrum, и почему сейчас он такой, каким мы его знаем.
Содержание статьи
The New New Product Development Game
Термин “scrum”, применительно к разработке проектов, был впервые упомянут Хиротака Такеучи и Икуджиро Нонака в статье, опубликованной в 1986 году в Harvard Business Review.
Один из параграфов статьи имел заголовок: “Moving the Scrum Downfield”, и дальше проводилась прямая аналогия с игрой в регби. Термином “scrum” в регби обозначается один из элементов игры, когда игроки двух команд после нарушения правил или приостановки игры собираются вместе, сцепляются друг с другом и с командой-соперником и ждут вброса мяча «девяткой» — игроком команды под номером девять (scrum half). Это первоначальное состояние, после которого та или иная команда овладевает мячом, и начинается игра.
Вот как это описывает статья :
Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field
The New New Product Development Game, 1986”
Перевод:
Компании все больше понимают, что старый, последовательный подход к разработке новых продуктов просто не помогает достигать цели. Вместо этого компании в Японии и США используют целостный (холистический) метод: как и в регби, мяч передается [между игроками] внутри команды, в то время, когда она движется по полю, как единое целое
Начало Scrum
Статья Такеучи и Нонака 1986 года послужила катализатором к созданию множества новых, гибких подходов к реализации продуктов.
Среди тех, кого увлекли идеи двух японцев, были Джефф Сазерленд и Кен Швабер. Вдохновившись статьей, они создали новый подход, который назвали Scrum,
Джефф Сазерленд вместе с коллегами впервые применил Scrum для разработки систем в 1993 году, во время работы в Easel Corporation. Перед ними стояла почти невыполнимая задача — за 6 месяцев создать работающую замену существующему продукту. Придуманный Scrum-процесс позволил успешно завершить проект в срок, в рамках бюджета и с небывало низким количеством багов. Позже Джефф Сазерленд объединил свои усилия с Кеном Швабером для формализации и окончательной доработки подхода,
Первая версия Scrum была создана под сильным влиянием идей Элияху Голдратта, Теории ограничений и бережливого подхода. По словам Джеффа Сазерленда, основной фокус делался на поиске и устранении потерь, описанных в производственной системе Тойта (TPS): “мури”, “мура” и “муда”.
Идущие “встык” спринты были введены после первых опытов применения Scrum, чтобы выровнять поток задач, и устранить “обнуление” результатов между спринтами (мури).
Постоянный рабочий ритм, используемый в подходе, привел к гиперпродуктивным состояниям сотрудников, и снижению выгорания в ряде компаний, где работал Сазерленд. Это позволило снизить “мура”, то есть перегрузку во время работы человека, производственного участка или процесса.
Заложенный в Scrum механизм непрерывного анализа и улучшение рабочего процесса приводил к устранению “муда” — простоев и действий, не несущих ценности.
Все что есть в Scrum было направлено на устранение вышеперечисленных потерь.
Но начиналось все совсем не так.
OOPSLA 95
В октябре 1995 года на конференции OOPSLA (“Object-Oriented Programming, Systems, Languages & Applications”) в Остине, штат Техас, Кен Швабер и Джефф Сазерленд впервые представили Scrum в своем докладе дали первое описание Scrum-процесса.
Это определение Scrum может очень удивить современного читателя, ведь мы привыкли, что Scrum применяется при продуктовой разработке новых продуктов, в условиях большой неопределенности, а вот как описывается область применения Scrum по версии 1995 года:
SCRUM is a management, enhancement and maintenance methodology for an existing system or production prototype
SCRUM Development Process, Ken Schwaber, OOPSLA, 1995
”
Перевод:
«Scrum — это методология управления, улучшения и сопровождения существующей системы или производственного прототипа”
Обратите внимание: речь про “существующие системы” или работающие производственные прототипы. Ни слова ни про продукты, ни про работу в большой зоне неопределенности.
С другой стороны, авторы доклада отмечают, что разработка сложного ПО обычно сопряжено с большой неопределенностью, с невозможностью построить детальный план реализации и предсказать, каким будет конечный результат.
А вот как выглядел Scrum-процесс на картинке:
Весьма непривычно для современного читателя. Где Ретроспектива? Что за Wrap и Adjust? Процедуры Planning & System Architecture вынесены за пределы рабочего процесса.
Очевидно, что фокус внимания был направлен на IT, и это понятно, ведь конференция была сугубо для разработчиков ПО, и посвящена гибкому созданию программ в объектно-ориентированной парадигме. Среди слушателей доклада сплошь программисты.
Scrum как шаблон
Одним из трендов в области объектно-ориентированной разработки в 90-е годы был поиск и формализация повторяемых шаблонов (patterns), с помощью которых, как из кирпичиков, можно собирать сложные системы.
Позже этот подход попытались повторить для конструирования процессов разработки, надеясь собрать из удачных “процессных” шаблонов, оптимальный итеративно-инкрементальный процесс.
В 1998 году Майк Бидл, Мартин Девос, Йонат Шарон, Джефф Сазерленд и Кен Швабер опубликовали статью SCRUM: An extension pattern language for hyperproductive software development.
Название статьи отсылает к “организационным паттернам”, которые появились как метод организационного моделирования в 1990-х годах в Bell Laboratories под руководством Джима Коплиена, Нила Харрисона и Брендана Кейна. В конце 1990-х Майкл Бидл, Джефф Сазерленд и Кен Швабер объединились, чтобы написать первый язык шаблонов Скрама, который они и описали в этой статье.
Эта статья впервые описала Scrum как набор процессных практик, а не просто набор ролей, артефактов и событий.
Особо интересно, что в этой статье впервые упоминается специальная роль Scrum-мастера как человека, устраняющего блокеры и проблемы на пути команды.
Кстати, название роли писалось слитно, вот так: “ScrumMaster”. Такое написание сохранялось до выхода первой версии Scrum Guide в 2010-м.
Статья написано совершенно «космическим» языком, но мы все равно ей благодарны за ScrumMaster’а 🙂
Первая книга о Scrum
Спустя 6 лет после конференции OOPSLA, в 2001-м году появился Agile-манифест, в разработке которого Джефф Сазерленд и Кен Швабер принимали самое непосредственное участие.
Совпадение или нет, но в том же 2001 году Кен Швабер и Майкл Бидл выпускают первую книгу “Agile Software Development with Scrum”.
Книга очень подробно описывает Scrum-процесс и вводит новые роли, встречи и правила, которых не было раньше.
Наконец-то появляется знакомый нам Scrum. В этой книге впервые были подробно описаны все Scrum-события. Правда Ретроспективы еще не было, она появится позже.
Добавилась роль Владельца Продукта, правда, она не входила в Scrum-команду и во многом была “передаточным звеном” между Заказчиком и Разработчиками. Как ни удивительно нам сейчас, но Владелец продукта по версии 2001 года не имел права определять видение и границы продукта, а мог лишь формализовать и описать требования от заказчика, формируя из них бэклог.
Смешно сейчас читать, но в книге 2001 года была фраза о том, что Владелец продукта должен приготовить элементы бэклога так, чтобы “разработчики не были перегружены необходимостью обдумывания задач для того, чтобы их понять” (“…the team isn’t swamped by having to think about understanding issues while it works…”)
Роль ScrumMaster также была очень экзотичной по нынешним меркам. Тогда ScrumMaster был менеджером, который нес всю полноту ответственности за успешную реализацию Scrum. Более того, ему вменялось в обязанность чуть ли не принудительно (enforce) обеспечивать, чтобы все практики Scrum реализовались как надо, и роли действовали так, как задумано в Scrum.
The Scrum Master is responsible for the success of Scrum. The Scrum Master is responsible for ensuring that Scrum values, practices and rules are enacted and enforced
Agile Software Development With Scrum, 2001
”
Перевод:
«Scrum-мастер несет ответственность за успех Scrum. Scrum-мастер отвечает за обеспечение того, чтобы ценности, практики и правила Scrum были приняты и соблюдались”
Чтобы Scrum-мастер мог этого добиться, ему нужны были полномочия, поэтому книга рекомендовала назначать на эту роль тимлида, руководителя проекта или даже старшего менеджера, то есть людей с властными полномочиями. Совсем не похоже на того “поддерживающего лидера”, который описан в современном Scrum Guide.
Это была основа на которой строилось развитие Scrum все последующие годы. Все дальнейшие статьи и книги уточняли и адаптировал эту картину сообразно реальности, делая ее адекватной меняющейся ситуации, и запросам аудитории.
Статья “What is Scrum?”
Эта статья Кена Швабера от 2003-го года делает большой упор на эмпирический подход к управлению проектом, еще раз разъясняя его основы.
Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process control in a set of simple practices and rules. When I say control, I don’t mean control to create what we predict. I mean that we will control the process to guide the work toward the most valuable outcome possible.
What is Scrum?, 2003
”
Перевод:
“Scrum решает проблему сложности проектов разработки программного обеспечения через инспекцию, адаптацию и прозрачность эмпирического управления процессами в виде набора простых практик и правил. Когда я говорю о контроле, я не имею в виду контроль над созданием того, что мы планируем [сделать]. Я имею в виду, что мы будем контролировать [рабочий] процесс, чтобы работа привела к наиболее ценному результату.”
Зато именно в этой статье, в обязанностях Владельца продукта было прописано обеспечение возврата инвестиций (ROI) и определение плана релизов. Начиная с этой статьи, Владелец Продукта стал нести ответственность за успех продукта, и наделялся необходимыми полномочиями, чтобы формировать продукт, чего не было раньше.
Наконец-то появилась Ретроспектива — дань уважения Кайдзен из производственной системы Тойта (TPS). И впервые Scrum был назван “фреймворком” именно в этой статье:
«After the Sprint Review and prior to the next Sprint Planning meeting, the ScrumMaster holds a Sprint Retrospective meeting with the Team. At this three hour, time-boxed meeting the ScrumMaster encourages the team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint»
What is Scrum?, 2003
”
Перевод:
“После Обзора Спринта и перед следующим Планированием Спринта Scrum-мастер проводит Ретроспективу Спринта с командой. На этой встрече, ограниченной по времени 3-мя часами, Scrum-мастер побуждает команду пересмотреть в рамках процессного фреймворка и практик Scrum свой [собственный] процесс разработки, чтобы сделать его более эффективным и приятным в следующем Спринте”
Первая сертификация на Scrum-мастера
В 2002-м году был создан Scrum Alliance и первая программа сертификации Scrum-мастеров (Certified ScrumMaster — CSM).
Как следствие, появилась потребность в разъяснении реальной практики применения Scrum, появились best practices, которыми могли бы руководствоваться новые специалисты. И авторы Scrum начали писать книги, которые отвечали на этот запрос и давали более глубокое погружение в практики, инструменты и нюансы работы по Scrum.
Scrum на практике
В книге 2004-го года Кен Швабер рассказывает множество реальных кейсов использования Scrum и раскрывает нюансы отдельных его элементов и практик. Книга подробно объясняет, как сделать так, чтобы Scrum работал.
Книга назрела, потому что многих уже тогда вводила в заблуждение обманчивая простота правил и практик Scrum. Значительная часть тех, кто начинал осваивать Scrum, думали, что можно взять из него только то, что нравится, и это даст необходимый эффект. И такое поведение было повсеместно. Например, в самой книге описывается случай: один из знакомых Кена Швабера утверждал, что читал книгу про Scrum и знает как все устроено, но в ходе обучения у Кена, для этого человека оказалось открытием, что ежедневный скрам является обязательной частью подхода, и приносит много пользы команде в ходе Спринта. Кен описывает этот случай с неподдельным удивлением.
Автор показал глубокую взаимосвязанность мероприятий Scrum для поддержки процесса непрерывного улучшения, должного уровня синхронизации внутри и вовне команды, а также обеспечения прозрачности работы.
Книга богата конкретными примерами, и подробно разъясняет многие аспекты Scrum на практике.
Забавная деталь: в описании Ежедневного Скрама сказано, что “любой опоздавший участник при появлении незамедлительно выплачивает 1 доллар Скрам-мастеру”. Такой вот способ мотивации и дисциплины.
В конце книги есть приложение, с кратким описанием встреч, ролей и артефактов Scrum. Это приложение практически один-в-один совпадает с текстом первой версии Scrum Guide, который появится лишь через 6 лет. Видимо это не случайно.
Пользовательские истории и относительные оценки
В ходе освоения Scrum, появлялись новые практики и ннструменты, помогающие команде в работе, при планировании и оценке.
В 2004 году Майк Кон опубликовал книгу “User Stories Applied: For Agile Software Development”, посвященную работе с пользовательскими историями (User Story). В ней также есть описание Scrum.
Несмотря на то, что ничего нового в описании Scrum эта книга не добавляет, в ней во всей полноте описано применение пользовательских историй, а также подробно расписаны принципы оценки задач бэклога в Scrum и отслеживание скорости команды.
Пожалуй, это самая подробная книга по вопросам планирования спринта, оценкам и скорости команды.
Благодаря этой книге вышеупомянутые практики являются неотъемлемой частью современного Scrum фреймворка.
Planning poker и Story Points
Подход к коллективной оценке под названием “покер планирования” (Planning poker) получил свое название благодаря Джеймсу Гренингу (James Grenning) в 2002 году, но лишь благодаря Майку Кону этот метод получил широкое распространение и стал обычной практикой в Scrum, наряду с относительными оценками.
Произошло это потому, что в 2005 году вышла книга Майка Кона “Agile Estimating and Planning”, в которой подробно рассматривались способы коллективной оценки, и давались подробные разъяснения об относительных оценках в Story Points или идеальных часах.
Там же рассказывалось о дельфийском методе оценки, и его адаптации для Scrum в виде “покера планирования”.
Книга изобилует графиками, пояснениями, расчетами, поясняющими идею относительных оценок. Например, вот визуализация распределения времени завершения для разных оценок в Story Points:
Книга заложила прочные основы под практику относительной оценки элементов бэклога, а также “покера планирования” как способа коллективной оценки.
Книга о том, как перейти на Scrum
Долгое время Scrum был уделом небольших компаний, или шустрых IT-компаний, но постепенно, в Scrum стало вливаться «позднее большинство», и примерять на себя этот подход стали большие, неповоротливе компании, которым нужен был гарантированный результат.
В 2009 году Майк Кон опубликовал книгу “Succeeding with Agile: Software Development using Scrum”.
В этой книге Майк Кон подробно описал алгоритм того, как подготовиться к переходу на Scrum, какой путь перехода выбрать, как преодолеть сопротивление при переходе и многое другое. Все это дано на примерах и максимально практично.
Майк Кон приводит множество данных, доказывающих эффективность применения Scrum при разработке продуктов. Например, вот сравнение Time To Market в Agile-проектах по сравнению со средним в индустрии:
Так же много внимания было уделено выбору пилотного проекта для Scrum. Это было крайне актуально, так как наступило время больших Enterprise-проектов, которые делаются по Scrum, и вопрос адаптации «мастодонтов» к новым реалиям стоял как никогда остро.
На рисунке — четыре атрибута идеального пилотного проекта для Agile: длительность, размер, важность, вовлеченность бизнеса. На пересечении этих атрибутов и лежит область идеального пилотного Agile- проекта.
Очень много внимания в книге уделено работе с бэклогом. По-моему, понятие “Айсберг бэклога” (Backlog Iceberg) впервые упомянуто именно в этой книге.
На рисунке — айсберг бэклога. Те требования, которые ближе к нам по времени, прорабатываются очень подробно, декомпозируются и оцениваются. То что дальше 2-3 спринтов от нас, лежит «как есть», в ожидании, когда до них дойдет очередь, и они окажутся в рамках планов на ближайшие 2-3 спринта.
Эта чрезвычайно полезная книга оказала большое влияние на IT сообщество и сыграла большую роль в принятии Scrum в мире, поэтому ее однозначно стоит упомянуть среди материалов, сформировавших Scrum таким, как мы его знаем.
Первая версия Scrum Guide (2010)
Первая версия Scrum Guide создавалась в 2008-2010 годах. К этому моменту Scrum уже довольно активно использовался в IT-индустрии.
Задачей создателей было сформировать короткий, свободно распространяемый, доступный и понятный документ, который бы однозначно определял как делать Scrum правильно, а что не является правильной реализацией.
Посмотреть на первую версию можно тут
Если посмотреть на частоту запросов по известным подходам к разработке, с которыми конкурировал Scrum (XP, DSDM, RUP), то можно увидеть необычный скачок в 2010-м году, как раз, когда вышла первая версия Scrum Guide
С тех пор было еще 6 ревизий Scrum Guide, каждая из которых старалась адаптировать Scrum к меняющейся реальности и новым потребностям рынка. За период с 2010 по 2020 годы Scrum пришел в большие Enterprise-проекты и вышел за рамки IT, все это не могло не отразиться на Scrum Guide, и создатели честно пытались идти в ногу со временем.
Удалось ли им это — судить тем, кто практикует Scrum и достигает с его помощью результатов.
Источники
- Статья Hirotaka Takeuchi and Ikujiro Nonaka. The New New Product Development Game (1986)
- Статья Jeff Sutherland. Origins Of Scrum (2007)
- Ken Schwaber. SCRUM Development Process (Тезисы доклада на конференции OOPSLA95)
- Статья Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland. SCRUM: An extension pattern language for hyperproductive software development (1998)
- Книга Mike Beedle, Ken Schwaber. Agile Software Development With Scrum (2001)
- Статья Ken Schwaber. What is Scrum? (2003)
- Книга Ken Schwaber. Agile Project Management With Scrum (2004)
- Книга Mike Cohn. User Stories Applied: For Agile Software Development
- Книга Mike Cohn. Agile Estimating And Planning (2005)
- Книга Mike Cohn. Succeeding with Agile: Software Development Using Scrum (2009)
- Первая версия Scrum Guide (2010)
Что такое интервизия и действительно ли она помогает скрам-мастерам и agile-коучам, как правильно организовать такую встречу и зачем интервизия нужна самой компании. В статье я постараюсь ответить на все эти вопросы и рассказать о своем опыте, а в конце поделюсь кратким чек-листом для участников, которые хотят извлечь из интервизии максимум пользы.
Современные компании сталкиваются с необходимостью постоянных изменений — будь то адаптация к новым рыночным условиям или улучшение внутренних процессов. Как найти способ эффективно внедрять изменения, причем так, чтобы сделать это быстро и с минимальным сопротивлением от команды? Один из инструментов, который может помочь в этом, — HADI-цикл.
Agile подразумевает смену культуры и изменение мышления, поэтому убедить в необходимости этого руководителей порой бывает очень сложной задачей. Более того, просьба перейти на гибкий подход иногда воспринимается как критика. Давайте разберемся, как можно сделать этот процесс проще и эффективнее.