Scrum. Навчись робити вдвічі більше за менший час

Перед Сазерлендом стояла не простая задача: как из нескольких полезных идей, которые легко уместились бы в небольшой статье в блоге, раздуть целую книгу почти на 300 страниц. Автор с этим успешно справился. Свет увидел целую книгу, посвященную методу управления проектами Scrum. Но мама дорогая, сколько же там воды… Автор и про войну во Вьетнаме рассказал, и про голод в африканских странах, привел великое множество каких-то нелепых историй.

Из основных идей:

• Scrum предполагает непрерывное совершенствование процессов разработки.
• Работа короткими спринтами с планированием в начале, с демо и ретро в конце.
• Использованием доски с разделами: бэклог, взято в работу, сделано.
• Правильное составление бэклога.
• Основные роли на проекте: владелец продукта, команда, скрам мастер.
• Прозрачность процессов для всей команды.

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

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

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

Ставлю книге 5 из 5. Крайне полезное чтение для руководителей и менеджеров проектов!

Очень полезная книга, рекомендую для улучшения командной работы и работы над проектами.
Книгу хорошо дополняет книга "Открывая организации будущего". Они написаны об одном с разной стороны. Такое ощущении, что все организации будущего используют методику Scrum, но забыли об этом написать

ОСНОВНОЕ ИЗ КНИГИ

Проблемы каскадного управления компанией.
Регулярным явлением большинства компаний является детальное планирование и процессов. Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того, чтобы выбросить в мусорную корзину и сам план и свой подход к нему, руководители делают вид, что план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

Новое мышление, создание Scrum
Я смотрел как люди на самом деле работают, а не то, что они говорят об этом. Попытки загнать творческую деятельность проекта в разноцветные графики и таблицы бессмысленны и обречены на провал.
Система Scrum предусматривает формирование подлинного процесса познания, что позволяет рабочим группам не только критически оценивать, что было сделано, но и как было сделано.
В Scrum лежит простая идея. Когда бы ни был запущен проект, вам ничего не мешает регулярно проверять ход работ и последовательно выяснять:
• справляетесь ли вы с заданием;
• в нужном ли направлении движетесь;
• создаете ли именно то, что хочет получить заказчик.
Вам также ничего не мешает постоянно поднимать следующие вопросы:
• Есть ли способы усовершенствовать методы разработки и выполнить работу наиболее качественно и быстро;
• Существуют ли факторы, препятствующие вашим задачам.
Иначе говоря, в любой подходящий момент и как можно чаще следует прерывать сиюминутную работу, пересматривать то, что уже создано и выяснять, все ли сделано, что нужно и как выполнить лучше.

Спринты Scrum
Процесс разработки по методике Scrum разделен на этапы и циклы, называемые спринтами. Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем в течении следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, что удалось достичь за время совместной работы. Они смотрят сколько единиц работы, занесенных на стикеры, действительно доведены до конца. В данном случае у группы развивается чувство собственной скорости, то есть появляется необходимое знание, как быстро они могут продвигаться в своей работе.

Команда
Оценивая производительность командной работы. Если самая лучшая группа смогла справиться с работой за неделю, то сколько времени на ваш взгляд, уйдет на ту же самую задачу у самой худшей? Вы наверное предположите, что соотношение будет примерно таким же, как в различии индивидов: десять к одному (то есть, самая медленная команда работает почти три месяца, чтобы выполнить задание, которое самая быстрая сделает за неделю). Однако правильны ответ другой: для группы эта разница на много больше, чем для отдельных людей. Медлительной команде понадобиться не десять недель. Страшно выговорить, но им пришлось потратить две тысячи недель.
Один из основных принципов Scrum гласит, что члены команды самостоятельно решают как они будут выполнять свое дело. Руководитель отвечает за постановку стратегической цели, но решение, каким путем достигать этих целей, принимает команда.

Размер команды
Командная динамика хорошо функционирует только в малочисленных группах. Классический вариант – семь человек, плюс или минус еще двое. Если в группе более десяти человек скорость работы действительно падает. Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Неопровержимость того, что многочисленный коллектив выполнит меньший объем работы, представляется чуть ли не железным законом человеческой природы.
Оказывается, что число объектов, которые человек может удерживать в краткосрочной памяти, не семь – четыре.
Пытаясь понять, почему увеличение числа задействованных людей замедляет работу над проектом, ученые обнаружили два обстоятельства.
Первая причина относиться ко времени, которое необходимо вновь пришедшим сотрудникам, чтобы они могли войти в курс дела, - это, как следует ожидать, задерживает всю группу. Вторая причина не только с тем, как мы мыслим, но и на что способен на мозг в процессе мышления. Количество коммуникационных каналов существенно увеличивается с количеством людей, и наш мозг просто не в состоянии справиться с этим.
Если вам нужно выяснить как влияет размер группы, нужно взять число людей в ней, умножить его на «это число минус один» и разделить на два.
Коммуникационные каналы = n (n-1)/2

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

