ФБР прозевало события 11 сентября 2001 года, потому что система обработки информации в ведомстве была не адекватна внешним вызовам. Многоярусная, иерархическая, громоздкая система просто не была способна отследить, оценить, интерпретировать ту информацию, которой располагала. Правительственная комиссия, проанализировавшая итоги катастрофы, охарактеризовала состояние информационных систем ФБР как «плачевное». Этот кейс приводит в своей книге «Scrum. Революционный метод управления проектами» Джефф Сазерленд. События 11 сентября в этой логике представляли собой кризис классического менеджмента, основанного на идее иерархии.
В конце ХХ века в таких областях, как проектный менеджмент, методология разработки программного обеспечения начала прорастать новая идея. Для ее определения используются такие термины как Scrum (схватка, давка) и Agile (живой, гибкий, маневренный, проворный). О том, что это такое, Executive.ru беседует с руководителем команды ScrumTrek, специалистом по гибким методологиям разработки Асхатом Уразбаевым.
Executive.ru: Что такое Scrum?
Асхат Уразбаев: Итеративная инкрементальная работа самоорганизующихся кросс-функциональных команд. Есть четыре пункта, которые определяют Scrum и его отличие от других подходов.
- Итеративность: значит, что мы работаем короткими итерациями, в Scrum они называются Sprints («спринты»). Мы не пытаемся создать идеальный план «до горизонта», до конца проекта: это не просто бесполезно, но и вредно, потому что в этом случае заказчик и исполнитель думают не о том, что правильного и полезного они сделали, а о том, насколько точно они двигаются по плану. В Scrum на верхнем уровне находится не подробный план, а Road map (дорожная карта), где сформулировано общее представление о том, куда мы двигаемся.
- Инкрементальность: мы стараемся на каждом этапе работы, в конце каждого спринта, сделать что-то полезное, ценное для клиента. Ну, или хотя бы провалидировать, проверить какой-то фрагмент проекта или продукта: то мы делаем, или не то.
- Кроссфункциональность: в Scrum стараются работать группами, в которых есть все нужные специалисты и избегаем «функциональных колодцев».
- Самоорганизация: в Scrum делается очень большой акцент на командной работе. Команда сама определяет правила работы.
Executive.ru: Какой из этих принципов является Know How Scrum?
А.У.: В том или ином виде они встречаются в классическом проектном менеджменте, который часто называют «водопадом». Когда я начинаю рассказывать о Scrum и задаю вопрос, бывало ли в вашей жизни, что вы действовали так, как принято в Scrum — ежедневно собирались и перепланировали свою работу, в аудитории очень часто находятся люди, которые рассказывают, что бывали сложные дни, например, во время сдачи проекта, когда надо было за короткое время выдать качественный результат, и они прибегали к подобным принципам.
Executive.ru: Почему ваши собеседники в критические периоды использовали именно эти методы?
А.У.: Потому что эти подходы позволяют эффективно организовать работу в условиях неопределенности, в меняющихся условиях. Эти методы были изобретены не сегодня. Scrum до какой-то степени стандартизировал их.
Executive.ru: В чем же новизна Scrum?
А.У.: В том, что надо следовать смыслу, а не плану. План – это способ максимально эффективно следовать меняющимся условиям. В одном из первых проектов, в котором я работал лет 15 назад, был менеджер проекта Иван. Мы подходили к нему и говорили: «Ты не можешь поговорить с заказчиком об этом и о том? Здесь есть реальные проблемы». Он отвечал, что ему некогда: у него в плане 800 задач, и ему не до наших проблем — все его время уходило на актуализацию плана.
Executive.ru: В книге «Scrum. Революционный метод управления проектами» Джефф Сазерленд пишет: «Планировать полезно, слепо следовать плану – глупо». Кто определяет слепость или не слепость?
А.У.: Люди действительно очень любят планы, и когда рассказываешь им про Agile, они почему-то думают, что Agile и Scrum – способ работы без плана. Это не так. Есть разные модели жизненного цикла проекта, например, «водопадная» и итеративная. Scrum – пример итеративной модели. В IT также используют модель, которую называют Code and fix (кодируй и исправляй). Это то, что применяется, когда прибегает заказчик и кричит: «Ребята! Бежим туда!». Все снимаются и бегут. Затем заказчик командует: «Бежим обратно!». Все бегут обратно. При таком подходе можно бесконечно бегать вокруг колышка и никогда не достигнуть цели. Это – точно не Agile. Это – противоположность Agile.
В Agile мы всегда, в каждый момент времени, представляем конечную цель, к которой мы приходим, и двигаемся к ней, как я уже говорил, короткими итерациями. В конце каждой короткой итерации, «спринта», мы оцениваем, приблизились мы к цели или нет. Общий план движения по проекту тоже есть, он называется Backlog, но он не является подробным. Слепость или не слепость определяет Product owner – его задача состоит в том, чтобы с помощью Backlog оценивать, правильно ли мы движемся к цели.
Executive.ru: Product owner находится на стороне заказчика?
А.У.: Может находиться на стороне заказчика или исполнителя, это не принципиально и определяется контекстом. Бывает, что это – представитель заказчика. Бывает, что это – кто-то внутри команды подрядчика. Иногда у проекта есть два Product owner, один из которых, представляющий заказчика, – «более главный». В каждом конкретном проекте мы оцениваем, кто лучше всего подойдет на роль Product owner. При этом подчеркну, что это – не должность, а роль.
Executive.ru: Что представляет собой Backlog?
А.У.: Представление о том, как мы движемся к цели проекта. План движения. Он состоит из того, что мы в Agile называем «пользовательскими историями». В каждой из них рассказывается о том, что мы хотим сделать для конечного пользователя, какую ценность мы хотим ему принести. Если сравнивать Backlog со стандартными документами проектного менеджмента, это ближе к плану проекта.
Executive.ru: А что находится над Backlog?
А.У.: Концепция или Vision. Обычно это короткий – от полстраницы до двух – документ, в котором сказано, куда мы движемся, сформулирована цель верхнего уровня.
Executive.ru: Что такое спринт, кем он инициируется, сколько длится, чем заканчивается?
А.У.: Допустим, заказчик просит сделать систему, которая позволит его подразделению решать какую-то задачу, например, делать расчет для получения неких вычетов. У исполнителя есть представление о том, как это надо сделать. Исполнитель хочет предложить, чтобы в конце каждого квартала подразделение заказчика могло закрывать квартальные отчеты с помощью новой системы. При этом «на берегу» исполнитель не представляет, как именно он достигнет этой цели, потому что не знает, как устроена жизнь в компании заказчика. А заказчик не представляет, что именно собирается сделать исполнитель, слабо представляя возможности системы.
При классическом «водопадном» подходе, мы сначала реализуем предпроект, или анализ. Готовим солидный документ, который называем техническим заданием (ТЗ), после утверждения которого начинаем двигаться. Задача менеджера проекта состоит в том, чтобы не отклониться от ТЗ ни влево, ни вправо.
Executive.ru: Что неправильно в этой схеме?
А.У.: То, что в ТЗ могли попасть ошибки. Например, исполнители могли не до конца разобраться в том, что нужно заказчику. Впрочем, ТЗ могло перестать быть актуальным и по «вине» заказчика: изменились бизнес-процессы, окружение компании, поменялось руководство, а вместе с ним – понимание того, зачем нужен проект. В результате получили то, что запланировали, но не то, что нужно.
Чтобы переписать ТЗ, нужны большие усилия, потому что изменения вносятся в план проекта, внутренние документы, графики и так далее, вплоть до программного кода. В Scrum действуют иначе. Здесь предпочитают двигаться короткими – обычно двухнедельными – «спринтами», в конце каждого отрезка получается простой и понятный результат, актуальный для заказчика. Если требования к проекту меняются, но не меняется конечная цель, это не влечет за собой переписывание ТЗ, мы просто учитываем эти изменения в следующих «спринтах».
Executive.ru: В Scrum используется диаграмма сгорания задач. Насколько она близка диаграммам Генри Ганта?
А.У.: Аналогом диаграммы Ганта в Scrum является Backlog. В свою очередь ближайшим аналогом диаграммы сгорания задач в проектном менеджменте является, наверное, Earned Value – «Диаграмма освоенного объема». Они близки по смыслу.
Executive.ru: Какие роли есть в команде Scrum?
А.У.: В классическом Scrum есть Product owner, который отвечает за Backlog, взаимодействует с заинтересованными лицами. Он отвечает за то, какую ценность нужно привнести заказчику. Другая важнейшая роль – Scrum-мастер. Его главная задача состоит в том, чтобы выстроить максимально эффективную, максимально крутую команду, способную решить те проблемы, которые есть у заказчика. Разница между менеджером проекта и Scrum- мастером состоит в том, что первый ориентирован на сдачу проекта. Проект закончился – его работа тоже закончена. Роль Scrum-мастера более долгосрочна, она не заканчивается в момент сдачи проекта, она рассчитана на бесконечный рост зрелости и компетенций команды.
Executive.ru: Как сохраняется эта роль, если работы выполнены и финансирование закончено?
А.У.: В Agile не рекомендуется строить команды «под проекты». Формирование и переформирование команд – это трудоемкий и дорогой процесс. Представьте, вы реализовали проект и попрощались с разработчиками. Через некоторое время появился новый проект, и вам надо создавать команду заново. Мы опять собираем другую команду, опять она проходит все стадии развития зрелости через неизбежный кризис. В Agile вместо того, чтобы переформировывать команды под проект, мы собираем стабильные команды, и стабильным командам отдаем проекты. Понимаете разницу?
Есть немалое количество вендоров, которые работают по Agile, при этом у них, как правило, стабильные команды внутри. Проекты приходят и уходят, а команда остается. Такие команды вследствие своей зрелости могут делать действительно крутые проекты.
Executive.ru: В каких ролях представлен заказчик и насколько он интегрирован в проект, который реализуется по методологии Scrum?
А.У.: Мы стараемся формировать команды так, что заказчик является составной частью команды. У нас получается команда, состоящая из двух сильно пересекающихся частей. Одну, мы обычно называем Product Delivery – поставка ценности, а вторая Discovery – она исследует, что же нужно на самом деле делать, в каком направлении двигаться. Представители заказчика могут быть и в Discovery, и в Delivery. Мы просто формируем максимально эффективную команду, члены которой классно взаимодействуют друг с другом, и неважно, кто с какой стороны вошел в команду.
Executive.ru: За счет чего в Scrum происходит экономия времени, если сравнивать Scrum с традиционным проектным менеджментом? Первый фактор, вы уже обозначали: за счет отказа от бюрократических процедур. Этот фактор не единственный?
А.У.: Не единственный. Важный фактор – кросс-функциональность. Вместо того чтобы выполнять операции последовательно (аналитик написал ТЗ, передал дальше по цепочке), мы в Agile создаем кросс-функциональную команду (аналитик, разработчики, тестировщик…), члены которой хорошо понимают друг друга, поэтому могут приступать к проекту совместно, ориентируясь на Backlog. В один момент над проектом работает вся команда (классическое ограничение на ее размер 7+2 человека). По нашим наблюдениям, благодаря такому подходу, Scrum выигрывает у классического «водопада», превосходя его по скорости в 2,5-3 раза.
Executive.ru: В каких отраслях применяется Scrum?
А.У.: Scrum возник в середине 1990-х. По крайней мере, первый доклад на конференции на эту тему был в 1996 году. В 2001 году появилось слово Agile, которое ныне расположено как зонтик над Scrum, и другими аналогичными подходами. В Россию эти подходы пришли в 2006 году, первыми их начали применять web-разработчики, которые реализовали проекты для «Яндекса», «Рамблера», «Афиши». Затем к этой методологии начали проявлять интерес компании, занимающиеся информационной безопасностью, крупные IT-компании. Сейчас к Scrum испытывают живой интерес банки – «Альфабанк», «Сбербанк», «Райффайзен банк», «Хоум кредит», – все они так или иначе переходят постепенно на использование гибких методологий.
Executive.ru: Какими программными продуктами поддерживается Scrum-процесс?
Таких продуктов очень много. Из зарубежных часто используют Atlassian Jira, пожалуй, он самый распространенный. Из российских могу порекомендовать Kaiten.io.
Executive.ru: Много ли в России сторонников Scrum?
А.У.: Конференция Agile days в марте 2016 года собрала 1200 человек. Это была уже десятая конференция. Сообщество в Facebook насчитывает около 2500 человек, оно довольно активно. Число сторонников, вероятно, больше, потому что есть люди, которые используют Scrum, но не участвуют в тусовках. Число сторонников Scrum прирастает за счет представителей классического проектного менеджмента. Начиная с четвертой версии PMBok, мы видим своего рода разворот в сторону Scrum, в том числе появилась сертификация PMI's Agile Certified Practitioner. Кстати говоря, из хороших Project managers получаются сильные Scrum-мастера. Я вообще считаю, что современный менеджер проекта должен обладать компетенциями Scrum-мастера, просто потому, что эти знания добавят ему ценности на рынке труда.
Спасибо за обзор. Есть вопросы
Интересно...
Несмотря на то. что я сам являюсь классическим "водопадным" project manager, технологию scrum хорошо знаю и периодически применяю - для некоторых типов проектов или даже этапов проектов scrum подходит лучше. Разумеется, у этой технологии есть свои минусы, о которых в статье не написано. Одним из главных минусов scrum я считаю то, что иногда очень сложно найти реального product owner, так как он должен быть один, а заказчиков/стейкхолдеров иногда десятки. Попробуй выбрать из них одного!
Но в общем и целом я согласен, что для большинства проектов scrum - более эффективная технология.
Ничего нового, кроме названий для себя не узнал и не увидел. Все давно и напрочь уже разработано и изобретено до нас. Новизна может заключаться только в различных интерпретациях сочетаемых или несочетаемых (по общепринятым правилам) управленческих решениях и/или приемов.
Уважаемый и любимый портал, E-xecutive, доброе утро.
Постараюсь конструктивно. Эмоции вначале зашкалили. Появилась очевидная русская потребность выразить чувства тем малым набором слов русской ненормативной лексики. Интеллигентность, красота портала, корпоративная этика замечательного творения лучших в бизнесе и жизни представителей не позволили.
Уже с 2004-го прошу Вас настоятельно рецензировать, отфильтровывать, очень очень тщательно подходить к публикации даже для дискуссии материалы. Материалы, которые даже гипотетически могут вызвать шквал (использую самый мягкий эпитет) неприятного ощущения "очковтирательности" (заметьте - не очковтирательства) авторов-"звёзд" о новизне подходов в бизнесе.
Сколько поразительного нам дал Восток. Имен, философии, математики, завидного умения трудиться в условиях аридного прессинга, увлечения звёздами, красотой языка и стихов, сладкого (медового) десерта...Мы многим обязаны Востоку.
Но только поживший среди представителей, в особенности современных, замечательно знает ИХ внутренний мир. Какими бы гиперобразованными они ни были. Они всегда О Д И Н А К О В Ы. Особенно на рубеже их 40 лет...
Как можно? Какое право имеет про-двинутый менеджер (по-русски - управленец) писать о новизне, инновативности, когда про все эти приёмы в проектном менеджменте четко сказано, написано, выпущено для пользования всему миру, положено на различные алгоритмы в простеньких и не очень программах и до сих пор совершенствуется, независимо от про-двинутого г-на А.У. аж с 1956 г.?Употребление НЕРУССКИХ (англоитераций) - это вообще внутреннее самоотрицание по-стулатов самого г-на А.У.
Поясняю. Метод разбиения большого проекта на малые его подпроекты (с 1956 г.) для достижения ОСНОВНОЙ цели проекта (о которой должен знать любой член проектной команды, выпускающей пусть не суперлайнеры, а хлеб насущный) - фундаментальная основа УПРАВЛЕНИЯ ПРОЕКТАМИ. "Звезда" это минимум ставит под сомнение. Метод разбиения на подпроекты должен упрощать работу команды проекта, о чем уважаемый Локхид и поведал миру в 1956-м. Г-н А.У. напротив, усложняет, использует далеко не всем понятный лексикон. Методы ЛСП и ЛСМ также, как и телескоп, изобретены ЗАДОЛГО до автора-"Звезды". Shame on you.
Да, Scrum. Хорошее современное слово и течение в управлении проектами. Да, приобрел и прочитал с полгода назад "Scrum. Революционный метод управления проектами". Но как его подать и с каким десертом?.. И дискутировать скорее буду с г-ном Джефом Сазерлендом. Нежели с г-ном А.У.
С 1996 г. международный проектный менеджмент. Преподаватель дисциплины управления проектами МАГМУ. Комм. директор в 6-ти различных видах бизнеса. Эксперт-эколог и автор проекта "Развитие Дальнего Востока" (с подпроектами во всех 9-ти субъектах ДВФО и Космодрома Восточный - имею ввиду создание Системы обращения с отходами). Соавтор проекта-обоснования негативности строительства Башни Охта-Центр. Автор проекта обращения с отходами полигона отходов "Красный Бор". Соисполнитель проекта "Защита прав интеллектуальной собственности" - консорциум из 9 -ти европейских университетов и 20-ти Российских - вот это команда экспертов, которой попробуй не обозначить конечную цель проекта!.. В Советском прошлом - зам.директора по науке НИИ "Чоллер институты" - Desert Research Institute (может так будет понятнее англоSCROMNOMU автору-"звезде".
И, знаю, я как профессионал, хотя бы на страничке любимого портала, защитил интеллектуальную собственность автора проектного менеджмента - компанию-команду Локхид.
Всего доброго, Dear E-xecutive.
Сергею Курбатову
Спасибо за неравнодушное отношение к публикациям Ехе.
Я не являюсь специалистом в Scrum: журналист задает вопросы, а не формулирует ответы. Поэтому вопросы о сущности Scrum лучше задавать эксперту. Я могу лишь заметить, что:
1. Идея Scrum не сводится к разбиению проекта на подпроекты.
2. На вопрос о новизне Scrum Асхат Уразбаев дает честный ответ.
Executive.ru: Какой из этих принципов является Know How Scrum?
А.У.: В том или ином виде они встречаются в классическом проектном менеджменте, который часто называют «водопадом».
* * *
Что касается редакционной политики Ехе. За 2004 год отвечать не могу: в столь давние времена я здесь еще не работал :) Нынешняя редакционная политика Ехе формируется под воздействием нескольких факторов. Исключение дискуссионных, провокационных материалов из практики медиа невозможно в принципе.
И что здесь нового. Всё уже дано известно, внедрено и работает. Просто названо другими словами. Претензия на новый стандарт?
Уважаемый Сергей, интересную тему Вы затронули. Есть фундаментальное знание, которое системно развивалось во времена большого модернизма и все искали институциональные источники и к ним припадали.
Но вот как то неожиданно образовались огромные гигантские по масштабам отрасли в которых деятельность строится таким образом каким не представляли во времена модернизации (например от невозможности поменять исходный программный код ^_^ ), а так как отрасль гигантская и центров роста много, людей вовлеченных миллиард, нужно учить еще миллиард а где? В этом бурном водовороте роста так или иначе должны появляться поставщики методов - рынок под эту поставку сформировался. Просто масштабом процессов.Похожие методы давно используются в промдизе так как как пишет уважаемый Автор статьи - нужно дать хоть что то полезное за этап. Но огромный гигантский Титаник IT уже отплыл навстречу событиям и его капитаны очень хотят купить очень красиво упакованные методы работы с айсбергами.
Сборщики и поставщики метода в красивой и полезной упаковке это ответ на "все растущие вызовы времени", а фундаментальные работы 30-50 летней давности академическая публика публикует под девизом "история мысли" например в японских университетах.
Когда я начал формулировать свой отклик, значение счетчика откликов было 0. Большая часть времени была потрачена на «сдерживание порыва, идущего от души», и сокращения объёма отклика. Потом, написанное чуть-отлежалось. Чтобы убедиться -- порыв сдержан.
.=================================.
Походил я по ссылкам в интернете. Всё, что там встречается о Scrum-е напоминает известное «Чем наглее и чудовищнее ложь, тем правдоподобнее она выглядит». Потому что, у каждого нормального человека есть наивная вера в то, что ложь -- маленькая и замаскированная; чтобы её можно было подсунуть незаметно. А очевидная и большая? – «Ну, не может быть!»
Лживость, так называемой, «методологии Scrum» заложена в выпячивании её «основной идеи». А именно: «Основная идея методологии Scrum – итеративный подход к планированию и выполнению проекта. В отличие от линейного (каскадного) подхода, когда проект изначально планируется «от» и «до», а результат где‑то «в конце пути». (Сие откровение изложено в предисловии к книге Джефф Сазерленд «Scrum. Революционный метод управления проектами»).
Почему, в проектном управлении, выпучивание итеративного подхода, в пику линейному, является лживым? – Потому что, там эти подходы являются двумя сторонами одной медали. Линейный подход отражает причинно-следственную связь между работами, выполнение которых приводит проект от его замысла к его результатам. А необходимость итерационного подхода – это следствие желательности-необходимости дополнять-уточнять замысел-работы-результаты.
«Симбиозу» линейного и итерационного подходов «в обед будет сто лет». Да-да; кому из проектировщиков неизвестен метод разработки проекта, называемый «методом нисходящего проектирования»? Особенно хорошо он известен в программировании. Когда разработка начинается с головной программы; а вместо подпрограмм-модулей временно размещаются их «заглушки». И, далее-итерационно (по ходу разработки), заглушки заменяются разрабатываемыми подпрограммами-модулями.
В материальных проектах, «заглушка» имеет вид не «запроса-отклика», как в программировании; а вид правдоподобного варианта того, что пока неизвестно. Например. Забуксовала разработка рабочего проекта (РП) торгового центра. Причина: отсутствует согласование требований к одному из входов-выходов ТЦ (согласование с метрополитеном). Совет (руководителю_проекта_от_заказчика): «Вместо пока неизвестного фрагмента ТЗ, поставь «заглушку» (правдоподобные требования) и «гони» разработку РП дальше. Потому что, сейчас, эта неясность в ТЗ парализует разработку РП. А стоимость задержки разработки всего РП будет заведомо больше стоимости возможной переделки этой части».
Итерации, конечно, встречаются не только при разработке РП, но и при его осуществлении. Последние, стоят (по понятным причинам) значительно дороже, переделок разработки.
Вот так. «Методология» Scrum – это не революция в проектном менеджменте. К сожалению, сия «методология» – это один из многих (ныне часто встречающихся) примеров схоластики-паразитизма на прошлых знаниях.
В скраме действительно нет ничего революционного, но тут ситуация примерно как с айфоном - грамотная обертка и маркетинг сделали методологию достаточно популярной. Я не являюсь поклонником скрама и agile в целом, тем не менее замечу, что толк от него может быть в одном из следующих случаев:
1. Защита проектной команды в забюрократизированной компании.
2. Защита проектной команды в ситуации часто и/или хаотично меняющихся требований.
3. Проектная команда новообразована, не имеет опыта совместной работы и опытного пиэма.
4. Проектная команда скучает - нужна геймификация для встряски (еще канбан хорошо для этого подходит - стикеры по доске двигать).
В зрелых (в хорошем смысле слова) компаниях с серьезными проектами и опытными пиэмами скрам не нужен. Он похож на трехколесный велосипед - позволяет ездить не падая, но не слишком быстро.