Софт за 30 дней. Как Scrum делает невозможное возможным

Софт за 30 дней. Как Scrum делает невозможное возможным
Кен Швабер

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

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

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

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

Кен Швабер и Джефф Сазерленд

Софт за 30 дней. Как Scrum делает невозможное возможным

Информация от издательства

Издано с разрешения John Willey & Sons International Rights, Inc., и литературного агентства Александра Корженевского

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова

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

© 2012 by Ken Schwaber and Jeff Sutherland. All rights reserved. This translation published under license with the original publisher John Willey & Sons, Inc.

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

* * *

Посвящается Икуджиро Нонаке, Бабатунде А. Огунайке и Хиротака Такеучи с благодарностью за их наставления и вдохновение

Введение

Мы, Джефф и Кен, работаем в индустрии программного обеспечения в общей сложности 70 лет.

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

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

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

Для этой аудитории у нас есть послание.

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

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

Кроме того, мы расскажем, как определить приоритеты по созданию функционала и получить их «а-ля карт», то есть как пожелаете.

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

Это софт за 30 дней.

Раздел I. Почему любой бизнес в мире может создать программное обеспечение за 30 дней

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

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

Мы надеемся, что сможем достичь этих целей с помощью нашей книги.

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

1. Кризис в программном обеспечении: неправильный процесс разработки приводит к неправильным результатам

Ваша организация, будь то коммерческая, некоммерческая или государственная компания, должна быть в состоянии выдавать полезный продукт путем создания, настройки и использования программного обеспечения. Без программ ваша способность достичь целей как бизнес-лидера сильно ограничена, если не полностью невозможна. Но, несмотря на эту потребность, разработка программного обеспечения – исторически ненадежный, дорогостоящий и подверженный ошибкам процесс[1 - Апрель 11, 2005. Отчет Forrester Corporate Software Development Fails to Satisfy on Speed or Quality («Корпоративная разработка программного обеспечения не может удовлетворить скорости и качества»). Корпоративные разработчики продолжают разочаровывать: к осени 2004 года опрос Forrester 692 влиятельных участников индустрии, которые заказывают разработку программного обеспечения, показал, что около трети недовольны временем, затрачиваемым на разработку, и такое же количество недовольно качеством предоставляемых приложений. Одна пятая опрошенных недовольна обеими позициями.]. Это создает проблему: вам нужно программное обеспечение, но вы не можете получить его в нужное время, по приемлемой цене и с уровнем качества, которое делает его использование удобным.

Действительно, The Standish Group в своем CHAOS Report 2011 года обнаружила, что половина проектов по разработке программного обеспечения с 2002 по 2010 год описывались либо как трудные для выполнения, либо как полный провал. Только 37 % были классифицированы как успешные (рис. 1.1). The Standish Group скромно называет успешным проект, который обеспечивает требуемый функционал в срок и по заявленной цене.

Рис. 1.1. Риски традиционного метода разработки программного обеспечения

Способность приспосабливаться к изменениям, управлять рисками или изначальная ценность программного обеспечения не рассматривалась.

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

И вы не одиноки. К примеру, проект «Страж» Федерального бюро расследований (ФБР) недавно столкнулся с проблемами, и его полностью обновили, используя идеи и процессы, описанные в этой книге.

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

Пример: проект «страж» федерального бюро расследований

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

В марте 2006 года ФБР приступило к разработке «Стража», целью проекта было создание базы для более чем 30 тысяч конечных пользователей, агентов ФБР, аналитиков и административного персонала. По предварительной оценке, на разработку и запуск «Стража», что должно было произойти к декабрю 2009 года, выделили 451 миллион долларов. Согласно первоначальному плану ФБР, разработка «Стража» должна была пройти в четыре стадии. Проекта поручили корпорации Lockheed Martin, практикующей традиционный процесс разработки программного обеспечения.

К августу 2010-го ФБР потратило 405 из 451 миллиона долларов бюджета «Стража», при этом предоставив функционал только двух из четырех стадий. Хотя эти результаты и улучшили систему управления расследованиями ФБР, они не обеспечивали всех полезных функций, которые предполагались первоначально.

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

До этого момента в ФБР использовали традиционный метод девелопмента и теперь решили опробовать новый подход с целью достичь лучших результатов. Мы разработали этот новый подход, названный Scrum, в начале 90-х. Тот самый CHAOS Report The Standish Group, который классифицировал только 37 % проектов успешными, продемонстрировал как различаются результаты традиционного подхода к разработке и тех, которые используют быстрый Scrum-подход (рис. 1.2).

Рис. 1.2. Гибкие проекты в три раза более успешны

В частности, отчет показывает, что 42 % проектов, использующих быстрый метод, добиваются успеха. Что касается традиционных проектов, то здесь успешны только 14 %. Мы полагаем, что в дополнение к стандартным определениям успеха The Standish Group Scrum-проекты также обеспечивают более быстрое реагирование на изменяющиеся потребности клиентов, позволяют снижать риски и в конечном счете предоставляют более высокое качество программного обеспечения.

К 2009 году в ФБР были приняты на работу новый директор по информационным технологиям (CIO) и новый технический директор (CTO) с опытом управления организациями, создающими программное обеспечение на основе нашего метода. Они решили проверить, сможет ли этот более быстрый подход к разработке помочь ФБР. В 2010-м CTO сообщил департаменту правосудия, что намерен изменить подход к разработке проекта «Страж». Он утверждал, что новый подход оптимизирует процессы принятия решений и позволит ФБР остаться в рамках предусмотренного бюджета. ФБР сообщило генеральному инспектору Министерства юстиции, что сможет закончить разработку «Стража» в пределах оставшегося бюджета в течение 12 месяцев после возобновления проекта. Проведенный перед этим компанией Mitre аудит проекта показал, что для завершения «Стража» традиционным методом потребуются шесть лет и дополнительные 35 миллионов долларов.

ФБР перевело всю команду по разработке проекта «Страж» в подвал здания в Вашингтоне и сократило персонал с 400 человек до 45, 15 из которых были программисты. Технический директор ФБР лично возглавил проект. Целью управления разработкой стало предоставление части функционала «Стража» каждые 30 дней. Все приращения функционала обязаны были соответствовать окончательным характеристикам, это не должен был быть «сырой продукт». Каждые три месяца ФБР объединяло три ранее полученные части в единый пилотный проект.

К ноябрю 2011-го, через год после возобновления работы с использованием нового подхода, все стадии проекта «Страж» были закончены. Программное обеспечение установили для пилотной группы агентов ФБР, оснащение оставшихся агентов новым программным обеспечением было запланировано к июню 2012 года. ФБР удалось закончить проект «Страж» за 30 миллионов долларов в течение года. Экономия средств составила более 90 %. Сотрудники так же усердно трудились и над первыми стадиями проекта «Страж», но сам подход к разработке программного обеспечения отбрасывал их назад. После применения нового метода, описанного в этой книге, они продолжили работать столь же усердно, как и раньше, но наградой им стали гораздо лучшие результаты. Если такая организация, как ФБР, смогла сделать это, почему не может ваша?