Вините не игрока, а игру
Обычно, столкнувшись с проблемой, группа сразу начинает искать виноватого, вместо поиска проблем в системе.

Эксперимент Милгрэма
Эксперимент проведен на часто задаваемом вопросе, связанным с Холокостом: «Как могло получиться, что многие миллионы стали добровольными сотрудниками этих страшных преступлений?». Вопрос, на который хотел найти ответ Милгрэм: «Так ли сильно отличаются рядовые американцы от рядовых немцев? Было бы их поведение другим, окажись они в подобной ситуации?». Увы, ответ оказался неутешительным: американцы не повели бы себя иначе. По сути, учитывая число стран и народов, повторивших эксперимент, никто не повел бы себя иначе. Оказавшись в соответствующих условиях, мы все способны стать нацистами.
Вот как выглядел эксперимент. Экспериментатор, одетый в белый лабораторный халат (что придавало ему вид авторитетного ученого), давал указания испытуемому, совершенно обычному человеку, применять электрошок, все большей мощности к третьему лицу – актеру, находившемуся в другой комнате. Испытуемый мог его слышать, но не мог видеть. По мере того, как сила ударов током возрастала, актер начинал кричать. Постепенно актер начинал колотить в стену и умолять прекратить эксперимент, в некоторых случаях он кричал испытуемому, что ему плохо с сердцем. Наконец он замолкал.
Некоторые испытуемые останавливались на 135 вольтах – когда актер начинал кричать – и наконец интересовались, в чем смысл эксперимента. Почти все продолжали дальше получив заверения, что с них снимается любая ответственность. Кто-то из испытуемых начинал нервно смеяться, услышав вопли из соседней комнаты. Когда испытуемый хотел остановиться, «ученый» просто говорил: «Пожалуйста, продолжайте». Если испытуемый отказывался, «ученый» настаивал: «Эксперимент требует, чтобы вы продолжали». Если и это не действовало, «ученый» добавлял: «Совершенно необходимо, чтобы вы продолжили». Большинство испытуемых сильно потели, испытывая огромное напряжение. В ответ на стресс у них возникала защитная реакция, известная как «борись или убегай», которая сопровождалась повышением пульса и температуры. И тогда, если они до сих пор не нажали кнопку, «ученый» совершал последнюю попытку: «У вас нет выбора. Вы обязаны продолжить».
Почти все продолжали и наносили последний удар током тому, кто кричал за стеной. После этого наступала тишина
Милгрэм подвел итог своих наблюдений в 1974 «Опасности повиновения»
«Обычно люди, просто выполняют свою работу, не испытывая лично никакой враждебности, могут становиться соучастниками ужасного разрушающего процесса. Более того, даже когда разрушающий эффект их деятельности становится уже очевидным, но их просят продолжать производить действия, несовместимые с основой морали, - довольно мало, кто обладает ресурсами, необходимыми, чтобы противостоять авторитету»
Если мы можем обвинить другого, мы ограждаем себя от возможности сделать то же самое. Мы убегаем от мысли, что с такой же вероятностью, как и любой другой, нажали бы на кнопку подачи тока, окажись мы в определенных условиях.

Открытость информации
По-настоящему великие команды с их принципом информационной открытости и владения общим объемом знаний несут в себе угрозу структурам с укоренившейся скрытостью и привычкой умышленно заметать следы своих дел. Руководители организаций, где свойственно все держать в тайне, не желают, чтобы кто-нибудь: рядовой сотрудник, ведущие специалисты, даже близкие к вершине иерархической лестницы, - знал, что происходит в настоящее время, что уже осуществлено и в какие сроки. Любые сведенья и знания не подлежат распространению, поскольку скрытая информация – единственный залог сохранения власти.

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

