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

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

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

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

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

До этого момента в ФБР использовали традиционный метод девелопмента и теперь решили опробовать новый подход с целью достичь лучших результатов. Мы разработали этот новый подход, названный 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]. График Стейси измеряет уверенность в сравнении с непредсказуемостью различных аспектов работы и определяет, где план будет провален.

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

В течение двух лет все обязательства Джейн перед Брайаном были выполнены. Джейн и ее сотрудники выпускали программное обеспечение каждые 12 месяцев, в то время как ранее выпуск занимал 24 месяца. Продукт был высокого качества. К 2011 году РТС изменилась – она превратилась в прозрачную организацию как внутри, так и для потребителей. Сюрпризы случались редко, клиенты знали, чего и когда ждать. Дефекты были редкими и к 2012 году практически равнялись нулю. Новые детали, пользовательские интерфейсы и возможности рабочего потока были добавлены. Продукт был переработан, стал безопасным от внешних угроз. В итоге бюджет и организационные расходы упали каждый более чем на 10 %. По поручению Брайана Шепарда для организации по разработке программного обеспечения было построено новое здание, которое отражало прозрачность, столь важную для перемен: все располагались в едином пространстве, без отдельных кабинетов, и стены были из стекла.

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

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

Итог

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

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

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

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

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

2. Прозрачность. Когда мы проводим проверку, то должны иметь возможность оценить, что мы видим в тех же условиях, в которых находится наша цель. Если наша цель – разработка системы с определенными признаками или функционалом, то мы должны проверять то, что составляет часть этого признака, функции или их сочетания. Если бы мы использовали предиктивный процесс, то должны были бы задать требования для разработки программного обеспечения, которое может занять годы. Но мы знаем, что в случае с программным обеспечением в течение такого долгого периода накапливается слишком много рисков и потерь. Вместо этого мы используем короткие периоды, обычно 30 дней или меньше. (Позднее мы обсудим значение более коротких периодов.) По окончании первых 30 дней проверяем результаты и определяем, что делать дальше для достижения нашего видения, и, если необходимо, вносим изменения.

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

Таблица 2.1. Бэклог требований для организации бизнес-операций

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

Во-первых, мы должны удостовериться, что наша идея осуществима. Сможем ли мы в течение 30 или меньше дней создать то, что будет полезным и оправдает дальнейшую работу над программным обеспечением?

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

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

Давайте сформулируем определения для того, что мы описали.

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

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

Инкремент (приращение). Это частица целого, которая увеличивается со временем. Функциональный результат итерации в процессе разработки называется инкрементом. Приращение создается повторение за повторением, пока мы не получим полезную систему.

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

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

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

На разработку системы, соответствующей нашим требованиям и видению, может потребоваться несколько или огромное количество итераций. Время каждой из них определено, то есть мы всегда можем выделить и использовать полную итерацию без изменения ее длины. Каждая итерация создает инкремент потенциально полезного программного обеспечения (рис. 2.1). Функционал становится законченным, нет необходимости что-то доделывать. Результат предыдущей итерации используется как стартовая точка для следующей.

Рис. 2.1. Одна итерация производит один прозрачный инкремент

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

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

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

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

Рис. 2.2. Несколько итераций создают инкремент дополнительной функциональности

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

Решает ли эмпиризм наши проблемы?

Решает ли наше эмпирическое решение проблемы каскадного метода? Давайте оценим новый процесс в болевых точках, обнаруженных в каскадном методе.

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

Проблема 2 каскадного процесса: срыв графиков релизов. Наш график разработки не может сдвинуться более чем на 30 дней, так как это максимальная длительность одной итерации. Мы выпускаем накопленные инкременты, когда достигаем даты релиза. Мы не выделяем итераций для построения малозначительного функционала, что позволяет выпускать законченную систему гораздо раньше, чем обычно. При использовании традиционного метода разработки программного обеспечения только менее 50 % функционала используется часто. Мы не разрабатываем этот функционал.

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

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

Проблема 5 каскадного процесса: изменения трудно вносить в процессе разработки. В итеративно-инкрементальном процессе нет состояния середины процесса разработки. Новые требования могут возникать и быть добавлены перед каждой итерацией с минимальными затратами.

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

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

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

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

Таким образом, можно создать график для управления проектом.

1. Бэклог требований по оси Y, или вертикальной оси. Работа по выполнению каждого требования разбита по размеру. Давайте предположим, что у нас есть пять требований. Каждое требует выполнения 2, 3, 5, 3 и 8 блоков работы. Они создают объем работы по оси Y из 21 блока. Блоки расположены в порядке, в котором вы хотите превращать их в пригодные к использованию функциональные возможности. Давайте, скажем, порядок сверху вниз будет 2, 3, 5, 3 и 8.

2. Время отложим по горизонтальной оси Х. Блоки по 30 дней, что составляет протяженность одной итерации.

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

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

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

Рис. 2.3. Диаграмма сгорания работы

План, или прогноз, в начале работы показывает, что вы начали с 21 блока работы.

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

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

Эмпиризм обеспечивает ряд факторов.

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

2. Контроль. Если информация показывает, что окончание работы может быть позднее, чем необходимо, вы можете уменьшить объем требований и количество оставшихся функциональных возможностей, которые необходимо доделать. К примеру, в конце второй итерации, с оставшимися 13 блоками работы для выполнения требований, вы можете уменьшить количество оставшихся блоков до десяти. Если команда разработки продолжит выполнять по пять блоков работы за итерацию в течение последующих двух итераций, функционал будет полностью закончен к концу четвертой итерации.

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

4. Управление рисками. Команда разработки закончила только два блока работы в каждой из первых трех итераций. В конце третьей прогноз показал, что окончание разработки не случится ранее середины десятой итерации. Если начальный бюджет был 100 тысяч долларов, новый прогноз предполагает перерасход средств на 150 тысяч. Если возврат инвестиций в размере 250 тысяч долларов невозможен, то проект можно отменить уже после третьей итерации.

Практические методы, основанные на эмпиризме

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

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

Наши идеи о качествах наиболее эффективных команд разработчиков в значительной степени опираются на работу Такеучи и Нонаки, которые изучали командную работу Гарвардском университете[3]. Они наблюдали за поведением автономных команд, мотивированных высшей целью, вовлеченных в перекрестное обучение и работавших в коротких итерациях. Активное сотрудничество этих команд способствовало генерированию цикла знаний и вело к созданию инноваций, более быстрому времени выхода на рынок и более высокому качеству.

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

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

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

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

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

Взаимное развитие. Совместно размещенные кросс-функциональные команды воспитывают в своих участниках стремление к высокой производительности, качеству и креативность. Члены команды работают совместно, и границы между сферами деятельности начинают размываться. На самом деле некоторые компании требуют от каждого члена команды знаний по двум специализациям (например, программирование более чем на одном языке плюс навыки тестировщика) и в двух областях (например, дизайн и маркетинг). Интенсивное взаимодействие индивидуальностей начинает задавать пульс, или темп команды.

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

Многоуровневое и мультифункциональное обучение. Обучение в команде идет в разных направлениях. В 3М, например, инженерам рекомендуется использовать 15 % своего рабочего времени, чтобы заниматься своей мечтой. Если команда работает с компанией Honda, ее члены могут быть отправлены в Европу, чтобы «осмотреться и понять, что там происходит». Идея в том, что обучение часто происходит в необычных местах и необычным способом и, самое главное, инициируется сотрудниками и поощряется и направляется руководством.

Тонкий контроль. Несмотря на то что команда разработки предоставлена сама себе, она работает не бесконтрольно. Акцент делается на самоконтроле и достаточном количестве контрольных точек, которые устанавливаются для предотвращения нестабильности, неопределенности и хаоса. Контроль со стороны равного и «контроль с любовью» – основы тонкого контроля. Динамическое движение возникает только в окружении, заботливо созданном руководством. Командные лидеры тщательно отбираются, а в самой команде иногда происходит замена участников, чтобы создать правильную динамику и уверенность, что люди смогут ужиться и работать вместе. В команде должен быть набор общих ценностей, а стимулы должны быть основаны на командной работе. При этом следует допускать возможность ошибок.

