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

Боевой и научный опыт

В 1967 году молодой военный летчик Джефф Сазерленд прибыл во Вьетнам. Самыми опасными заданиями были разведывательные полеты, которые и пришлось выполнять автору книги. “И нерешительность, и безрассудная храбрость могли стоить летчику жизни”. Летчиков учили простому алгоритму поведения: “наблюдать, ориентироваться, решать, действовать”. Именно этот профессиональный навык помогал Сазерленду быстро принимать решения в смертельно опасных ситуациях, а позже на всю жизнь определил его подход к работе.

“С самого первого дня я старался постичь удивительную тайну. Почему люди упираются в своем желании придерживаться привычной для них организации труда, хотя прекрасно осознают бесплодность и расточительность своей деятельности… Могу только предположить: им кажется, будто если так поступают все – значит, это наилучший способ”.

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

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

“Компания внутри компании”

В 1983 году компания MidContinent Computer Services предложила Сазерленду, как специалисту по системам сбора и анализа данных, возглавить проект по созданию единой сети новых устройств, получивших название Automatic Teller Machines (банкоматы). Сазерленд обнаружил, что работа над этим проектом была организована по традиционной “каскадной” модели. Программисты никогда не укладывались в сроки. Бюджет не соблюдался. В коллективе царила пассивность, руководители занимались мелочным контролем, требовали проявлять максимум усилий и работать внеурочно. Никакие меры не помогали. Сазерленд убедил президента MidContinent выделить занятых в проекте сотрудников в новую автономную структуру. Группа придумала свой процесс разработки продукта со своими инструментами, собственную систему премиальных. Именно тогда появились общая концепция и термины, которые позже составят основу методики Scrum: “владелец продукта”, “бэклог”, “спринты”. Через полгода команда Сазерленда стала самой рентабельной структурной единицей компании.

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

“Мыслящие конечности” организма

Методика совершенствовалась с каждым очередным проектом, которым руководил Сазерленд. На новые идеи его наталкивали сотрудники софтверных компаний и коллективы ученых, разрабатывавших новые технологии. Одним из таких ученых стал Родни Брукс, специалист по робототехнике и искусственному интеллекту из Массачусетского технологического института (МТИ). Брукс рассказал Сазерленду, что попытки создания мыслящего робота с центральным мозгом ничего не дали, зато устройство, у которого каждая конечность обладала собственным “мозгом”, оказалось очень эффективным. Заложенные в него простые алгоритмы позволяли роботу учиться и очень быстро адаптироваться к окружающей обстановке. Сазерленда это натолкнуло на мысль, что, сформулировав такие же простые алгоритмы для рабочего коллектива, можно превратить его в самоорганизующуюся систему. Необходимо было создать такой механизм, который координировал бы действия независимых специалистов и обеспечивал бы им постоянную взаимосвязь с окружающим миром. Сазерленд был уверен: “Достаточно оптимизировать обмен информацией между «конечностями» рабочей группы, и мы добьемся эффективности, о которой раньше не смели мечтать”.

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

Правила Toyota и айкидо

Другим источником вдохновения послужила для Сазерленда производственная система Toyota. В Toyota принято выделять три типа потерь: мури (потери из-за неблагоразумного обращения с ресурсами), мура (потери из-за неравномерного обращения с ресурсами), муда (любые потери, связанные с производственным процессом). Философию устранения потерь можно применить к любому виду деятельности. В приложении к разработке продуктов главные рекомендации будут звучать так. Не пытайтесь делать все и сразу; выполняйте за один раз только одну задачу, требующую особой концентрации. Сведите до минимума количество недоделок – в конце каждого этапа проекта не должно оставаться задач, выполненных наполовину. Немедленно исправляйте ошибки: потом это дороже вам обойдется. Не истощайте силы членов своей команды – они будут ошибаться и принимать неверные решения.

“Суть системы Scrum заложена в ритме деятельности. Для человека ритм имеет особое значение”.

Каждому, кто занимался айкидо, знакомо понятие сюхари: “соблюдать – прорываться – отделяться”. Сначала необходимо повторять за учителем все движения, ничего не меняя, затем – овладеть всеми приемами и научиться импровизировать. Наконец, приобретенное мастерство позволит освободиться от освоенных приемов и начать творить. Подобно айкидо, методике Scrum можно научиться лишь в процессе. (А все правила нужно сначала хорошо освоить, а потом о них можно забыть.)