Спринты
Вся работа построена по системе спринтов.
Все задачи, которые необходимо выполнить размещены на доске поделенной на несколько колонок: «Бэклог»; «В работе»; «Сделано».
Бэклог – что нужно сделать, это список всех требований, предъявляемых к продукту и расставленных по их приоритету. Бэклог существует и развивается на протяжении всей жизни продукта, чьим ориентиром он является.
Перед каждым спринтом члены команды наклеивают в колонку «Бэклог» столько стикеров с задачами, сколько, как им кажется, они могут выполнить за неделю. В течении недели кто-то из задачи возьмется за какую-либо задачу и переклеит стикер в колонку «В работе». Когда задача будет выполнена, стикер переместят в колонку «Сделано». Каждый член команды в любой момент может видеть, над чем сейчас работают остальные.
Вы не можете сначала сделать недельный спринт, а потом трехнедельный. Нужно быть последовательным. Ваша цель - установить рабочий ритм, при котором люди будут знать, сколько работы они могут выполнить за определенное время. Нередко объемы работы потрясают их самих.
Важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка «блокируются».

Ежедневные собрания на ходу
Скрам-мастер задает участнику три вопроса:

• Что ты делал вчера, чтобы помочь команде завершить спринт?
• Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
• Какие препятствия встают на пути?

Многофункциональность – миф
Минимизируйте потери, стараясь выполнять за один раз, только задачу, требующую особой концентрации. Выделите для нее определенные временные промежутки, когда вы сможете отключить телефон и повесить табличку «Не беспокоить»

Сделано наполовину – не сделано никогда
Слишком расточительно держать валяющуюся повсюду кучу всякой недоделанной всячины, которая только занимает место, не используется для создания нового продукта и не имеет никакой ценности.

Размер задачи
Нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Люди плохо справляются с такими расчетами, но мы хорошо умеем сравнивать один размер с другим, то есть сравнивать относительную оценку.
Присваивая разным пунктам из списка числа в последовательности Фибоначи - 0,1,1,2,3,5,8,13,21,34,55 (последующее число равно сумме двух предыдущих). Данная последовательность позволяет более четко чувствовать разницу между размером задачи. Если человек оценить объект как пять, а другой как восемь, мы интуитивно чувствуем разницу. Но когда второй объект оценивается как шесть, то мы уже не в состоянии отличить, чем они отличаются друг от друга – наш мозг не справляется с такой тонкой гранью.
Применяя эти числа, можно собрать мнения о масштабах задчи в условиях, когда все пользуются приблизительно одной системой измерений – так мы быстрее достигнем согласия.

Оценка всего проекта
Дельфийский оракул
Человеку свойственно считать, что мнение других людей более верное, чем его, даже если эти суждения противоречат его собственной оценки. Для снижения данного фактора, возможно проведения анонимных опросов. Ни один из экспертов не знает, кем были остальные. Потом индивидуальные оценки квалифицированных экспертов изучаются и обрабатываются организационной группой других ученых, и уже в обезличенном виде их снова скармливают анонимной экспертной группе. Данный подход позволяет в несколько этапов сократить коридор оценок.
Покер планирования
Каждому участнику дается колода карт с числами Фибаначи – 1,3,5,8,13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождения не более чем на две карты (5,8,8,13), команда просто берет среднее арифметическое и переходить к следующей задаче. Если расхождение получается более, чем на три карты, тогда те, кто положил карту с самым большим и с самым маленьким значением, объясняют почему они так считают. Затем проводиться еще раз раунд покера планирования.
Покер планирования очень хорош : во-первых это невероятно простой метод; во-вторых, он дает возможность избавиться от любого нежелательно влияния и избегает эффекта стадности; в-третьих, позволяет команде делиться информацией по конкретной задачи. При этом важно, что оценка проводиться группой специалистов, которые действительно будут выполнять эту работу, а не некими анонимными и «идеальными» экспертами. Только тот, кто непосредственно выполняет проект, знает, сколько он требует времени и сил.

История
Прежде, чем расставлять приоритет в списке задач, определитесь с персонажем, пользователем, клиентом – тем человеком, который будет использовать то, что вы собираетесь производить. Вам нужно знать, что ему нравиться, чего он терпеть не может, о чем мечтает, что вызывает вдохновение. Но более всего нужно понять его потребительские мотивы. Как он распорядиться той вещью, которую заказал.
Чтобы считать любую историю законченной она должна соответствовать определенным критериям:
• Завершенность, выполнимость, независимость
• Открытость для общего обсуждения
• Ценность (реальная польза)
• Оценочность (удобна для оценки объема работы)
• Лаконичность (короткой)
• Тестируемость (список критериев, которым должна соответствовать конечная история)

