Джефф Сазерленд. Scrum. Революционный метод управления проектами

Методика Scrum — решение, найденное Джеффом Сазерлендом, чтобы преодолеть классические недостатки управления проектами: отсутствие слаженной работы внутри команды, невыполнение намеченных планов, дублирование задач внутри подразделений и т.д. В отличие от старого «поэтапного» подхода, при котором выбрасываются на ветер огромные средства и который зачастую так ни к чему не приводит, Scrum позволяет выполнять обязательства меньшими силами, в короткие сроки и с низкими затратами, а итоговый продукт отличается отменным качеством. Сегодня Scrum прочно закрепилась в управленческом арсенале большинства технологичных компаний мира.

Джефф Сазерленд. Scrum. Революционный метод управления проектами. – М.: Манн, Иванов и Фербер, 2017. – 272 с.

Скачать краткое содержание в формате Word или pdf (конспект составляет около 6% от объема книги)

Купить цифровую книгу в ЛитРес, бумажную книгу в Ozon или Лабиринте

Глава 1. Привычное мироустройство дает трещину

Традиционно в управлении проектами по разработке программного обеспечения использовали каскадную модель (рис. 1). Поэтапные планы, представленные на диаграммах Ганта, выглядят настолько подробными, что внушают руководству уверенность, будто процесс разработки находится под полным контролем. Существует лишь единственная проблема: диаграммы Ганта всегда неправильны — без исключения.

Рис. 1. Каскадная модель

Почему для названия эффективной групповой работы я выбрал спортивный термин. Слово scrum («схватка») взято из регби и обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели.

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

В начале 2000-х я был среди тех, кто подготовил Agile-манифест разработки программного обеспечения. «Манифест…» провозглашал следующие ценности: люди важнее процессов; фактическая работа продукта важнее документации, фиксирующей, что и как продукт должен делать; сотрудничество с заказчиком важнее обсуждения условий договора с ним; реакция на изменения важнее следования первоначальному плану. Scrum — это концепция, созданная мною, чтобы воплотить эти ценности в жизнь. Не существует никакого единого подхода под названием «гибкая методология» или Agile.

Прежде всего, крайне важно, чтобы участники группы выяснили причину, мешающую ускорять процесс разработки. Представление о «препятствии» зародилось в Toyota — компании, в которой впервые были сформулированы многие идеи, заложенные потом в основу Scrum. Я имею в виду Производственную систему Тойоты, созданную Тайити Оно. Одно из понятий, внедренных Тайити Оно, — создание непрерывного потока. Идея заключается в том, что процесс производства должен быть быстрым и бесперебойным, а одна из ключевых задач руководства — выявлять и устранять препятствия на пути течения потока. Все, что мешает его непрерывности, классифицируется как потери.

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

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

Глава 2. Истоки и рождение Scrum

Родни Брукс преподавал в МТИ искусственный интеллект и был одним из основателей компании, занимавшейся созданием роботов. Брукс говорил, что робот учится ходить заново всякий раз, как его включают. В нем не заложена база данных с информацией, где и что расставлено в каждом помещении. Его включают — и он начинает во всем разбираться с чистого листа. Робот врезается в предметы и учится на основе окружающей реальности, то есть он в состоянии адаптироваться к любой обстановке.

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

— Не знаю. Почему бы не попробовать? Потом расскажете, что из этого вышло, — ответил он.

Вероятно, вам знакома одна из сегодняшних компаний Брукса — iRobot, которая выпускает пылесосы Roomba.

Методология Scrum берет начало в организационных приемах, которые впервые были применены на японских предприятиях.[1] По иронии судьбы обучал их американский ученый Уильям Эдвардс Деминг. Основные положения философии Деминга: точно измерять объем всего, что делается; контролировать, насколько хорошо все делается; стремиться к непрерывному улучшению. В июле 1950 года Деминг выступил с лекцией перед руководителями ведущих японских компаний.

Цикл Деминга, или цикл PDCA (Plan-Do-Check-Act «Планировать, действовать, проверять, корректировать») — наиболее прогрессивная модель управления в те времена, когда американский ученый внедрял ее в экономику Японии, — в итоге привел к тому, что Toyota стала выпускать лучшие автомобили в мире.

