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

Издано с разрешения Scrum, Inc. c/o The Ross Yoon Agency

Научный редактор Анастасия Медведева

Книга не пропагандирует употребление наркотических или любых других запрещенных средств.

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

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

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

© Jeff Sutherland and Scrum, Inc., 2014

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2022

Введение

Почему Scrum?

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

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

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

С момента своего возникновения концепция Scrum легла в основу проектирования новых программных продуктов для технологических отраслей. Однако, снискав признание и успех в Кремниевой долине среди руководителей проектов по созданию программного обеспечения и нового оборудования, в общей деловой практике Scrum остается еще малоизвестной методологией. Именно ради этого делового сообщества – людей, не связанных напрямую с миром высоких технологий, – я задумал написать книгу, в которой собираюсь раскрыть и разъяснить преимущества Scrum как системы управления в бизнесе. Я расскажу о первоистоках методологии Scrum: производственной системе компании Toyota и концепции, созданной для задач боевой авиации, – цикле OODA[1]. Рассмотрю вопрос, почему организация проектов силами небольших команд является более эффективным способом работы. Остановлюсь на следующих моментах: как правильно определять приоритеты в работе над проектом; как организовывать спринты, то есть короткие этапы разработки проекта (от одной недели до одного месяца), – причем делать это таким образом, чтобы каждый член команды отвечал за свою часть работы, а результат последующего этапа вбирал в себя функции проекта, реализованные на предыдущих этапах; как проводить ежедневные короткие обсуждения задач проекта, чтобы быть не только в курсе сделанного, но и тех трудностей, с которыми неизбежно приходится сталкиваться. Кроме того, я объясню, как методология Scrum объединяет концепцию непрерывного совершенствования и концепцию реализации продукта с минимальным функционалом, что позволяет не ждать завершения всех работ, а оперативно удовлетворять требования заказчика на каждом этапе проекта. Вы узнаете, что мы применяли Scrum при проектировании абсолютно всего: от создания дешевых автомобилей с расходом топлива четыре литра на сто пятьдесят километров до разработки современных, на уровне XXI века, баз данных ФБР.

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

Джефф Сазерленд

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

Джефф Джонсон был заранее уверен, что денек выдастся нелегким. Тогда, 3 марта 2010 года, Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией. Воплотив его, ФБР смогло бы предотвращать события, подобные 11 сентября. Однако разработка проекта потерпела фиаско – одно из самых грандиозных, которое знавала история развития программного обеспечения. В Бюро пытались обновить свою компьютерную систему уже более десяти лет, и похоже, их постигла катастрофа. Опять провал.

Но на сей раз – с детищем Джеффа Джонсона – все пойдет иначе.

Семь месяцев назад он появился в ФБР и заинтересовал своим предложением директора по информационному обеспечению Чеда Фулгэма – когда-то они вместе работали в банке Lehman Brothers. Джеффа назначили помощником начальника управления информационных разработок и дали офис на верхнем этаже здания имени Эдгара Гувера, то есть в штаб-квартире ФБР, расположенной в центре Вашингтона, округ Колумбия. Из его просторного кабинета открывался вид на монумент Вашингтона. Вряд ли Джефф предполагал, что ближайшие два года ему предстоит провести в бетонном подвале, в каморке без окон, где он будет пытаться исправить проект, который, по общему мнению, считался безнадежным.

Джефф Джонсон и его босс сочли правильным заявить о поражении и закрыть программу, работа над которой длилась без малого десять лет и обошлась ФБР в сотни миллионов долларов. Настал момент признать, что больший смысл имело бы забрать ее себе и трудиться над ней самостоятельно внутри отдела. «Решение далось нам нелегко, – сказал Джефф. – Но проект требовалось сделать, и сделать хорошо».

Столь долгожданная электронная система была призвана помочь ФБР вступить в новую эпоху – эпоху Facebook, Twitter, Amazon и Google. Шел 2010 год, а большинство документации хранилось в бумажном виде. Программная система, когда-то созданная для нужд Бюро, называлась «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и работала на гигантских ЭВМ – последнем слове техники далеких восьмидесятых. Многие спецагенты предпочитали ею не пользоваться. Слишком она была громоздкой и медленной для эпохи терактов и стремительно перемещающихся преступников.

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