Динамика производительности
В конце недели мы подсчитываем все завершенные нами истории и общее количество очков, на которые они были оценены. Это число покажет нам, на сколько быстро движется группа и какова динамика производительности.
Выяснив текущую динамику мы подсчитываем оставшееся количество историй, оцениваем сложность каждой, опять складываем все очки и смотрим на получившееся число. Теперь мы ясно понимаем, когда сможем завершить проект.

Количественная сторона счастья
Оценка счастья более показательна оценки производительности, она быстрее отражает динамику и проблемы группы.
Как функционирует оценка счастья: в конце спринта каждый участник группы должен ответить на несколько вопросов.

• Оцените свою роль в компании от 1 до 5
• Оцените компанию в целом по такой же шкале
• Почему вы так считаете
• Назовите вещь, которая может сделать вас счастливее в следующем спринте

Открытость
Один из моментов методологии Scrum - прозрачность всех действий и процессов.
Не должно быть никаких тайных интриг, скрытых мотивов и подковерных игр.

Расстановка приоритетов
Необходимо выяснить какие пункты списка:
• Имеют самое большое значение для хода над проектом;
• Важнее всего для заказчика и будущего потребителя
• Принесут максимальный доход
• Проще всего осуществить
В списке полно задач, до которых у вас никогда не дойдут руки, но вам требуется выбрать те, что принесут наибольшую пользу при наименьшем риске. Надо начать с того набора возможностей продукта, который медленно принесет доход; тем самым вы снизите риск, связанный с проектом.

Владелец проекта
Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение «бэклога»; собирает и формирует пользовательские требования, определяя их приоритетность.

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

Выпуск продукта
Как только люди получают ваш продукт или сервис у них происходят перемены в жизни, они сообщают вам какой будет следующая наиболее ценная вещь. Просто выполните из этого 20 процентов. И снова продемонстрируйте результат. А потом еще. И снова продемонстрируйте результат. При данном подходе, пошагового выпуска к моменту, когда вы закончите работу над половиной функций продукта, вами будет уже выпущено 200 процентов ценности за половину отведенного времени.

Внедрение Scrum. С чего начать

• Выберите владельца продукта
• Выберите команду
• Выберите скрам-мастера
• Создайте бэклог продукта
• Уточните и оцените Бэклог продукта – сколько усилий это потребует. Оценка относительных размеров
• Планирование спринта – первое собрание, определение целей спринта и что необходимо сделать за спринт; срок меньше месяца – неделя, две; определение количества баллов на выполнение первого спринта
• Работа должна быть видимой. Прозрачность всех действий и процессов – скрам-доска или диаграмма выгорания задач (количество баллов/количество дней)
• Ежедневные собрания на ходу (Что делал вчера? Что сегодня? Препятствия)
• Обзор спринта. Это встреча на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта (только полностью законченные этапы)
• Ретроспективное собрание. После презентации сделанного клиенту обсуждаются вопросы: Что прошло хорошо? Что можно было сделать лучше? Что можно сделать лучше в следующем спринте? Какие улучшения команда может внедрить в процесс немедленно?

Книга написана очень живым языком, в ней много примеров, она легко читается. Автор "проповедует" (другим словом это не назовешь) новый метод управления проектами SCRUM, суть метода (если кратко) заключается в итеративном выполнении задач небольшими проектными командами, постоянно отслеживая статус помощью стикеров на SCRUM досках и запрашивая регулярную обратную связь у заказчика.
Лично меня коробило то, что автор чрезвычайно назойливо противопоставляет данный метод классическому каскадному планирования проектов (с помощью диаграммы Ганта). С одной стороны, соглашусь с автором, чрезмерно детальное планирование проекта ОТ и ДО, со всеми нюансами - крайне не эффективно и в 99,9% случаев не реализуется фактически, но в целом определение и планирование вех проекта, распределение задач - просто необходимо. В целом могу сказать, что частично элементы данной методики интересны (например, оценка объемов работы с помощью чисел Фибоначчи, монозадачность как залог эффективности и пр.).

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

В любом случае местами было интересно узнать о проектах внедрения ИТ систем ФБР, развитии он-лайн бизнеса. Так что "тройка", но твердая.

Кто не слышал в наше время про Agile и гибкую систему работы с проектами? 

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