Передача знаний. Чтобы компания была успешной на рынке, выстраданные знания, накопленные внутри нее, должны быть доступны во всей компании, которая нуждается в новых командах с опытными людьми. Успешные мероприятия в рамках одного проекта распространяются внутри компании как стандартная практика. В то же время разучиться так же важно, как и научиться. Рынок меняется быстро, старые трюки могут больше не работать. Управление предъявляет новые требования, которые явно не могут быть удовлетворены старыми методами ведения дел.

Мы обнаружили, что некоторые практические методы также улучшают разработку программного обеспечения.

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

Люди в команде. Команды и люди делают работу лучше всего, когда их не прерывают. Команды больше совершенствуются, когда сами решают свои проблемы. А общение, в том числе лицом к лицу, – наиболее продуктивный способ для команды работать вместе.

Состав команды. Команды более продуктивны, если имеют один и тот же состав участников. Продукты более надежны, когда команда имеет все кросс-функциональные навыки, сосредоточенные на работе. Изменение состава команды часто временно снижает ее производительность

Даже если мы знаем лучше

Несмотря на то что предиктивный, или каскадный, процесс испытывает трудности, многие организации продолжают пытаться заставить его работать. Мы встретились в 2005 году с СТО и персоналом компании розничной торговли Marks and Spenser из Великобритании, чтобы обсудить эмпиризм и Scrum. Компания только что модернизировала весь процесс развития, приобретя в PricewaterhouseCoopers (PWC), интернациональной консалтинговой компании, набор методологий, инструментов, обучения и услуг по внедрению. Подход PWC был предиктивным, или каскадным.

Но CTO Marks and Spenser хотел понять эмпиризм. Когда мы объяснили ему процесс, он заметно разволновался, прервал нас и сказал, что его компания тоже использует эмпиризм. Всякий раз, когда один из их больших проектов по разработке, основанный на подходе PWC, попадает в беду, они его останавливают и затем применяют другой подход, чтобы вернуть процесс на правильный путь или закончить. Он сказал, что это их «туз в рукаве», имея в виду трюк, который позволяет компании выходить из трудных ситуаций.

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

Гибкость

Поскольку наш мир становится все более сложным, для организаций и бизнеса открывается все больше перспектив. Мечта каждого предпринимателя и бизнесмена с душой предпринимателя – воспользоваться преимуществом новой возможности, выяснить, какая будет цена и какие риски нужно предвидеть. Если риски приемлемы, предприниматель захочет продолжить шаг за шагом, настолько быстро, как только можно, чтобы воспользоваться открывающимися возможностями. Тем не менее, как бы мы ни хотели контролировать риски, все может быстро выйти из-под контроля. Здесь очень желательны смелая осторожность и осторожная смелость. Мы называем способность брать преимущество от появляющихся возможностей гибкостью. Мы можем развернуться на месте, немедленно развить смелые инициативы и начать управлять рисками. Мы можем заставить наших конкурентов рыдать по утрам и мы можем радовать наших новых клиентов. Гибкость – это способность пользоваться возможностями или бороться с трудностями с расчетными рисками. Сегодня это наиболее значимое конкурентное преимущество. Мы создаем это преимущество и контролируем риски, ограничивая все наши проекты сроком в 30 дней или меньше. В этом случае мы можем пробовать идеи и без сожаления от них отказываться. Уже на ранней стадии нам понятно, что они, к примеру, слишком дорогостоящие или нереальные. И мы останавливаемся до того, как потратим слишком много денег.

Итог

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

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

Эмпирический процесс разработки программного обеспечения, использующий итеративно-инкрементальные методы, с нами уже более чем 20 лет. Используя его, вы можете создать плотный контроль над рисками с помощью ограниченных по времени инкрементов программного обеспечения. Это обеспечивает прозрачность путем доставки законченного, готового к использованию прироста полезного функционала каждые 30 дней (или в меньший срок), так что потери могут быть сведены к минимуму. Это обеспечивает скорость и гибкость настройки приложения для более полного удовлетворения возникающих потребностей и тем самым значительно увеличивает применимость. Мы больше не беспокоимся, что наши требования не будут выполнены. Мы больше не волнуемся, что бюджет увеличится. Мы больше не должны зависеть от абстрактных представлений о динамике проекта, таких как диаграммы Ганта или прототипы. Мы точно знаем, где мы находимся с точки зрения ценности продукта и графика, по крайней мере каждые 30 дней.

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

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

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

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

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

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

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

F-Secure разрабатывает в Финляндии антивирусные программы и программное обеспечение в сфере безопасности для международного рынка. Партнер компании предложил ей войти в специфический сегмент рынка антивирусного обеспечения, где она раньше не участвовала, – предстояло разработать дополнительный функционал для партнерской компании, которая затем бы продавалась под ее брендом.

F-Secure использовала эмпирический подход к разработке программного обеспечения в течение трех лет. В компании знали, сколько в среднем полезного функционала ее команды разработки могут создать в течение одной итерации. Основываясь на этом знании, она согласовала с партнерской компанией план разработки: создать частичный релиз программного обеспечения к запланированной пресс-конференции, а вскоре после этого выпустить на рынок первый релиз. К несчастью, команды F-Secure, назначенные для разработки этого продукта, создали в течение первых трех итераций меньше функциональных возможностей, чем планировалось, – 25 % необходимого для пресс-конференции. Уже было ясно, что продукт не будет готов вовремя.

Партнер и руководство F-Secure обсудили замедление прогресса в разработке и приостановили все процессы. Деньги были потрачены, но ничего полезного не было создано. Партнер, узнав, что не получит продукт в срок, остановил все приготовления к пресс-конференции, свернул маркетинговую активность и тем самым спас себя от потери репутации на рынке. Ценным опытом, полученным в результате этого проекта, было ограничение потерь.

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

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

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

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

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

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

Компания Kronos из Бостона – девелопер софта для планирования ресурсов организации и учета рабочего времени. Компания предприняла попытку использовать эмпирический метод, чтобы ускорить свои процессы разработки. В 2008 году правление компании было недовольно прогрессом в разработке нового релиза. Команде девелоперов дали это понять и попросили работать усердней. Те, пытаясь соответствовать требованиям руководства, стали создавать функционал быстрее, чем обычно, но с гораздо более низким качеством.

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

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

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

Роль менеджера при таком подходе – только устанавливать цели, содействовать и устранять препятствия. Он наделяет членов команды правом принимать решения.

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

Расположенная в Филадельфии компания Primavera, которой сейчас владеет Oracle, создает программное обеспечение для управления проектами, основанными на предиктивном процессе. Учредители понимали иронию: использовать эмпирический процесс разработки программного обеспечения для создания своих предиктивных (прогнозируемых) инструментов. Тем не менее, чтобы решить свои проблемы, они должны были к нему прибегнуть.

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

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

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

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

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

Мы начнем с быстрого знакомства с ним, затем разделим метод на три шага, каждый из которых рассмотрим в отдельной главе.

Scrum на уровне проекта. Этот подход применяется «по необходимости» (от лат. pro re nata (PRN), что означает «бери, когда нужно»). Например, когда кто-то нуждается в программном обеспечении за 30 дней или меньше. Глава 6 объясняет, как реализовать Scrum на уровне проекта с минимальными расходами и самыми быстрыми результатами.

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

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

Scrum – это фреймворк (программная платформа) для управления сложным процессом, таким как разработка программного обеспечения. Он очень простой, состоит только из трех ролей, трех артефактов и пяти событий (табл. 5.1). Scrum связывает их вместе правилами игры.

Таблица 5.1. Основы Scrum

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