“Команда может самоорганизоваться и решать проблемы, становящиеся очевидными благодаря открытости всех процессов”.

Вместо каскадной модели – параллельные процессы

Традиционный последовательный (или “каскадный”) подход к работе над проектами безнадежно устарел, как показало множество проектов, в особенности в области разработки ПО, закончившихся полным провалом. Среди первых, кто заговорил о несостоятельности каскадной модели, были японские экономисты Хиротака Такеучи и Икуджиро Нонака, опубликовавшие в 1986 году в журнале Harvard Business Review статью “Разработка нового продукта: новые правила игры”. На смену линейной модели, в которой процессы происходят последовательно, один за другим, утверждали Такеучи и Нонака, должна прийти более современная модель, в которой процессы разработки продукта идут параллельно.

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

Работу при такой организации труда ведут автономные многофункциональные проектные группы, наделенные свободой принятия решений. В этой модели сотрудники перестают руководствоваться только личными интересами, а руководители относятся к лидерству как к служению. Они видят свою основную задачу в том, чтобы устранять препятствия на пути своих команд. Такеучи и Нонака сравнивали работу таких команд с игрой в регби, в которой одним из приемов розыгрыша мяча является “схватка” (по-английски scrum): игроки группируются вокруг мяча и движутся по полю как единое целое. Так у методики, которую разрабатывал Сазерленд, появилось название – Scrum. Командная работа над проектами, как регби, предполагает “слаженность, единство намерений и четкое понимание цели”. От участников требуются взаимное доверие и искреннее желание разобраться в причинах успехов и неудач.

“Я… укажу, каких потерь следует избегать в первую очередь, – потерь, связанных с нанесением ущерба имуществу; потерь, вызванных неправильным выполнением задания с первого раза; потерь от чрезмерного усердия; эмоциональных потерь, связанных с завышенным ожиданием”.

Автономная многофункциональная команда

Высокоэффективные команды имеют три общие черты:

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

  1. Стремление к постоянному совершенству. У выдающихся команд есть представление об общей цели. Они не останавливаются на стандартных решениях, высоко оценивают свои возможности и предъявляют строгие требования к себе и своей работе.
  2. Автономность. Им присущи черты самоорганизующихся и самоуправляемых систем.
  3. Многофункциональность. Они обладают всем необходимым, чтобы без внешнего вмешательства принимать решения и осуществлять их. Передавать проект поэтапно от одного специализированного отдела организации к другому гораздо менее эффективно, чем вести его одной командой, состоящей из разных специалистов.

“Скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос «Как делать?», а владелец продукта – за ту часть, которая отвечает на вопрос «Что делать?»”.

Достичь высоких показателей способны только небольшие команды – от пяти до девяти человек. Скорость работы группы, в которой больше девяти человек, заметно падает. Об этом же говорит и закон Фреда Брукса, сформулированный им в известной книге “Мифический человеко-месяц”: “Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше”. Группы, начавшие использовать методику Scrum, повышали эффективность на 300 или 400%, а лучшие команды – даже на 800. Качество работы при этом тоже существенно возрастало. Их успехи показали, что сверхэффективности в работе можно достичь только при соблюдении следующих условий: режим автономности, постоянное совершенствование, атмосфера сотрудничества и взаимное обогащение знаниями и идеями.

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

Основные понятия и принципы Scrum

В самом начале проекта, который ведется по методике Scrum, команде необходимо составить максимально полный список требований к функциональным характеристикам продукта. Он называется “бэклог”. В нем могут быть записаны десятки и даже сотни задач – часть из них, естественно, никогда не будет решена. Первым делом отбираются приоритетные требования на основе нескольких критериев. Необходимо определить, какие задачи: “1) имеют самое большое значение для хода работ над проектом; 2) важнее всего для заказчика или будущего потребителя; 3) принесут максимальный доход; 4) проще всего осуществить”.

“Я все время пытаюсь объяснить главное: вместо того чтобы планировать все заранее, дорабатывайте план на протяжении всего проекта”.

