Scrum без ошибок - страница 6

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

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