Илан Голдштейн - Scrum без ошибок

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

А теперь давайте раскроем ключевые преимущества, которые получают наши главные спонсоры проекта.

Снижение рисков

У традиционного проекта по разработке программного обеспечения риск составляет 100 %, а поставленная ценность – 0 %, и так будет, пока не настанет день успешного релиза. Длительные 18-месячные циклы выпуска продукта по водопадной модели [14]не могут дать осмысленной целостной картины или понимания ценности вплоть до самого релиза (см. рис. 1.2).

Рис. 1.2. Проекты, разрабатываемые по водопадной модели, сопряжены со 100-процентным риском вплоть до самого конца

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

Прозрачность, открытость и меньше неожиданностей

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

Непрерывное улучшение

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

Изменения – это возможности

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

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

Не очень хорошая – как бы ни было легко продать Scrum, его реализация – совсем другая история. Чтобы ваша scrum-команда ревела как готовый к старту Scrum Ferrari, а не урчала как старенький Scrum Pinto, потребуются терпение, непредвзятость, шишки, которые вы уже успели или только успеете набить. И конечно, такие полезные книги, как эта.

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

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

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

Чтобы правильно внедрить Scrum, важно следовать четким правилам и работать в рамках практик фреймворка. Только так вы окажетесь на верном пути. Кен Швабер в своем блоге пишет: «Scrum – это как шахматы. Вы либо играете по правилам, либо не играете совсем» [15]. Расширяя эту аналогию, можно сказать, что частичная реализация Scrum похожа на игру с 20 шахматными фигурами вместо стандартных 32. Есть небольшой шанс, что игра так или иначе пойдет, но это будет не стандартная и выверенная игра в шахматы, это будет другая игра с непредсказуемыми последствиями (см. рис. 1.3).

Рис. 1.3. Так же как нельзя менять правила игры в шахматы, не следует менять и правила Scrum

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

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

даже если он несколько лет потратит на обучение, все равно ему не стать scrum-мастером, ведь качества гораздо важнее подтвержденной сертификации (см. лайфхак 4).

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

Манифест agile-разработки программного обеспечения

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

• люди и их взаимодействиеважнее процессов и инструментов;

• работающее программное обеспечениеважнее исчерпывающей документации;

• сотрудничество с заказчикомважнее согласования условий контракта;

• готовность к изменениямважнее следования плану.

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

Те, кто злоупотребляет Agile-манифестом, либо (а) не прочитали последнюю строку, либо (б) забыли последнюю строку, либо (с) проигнорировали последнюю строку.

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