Автор придумал свою методику в противоположность традиционной каскадной модели управления проектами. Каскад это когда все делают последовательно и постепенно и никому не показывают результат, пока не доведут до конца: сначала соберут требования, потом проведут анализ, напишут код и дадут результат. Проблема каскадной модели состоит в том, что пока проект проходит по всем стадиям, требования могут измениться, окружающая среда может скорректироваться, заказчик сообразит что он на самом деле хотел не так, и все либо надо переделывать заново, либо допиливать как есть по сути никому не нужный продукт. Программисты постоянно упирались в это и вот один из них (Джефф Сазерленд) наконец сказал: "Хватит. Давайте попробуем иначе".

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

Особое уважение автор заслуживает тем, что скромно признается: его система это компиляция идей японских экономистов (Такеучи, Нонака), американского ученого (Деминг) и гениального СЕО Тойоты - Тайити Оно. Но будем честны, скромность здесь неуместна. Автор не просто собрал вместе чужие мысли, он их систематизировал, развил и создал новую методологию работы, без которой не мыслит себя теперь ни одна быстроразвивающаяся компания.

Основные отличительные особенности работы в SCRUM:

1. Команда

В этой методологии команда работает автономно от всей остальной организации. Это небольшая боевая единица профессионалов  - семь плюс минус два человека. Она многофункциональна и содержит всех необходимых специалистов. У них есть цель, но никто не говорит КАК они туда придут - это решает сама команда и все уважают их право самостоятельного выбора способа достижения цели. 

2. Бэклог 

Команда должна произвести некий продукт - так вот бэклог это список всего, что команда в принципе может сделать для достижения результата. Задачи бэклога должны быть расставлены по приоритетам. Владелец продукта максимум своего времени тратит на актуализацию бэклога, за отражение там всех требований и пожеланий потребителя. Для оценка задач бэклога используется последовательность Фибоначчи.

3. Спринт

Спринты используются фиксированной продолжительности, но не более месяца (лучше - 1 р/ 2 недели). Каждый раз перед началом спринта команда совместно выбирает из бэклога те задачи, которые по своей экспертной оценке, успеет сделать целиком. И, что самое важное, по итогам спринта показать какой-то результат. Хотя бы крупицу ценности, важной для заказчика. Команда должна быть в состоянии работать автономно на протяжении всего спринта и завершить то, что пообещала заказчику сделать.

4. Прозрачность

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

5. Процедуры

В Sscrum'е есть свои уникальные процедуры, на которых базируется успех методологии. Например, ежедневный стендап митинг, на котором все члены команды отвечают на три вопроса: что сделано вчера для цели, что сделаем сегодня для помощи команде в достижении цели, какие препятствия тебе мешают? 15 минут. Каждый день. И никаких ненужных формуляров и глупы совещаний.

6. Обзор спринта

По итогам спринта команда демонстрирует ту ценность, которую реализовала для заказчика. Демонстрируются только завершенные задачи, все что сделано наполовину - считается несделанным. Если найдена ошибка - она исправляется немедленно. Прийти на демонстрацию может может любой.

7. Ретроспектива спринта

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

Ну а дальше - повторение по кругу. 

Такая на первый взгляд простая система дает возможность наращивать производительность на десятки и сотни процентов. Она повышает удовлетворенность сотрудников и выводит их на новый уровень профессионализма. Улучшает сервис и продукт компании.

Но внедрить Scrum сложно. Многие процессы внутри традиционных компаний потребуют изменений. Люди будут сопротивляться, особенно ленивые и властолюбивые. Но в итоге мир вокруг нас меняется так быстро, что у вас нет особого выбора: или вы меняетесь, или вы умираете.

Рецензию собирался писать, но все никак не было повода, а тут игра. Что называется, в точку.

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

До сих пор в моей голове был только один способ организации дела (точнее, альтернатива-то была, но вот вживую или даже в примере я ее никогда не видел). Для меня управление всегда означало распределение власти, контроль и жесткую иерархию. Даже новомодные постиндустриальные принципы Toyota содержали принципы "власти - подчинения". И тут открылось... Оно!
Мало того, что альтернатива существует и работает, так еще и показала в действии всю свою эффективность - децентрализация оказалась в тренде.
Конечно, я быстренько прикупил книгу, которая еще раз сыграла на струнах моих внутренних устремлений - черно-белый шрифт на красной обложке, так еще и "Революционный" метод! Революционный. Да, то, что нужно!