Создание Scrum-команды и планирование спринта

Первая задача Scrum-мастера – поиск разработчиков и создание команды разработки. Люди в этой команде должны иметь необходимую квалификацию по превращению потребностей и требований владельца продукта (бэклог продукта) в рабочие инкременты программного обеспечения после каждого спринта.

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

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

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

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

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

Спринт за ценностью

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

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

Проведение обзора спринта

В конце спринта Scrum-мастер встречается с разработчиками для проведения обзора спринта. Эта встреча не должна продолжаться более четырех часов. Scrum-команда и ключевые заинтересованные стороны собираются и дают оценку результатам предыдущего спринта и прироста функционала. Обзор включает следующее: что было сделано, каков объем реализованных задач, насколько эффективна разработка и насколько полезен ее результат. Инкремент должен быть законченным фрагментом пригодного к применению программного обеспечения. Пункты бэклога продукта, которые выполнены не полностью, остаются в списке как «все еще требующие выполнения». Новые требования часто возникают в течение обзора спринта. Также часто появляются новые возможности и трудности. Иногда достаточно просто увидеть инкремент, чтобы зародились новые идеи.

Результаты обзора спринта могут включать один или несколько из следующих пунктов:

• начало использования разработанного функционала;

• решение, что делать в течение следующего спринта, и подготовка к нему;

• решение остановить работу.

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

Проведение ретроспективы спринта

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

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

Обсуждение может включать следующие вопросы:

• хорошо или плохо работают члены команды вместе и почему;

• больше или меньше работы, чем предполагалось, делает команда и почему;

• обладает ли команда всеми необходимыми навыками и обеспечением, требующимся для выполнения работы;

• понимают ли разработчики требования и почему;

• способна ли команда закончить спринт в соответствии с требованиями, и если нет, то почему;

• что можно добавить или выбросить из следующего инкремента функционала;

• что команда думает об использовании подхода Scrum.

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

Продолжение спринта

Scrum-команда продолжает повторять шаги, описанные ранее, пока цели не будут достигнуты, возможности максимально использованы, возврат инвестиций достигнут или пока не столкнутся с непреодолимым препятствием (рис. 5.1).

Рис. 5.1. Scrum в действии

Выводы

Scrum прост. Мы рассмотрели его и знаем его составные части. Мы знаем, как двигаться от планов к реализации. Теперь мы посмотрим, как заставить Scrum работать в вашей организации.

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

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

В течение предыдущих 20 лет многие Scrum-проекты проходили внизу организации, скрытые от взгляда. Команда, работающая над проектом, пробовала применить Scrum и создавала впечатляющие результаты. Затем другая команда пробовала его, и скоро команды внутри организации начинали разрабатывать программное обеспечение быстрее и чаще. Довольно скоро Scrum-проекты стали проявляться повсюду в организации. Мы называем такой Scrum PRN.

Как и в медицинском случае, PRN, когда применение лекарства оставлено на усмотрение медсестры или пациента сообразно возникающим обстоятельствам, Scrum-PRN необходим, когда возникает важная возможность или критическая трудность и программное обеспечение требуется быстро. Он может быть использован незамедлительно. Исключения в обычном подходе допускаются для разрешения кризиса или для того, чтобы не упустить возможность. Использование Scrum-PRN не требует разрешения. Разрешение для его применения – безотлагательная потребность в программном обеспечении.

Затраты на 30-дневный спринт могут варьироваться от 50 до 150 тысяч долларов в зависимости от размера Scrum-команды, заработной платы ее членов и других факторов. Каковы же преимущества метода?

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

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

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

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

Управление работой: диаграммы сгорания задач

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

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

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

Когда требования трансформируются в инкременты функционала. проявляется тенденция. Например, в начале первого спринта команда разработки оценила размер требований в 140 единиц работы. Она представила 20 единиц работы в спринте № 1, 40 единиц – в спринте № 2 и 40 единиц – в спринте № 3. Это может быть прослежено при помощи диаграмм сгорания задач, измеряющих требования в единицах работы, которую еще предстоит сделать. Оставшаяся работа вычисляется в конце каждого спринта. Она равна единицам работы, прогнозируемой в начале спринта, за вычетом единиц законченной работы, которая была переведена в инкремент к концу спринта. Как выглядит диаграмма сгорания задач для примерного проекта, показано на рис. 6.1.

Рис. 6.1. Пример диаграммы сгорания задач

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

Чтобы прогнозировать будущее, можно использовать средние значения прошедших спринтов. В первых трех средняя единица законченных требований была 33,3 со стандартным отклонением 11,5. Прогнозная линия строится, как показано на рис. 6.2.

Рис. 6.2. Пример прогноза

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

Новые требования появляются, когда проект продвигается вперед. В ходе тестов выясняются новые потребности клиентов. Когда инкременты изучаются, появляются новые возможности. К примеру, со 140 единиц требований в начале первого спринта, если 20, 40 и еще 40 единиц новых требований возникнут и будут добавлены в бэклог продукта в начале каждого из трех спринтов, диаграмма выгорания задач будет плоской, давая неправильное впечатление, что никакой работы не сделано (рис. 6.3).

Рис. 6.3. Реальная и предполагаемая диграммы сгорания задач

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

Чтобы сохранить тренд снижения диаграммы сгорания, вычисляется новая конечная базовая линия: [(начальная базовая линия + дополнительные единицы работы над новыми требованиями) – (законченные единицы работы над требованиями) = новая конечная базовая линия]. Эта новая конечная базовая линия показана на рис. 6.4. Она помогает нам спрогнозировать, что проект, скорее всего, будет закончен гораздо позднее, чем ранее предположенный конец четвертого спринта.

Рис. 6.4. Конечная базовая линия отражает бэклог продукта

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

The Standish Group оценила, что 50 % всех функций программного обеспечения очень редко или никогда не используются пользователями[4]. К примеру, 80 % пользователей применяют только 14 % функционала массивного сайта hp.com[5].

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

Не игнорируйте сложности – всегда держите глаза открытыми

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

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

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

Длина спринта

Организации, которые применяют Scrum, имеют тенденцию к использованию 30-дневных спринтов, но Scrum также позволяет более короткие спринты наравне со спринтом в один месяц. Более длинные спринты хороши для более стабильных ситуаций, а более короткие – для более сложных и требовательных.

Рис. 6.5. Переменные, влияющие на длину спринта

Лучшая длина спринта для вашего проекта определяется после оценки следующего (рис. 6.5):

• перерасходы на короткие спринты;

• увеличение гибкости и контроля;

• длина спринта.

Спринт никогда не должен превышать один месяц.

Доводы в пользу более коротких спринтов

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

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

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

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

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

5. Предоставление обучающего опыта. Люди любят быть успешными. Когда они учатся ездить на велосипеде, кататься на коньках или лыжах, то для начала делают короткие попытки. Неудача может быть оценена и внесены изменения. Затем они пробуют снова. Короткие спринты способствуют обучению.

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

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

Доводы против более коротких спринтов

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

Цена, которую приходится платить за более короткие спринты, – увеличение времени, необходимого для планирования и разбора. Вы можете сами выбирать, хотите ли вы платить за дополнительную страховку. Таблица 6.1 показывает, какое примерно время необходимо на спринты разной длины. В примере время на проведение мероприятий спринтов разной длины приведено к эквиваленту 30-дневного спринта. Стоимость мероприятий спринта, таких как планирование спринта, обзор спринта и ретроспектива спринта, принята одинаковой. Стоимость Scrum-команды, о которой идет речь в примере, составляет 200 тысяч долларов за тридцатидневный спринт.

Таблица 6.1. Стоимость коротких спринтов

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

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

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

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

1. Заинтересованные лица теряют внимание и забывают о проекте.

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

3. Объем информации для обзора и изучения, а затем для принятия решений разрушает эффективность коротких Scrum-мероприятий.

В пределах проекта применяйте спринты одной длины

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

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

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