Работу над проектом принято делить на короткие, но законченные этапы, или “спринты” (по аналогии с бегом на короткую дистанцию). Принцип разделения проекта на короткие этапы с публичным обсуждением Сазерленд позаимствовал у лаборатории Media Lab при МТИ. Идея “спринта” состоит в том, чтобы за короткое время попытаться решить ограниченное число задач, а затем посмотреть на полученный результат. Продолжительность каждого “спринта” должна быть оговорена заранее: чаще всего это неделя или две и в любом случае меньше месяца. В начале каждого такого цикла члены группы отбирают задачи (“единицы работы”), а в конце – внимательно анализируют свои результаты, взаимодействие между участниками, процессы и возникшие помехи. Члены команды идентифицируют самое важное из препятствий, с которыми им пришлось столкнуться, и решают, как его устранить в следующем “спринте”. Так выполняется правило “непрерывного совершенствования” (по-японски кайдзен).

“Все дело в построении правильной системы с правильными стимулами. Нужно дать людям свободу, уважение и право делать свое дело самостоятельно”.

Промежуточные результаты нужно не только оценивать самим, но и обязательно демонстрировать заказчику, например раз в месяц. Заказчику показывается какой-то завершенный фрагмент: допустим, полностью разработанная функция компьютерной программы или “функциональный прототип” автомобиля – то, что он сможет опробовать в деле, не дожидаясь конца проекта. На основе пожеланий заказчика “бэклог” модифицируется.

Информация о ходе проекта размещается на большой белой доске. Доска делится на три столбца: “Нужно сделать”, “В работе”, “Сделано”. Каждое из действий или заданий, которые группа должна выполнить за один “спринт”, записывается на отдельном стикере. По мере их выполнения стикеры перемещаются членами команды из колонки в колонку. В “Cделано” попадает только то, что было уже протестировано клиентом. Исполнитель каждой задачи известен всем: это обеспечивает взаимопомощь, а значит, саморегуляцию деятельности группы.

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

С чего начинать проект

Начните работу над проектом по методике Scrum со следующих шагов.

  1. Выберите “владельца продукта”. Он должен хорошо разбираться в сути продукта, знать рынок, быть всегда доступным для команды. “Владелец продукта” формулирует требования на текущий спринт и “несет ответственность за полезность продукта”.
  2. Сформируйте команду. В группу должны войти специалисты, сумма навыков которых достаточна для выполнения работы. Команда сама решает, как она будет работать; руководство отвечает лишь за постановку стратегических целей.
  3. Выберите “скрам-мастера”. Его задача – проводить все короткие собрания, обеспечивать выполнение всех необходимых процедур и помнить, что сам процесс может стать препятствием к выполнению задач.
  4. Создайте “бэклог” продукта. Как можно быстрее продумайте и запишите все функциональные требования. Упорядочьте список по степени важности задач.
  5. Оцените и уточните “бэклог”. Объем усилий, которые требуются на выполнение каждой задачи, оценивается не в часах, а относительно. Один из способов такой оценки – присвоить задачам “баллы” на основе последовательности Фибоначчи: 1, 2, 3, 5, 8, 13 и так далее.
  6. Спланируйте первый “спринт”. Из верхней части “бэклога” команда выбирает задания для одного “спринта” и решает, какой будет “цель спринта”. Добавлять новые задачи до его завершения нельзя. В конце каждого “спринта” анализируется “динамика производительности”: для этого складываются “баллы” всех выполненных задач. Таким же образом оценивается сложность еще не сделанных работ. Через несколько спринтов уже можно приблизительно рассчитать необходимое для окончания проекта время.
  7. Обеспечьте прозрачность. Завершить проект в кратчайшие сроки можно лишь при условии прозрачности процессов. Повесьте на видном месте скрам-доску. Также составьте “диаграмму выгорания задач”. Для этого по одной оси откладывайте число набранных за уже выполненные задачи баллов, а по другой – дни.
  8. “Собрания на ходу”. Такие собрания проводятся “скрам-мастером” каждый день в одно и то же время и длятся не более 15 минут. Их цель – обсуждение хода работ.
  9. “Обзор спринта”. На этой встрече присутствуют владелец продукта, скрам-мастер, команда и “любые заинтересованные лица – заказчик, представители руководства, потенциальные потребители”. Показывается готовая часть продукта.
  10. “Ретроспективные собрания”. После каждой демонстрации заказчику проводится обсуждение, несущее функцию проверки из цикла Деминга “Планировать, действовать, проверять, корректировать” (PDCA). Команда обсуждает, что удалось в завершенном “спринте”, а что можно было сделать лучше, какие улучшения можно внести в работу немедленно. После этого начинается новый “спринт”.