Обзор книги “Scrum” Джеффа Сазерленда
Измениться или умереть: биография одной методологии ведения проектов
На сегодняшний день Scrum считается одной из самых эффективных методологий управления проектами. Компании, сделавшие выбор в ее пользу, начинают работать гораздо эффективнее — как утверждает Сазерленд, отдельные команды повышают свою производительность в 8 раз.
Предисловие
Когда я начинала читать эту книгу, я ожидала, что это будет “практическое руководство по внедрению Scrum” с множеством сухой информации, правил и вариантов решения возможных проблем. Но книга не о том — это биография методологии Srum, о том, как она появилась и как она сработала в разных компаниях. Конечно, про основные принципы, роли участников проекта, ежедневные митинги будет рассказано, но гораздо важнее, прежде чем внедрять что-то у себя, понимать историю, почему в Scrum сформировались именно такие правила и принципы.
Иногда я вижу вопросы про детали внедрения Scrum, например: “а может ли владелец продукта изменить набор задач в спринте, если одна задача стала ненужной?”, “а если кого-то из участников команды нет — нужно ли проводить митинг?”. Думаю, если вы прочитаете эту книгу, то поймете, что Scrum основан прежде всего на здравом смысле. Перед тем, как слепо пытаться следовать таким правилам, как “больше никаких изменений после начала спринта”, поймите, зачем это правило существует. А потом спросите команду, чего она больше хочет — сделать запланированную задачу в спринте, которая никому не нужна, потому что вы придерживаетесь правила “ничего не менять”, или заменить задачу, но получить на выходе что-то действительно полезное? Думаю, ответ очевиден.
История Scrum
Все началось задолго до манифеста Agile. Как и многое в наше время, Agile манифест и многие из методологий гибкой разработки появились ровно тогда, когда были нужны — когда многие проекты, которые велись по водопадной модели, выходили из сроков и бюджета. Рассказ про историю Scrum начинается с далекого 1967 года, когда Джефф Сазерленд был летчиком на службе во Вьетнаме и придерживался правил “наблюдать, ориентироваться, решать, действовать”, которые и сформировали его будущий подход к работе. Подумайте сами — ведь “наблюдать, ориентироваться, решать, действовать” — это и есть Scrum. Вы наблюдаете за реакцией заказчика (сделали ли вы то, что было нужно), ориентироваться по ситуации (смотреть на список задач), решать (формировать бэклог) и действовать (делать задачи).
Также в книге есть пример из 1960 года, когда Сазерленд был кадетом последнего курса военной академии США, и его назначили инструктировать роту, которая маршировала хуже всех. Он стал приклеивать на доску стикеры с неудачами и успехами кадетов, чтобы все могли посмотреть на свои действия со стороны и исправить их. Через несколько недель рота стала лучшей.
В 1983 году Сазерленда позвали руководить проектом по созданию первых банковских терминалов, и, когда он пришел туда, он осознал, что процессы в компании настолько безнадежно испорчены, что проще создать компанию внутри компании и выстроить все заново. Именно в этом проекте начали формироваться главные термины Scrum — спринты, владелец проекта, бэклог проекта.
Первый настоящий запуск Scrum был осуществлен в 1992 году в компании Easel — именно тогда по-настоящему заработали спринты, и сначала они были еженедельными. Чтобы понять, как сделать работу команды лучше, Сазерленд с сотрудниками каждый день смотрели игры команды регбистов, которые действовали настолько слаженно, что мотивировали их постоянно улучшать и свою работу.
Сазерленда, как человека, умеющего повышать производительность компании в краткие сроки до огромных цифр — от 400 до 800%, звали в огромное количество безнадежных проектов — как в проект разработки системы сбора и анализа данных в ФБР, на которую были потрачены миллионы долларов и, по их признаниям, которая смогла бы избежать трагедии 11 сентября, если была бы сделана в то время. Первое, с чего всегда начинал Сазерленд — это со слов о том, что диаграммы Ганта, нежно любимые всеми менеджерами, не работают. Если кто-то не знает, то диаграмма Ганта — это нарисованные последовательные шаги выполнения проекта:
В начале проекта вы все распланировали — в первые три месяца вы завершите аналитику, потом — разработка, потом — тестирование и сдача проекта. На самом деле требования будут меняться в процессе разработки, аналитику придется переписывать, отдел юристов, которого вы привлечете в самом конце для утверждения каких-то норм, не сможет выделить время на ваш проект, т.к. был не в курсе происходящего, а когда вы сдадите продукт заказчику — окажется, что он совсем не это имел в виду.
Если вы смотрели сериал “Дживс и Вустер”, там есть знаменитая фраза от Дживса — мне кажется, она подходит про диаграммы Ганта:
“ Это всего лишь мое мнение, сэр, но в вашем плане слишком много непредсказуемого. Предприятие, для которого необходимо присутствие четырех человек в одном месте в одно и то же время, причем, двое из них не знают об этом, обречено на провал”
Конечно, не все компании, звавшие Сазерленда, были на самом деле готовы менять свой привычный уклад. Одна из таких компаний, BellSouth, работала как часы: они собирали требования с заказчика, работали по водопадной модели и точно в срок сдавали проект. Проблема была в том, что в момент сдачи проекта заказчик переставал хотеть тот продукт, который описывал в самом начале. Сотрудники компании не услышали рекомендации изменить подход на более клиентоориентированный, получили предупреждение “изменитесь — или умрете”, и не изменились. Кто-то из вас слышал название BellSouth?
Заключение
Мы привыкли думать, что все гибкие методологии проектов подходят только для IT-компаний. Но если посмотреть немного глубже, то они подходят для многого другого: для того, чтобы одна из худших рот в Вест-Пойнте стала лучшей, чтобы спланировать свадьбу и ремонт дома, чтобы дети в одной из голландских школ повысили успеваемость по химии, чтобы разработать свод законов одной из стран и чтобы повысить уровень качества жизни населения Уганды.
Прочитать книгу нужно каждому, кто работает в IT-компании либо просто пытается научиться лучше организовывать свои дела. Даже сли вы не внедрите у себя ничего нового, вы сможете сказать, что вы действительно понимаете, что Scrum — это не просто “митинги каждый день и ретро раз в неделю”, а в первую очередь клиентоориентированная методология, делающая все, чтобы произвести именно то, что нужно, не превысив бюджет и сроки.
А про основные термины Scrum вы можете прочитать в книге. Каждая глава историей подводит к различным выводам, например, почему митинги не должны быть длиннее 15 минут, почему не получится хорошо вести несколько проектов одновременно, и почему командный игрок лучше, чем гений-одиночка. В конце книги есть приложение “внедряем Scrum: с чего начать”, в котором есть инструкции, поэтому не буду приводить его здесь.
Канал в телеграме: t.me/analysis_paradisis