Книга свое название, безусловно, оправдывает и богата на кейсы. Тут тебе и принципы организации работы в FBI, и Starbucks, и отсылка к методам Toyota. Радикально звучат воззвания современному бизнесу отказаться от ненужных бумаг, бюрократии, структуры, увещевания сделать работу подвижной, гибкой, эффективной. Вот некоторые вполне революционные призывы:

Самая главная мысль книги - работа без иерархии, управления, мотивации и планирования не просто возможна. Такая организация труда имеет преимущество перед традиционными методами построения проектов и выгодное отличие от традиционной структуры организации. В целом, Сазерленд делает бизнес человечным в полном смысле этого слова. Человек - не животное, ему мотивирующая морковка не нужна.
Возможно ли это? Стоит ответить цитатой самого, скорого на слова, Джеффа:

Надеюсь, что и российский бизнес, и некоммерческие учреждения к этому скоро придут.

К прочтению книга рекомендована всем, кто интересуется способами организации любой работы.

Из "минусов" книги:
Вся технология изложена на пяти страницах книги. Остальное - обоснование, философия, история утверждения и кейсы. Много воды. Зато вся вода - от основателя метода.

Джефф, у минулому військовий пілот літака (Good morning Vietnam!) черпав натхнення для створення своєї книги із філософії виробництва Toyota, свого військового досвіду та на основі помилок інших компаній і установ при виконанні певних проектів. Загалом методика досить цікава і, певно, має право на життя, хоч на мою скромну думку не є універсальною і не підійде під кожний проект, сферу виробнитцва і тому подібне. Деякі його постулати досить складно лягають мені у голову (наприклад мультифункціональність кожного члена команди), я деякі я підтримую на всі 113% (ні - мультизадачності або гейміфікація завдань шляхом їх оцінювання). Час від часу у книжці починали напрягати похвальні оди, які Сазерленд виспівує своєму методу (Scrum викопає вам картоплю на городі, винайде нову соц. мережу із мемами і безкоштовною музикою та погодує рибок рано вранці. І це все удвічі швидше та ефективніше). Не варто очікувати дива від цієї книги, але все-таки варто ознайомитися та підчерпнути якісь нові ідеї, тим паче якщо ви маєте справу з керуванням проектами.
"Люди не тому щасливі, що успішні, а тому успішні, що щасливі"
"Зробити половину чогось - це, по суті, не зробити нічого"
"Люди прагнуть звинувачувати певних осіб, а не систему"
"Існує обмежена кількість правильних рішень, які ви можете прийняти в той чи інший день" (судді і обід)
"Лише ті люди, які виконують роботу знають, скільки часу і зусиль вона потребує"
"Якщо не взятися за виправлення помилки у програмному коді у той же день, то через 3 тижні на це піде у 24 рази більше часу"
Ключові моменти перебігу проекту за Сазерлендом:
1) Власник продукту - людина, яка має бачення майбутнього продукту.
2) Команда - від 3 до 9 людей і ні в якому разі не більше.
3) Скрам-майстер - людина, яка буде керувати командою і всіма поточними процесами.
4) Беклог - максимально вичерпний список усього, що потрібно зробити/створити для реалізації проекту. Далі - дати відносну оцінку (у балах) зусиль на виконання кожного пункту беклогу (привіт числа Фібоначчі, планувальний покер і метод дельфійського оракула).
5) Після вищеописаних веселощів всі збираються на перше скрам-засідання і складають план першого спринту. Спринт - це проміжок часу від тижня до місяца, виділений на виконання певних завдань, вибраних із беклогу. Таким чином після кожного спринту можна оцінити у балах скільки роботи команда виконала та скільки ще залишилось.
6) Scrum-дошка зі стікерами усіх пунктів беклогу. Має три колонки: "Виконати", "Виконується" та "Виконано". Члени команди переміщуєть стікери по дошці по мірі виконання завдань. Доступ до дошки мають усі члени команди.
7) Щоденні стендапи, які обов'язково проводяться стоячи, на яких кожен відповідає на три питання: "Що ви робили вчора, щоб допомогти команді завершити спринт? Що ви робитимете сьогодні, щоб допомогти команді завершити спринт? Чи є якісь перешкоди, що заважають вам чи команді досягти мети спринту?"
8) Огляд спринту - зустріч, на якій демонструється робота, виконана за останній спринт. Прийти на неї може будь-хто: власник продукту, клієнти, керівництво, просто зацікавлені особи.
9) Ретроспектива спринту - обговорення того, що пройшло добре під час останнього спринту та що можна покращити; допущенні помилки та перешкоди, які можна усунути.