Примеры проектов Scrum-PRN

В Fidelity Investments применили Scrum в 1997 году, чтобы предоставлять интернет-услуги для своих пользователей. Чарльз Шваб и клиенты E-Trade уже управляли своим капиталом онлайн, а пользователи Fidelity – еще нет. В то время Fidelity представляла собой жесткую каскадную организацию. Многочисленные попытки по предоставлению интернет-услуг заканчивались неудачей. В отчаянии компания обратилась к Scrum. За несколько месяцев первый вариант сайта Fidelity.com был разработан и запущен, и в течение 18 месяцев инвесторы были счастливы работать с Fidelity.com, который стал не хуже решений конкурентов. Успех был достигнут, и Scrum выведен из оборота компании. Следующие семь раз, когда Fidelity критически нуждалась в разработке программного обеспечения, она создавала Scrum-проекты. Однако компания не воспользовалась всеми преимуществами, которые могла бы получить, приняв во внимание предыдущий опыт. Каждый Scrum-проект мог быть более эффективным, чем предыдущий. Тем не менее Fidelity сделала выбор – использовать Scrum только в чрезвычайных ситуациях, PRN.

Шаг на следующую ступень в организации – переход Scrum с уровня проекта на уровень студии разработки программного обеспечения. Как только студия создана, у организации появляется постоянная база для быстрого запуска Scrum-проектов по разработке программного обеспечения.

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

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

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

Вся работа в студии основывается на Scrum. Каждый разрабатываемый проект содействует накоплению знаний, квалификации, производительности и ценности всех последующих проектов. Чем больше проектов произведено в студии, тем больше накапливается опыта, знаний и технических средств. В результате каждый последующий проект становится более продуктивным и создает больше ценности.

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

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

• иметь за плечами несколько лет опыта работы Scrum-мастером, менеджером в Scrum-среде;

• понимать процесс разработки программного обеспечения;

• иметь квалификацию и опыт по внедрению изменений и упрощению процедур;

• обеспечивать обучение и инструктаж разработчиков в студии;

• быть уверенным, что Scrum-мастера, работающие над проектами, хорошо делают свою работу;

• помогать оптимизировать результаты проектов;

• постоянно совершенствовать технические средства студии, чтобы последующие проекты становились более экономичными и эффективными.

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

Цель менеджера студии – обеспечить рабочую обстановку с максимально возможной стоимостью. Как минимум цель студии – сделать более легким запуск новых Scrum-проектов.

Обучение и условия использования

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

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

Способы работы оформляются и объясняются. Новые техники могут потребоваться для следующего:

• увеличение вклада в работу команды по сравнению с личной производительностью;

• создание структуры отчетности и проверки производительности;

• разрешение конфликтов;

• урегулирование отношений с проблемными членами команды;

• преодоление препятствий и потребностей.

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

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

Сотрудники, участвующие в Scrum-командах, подписывают соглашение об условиях использования технических средств студии. Соглашение обеспечивает их пониманием того, чего от них ждут. На рисунке 7.1 перечислены типичные условия использования Scrum.

Условия сотрудничества в рамках студии

1. Каждый проект должен быть основан на процессе Scrum и его принципах: эмпиризме, накоплении знаний и самоорганизации.

2. Каждый проект будет реализован отдельной Scrum-командой, состоящей из владельца продукта, Scrum-мастера и не более чем девяти разработчиков.

3. Scrum-мастер должен иметь опыт управления Scrum-проектами. Если его опыта недостаточно, он должен не стесняться принимать помощь и проходить обучение у старших Scrum-наставников.

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

5. Scrum-команда (команда разработки) будет состоять из разработчиков программного обеспечения, обладающих всеми навыками, необходимыми для создания инкремента потенциально пригодной к использованию функциональности, основываясь на требованиях владельца продукта.

6. На протяжении всего проекта внешние связи и подчиненность должны быть приостановлены.

7. Каждый инкремент должен соответствовать определению «прозрачности» и «законченности».

8. Scrum-команда будет использовать современные методы разработки и технические инструменты, предоставляемые студией, а также по необходимости проходить обучение по их использованию.

9. Проект должен соответствовать всем политикам и стандартам студии.

10. Члены Scrum-команды по возможности должны находиться на территории студии и работать над проектом полный рабочий день.

11. Scrum-команда имеет право и возможность пользоваться всеми преимуществами и удобствами студии, помогающими в разработке.

12. Члены Scrum-команды будут способствовать возрастанию общих знаний, основанных на опыте их работы над проектом, а также будут делиться этим знанием с другими командами.

ФИО ______

Дата ______

Рис. 7.1. Условия сотрудничества в рамках студии

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

Технические средства студии

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

1. Рабочее помещение. Scrum-команды преуспевают в открытых помещениях, которые поддерживают взаимодействие команды, то есть следует создать пространство, где члены Scrum-команды могут легко общаться, пока разрабатывают программное обеспечение. Должно быть достаточно пространства возле каждого человека, для двух или трех человек, чтобы они могли работать вместе. Кресла должны быть удобными, а рабочие столы – легко двигаться. Интернет, локальную сеть и серверы следует настроить и обеспечить инструменты для разработки, необходимые Scrum-команде. Оборудование также должно включать средства вывода, проекторы или большие телевизоры в местах проведения мероприятий, а также множество офисных мольбертов. Также должно быть предусмотрено место для посетителей или временных членов команды. Зачастую необходимо или желательно настроить пространство на основании стиля разработки или меняющихся потребностей.

2. Инструменты для разработки и методики. Scrum-команда должна иметь полностью автоматизированное оборудование для разработки и тестирования, чтобы, как только новое программное обеспечение будет разработано или изменено, его можно было бы протестировать и посмотреть, как оно работает. Тесты могут быть большими, например функциональными, или маленькими, например модульное тестирование кода. Критические тесты проводятся для проверки стабильности, производительности и безопасности. Должны использоваться техники бережливого качества, когда качество встроено, чем когда оно достигается путем тестирования, когда функционал уже закончен. Команда разработки характеризует продукт с точки зрения тестов или вещей, которые он должен делать, и того, как он их делает. Если какой-то тест не пройден, разработка останавливается, пока причина неудачи не будет исправлена. Незаконченная или дефектная продукция требует денег на исправление. Чем больше таких багов накапливается к концу разработки, тем выше будет стоимость или технические усилия по их исправлению. Это работа и стоимость уже не подчиняются линейному закону. Scrum-команда не только должна проводить тесты, чтобы удостовериться в том, что разработанное ими сейчас функционирует правильно, но также должна применить все предыдущие тесты, чтобы убедиться, что вся система не подорвана.

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

Изменения и дилемма

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

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

Таблица 7.1. Опросник

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

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

Управление с помощью цифр

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

Эти показатели объединены на общей инструментальной панели студии, которая отслеживает историю проектов и отражает тенденции. Эти показатели используются и для оценки затрат и прибыли студии, и для оценки финансирования ее необходимого развития. Руководство организации может использовать совокупные показатели для определения общей рентабельности инвестиций (ROI) студии и решить, должно ли быть применение студии расширено или сжато. Рисунок 7.2 показывает первичные показатели на инструментальной панели студии. Каждый может иметь много подчиненных показателей.

Рис. 7.2. Инструментальная панель проекта

1. Продуктивность – это количество единиц бизнес-функционала, которое разработано на определенное количество денег (например, на 100 тысяч долларов инвестиций). Продуктивность также называют скоростью. Это показатель не ценности, а только количества произведенного функционала. Изначально произвольная единица функционала определяется и измеряется. Размер измеряется в функциональных точках, объективной и абстрактной системе измерений для программного обеспечения[8]. Функциональные точки универсальны и могут быть применены везде в пределах системы, продукта или для любой другой системы. Весь другой функционал определяется относительно базовой единицы. Эта система измерений (измерение размера единицы функционала в функциональных точках) становится стандартным показателем студии. Базовая единица требует периодической калибровки, чтобы гарантировать ее соответствие.

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

