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

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

Ваша организация, будь то коммерческая, некоммерческая или государственная компания, должна быть в состоянии выдавать полезный продукт путем создания, настройки и использования программного обеспечения. Без программ ваша способность достичь целей как бизнес-лидера сильно ограничена, если не полностью невозможна. Но, несмотря на эту потребность, разработка программного обеспечения – исторически ненадежный, дорогостоящий и подверженный ошибкам процесс[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 %. Сотрудники так же усердно трудились и над первыми стадиями проекта «Страж», но сам подход к разработке программного обеспечения отбрасывал их назад. После применения нового метода, описанного в этой книге, они продолжили работать столь же усердно, как и раньше, но наградой им стали гораздо лучшие результаты. Если такая организация, как ФБР, смогла сделать это, почему не может ваша?

Неправильный подход: предиктивные процессы

Процесс, который ФБР изначально использовало для «Стража», мы называем предиктивным, или последовательным. По сути, до 2005 года большинство проектов по разработке программного обеспечения использовали предиктивные процессы, которые при определенных обстоятельствах наиболее подходят и могут обеспечить успех. Эти обстоятельства, однако, скорее исключение, чем правило. Если кто-то может создать окончательное видение, определить все требования к нему и затем разработать детальный план по воплощению их в жизнь, тогда предиктивный процесс будет эффективным. Но любое отклонение от изначального видения, требований или плана создает большой риск. При частой смене требований бизнеса и технологий, которые присутствуют в реальных условиях, очень редко встречается, чтобы все элементы проекта оставались неизменными. Как результат, о чем и сообщает отчет The Standish Group, 86 % проектов по разработке программного обеспечения, основанных на предиктивных процесах, неуспешны. На самом деле мы считаем использование предиктивных процессов самой распространенной причиной проблем при разработке программного обеспечения.

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

Руководители и менеджеры обычно описывают проблемы, с которыми сталкиваются, следующим образом.

1. Выпуск продукта занимает все больше и больше времени. «Каждый релиз занимает больше времени, требует больше усилий и затрат до момента передачи потребителю. Несколько лет назад выпуск новой версии занимал 18 месяцев, теперь на разработку, комплектацию и установку требуется 24 месяца. И при этом каждый релиз становится стрессом и требует значительных усилий. Мы тратим все больше, при этом получаем все меньше и меньше.

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

3. Создание стабильной версии перед релизом занимает все больше и больше времени. «Мы установили разработчикам четкие, неизменяемые даты выполнения заказа. Они уложились в эти сроки, но программное обеспечение было нестабильным, не функционировало, как требуется. У нас даже не получилось отгрузить этот софт как бета-релиз, так что мы смогли получить отзывы только от ограниченного количества пользователей. Дефекты оказались настолько значительными, что наши бета-тестеры отказались участвовать. Нам потребовалось еще девять месяцев, чтобы выпустить релиз, и даже тогда он был нестабилен и требовал множества доработок и оправданий перед пользователями».

4. Планирование занимает слишком много времени и выполняется неправильно. «Мы выяснили, что разработка и развертывание релизов занимают слишком много времени, потому что мы не планировали достаточно хорошо в начале работы. Наши требования были не четко определены и не полностью разработаны, а оценки включали больше догадок, чем возможно. Чтобы это исправить, теперь мы больше времени тратим на планирование. Новые идеи продолжают поступать постоянно. Так как люди пересматривают планы, они находят части, которые должны быть переделаны или уточнены. Теперь мы тратим гораздо больше времени на планирование, чем раньше, но наш график плывет, и периоды стабилизации программного обеспечения все еще большие и ужасные. Несмотря на наши значительные усилия, во время разработки происходят изменения, которые не были и не могли быть учтены во время планирования».

5. Изменения трудно вносить в процессе разработки. «Текущий процесс не приспособлен к внесению изменений. Мы тратим много времени на планирование всего в начале разработки, и все необходимые этапы предусмотрены планом. Но часто необходимо вносить критические изменения или новые функции близко к дате релиза. Для этого мы должны настроить всю ранее проделанную работу для приспособления нового изменения. Это очень сложно, потому что трудно предсказать, как именно это изменение повлияет на стабильность программы. Даже если оно очень важное, есть ощущение, что для его приспособления в процессе разработки требуется в сто раз больше времени, чем если бы знать об этом изменении в самом начале. Но что мы можем сделать? Если важное изменение не внести в текущую разработку или релиз, нужно ждать два и более года до следующего релиза».

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

7. Авралы наносят моральный вред. «Мы обращаемся с людьми так, как нам бы не хотелось. Однако у нас есть обязательства, и бизнес требует, чтобы все, кто работает над проектом, выходили в выходные и задерживались по вечерам. Их семьи и здоровье страдают. Как следствие, у нас есть проблемы с наймом хороших разработчиков, а наши лучшие разработчики уходят в другие организации. Персонал настолько деморализован, что его производительность ухудшается, несмотря на увеличение часов работы».

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

Неправильные результаты: провал проекта

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

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

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

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

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

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

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

Полезный инструмент, оценивающий уверенность и предсказуемость проекта, – график Стейси[2]2
  R. Stacey, Complexity and Emergence in Organizations (London: Routledge, 2001).


[Закрыть]. График Стейси измеряет уверенность в сравнении с непредсказуемостью различных аспектов работы и определяет, где план будет провален.

Мы использовали его, чтобы смоделировать три аспекта в разработке программного обеспечения: требования, технологии и люди, как показано на рис. 1.3.

Рис. 1.3. График Стейси

Можно изобразить проекты по разработке программного обеспечения так, как показано ниже.

Требования: от близко к определенности без риска изменений до далеко от определенности со смутными, сложными характеристиками и множеством ожидаемых изменений.

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

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

Используя график Стейси, можно увидеть, что проекты по разработке программного обеспечения как минимум сложные, а иногда и хаотичные. Предиктивный процесс, на котором основаны каскадный и традиционный методы девелопмента софта, пригоден только для простой, повторяющейся работы. Вы можете определить, правильный ли процесс вы используете, по ставке доходности, степени успеха. Если бы предиктивный подход был подходящим для проектов разработки программного обеспечения, ставка доходности (или процент успешного завершения проектов) была бы очень высокой – около 99,99 %. Однако рассмотренный ранее отчет The Standish Group оценивает процент успеха проектов разработки программного обеспечения, использовавших предиктивный метод, в 14 %.

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

Люди иногда сравнивают разработку программного обеспечения со строительством мостов. Такие инженерные дисциплины находятся на графике Стейси где-то посередине между простыми и сложными. Стандартизация относит эту работу к сложным. Существует три формы стандартизации. Во-первых, есть законы Ньютона, объясняющие, как физические объекты взаимодействуют друг с другом. Во-вторых, применяются стандартные материалы, такие как деревянный брус, стальная арматура, крепления с известными размерами и характеристиками. В-третьих, есть различного рода стандарты, описанные в разных документах и проверяемые различными органами. Ничего из этого не существует в программном обеспечении. Более того, при таком быстром развитии технологий, как сейчас, это вряд ли изменится.

Пример: Parametric Technology Corporation

Parametric Technology Corporation (PTC) – международная компания, насчитывающая около 5000 сотрудников, которая занимается разработкой программного обеспечения управления жизненным циклом продуктов. Эти продукты, которые выросли из CAD/CAM (систем автоматизированного проектирования/производства), помогают некоторым крупнейшим в мире организациям, например Raytheon, BAE System, Airbus, управлять разработкой массивных систем, таких как «Аэробус-А380». Они делают это отчасти путем отслеживания конфигурации всех частей, узлов и сборок.

В 2005 году компания PTC страдала от всех симптомов предиктивного процесса разработки программного обеспечении.

1. Выпуск новой версии продукта занимал все больше и больше времени. Выпуск релизов сползал с 18 месяцев к 24, и казалось, что текущий релиз опять займет больше времени.

2. График разработки релиза не выполнялся. Сдвиг от первоначального графика уже составлял девять месяцев и увеличивался шаг за шагом. Потребители, которые полагались на этот график, были не в восторге.

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

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

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

6. Качество ухудшалось. Это было серьезной и усиливающейся проблемой.

7. Авралы наносили моральный вред. РТС испытывала проблемы с наймом хороших специалистов.

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

Джейн Вачутка, вице-президент по разработке продукта Windchill в компании PTC, как новый сотрудник попыталась применять используемый в компании каскадный метод и столкнулась со всеми обычными для этого метода проблемами. На предыдущей работе она использовала множество некаскадных процессов, подобных тем, что помогли достигнуть успеха проекту ФБР «Страж». В соответствии с этим методом проект состоит из одного или нескольких повторений работы (итераций), каждый из которых длится не более 30 дней. Множество небольших команд разработчиков выбирают наиболее важные требования для каждой итерации и превращают их в часть готового к употреблению программного обеспечения. Все эти части затем объединяются в одну полностью законченную и готовую к применению программу. В конце каждой последующей итерации другие части и надстройки программы добавляются к существующему функционалу.

Брайан Шепард, исполнительный вице-президент по развитию продуктов компании РТС, был настроен скептически, когда в 2007 году Джейн предложила новый процесс производства программного обеспечения.

Она просила позволить ей раньше подключать программистов к разработке, задействовать контроль качества и не выпускать продукты, которые не прошли полного тестирования. Джейн подчеркнула, что функциональные характеристики могут быть несовершенными, так как группа управления разработкой часто будет получать и использовать части разрабатываемого продукта в течение всего цикла разработки, чтобы давать обратную связь. Брайан согласился попробовать новый процесс – гибкий метод разработки под названием Scrum. При этом он предупредил Джейн: «У тебя нет права на ошибку!»

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

Команда управления продуктами имела в своем распоряжении трех-, двух– и однолетний набор требований. За три года до выпуска это было всего лишь видение продукта с описанием самых главных возможностей. Более детальная картина будущего продукта прорабатывалась во второй год разработки. Для текущего года 30-дневные итерации определялись на первые шесть месяцев и составлялась дорожная карта на последующие шесть. Набор требований для каждого года имел больше деталей, чем предыдущий. Разработчики трудились над набором требований для одного года совместно с клиентами РТС, чтобы выяснить больше деталей. Вся организация стала средоточием творчества и продуктивности.