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

Эту книгу хорошо дополняют:

Управление проектами

Вадим Богданов

Бизнес-процессы

Владимир Репин

Deadline

Том Демарко

Jeff Sutherland

SCRUM

The Art of Doing Twice the Work in Half the Time

Crown Business

New York

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

SCRUM

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

Манн, Иванов и Фербер

Москва, 2016

Информация

от издательства

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

На русском языке публикуется впервые

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

Scrum. Революционный метод управления проектами / Джефф Сазерленд ; пер. с англ. М. Гескиной — М.: Манн, Иванов и Фербер, 2016.

ISBN 978-5-00057-722-6

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

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

Правовую поддержку издательства обеспечивает юридическая фирма «Вегас-Лекс»

© Jeff Sutherland and Scrum, Inc., 2014

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

Предисловие партнера к российскому изданию

Книга, которую вы держите в руках, написана одним из авторов Scrum. Он рассказывает о предпосылках создания методологии и основных ее аспектах.

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

Основная идея методологии Scrum — итеративный подход к планированию и выполнению проекта. В отличие от линейного (каскадного) подхода, когда проект изначально планируется «от» и «до», а результат где-то «в конце пути», данный способ позволяет в короткие сроки с минимальными затратами получить готовый продукт. Конечно, он еще не обладает всеми требуемыми характеристиками, но его уже можно использовать. Далее в ходе проекта исполнитель получает обратную связь от клиента, на основе которой осуществляется циклическое наращивание функциональности и совершенствование продукта.

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

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

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

Книга написана очень живым языком и благодаря насыщенности фактическим материалом легко читается. Автор приводит множество примеров проектов, в которых использовалась Scrum: от таких крупных, как план модернизации системы управления информацией ФБР и одной из крупнейших фармацевтических компаний, до проекта ремонта дома. Также в ней даются ссылки на исследования, которые иллюстрируют психологические аспекты управления проектами.

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

Ульяна Самолова,

президент Samolov Group

Введение

Почему 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 сентября. «Информационные системы катастрофически не соответствовали ситуации, — заключила комиссия в отчете, — в ФБР были лишены возможности охватить в полной мере ту информацию, которой оно обладало, поскольку не существовало эффективного механизма хранения и совместного использования накопленного объема знаний».