Глава 3. Команды

В статье «Разработка нового продукта», о которой шла речь выше, Такеучи и Нонака перечислили характеристики коллективов, работавших в лучших компаниях мира:

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

Всем, кто когда-либо занимался разработкой программного обеспечения, хорошо знаком принцип, впервые сформулированный в 1975 году в эпохальной книге Фреда Брукса Мифический человеко-месяц: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Пытаясь понять, почему увеличение числа задействованных людей замедляет работу над проектом, ученый обнаружил два обстоятельства. Вновь пришедшим сотрудникам, чтобы они могли войти в курс дела, требуется время, а это задерживает всю группу. Вторая причина связана с тем, что количество коммуникационных каналов существенно увеличивается с количеством людей, и наш мозг просто не в состоянии справиться с этим. Не поступайте так. Пусть ваши группы остаются малочисленными.

Вините не игрока, а игру. Отсутствие командного духа, сплоченности и низкая продуктивность возникают из-за фундаментального непонимания того, как работают люди. Сколько раз вам случалось обсуждать с коллегой кого-то третьего, кто «не тянет», «вечно всех тормозит» или «принимает идиотские решения»? И наверняка любой из вас раз-другой оказывался на месте человека, на кого взваливали вину за ошибки. Когда вы осуждаете другого, вы быстро находите подтверждения его персональной вины, но когда упрекают вас, вы гораздо лучше видите внешние факторы, приведшие к проблемам, и можете объяснить причины своего поведения. Когда вы обсуждаете чужие поступки, вы совершаете фундаментальную ошибку атрибуции.[2]

При обсуждении других людей мы говорим об их внутренних свойствах, вместо того чтобы рассматривать эти свойства в контексте внешних условий. Именно взаимодействие с окружающей средой управляет нашим поведением. Все дело скорее в системе, которая нас окружает, а не в некоем внутреннем качестве, которое по большей части в ответе за наше поведение (подробнее см. Ли Росс, Ричард Нисбетт. Человек и ситуация. Уроки социальной психологии). Методология Scrum создавалась ради изменения этой системы. Вместо того чтобы искать, на кого бы возложить вину, она вознаграждает позитивное поведение, ориентируя людей на совместную работу и достижение результата.

Пожалуй, самая известная иллюстрация человеческой реакции на системы — эксперимент подчинения авторитету, или эксперимент Милгрэма. За три месяца до начала эксперимента перед судом предстал Адольф Эйхман — человек, непосредственно ответственный за массовое уничтожение евреев во время Второй мировой войны. Одним из наиболее часто задаваемых вопросов, связанных с Холокостом, был вопрос: «Как могло получиться, что многие миллионы немцев стали добровольными соучастниками этих страшных преступлений?» Вероятно, немцы как народ морально ущербны? Вопрос, на который хотел найти ответ Милгрэм, звучал иначе: «Так ли сильно отличаются рядовые американцы от рядовых немцев? Было бы их поведение другим, окажись они в подобной ситуации?» Увы, ответ оказался неутешительным: американцы не повели бы себя иначе. Мы все способны стать нацистами.

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

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

Глава 4. Время

В начале 1990-х годов исследовательская лаборатория МТИ Media Lab постоянно предлагала разнообразные интересные продукты. Они использовали оригинальную стратегию, применяемую ко всем проектам. Каждые три недели любая рабочая группа должна была демонстрировать коллегам, над чем она сейчас работает. Это был открытый показ, прийти посмотреть мог любой. И если выяснялось, что пробная версия не отличалась ни эффективностью, ни особой крутизной, руководство лаборатории проект закрывало. Немедленная критическая оценка работы была особенно важна — именно она заставляла работать еще быстрее и создавать невообразимые вещи.

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

Я стал практиковать спринты – короткие этапы разработки. Мы собирались решить задачу за короткий срок, а потом остановиться и посмотреть, что получилось.

Спринты имеют определенную продолжительность. Вы не можете сначала сделать недельный спринт, а потом трехнедельный. Нужно быть последовательными. Ваша цель — установить рабочий ритм.

