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

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

Софт за 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]. Это создает проблему: вам нужно программное обеспечение, но вы не можете получить его в нужное время, по приемлемой цене и с уровнем качества, которое делает его использование удобным.

Действительно, 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 года ФБР выпустило распоряжение о прекращении сотрудничества и приостановке оставшихся двух стадий проекта.