3. Ценность – мера того, насколько ценен созданный функционал для организации. Это мера эффективности (в процентах) от каждого доллара, потраченного на разработку программного обеспечения, которая создает ценность для организации. Показатель ценности не включает рыночную ценность. Рыночная ценность отражает показатель ROI, о котором мы не станем говорить в рамках этой книги. В среднем в общем уровне затрат на создание ценности в организации на разработку программного обеспечения затрачивается меньше 10 % от каждого доллара. Значительный процент расходуется на поддержание и сохранение существующих систем. Также большое количество средств идет на разработку функционала, который используется не очень часто. Большая часть денег тратится на создание программного обеспечения, которое могло быть полезным где угодно, но не в пределах организации, которая за него платит.

Инструментальная панель студии отражает тенденции по повышению продуктивности и качества, как показано на рис. 7.3.

Рис. 7.3. Инструментальная панель качества и продуктивности

Следующая панель отражает тенденции в увеличении ценности и ROI, как показано на рис. 7.4.

Рис. 7.4. Инструментальная панель ценности и возврата инвестиций

Можно учитывать еще несколько показателей.

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

• разработка – средства, выделяемые на разработку продукта или системы;

• техническое обслуживание – затраты на поддержание, сохранение и развитие продукта;

• эксплуатационные затраты – средства, выделенные для запуска и управления продуктом, когда он доступен для использования по назначению.

2. Проекты. Количество проектов, чьи данные объединяются и отображаются.

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

Таблица 7.2 показывает примеры показателей, которые могут быть сделаны в студии.

Таблица 7.2. Инструментальная панель тенденций

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

Рассмотрим некоторые из этих воздействий.

• Функциональные возможности, которые редко используются, по-прежнему должны быть сохранены и увеличивают эксплуатационные расходы.

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

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

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

Показатели зависят от прозрачности

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

Scrum обеспечит вам следующие возможности.

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

2. Представление о том, какой функционал уже сделан. Функционал соответствует тому, сколько денег потрачено. Это прибыльно.

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

4. Возможность взять один или несколько инкрементов функционала, которые уже закончены, и начать ими пользоваться, изучая ценность на раннем этапе.

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

Законченный инкремент функционала

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

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

Непрозрачность вместо прозрачности

У нас есть опыт работы с последствиями отсутствия прозрачности в крупной энергетической компании в 2002 году. Scrum был опробован в одном из отделов, менеджер которого, Дэвид, был в восторге от прозрачности, обеспечиваемой Scrum. К сожалению, он не убедился, что инкремент полностью доделан и годен к употреблению. Он даже не знал, что должен это делать. Вот его история.

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

Всю информацию его организация получала в форме распечатанных документов. Объем становился ошеломляющим, и Дэвид хотел автоматизировать этот процесс.

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

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

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

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

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

Что думали люди о том, что происходило

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

.

Рис. 7.5

Что произошло на самом деле

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

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

Рис. 7.6. Инкрементальный прогресс в сторону готовой к использованию функциональности

В самом начале проекта они думали, что сделают все инкременты действительно готовыми к употреблению, когда все спринты будут закончены.

Дэвид уловил идею прозрачности и предсказуемости. Команда разработки – только общую идею Scrum. Они перенесли непредсказуемость разработки каскадного процесса внутрь Scrum.

Прозрачность инкрементов должна была позволить Дэвиду управлять рисками и добиваться предсказуемости. В начале проекта Дэвид со Scrum-командой определили план выпуска. После спринта № 1 он оценил динамику приближения к будущей цели путем оценки того, что, как он думал, было рабочим инкрементом, и принял решение о том, что необходимо сделать в спринте № 2 в рамках движения к цели. Если бы он знал, что прогресс был недостаточным, то мог бы отменить проект. Однако из-за того, что инкремент был непрозрачным, он не мог эффективно принять решение.

Когда команда разработки оценила объем работы, которая не была доделана в течение первых трех спринтов, это добавило еще 14 единиц работы. Расхождение между планом и реальным прогрессом в конце третьего месяца разработки отражает эти «скрытые» 14 единиц работы, как показано на рис. 7.7.

Рис. 7.7. Реальная и планируемая законченная работа

В конце третьего спринта Дэвид верил, что 30 % работы уже сделано, как показано на рис. 7.5. Он думал, что может начать использовать эти 30 % готового продукта. К сожалению, инкремент не был законченным. Как показано на рис. 7.7, чтобы устранить расхождение между диаграммой сгорания задач, которую Дэвид считал правдивой, и реальной диаграммой, нужны два дополнительных спринта, чтобы сделать три предыдущих инкремента пригодными для использования в бизнесе.

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

Когда проект «закончен», «завершен» или «финализирован», не должно быть недоделанной работы. Этот важный момент – одно из наиболее неявных, но фундаментальных требований Scrum-подхода.

Аналогия

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

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

Устранение технических долгов для получения готовых к использованию инкрементов

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

Таблица 7.3 предоставляет в первой колонке типичную работу, которую проделывает команда девелоперов, чтобы превратить требования бэклога продукта в стабильный функционал. Вторая колонка, обозначенная «Обычно», содержит количество единиц работы, которую команды привыкли делать предварительно до конца предиктивного, традиционного, проекта для каждой задачи из первой колонки. К примеру, разработчики привыкли тратить 12 единиц работы на анализ требований. Они привыкли тратить 10 единиц работы, создавая компоненты архитектуры. Это относительные цифры, показывающие, что разработчики тратят на две единицы больше работы в первом пункте, или на 20 % больше работы, чем по второму пункту.

Таблица 7.3

Третья колонка, названная «Сделано», содержит единицы работы, которые им требуется выполнить, чтобы создать полностью законченные, прозрачные инкременты функционала по каждому пункту из первой колонки. Общая сумма работы для создания прозрачных инкрементов составляет 171 единицу. Большинство разработчиков привыкли заканчивать только 71 из этих единиц работы, когда они переходят на эмпирические Scrum-проекты, как это показано в колонке «Обычно». Они привыкли оставлять на потом 100 единиц работы в каждом фрагменте функционала, который они создают. спринт за спринтом, эта незаконченная работа накапливается по экспоненте до самого конца проекта.

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

Компания Adobe и технический долг

Продукт Adobe Premiere Pro – ведущий в отрасли набор программного обеспечения для нелинейного видеомонтажа. Программы канала BBC и The Tonight Show («Сегодня вечером») создаются с его помощью. Вице-президент подразделения Стив Уорнер управлял Premiere Pro. Питер Грин был программным менеджером пакета Creative Suite в его составе. Развивающиеся стандарты и запросы на новые возможности требовали от них очень быстрого выпуска новых релизов.

Premiere Pro CS3 (Creative Suite, версия 3.0) был выпущен в июле 2007-го. Для его создания были использованы традиционные методы, и программное обеспечение поставлялось одним большим фрагментом после 18 месяцев разработки. Когда дата выпуска стала приближаться, разработчики начали собирать CS3 к релизу. Было очень много «стучащих труб» (то есть дефектов или ошибок). Разработчики не располагали достаточным количеством времени, чтобы их все исправить, поэтому собрали релиз так, как смогли в эти временные рамки, и выпустили его. Вот какие комментарии оставляли пользователи о CS3:

«Если вы хотите легкую в использовании, дружелюбную по отношению к пользователю программу для редактирования видео, это точно не она. Были вещи, которые я от нее ждал, а она их не делает. Или я не смог их запустить»[9].

«…это программное обеспечение – заведомо плохой код с большим количеством утечек памяти. Если вы попробуете перекодировать большой видеофайл в mpeg2, Premiere, скорее всего, выдаст ошибку из-за плохого управления памятью. Единственное решение – просто перезапустить систему и молиться, чтобы это опять не случилось»[10].