Ежедневные собрания на ходу. Каждый день группа собирается перед белой доской во всю стену. На доске три столбца: «Бэклог»; «В работе»; «Сделано». Скрам-мастер задает каждому участнику группы три вопроса:

Что ты делал вчера, чтобы помочь команде завершить спринт?
Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
Какие препятствия встают на пути команды?

Если на собрание уходит более пятнадцати минут, вы неправильно его проводите.

Важно, чтобы все в группе были хорошо осведомлены, что должен делать каждый участник группы, чтобы задание было выполнено. Чем выше уровень коммуникационного шума, то есть когда все обо всем знают, тем быстрее работает группа. Лучшие команды показывают уровень осведомленности 90%. Большинство компаний оставались на уровне 20%.

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

Глава 5. Потери – это преступление

Тайити Оно, выделяя три вида потерь, использовал японские термины: мури (потери из-за неблагоразумного обращения с ресурсами); мура (потери из-за неравномерного обращения с ресурсами); муда (любые потери, связанные с производственным процессом). Эти идеи тесно связаны с циклом Деминга, о котором я писал ранее: планировать, действовать, проверять, корректировать. Планировать означает «избегать мури»; действовать означает «избегать мура»; проверять означает «избегать муда»; корректировать означает «воля, стимул и решимость воплотить все это».

Не беритесь за всё сразу. Многозадачность – это миф. Не бросайте проекты / производство на полпути. Незавершенка – это потери. Не производите продукцию на склад. Запасы готовой продукции – это потери. Получайте результат с первого раза. Исправления и переделки – это потери. Если уж нужно что-то исправить, то делайте это сразу, а не откладывайте на потом. Напряженный труд порождает еще больше работы (рис. 2).

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

Работа допоздна не свидетельствует о преданности делу, скорее, это признак неисправности системы. Трудясь меньше часов, можно успевать делать больше, поднимая качество работы. Есть ограниченное количество здравых решений, которые вы можете принять за день, но если вы будете принимать их все больше и больше, вы разрушаете свою способность регулировать собственное поведение. Вы начинаете совершать ошибки — не исключено, что очень серьезные. Поэтому отправляйтесь домой в пять. Отключайте сотовый на выходные. Посмотрите кино.

Глава 6. Планируйте реальность, а не пустую мечту

Акт планирования всегда кажется столь соблазнительным и привлекательным, что составление плана становится важнее самого плана. А план становится важнее реальной жизни. Никогда не забывайте простую истину: карта — еще не живая местность.

К несчастью, фаза расчетов может обернуться чистой профанацией, и все заканчивается принципом «мечтать не вредно». Люди, занимающиеся планированием — скорее всего, они настоящие профессионалы своего дела, — как правило, не сознают, что в красивой упаковке таблиц и диаграмм они навязывают разработчикам пустые мечты.

Я хочу познакомить вас с одной диаграммой, имеющей очень привлекательное название — «конус неопределенности» (рис. 3). Мы видим, что сначала оценки работы колеблются от 400 процентов до двадцати пяти сверх реально потребовавшегося времени. Низкие и высокие оценки отличаются друг от друга в 16 раз. По мере того как работа продвигается вперед, оценки все более приближаются к реальной величине — и так до того момента, когда уже нет никаких оценок, а есть одна реальность.

Рис. 3. Конус неопределенности

Первое, что нужно сделать, — составить список того, что предстоит сделать. Далее, выстроить его в соответствии с приоритетностью дел. Теперь нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Люди довольно плохо справляются с такого рода расчетами, но мы хорошо умеем делать другое — сравнивать один размер с другим, то есть определять относительную оценку. Мой любимый пример определения относительных размеров — это измерение «в собачьих баллах». Мой друг Майк Кон придумал измерять объем той или иной работы по проекту «в собаках». Чтобы его разработчикам было удобнее ориентироваться в «собачьей» системе, он составил для них список пород:

лабрадор-ретривер;
терьер;
немецкий дог;
пудель;
такса;
немецкая овчарка;
ирландский сеттер;
бульдог.