Итак, если ваш запрос одобряли, то первый экземпляр пронумеровывали и спускали вниз. Просто номер, проставленный на листе бумаги, – именно так в ФБР осуществлялось управление документами по расследуемым делам. Система была вопиюще архаичной и фантастически уязвимой. В том числе и из-за нее на Бюро возложили вину, что его подразделения не сумели связать все сведения воедино и обнаружить многочисленных активистов «Аль-Каиды», въехавших в страну за месяцы и даже считаные недели до 11 сентября. Один отдел следил за некой подозрительной личностью. Другой отдел занимался сомнительными иностранцами, почему-то одновременно в большом количестве проходящими летную подготовку. В третьем отделе занесли в список особого контроля кого-то неблагонадежного. Но между отделами не существовало никакого обмена информацией. Во всем ФБР никто так и не сложил вместе имеющиеся данные.

Комиссия 11 сентября[2] – в попытках установить внутренние факторы, позволившие произойти тому, что произошло, – детально изучила все обстоятельства террористических атак. По мнению членов комиссии, аналитики не могли получить доступа к информации, которую должны были исследовать. «Плачевное состояние информационных систем ФБР, – гласит отчет, – привело к тому, что получение такого рода доступа в большей степени зависело от личных отношений аналитика с сотрудниками оперативных команд и подразделений, располагавших информацией».

До событий 11 сентября в ФБР никогда не выполняли экспертной оценки общей террористической угрозы Соединенным Штатам. На то было множество причин: от погони за карьерой до проблем с обменом информацией. Однако недостаток технологического развития указан комиссией как, пожалуй, основной фактор, из-за чего Бюро потерпело такое трагическое фиаско в дни, предшествовавшие 11 сентября. «Информационные системы катастрофически не соответствовали ситуации, – заключила комиссия в отчете, – в ФБР были лишены возможности охватить в полной мере ту информацию, которой оно обладало, поскольку не существовало эффективного механизма хранения и совместного использования накопленного объема знаний».

Когда сенаторы начали задавать ФБР некоторые неудобные вопросы, представители Бюро в основном отделывались фразой: «Не беспокойтесь, мы уже разрабатываем план модернизации». На этот проект под названием «Виртуальные следственные дела» (Virtual Case File, VCF) возлагали большие надежды. В желании извлечь максимальную выгоду из любого кризиса отвечавшие за разработку чиновники заявили о необходимости добавить всего лишь 70 миллионов долларов к имеющимся 100 миллионам, которые были предусмотрены в бюджете. Если вы почитаете публикации того времени, рассказывавшие о новом программном обеспечении для ФБР, то обнаружите, что никто не скупился на слова вроде революционный и преобразование.

Спустя три года проект закрыли. Программа была непригодна для работы. Ни на йоту. ФБР потратило 170 миллионов долларов из кармана налогоплательщиков на покупку компьютерной системы, которой никто никогда не будет пользоваться – ни единой строчкой кода, ни одним приложением, ни малейшим кликом мыши. Проект в целом оказался полностью провальным. И это нельзя считать простым недоразумением – неудачей IBM или Microsoft. Ведь на кону без преувеличения стоял вопрос о человеческих жизнях. На страницах Washington Post появилось признание Патрика Лехи, сенатора-демократа от штата Вермонт, председателя юридического комитета сената:

Мы располагали информацией, которая могла бы предотвратить 11 сентября. А они там сидели, и никто не принял никаких мер… Я до сих пор не вижу, что они устраняют проблему… Пока мы дойдем до технологии XXI века, уже наступит XXII столетие[3].

Довольно показательно, что после провала программы «Виртуальные следственные дела» многие сотрудники ФБР перестали быть таковыми.

