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

• Название: Scrum без ошибок
• Автор: Илан Голдштейн
• Жанр: Управление, подбор персонала
• Год: 2020
• ISBN: 978-5-00146-306-1

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

---

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

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

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

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

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

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

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

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

ХОРОШИЕ И НЕ ОЧЕНЬ ХОРОШИЕ НОВОСТИ

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

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

Лайфхак 2. Хрупкий Agile

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

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

ЭТО ФРЕЙМВОРК, А НЕ МЕТОД

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

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

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

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

КВАЛИФИКАЦИЯ ПРОТИВ КАЧЕСТВА

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

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

ЗЛОУПОТРЕБЛЕНИЕ AGILE-МАНИФЕСТОМ

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

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

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

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

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

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

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

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

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

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

АНТИПАТТЕРНЫ SCRUM

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

Спринты тестирования

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

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

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

Бесконечные нулевые спринты

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

Эта предварительная работа, как правило, не подразумевает временных рамок и не обладает всеми типичными структурными элементами, которые есть в реальном спринте (бэклог спринта и четко сформулированные требования).

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

Рис. 1.4. Минимальный список задач для нулевого спринта