Следующий релиз, Premiere Pro CS4, должен был устранить дефекты CS3. CS4 должен был улучшить стабильность, скорость и легкость в использовании, а также остановить утечки памяти. Питер Грин услышал об этом и решил, что короткие циклы разработки позволят Adobe создать законченные инкременты общего продукта после каждого спринта. Затем инкременты будут складываться в нечто работающее, и это должно понравиться пользователям. Питер также хотел знать реальное положение дел в каждом спринте, поэтому поручил нескольким командам, работающим над CS4, попробовать Scrum.

У Adobe было более 100 девелоперов в 18 Scrum-командах, работающих над выпуском этого релиза. Все решили, что интегрирование всех инкрементов от всех 18 команд после каждого спринта будет слишком большой работой. Они решили подождать до даты, близкой к релизу, чтобы интегрировать все инкременты. Прямо перед выходом CS4 команды пытались соединить фрагменты своей индивидуальной работы в один объединенный продукт. Все противоречия и неразрешенные зависимости, которые препятствовали интеграции, выявились в виде ошибок, и фрагменты CS4 не работали вместе. Рисунок 7.8 показывает медленное увеличение в течение разработки до попытки интеграции и затем резкий скачок в количестве дефектов. Разработчики героически исправляли максимум возможного, но все-таки им пришлось выпустить продукт с заметными дефектами. Имена разработчиков, которые были госпитализированы по причине стресса и переработки в Adobe, стали легендой.

Рис. 7.8. Дефекты в Adobe CS4 и CS5

CS4 был выпущен в сентябре 2008 года и вызвал критические обзоры и негативные отзывы пользователей. Adobe использовал Scrum, чтобы стать более продуктивным, однако более продуктивной стала только каждая отдельная команда. Работа всех команд не была интегрирована и не стала прозрачной. Потенциальные проблемы интеграции были отложены для краткосрочной продуктивности. Качество продукта, отзывы критиков индустрии, своевременный выпуск новых возможностей, удовлетворенность клиентов, моральный дух и здоровье сотрудников в результате пострадали. Что-то надо было менять.

Стив и Питер решили в работе над CS5 использовать Scrum как можно шире, а также обучить методу всех разработчиков и программных менеджеров. Новой задачей Питера было обучать и инструктировать команды, чтобы они могли создать качественное программное обеспечение после каждого спринта. Все инкременты всех команд интегрировались и тестировались после каждого спринта. Каждый спринт естественным образом производил продукт уровня релиза CS5. Рисунок 7.8 показывает, что дефекты никогда не выходили из-под контроля в течение всего процесса. Более того, ко всеобщему удивлению, разработчики закончили работу быстрее, чем было запланировано. Неожиданные дефекты и ошибки от интеграции инкрементов больше не замедляли их прогресс. В дополнительное время перед выпуском разработчики исправили часть проблем, оставшихся от релиза CS4. CS5 был выпущен в апреле 2010-го, обзоры и отзывы пользователей были на этот раз одобрительными.

Питера попросили разработать показатели, которые могли быть использованы для управления Scrum-разработкой в Adobe. Он отметил три таких показателя. На первом месте было удовлетворение сотрудников Scrum процессом во время работы над CS5 и их вера в то, что Scrum улучшил их методы разработки программного обеспечения. Adobe предложил 200 разработчикам из 25 команд ответить на 50 вопросов[11]. Результаты были проанализированы командами, и выявлены области, в которых требовались улучшения. Впечатляет, что 80 % разработчиков отметили, что продолжат использовать Scrum даже без распоряжения руководства. Среди наиболее производительных команд так ответили 100 % разработчиков. Уровень дефектов уменьшился значительно, и практически ни один продукт не был выпущен с «отложенными» дефектами. Удовлетворение пользователей заметно возросло.

Adobe опробовал Scrum, потому что испытывал проблемы, которые только усугублялись. Благодаря настойчивости, обучению и согласованности усилий многие проблемы были решены, и релизы программного обеспечения стали занимать меньше времени, а качество улучшилось.

Происхождение греха

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

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

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

Продолжаем наш пример. Вы ожидаете, что к концу десятого месяца сможете использовать весь функционал программного обеспечения. Однако в конце концов узнаете, что накопилось 48 единиц недоделанной работы, и вас это, конечно, не радует. Что делать? Просить разработчиков закончить недоделанные задачи, чтобы увеличить процент законченного для каждой строчки бэклога продукта как можно быстрее? Но мы ошибаемся, если требуем закончить работу как можно быстрее. Обычно на это уходит еще шесть месячных спринтов (48 единиц, деленные на предполагаемую скорость восемь единиц). Оставшаяся несделанная работа отражена на рис. 7.9 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.

Рис. 7.9. Накопление технического долга по мере выполнения работы

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

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

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

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

Выводы

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

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

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

Мы работали со многими организациями, большими и маленькими, чтобы помочь им трансформироваться и получить эти преимущества. Первая публикация об этих усилиях, The Playbook for Achieving Enterprise Agility («Пособие для достижения бизнес-гибкости»), выпущена в 2005 году в результате сотрудничества Кена Швабера с корпорацией Rally. Она не была доступна широкой публике, но часто используется при развертывании Scrum. С этой публикацией можно ознакомиться в Приложении 2.

Позже, в 2007 году, Кен написал книгу об адаптации Scrum на уровень организации, The Enterprise and Scrum[12]. Он описал стратегию и тактику для этой адаптации. Тактика применения Scrum для управления самой трансформацией также объяснялась.

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

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

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

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

Компания Primavera служит примером такого типа трансформации. Primavera производит пакет программного обеспечения для управления проектами, TeamPlay, созданного для индустрии разработки программного обеспечения. Все аспекты каскадного процесса автоматизированы в этом продукте. В начале 2000-х Primavera билась изо всех сил, чтобы закончить новый релиз TeamPlay. Выпуск выбился из графика, стоил дорого, был не закончен и имел неудовлетворительное качество. В 2003 году Primavera изучала использование Scrum. Возглавляемая Бобом Шацем, исполнительным директором по разработке программного обеспечения, организация трансформировала себя. Управление продуктами, продвижением, продажами, штатный персонал, поддержка и разработка продукта – все стало гибким, приспособленным и в высшей степени конкурентоспособным. Ирония была в том, что Primavera использовала эмпирический процесс, Scrum, для создания инструмента для предиктивного процесса TeamPlay. Вся история рассказана на сайте Боба[13].

Боб покинул Primavera в 2005 году. Его главный помощник Ибрагим Абдельсафи ушел из компании почти сразу за ним. СТО и СЕО Primavera действительно никогда не нравился Scrum – точнее, их устраивали результаты, но не устраивало, что это подрывает использование их продуктов. Когда Боб и Ибрагим покинули компанию, не осталось высшего руководства, приверженного Scrum. Все использовали форму Scrum, но делали это все хуже и хуже. Прозрачность стала затуманиваться, предсказуемость пропала и так далее. Когда в 2008 году компания Oracle приобрела Primavera, она была лучше, чем до использования Scrum, но уже не превосходна. Важно отметить, что сотрудники больше не мечтали скорее прийти на работу и делать великие дела.

Наиболее успешная персона в организации – топ-менеджер, который разворачивает Scrum по всей компании. Этот человек знает, что требуется, чтобы добиться значительных организационных преобразований. Он знает, что культурная трансформация должна быть глубокой и полной, чтобы затронуть корни. Когда такой человек описывает успехи, он говорит не о том, что сделал он, а о том, что сделали другие. Джон П. Коттер, профессор Гарвардской школы бизнеса и автор книг по изменениям, сказал: «Когда я иду говорить с CEO о трансформации организации, он обычно просит меня провести встречу с ним и его персоналом. Если его персонал участвует в разговоре, я высоко оцениваю их шансы на успех. Если все переговоры ведет руководитель, у организации нет ни единого шанса».