Его вопросы звучали примерно так: «Эта проблема — такса или дог?». Позже Майк предложил присвоить каждой породе числовое значение: такса — единица; дог—тринадцать; лабрадор стал пятеркой, а бульдог — тройкой.

В числах, которые я вроде бы произвольно присваивал разным пунктам из списка, есть некая последовательность: 1, 2, 3, 5, 8, 13. Каждое число в этой последовательности является суммой двух предыдущих. Это называется последовательность Фибоначчи.

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

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

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

Можете попытаться переиграть воздействие этих эффектов. Корпорация RAND в 1950-е годы разработала дельфийский метод, использующий анонимные опросы экспертов. Индивидуальные оценки экспертов изучались, обобщались и уже в обезличенном виде их снова скармливали анонимной экспертной группе. И так несколько циклов. Постепенно диапазон оценок сужался. Первоначально оценки колебались в пределах двух порядков (100 раз). После трех циклов отличие сокращалось до двух раз. Это настолько действенный инструмент, что он и по сей день используется корпорацией RAND. Один из недавних примеров дельфийского метода — прогноз возможности успеха американских вооруженных сил в Афганистане, сделанный в 2011 году. И если вдруг вам интересно, то прогноз был неутешительный.

Дельфийский метод требует слишком много времени. Поэтому я придумал «покер планирования»:

Рис. 4. Покер планирования

Каждому члену команды дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче.

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

Оценивать время должны только те, кто непосредственно выполняет проект.

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

Дело в том, что вы, с одной стороны, не получаете, а с другой — не предоставляете того объема информации, который необходим для выполнения хорошей работы. Люди мыслят фактами и сценариями. Именно через них мы понимаем мир. Проблемы появляются сразу, как только мы начинаем вытягивать из основного сюжета отдельные линии, чтобы оперировать ими вне контекста. Таким образом, первое, о чем стоит задуматься, когда вы размышляете о смысле своего задания, — это действующее лицо. Покупатель, невеста, читатель, служащий — тот, для кого вы будете выполнять данную задачу.

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

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

У нас написаны и собраны пользовательские сценарии, и потому мы знаем все задачи, которые должны быть выполнены. Мы уже успели оценить объем каждого задания. И мы готовы приступить к первому спринту. Длиной в неделю. В конце недели мы подсчитаем все завершенные нами сценарии и общее количество очков, на которое они были оценены. Это число покажет нам, насколько быстро движется группа и какова динамика производительности. Мы делаем последний шаг: подсчитываем оставшееся (несделанное) количество сценариев, оцениваем сложность каждого, опять складываем все очки и смотрим на получившееся число. Теперь мы ясно понимаем, когда сможем завершить проект.

Глава 7. Счастье

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

Как мы можем сделать счастливыми себя, своих подчиненных, своих коллег по команде? Как преобразовать счастье в продуктивный труд, приносящий прибыль? Обратимся снова к Toyota и крестовому походу Тайити Оно, объявленному им против потерь. Ликвидация потерь — высокая цель, приведшая Оно к идее непрерывного совершенствования.

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

Главное, о чем нужно помнить, — вы никого не обличаете, а рассматриваете рабочий процесс.

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

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

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

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

Глава 8. Приоритеты

Первое, что полагается делать, когда приступаешь к проекту по методике Scrum, — создать список требований к функциональности продукта; список должен быть упорядочен по степени важности задач, подлежащих реализации. Традиционно такой список называется «бэклог». Основной момент – принцип расстановки акцентов. Для этого нужно выяснить, какие пункты списка:

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

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

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

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

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

Рис. 5. Минимально жизнеспособный продукт

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

Приложение. Внедряем Scrum

Книга была написана для того, чтобы объяснить вам, почему методология Scrum работает. Здесь, в приложении, вы получили ответ на вопрос, как она работает:

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

[1] См. оригинальную статью Hirotaka Takeuchi, Ikujiro Nonaka. The New Product Development Game // Harvard Business Review, 1986, January/February, p. 285-305 и перевод на русский язык.

[2] Фундаментальная ошибка атрибуции — понятие в психологии, обозначающее склонность человека объяснять поступки и поведение других людей их личностными особенностями, а собственное поведение — внешними обстоятельствами.