К следующему проекту, названному «Страж» (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроля. Они как следует выучили урок. Цена вопроса? Сущий пустяк – 451 миллион долларов. И система «Страж» будет полностью работоспособной в 2009 году.

Что на этот раз могло пойти не так? Ответ появился в марте 2010 года и лежал на столе Джеффа Джонсона. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.

Разбираться с проблемой пришлось Джонсону.

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

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

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

Такие графики называют диаграммами Ганта, по имени их создателя Генри Ганта. С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы – и делать их по-настоящему комплексными – они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны – без исключения.

Генри Гант придумал свои знаменитые диаграммы в 1910 году. Впервые ими начал пользоваться генерал Уильям Крузер, начальник артиллерийско-технической службы вооруженных сил США в Первую мировую войну. Каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее «окопные» организационные идеи остаются популярными и по сей день.

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

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

В бытность свою кадетом Военной академии США, более известной как Вест-Пойнт, я спал в бывшей комнате Эйзенхауэра. По ночам уличные огни, отражаясь в висевшей над камином золотой табличке, иногда будили меня. Табличка гласила: «Здесь спал Дуайт Эйзенхауэр». Я вспомнил об этом президенте, поскольку он однажды заметил, что планировать сражение очень важно, но стоит прогреметь выстрелам – и твоя схема действий развеивается вместе с первым дымом. По крайней мере, Эйзенхауэру хватило здравого смысла не использовать диаграммы Ганта.

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

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

Чед доложил генеральному инспектору Министерства юстиции[4], что завершить систему «Страж» Бюро сможет только в том случае, если возьмет на себя управление проектом: они сократят количество разработчиков, выполнят наиболее трудную часть плана в пять раз быстрее и истратят менее одной десятой бюджетных денег. В докладах генерального инспектора Конгрессу, обычно сухих и официальных, явственно звучали скептические нотки.

Представители финансового контроля, регулярно проводившие по распоряжению генерального инспектора проверку хода работ над проектом, в октябре 2010 года представили очередной отчет, в котором выразили серьезную озабоченность по поводу предложения ФБР; свои основные соображения они изложили в девяти пунктах, после чего следовало их заключение:

В общем и целом у нас есть существенные опасения в отношении предложенного нового подхода; остается немало вопросов по поводу способности исполнителей обеспечить завершение проекта «Страж» без дополнительных расходов, без нарушения сроков и при сохранении в новой системе функциональности старой системы управления следственными делами…[5]

Новый подход назывался Scrum. Создал его я двадцать лет назад. На сегодня Scrum является единственной проверенной на деле методологией, способной вытянуть проекты, подобные «Стражу». Существует два подхода к работе: старый «каскадный» – при нем выбрасываются на ветер сотни миллионов долларов, и зачастую он так ни к чему и не приводит; новый – когда обязательства выполняются меньшими силами, в короткие сроки и с низкими затратами, а итоговый продукт отличается отменным качеством и обеспечивает высокую производительность. Я понимаю, мои слова звучат слишком хорошо, чтобы быть правдой, но результаты говорят сами за себя. Методология работает.

Двадцать лет назад я был близок к отчаянию. Мне требовалось выработать новое мышление. Изучив тонны исследовательских и экспериментальных материалов, просмотрев горы статистических данных, я осознал, что нам всем нужен новый подход к организации человеческой деятельности. Вряд ли поставленную мною задачу можно считать слишком сложной или особенно свежей, этот вопрос обсуждался, и не раз, в прошлом. Известны исследования еще времен Второй мировой войны, в которых рассматриваются наиболее эффективные способы организации труда. Однако по каким-то мотивам люди никогда не стремились сложить воедино разрозненные фрагменты. Последующие два десятилетия я пытался идти исключительно по этому пути, и моя методика получила широкое распространение при разработках программного обеспечения – сферы, ради которой я ее создавал. И в таких гигантах, как Google, Amazon и Salesforce.com, и в маленьких никому не известных стартапах люди с помощью Scrum принципиально изменили свой подход к достижению цели.

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

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

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

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

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

Мы, адепты Scrum, недоумеваем. Почему работа требует столько времени и сил? Почему так трудно рассчитать, сколько времени и сил уйдет на реализацию задуманного? Шартрский собор строился пятьдесят семь лет. Готов поспорить, что перед началом строительства каменщики, глядя в глаза епископу, утверждали: «Двадцать лет – самое долгое. Может, и за пятнадцать справимся».

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

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

Процесс, описанный мною, назван «проверять и адаптироваться». Иначе говоря, в любой подходящий момент и как можно чаще следует прерывать сиюминутную работу, пересматривать то, что уже создано, и выяснять, все ли сделано, что нужно, и как это выполнить лучше. Мысль крайне простая, но ее воплощение потребует от вас внимательности, самоанализа, честности и дисциплины. Для того я и задумал свою книгу, чтобы показать, как это делать. Не только в компаниях, занимающихся разработкой программного обеспечения. Я был свидетелем, насколько успешно методологию Scrum применяли при выпуске автомобилей, управлении прачечной, обучении детей в классе, конструировании космических кораблей и планировании свадьбы. Более того, я вижу, как моя жена пользуется ею, чтобы проконтролировать, тщательно ли выполняются мною по выходным все домашние дела из составленного ею списка.