Настоящие изменения могут быть достигнуты старомодным путем: с помощью упорного труда. Чтобы трансформация произошла как надо, вся организация должна понять новую культуру и создать ее. Даже при вынужденных обстоятельствах трансформация организации – очень сложная задача. Коттер, один из самых профессиональных агентов по внедрению изменений, посчитал, что этот тип трансформации требует от пяти до семи лет и только 30 % организаций успешно изменяются. Мы должны посмотреть на General Motors, Ford и Chrysler. Перед лицом жесткой конкуренции они не смогли поменяться за 40 лет, и только сейчас изменения начинают проявляться.

Если вы заинтересованы в таком типе изменений, мы адресуем вас к экспертам. Советуем начать с прекрасных книг Коттера, включая Leading Change[14] и Changing and Succeeding under Any Conditions[15]. Затем свяжитесь с его организацией или какой-либо другой, специализирующейся на организационных изменениях.

Carbonite была основана в 2005 году и стала публичной компанией в августе 2011 года. Продукты компании предлагают автоматическое онлайн-резервирование персональных компьютеров, везде и в любое время. Роб Рубин, вице-президент по разработке, сотрудничал с основателями Carbonite, Джеффом Флауэрсом и Дэвидом Френдом, с самого начала. Это был их шестой стартап, поэтому Роб полагался на их дальновидность и управленческие качества, а Джефф и Дэвид полагались на профессионализм Роба в управлении разработкой. Тем не менее к 2008 году основной продукт Carbonite внутри называли «болото». Для выпуска нового релиза потребовалось очень много времени.

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

Роб присутствовал на презентации Scrum в Массачусетском технологическом институте в 2006 году. Ему действительно понравилась идея, что Scrum даст ему то, что он сможет измерить. В работе по управлению измерение результатов было для него на первом месте, а действие основывалось на этом измерении. Без измерений невозможно управлять. Роб хотел, чтобы Scrum обеспечивал четкие, прозрачные измерения прогресса навстречу цели каждые 30 дней и надежное измерение прогресса следующих 30 дней каждый день. Роб также верил, что технологические проекты и продукты – трудные, потому что их природа сложна, невозможно предсказать, когда они потерпят неудачу. И неудачи в них случайны. Ежедневная и 30-дневная информация о прогрессе или неудаче может быть критической для такого типа работы.

Роб обучил свою организацию Scrum в 2008 году. С тех пор Carbonite улучшил свой цикл выпуска продуктов, распространившись по всему миру. На недавней презентации Роб и Джефф Флауэрс сообщили, что без Scrum Carbonite никогда бы не смогла стать публичной компанией. Scrum дал организации стандартный процесс для внутреннего пользования и расширения компании. Самое ценное – то, что Scrum не был навязчивым. Если компания, внедряющая его, уже имела высокий уровень мастерства и налаженные процессы, Scrum сохранял их, их оказалось легко комбинировать с моделью Scrum для обеспечения нужной измеримости и предсказуемости.

Роб и Джефф верили в своих сотрудников. Они использовали Scrum, чтобы создать окружающую среду, в которой сотрудники Carbonite могут быть креативными и работать эффективнее. Все они понимали суть проблем и работали вместе над их решением. В дополнение команды Carbonite в конце каждого спринта проводили ретроспективу. Это мероприятие было интенсивным. Все, что в работе могло быть сделано лучше и повышало производительность продукта, было открыто для дискуссий. Споры возникали жаркие, но продуктивные. Складывались крепкие рабочие команды, даже несмотря на то что количество сотрудников возросло с семи человек почти до сотни. Они создали свое будущее. В 2011 году «Бостонская деловая газета» назвала Carbonite одним из лучших рабочих мест в Бостоне[16].

При попытке трансформации организации надо иметь в виду два предостережения.

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

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

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

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

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

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

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

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

Основные направления деятельности проекта преобразования приведены в табл. 9.1 наряду со средней продолжительностью каждого вида деятельности. Некоторые виды деятельности могут частично перекрываться.

Таблица 9.1. Основные виды деятельности проекта преобразования

Около видов деятельности, которые необходимы, чтобы сделать переход постоянным, стоит «Да» в колонке «Требуется для перманентности».

Начало проекта трансформации

Первое действие закладывает основу для всего проекта – это действие описано в табл. 9.2, из которой вы узнаете, что такое Scrum и как его использовать для улучшения, чтобы стать гибким. Основные показатели производительности для измерения гибкости и оценки достигаемой ценности строятся на тех же принципах, что обсуждались для Scrum-студии в главе 6. Видение, цели, стратегии и тактика проекта разрабатываются в этом действии наряду с бюджетом и дорожной картой. Дорожная карта проекта носит предварительный характер и полностью зависит от энергии и приверженности переходной команды и способности организации меняться.

Таблица 9.2. Начало проекта трансформации

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

Определить полезность и срочность

Безотлагательная необходимость возникает из необходимости организации предоставлять конкурентоспособные услуги и продукты. Если она не сможет это делать, ее клиенты обратятся к другим компаниям. Пункт о срочности отражает необходимость решения двух важных задач. Первая – необходимость оставаться конкурентоспособным, чтобы просто не выходить из игры и обеспечить выживание бизнеса. Вторая – желание расти и процветать, увеличивать долю рынка и предлагать наиболее инновационные продукты. Люди, которые считают, что преобразование должно быть срочным, должны представить убедительные аргументы в пользу этого. Цель необходимо заявить всеми возможными способами: важными можно считать официальные презентации, а также финансовые модели. Самое важное – описание того, что произойдет, когда преобразование случится. Оно может быть анекдотичным, метафоричным или в виде макета. Но оно должна стать частью воображения сотрудников компании.

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

Причина срочности трансформации может быть простой, например:

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

Сформировать команду изменений

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

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

Сформулировать видение и стратегию

Задача команды трансформации – направлять организацию из текущей критической ситуации к желаемому состоянию. Сначала она разрабатывает видение: как будет выглядеть организация, когда трансформация будет закончена. Например, книга Our Iceberg Is Melting, о которой мы уже упоминали, описывает колонию пингвинов, живущих на тающем айсберге. К сожалению, колония считает айсберг своим любимым домом. Пингвины должны уходить, но мыслят свою жизнь только на этом айсберге. Для них создается новое видение – миграционная колония. Этот текущий айсберг – их настоящий дом, но важнее становится то, что они – колония. Они продолжат свое существование как колония и тогда, когда этот айсберг совсем растает. Они все вместе просто будут жить на другом айсберге. Это видение дает колонии точку опоры, контекст, в котором можно увидеть надвигающиеся изменения. Новая цель для них – спасти колонию, и движение становится способом это сделать. Волнение о процессе трансформации все еще присутствует, но не о будущем.

Каждое видение содержит полезность необходимости его реализации. Формулировка видения может быть следующей:

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

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

Во время подготовки трансформации команда очерчивает начальную задачи и создает бэклог. Например, задача начала обсуждения следующих этапов деятельности определяется, разбивается на пункты, проясняется и заносится в бэклог трансформации. Работа упорядочена и проверяется в течение времени. Из этого выкристаллизовываются конкретные проекты. Эти проекты – спринты, а инкремент изменения организационной структуры – результат каждого спринта. (Следующая глава, «Скрамить Scrum», объясняет, как команда трансформации использует Scrum для управления трансформацией.)

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

Связь видения и стратегии

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

Таблица 9.3. Связь видения и стратегии

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

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

Развеять сомнения и сопротивление

Люди видели книги о Scrum на столах и слышали «внутреннюю информацию». Начинают ползти слухи. Проблема слухов в том, что они анонимны, люди вкладывают в них собственное мнение и худшие страхи. Слухи могут остановить каждого на его пути, потому они должны быть развеяны при любом значительном изменении.

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

