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

ОТРЫВОК ИЗ КНИГИ

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

Книга, которую вы держите в руках, написана одним из авторов 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 сентября в ФБР никогда не выполняли экспертной оценки общей террористической угрозы Соединенным Штатам. На то было множество причин: от

Конец ознакомительного фрагмента...

GERMES — Бизнес-библиотека в Telegram

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

ОГЛАВЛЕНИЕ

ОТРЫВОК ИЗ КНИГИ

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

Введение