Сопротивление принимает множество форм, и самая пагубная из них – пассивное сопротивление. Люди не протестуют, они не спорят и не возражают. Они не хотят быть отождествлены как помеха, но они не хотят меняться.

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

Создать и запустить методы коммуникации

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

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

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

Распространение по всей организации

Первые проекты по разработке программного обеспечения начинаются в действии 3 (табл. 9.4). Ваша организация уже имеет некоторый опыт работы со Scrum, из пилотного проекта (глава 3), разовых проектов (глава 4) или работы Scrum-студии (глава 5). Эти проекты – часть устойчивого внедрения и использования Scrum путем разработки продуктов организаций. Также они – причина изменений во всех смежных областях.

Таблица 9.4. Распространение по всей организации

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

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

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

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

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

Достичь воздействия

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

1) проект улучшения, встраивающий новые возможности в существующую систему, которой не больше пяти лет;

2) проект по созданию новой системы, использующей новые технологии.

Таблица 9.5. Достичь воздействия

Эти проекты должны быть продолжительностью от трех до шести месяцев каждый. Один из проектов, желательно новая разработка, должен состоять из 20–30 человек, организованных в три или четыре Scrum-команды. Другой проект должен состоять из одной Scrum-команды. В связи с тем что почти любой процесс работает с легким проектом, оба проекта должны включать трудные технологии и требования, в противном случае оценки будут иметь ограниченную ценность.

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

Измерение, оценка и укрепление достижений

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

Таблица 9.6. Измерение, оценка и укрепление достижений

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

Проникновение

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

Развитие

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

Внедрение, расширение и сохранение

Закрепление преобразования означает встраивание изменений в организацию так, чтобы она приобретала новую культуру. Действие 6 обращается к этому, как показано в табл. 9.7. Любые процедуры, процессы, привычки, способы выполнения работ или привычки, которые были частью старой культуры организации, необходимо искоренить и заменить новыми способами ведения дел, которые поддерживают видение трансформации.

Таблица 9.7. Внедрение, расширение и сохранение

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

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

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

Выводы

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

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

Интернациональная компания SeaChange – мировой лидер в продуктах по передаче мультиэкранных видеоматериалов. Ее технологии представлены такими партнерами, как NBC, Comcast, Telus, PBS, SKY, Vodacom, Verizon, Cox, Time Warner Cable и другие, распространяющими высококачественные видеоматериалы. Корпорация Digital Equipment запустила SeaChange в 1993 году.

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

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

SeaChange договорилась о продаже компании Verizon следующего выпуска продукта с добавлением некоторых дополнительных функций. Договор обязывал запустить релиз в течение трех месяцев. Стив счел это невозможным, но, как и раньше в подобных случаях, ему сказали, что это нужно сделать. Он со своей командой упорно работал, даже ночью и в выходные. В течение трех месяцев им удалось поставить Verizon около 90 % релиза. Продукт был полон дефектов и проблем производительности. В течение следующих шести месяцев Стив часто посещал Verizon в Баскинг Ридж, постоянно выслушивал жалобы на низкое качество продукта и обещал, что исправит проблемы.

Неудивительно, что Verizon не выпускал на рынок новое программное обеспечение SeaChange в течение шести месяцев после поставки. Если бы Стив мог объединить три месяца разработки с дополнительными шестью месяцами после, его частые визиты в Нью-Джерси не потребовались бы.

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

Люди, применявшие Scrum, в большинстве случаев делали это, потому что в этом нуждались. Если бы их метод работал, им не нужно было бы меняться. Изменения – это всегда трудно, травматично и рискованно. Только отчаявшиеся или дальновидные люди берутся за это. Проблемы должны ощущаться сильнее, чем трудности или риски. Более того, многие руководители квалифицированы в текущем управлении, но не в управлении изменениями. К счастью, одним из умений Стива Дэйви было управление изменениями. В 2005 году он опробовал Scrum на одном продукте: новом, основанном на использовании интернета, нацеленном на рынок социальных средств коммуникаций. Scrum показал себя очень хорошо, и продукт был быстро разработан. К сожалению, ниша этого продукта оказалась неактуальной до 2009 года, поэтому его отложили. Тем не менее SeaChange получила уверенность в пользе Scrum.

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

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

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

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

SeaChange теперь использует Scrum по всему миру. Все приобретаемые компании должны его адаптировать. Приобретения могут сохранять все свои успешные практики, как это было сделано в Carbonite. Они используют Scrum, чтобы окружить эти практики для создания предсказуемости, регулярности, управления информацией и интегрировать работу каждого. Используя Scrum, SeaChange смогла идти в ногу со временем и оторваться от конкурентов. Кроме того, компания теперь способна быстро интегрировать новые компании и использовать их продукты.

В главе 3 мы обсуждали, как Iron Mountain боролась с разработчиками и как Пол Луппино успешно решил эти проблемы. Scrum распространился по всей организации разработки программного обеспечения Iron Mountain.

Пол получил повышение и теперь работает на президента компании Iron Mountain Гарольда Эббигхаузена. Он применил принципы Scrum к управлению бизнесом, и теперь шесть линий бизнеса должны отчитываться о законченных инкрементах работы каждые 30 дней вместо их одно-, трех- и шестимесячных планов. Руководящая работа, такая как создание экономических связей, изменение процессов, работа с потребителями по улучшению взаимосвязей и решению организационных вопросов, представлена в бэклоге, называемом бэклог трансформации продукта, который более подробно мы опишем в этой главе далее. Определенные пункты должны быть закончены в течение каждого спринта. Когда что-то не заканчивается, вся команда управления работает, чтобы понять причину. Насколько задача трудновыполнима? Возможно, какая-то ее часть слишком велика, не нужно ли ее разбить на более мелкие фрагменты? Требуется ли менеджеру помощь? После этого работа для следующего спринта формулируется иначе. Iron Mountain также применил принципы Scrum для общего управления. Так как обе сферы, разработка программного обеспечения и общая организация, очень сложны, Scrum был эффективен в применении в обеих сферах.

Две Scrum-команды задействованы во время трансформации организации:

1) команда трансформации, которая использует Scrum, чтобы трансформировать организацию и достигнуть видения;

2) команда развертывания, которая использует Scrum для выполнения актуальной работы по трансформации, вызывающей изменения.

Команда трансформации

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

Команда трансформации может добиться успеха, только если ее члены работают вместе и слаженно. Если индивидуальные успехи высшего руководства признаются более важными, чем командный успех, трансформация потерпит неудачу. Изменение не может произойти без взаимодействия и командной работы. Прекрасный пример такого типа командной работы – The Five Dysfunctions of Teams Патрика Ленсиони[18].

Команды развертывания трансформации

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

Команды развертывания отличаются от команды трансформации, которые управляют и направляют к изменению (рис. 10.1).

Рис. 10.1. Команда трансформации и развертывания

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

Процесс трансформации

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

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

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

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

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

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

Выводы

Scrum – процесс для управления сложной работой. Нет более сложной работы, чем изменение организации с одного способа ведения бизнеса на другой. Мы рассказали, как для этого использовать Scrum. Scrum остается неизменным, только тип работы, записанный в бэклоге, меняется, так же как и результат этой работы.

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

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

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

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

Примеры:

• общая терминология, относящаяся к процессу, должна использоваться всеми его участниками;

• общее определение «законченности» (см. статью VIII «Определение “законченности”») должно разделяться и теми, кто производит работу, и теми, кто принимает продукт этой работы.

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

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

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

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

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

По мере увеличения профессионализма Scrum-команды критерии «законченности» могут дополняться более строгими критериями для достижения лучшего качества продукта.

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

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

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

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

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

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

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

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

Обычно организации, специализирующиеся на разработке программного обеспечения, после внедрения Scrum получают следующие преимущества:

• уменьшение времени цикла разработки;

• больше ценности для конечных пользователей;

• более высокое качество;

• меньше производственных рисков;

• большая удовлетворенность пользователей;

• улучшение морального духа компании.