Рецензии на книгу «Scrum. Революционный метод управления проектами»

ISBN: 978-5-00057-722-6
Год издания: 2015
Издательство: Манн, Иванов и Фербер

Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее.
Возможно, историки будущего будут разделять прогресс человечества четкой линией: «до Scrum» и «после» — настолько эта методика революционна. Её используют в большинстве технологичных компаний мира, но теперь она доступна всем, кто имеет дело со сложными проектами в любой отрасли.
Джефф изобрел свою методику, пытаясь справиться с недостатками классического управления проектами: людям редко удается работать слаженно, эффективно и быстро, большинство планов не выполняются (ни по времени, ни по ресурсам), подразделения и команды часто выполняют противоречащие друг другу задачи или дублируют их.
За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела.
Эта книга полностью перевернет ваш подход к управлению проектами и поможет достичь результатов, которые раньше казались невозможными. Неважно, хотите ли вы изменить систему образования, изобретать новые технологии, бороться с голодом, просто открыть стартап или управлять своей командой в разы эффективнее — Scrum поможет вам успевать больше, затрачивая меньше времени и ресурсов.

Книга для всех менеджеров проектов, руководителей, ИТ-специалистов.

Показать все

Лучшая рецензия на книгу

Оценка: 4  /  4.2
Оказывается, весь мир играет в регби!

Играли ли Вы когда-нибудь в регби? Есть такой контактный вид спорта с смешным и необычным мячом в виде эллипсоида. Я тоже еще не играл ранее. Но, вот, пришел у нас на работе новый большой начальник, после чего на всех уровнях управления стали внедрять эту новую для нас систему, так называемый SCRUM - что как раз и переводится с английского языка как начальная схватка в регби перед вводом мяча в игру:

картинка russischergeist

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

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

Книга мастерски приукрашена. Автор, казалось, взял буквально весь мир в свидетели, где каждый его представитель доказывает выгодность применения тех или иных элементов Scrum. Тут вам и суперагенты ФБР, и японские мастера сюхари, и друзья, планирующие свадебное торжество, и губернатор городка одного американского штата, и работники специального фонда в африканской Уганде, и вооруженные силы США, успешно воевавшие в Афганистане (а теперь и в Сирии), и рядовая голландская общеобразовательная школа, и американские баскетболисты, проигрывающие "какой-то там Литве" (которые, вообще говоря, были уже чемпионами Европы, и в последние четыре чемпионата мира и Европы всегда участвовали в полуфинальных матчах). Абсолютно все успешно используют или использовали элементы методологии.

В итоге получился смачный рассказ о том, как Сазерленд "до такой жизни докатился", придумав Scrum. Мы можем узнать, где он почерпал идеи, получил опыт, чтобы выработать из известных приемов менеджмента свои элементы, которые и стали составными механизмами предлагаемой методики. Подходит ли она для организации управления проектом? В основном да, но не всегда. Подходит ли она к организации рабочих мест на любом предприятии? Однозначно не всегда. Например, в моей компании, где каждый работник на 40% занят в своей линии, а на 60% - в нескольких проектах, повсеместное применение Scrum нереально, для отдельных проектов, где нужны быстро реагировать на изменения - да, это интересно.

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

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

Ну, а пока посмакуйте несколько откровенных выводов Сазерленда:

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

Великие команды стремятся к цели, которая намного больше, чем устремления отдельной личности: выиграть Кубок НБА или стать лучшей ротой, чтобы удостоиться чести маршировать на похоронах генерала Макартура.

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

Поделитесь своим мнением об этой книге, напишите рецензию!

Текст вашей рецензии

Рецензии читателей

Оценка: 4  /  4.2

Очень рад что такая книга появилась на русском языке. Уверен, что она станет (если уже не стала) бестселлером. А это значит, что еще больше людей будет не только говорить про гибкие методологии и Scrum, но еще и понимать, о чем они вообще говорят.

Местами в книге много воды. Особенно в первых главах, через которые продираешься с мыслью "да когда ж ты что-нибудь по делу то писать начнешь?!". Но сама методология и ее идеология отлично разложены по полочкам. И это однозначный плюс книги. Удалось уяснить для себя несколько нюансов, которые раньше понимал не до конца.

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

Но поскольку книга рассчитана на тех, кто еще не знаком со скрамом, то эти детали можно и опустить. Они есть в другой литературе.

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

Оценка: 5  /  4.2
Основное из книги

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

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

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

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

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

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

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

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

Вините не игрока, а игру

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

Эксперимент Милгрэма

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

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

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

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

Ежедневные собрания на ходу
Скрам-мастер задает участнику три вопроса:
1. Что ты делал вчера, чтобы помочь команде завершить спринт?
2. Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
3. Какие препятствия встают на пути?
Данные вопросы помогают делиться друг с другом информацией, понимать все ли задачи будут выполнены в срок, есть ли возможность участникам группы преодолеть помехи.
Принципы проведения собраний на ходу
• Команда работает автономно – никто не распределяет задачи сверху; они все делают сами. Нет подробных отчетов руководству. Любой руководитель или член другой группы может зайти, взглянуть на скрам-доску группы, и увидеть, что к чему.
• Чем выше уровень коммуникационного шума, то есть когда все обо всем знают, тем быстрее работает группа.
• Неважно какой час вы проводите для проведения таких собраний; главное, они должны проходить каждый день в одно и тоже время. Идея заключается в том, чтобы придать группе ощущение регулярного ритма.
• Собрание не может длиться более 15 минут, если возникла тема, требующая дополнительного обсуждения, назначается отдельная встреча для обсуждения. Суть в том, чтобы успеть обменяться самой актуальной и ценной информаций за короткое время – буквально на ходу.
• Предполагается участие всех членов группы
• Лучше проводить стоя, на ходу, почти не отрываясь от дел.

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

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

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

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

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

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

Количественная сторона счастья
Оценка счастья более показательна оценки производительности, она быстрее отражает динамику и проблемы группы.
Как функционирует оценка счастья: в конце спринта каждый участник группы должен ответить на несколько вопросов.
1. Оцените свою роль в компании от 1 до 5
2. Оцените компанию в целом по такой же шкале
3. Почему вы так считаете
4. Назовите вещь, которая может сделать вас счастливее в следующем спринте
Одна вещь, которая точно не имеет отношения к счастью – по крайней мере тому типу счастья, о котором говорю я, - это удовлетворенность. Она скорее противоположна счастью – позитивной и страстной увлеченности. Для поддержания счастливой атмосферы руководитель должен поддерживать независимость сотрудников, доверяя им принятие решений в рамках их работы.

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

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

Владелец проекта
Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение «бэклога»; собирает и формирует пользовательские требования, определяя их приоритетность.
1. Владелец продукта должен обладать всей полнотой знаний о том, что входит в круг его обязанностей
2. Должен быть наделен полномочиями для принятия решений. Владелец проекта несет ответственность за результат, отбирает и формулирует для команды все требования на текущий спринт, при этом он не вправе давать задания отдельным участникам и вмешиваться в решения команды
3. Владелец команды должен быть всегда доступен для команды, поскольку в любой момент может потребоваться его объяснение.
4. Владелец продукта должен нести ответственность за полезность продукта.
На этапе каждого спринат постоянно меняя приоритеты и порядок бэклога, постепенно приближаясь к той последовательности, которая поможет получить ценность максимально быстро. Абсолютного совершенства вы, должно быть, не достигните никогда, но нужно идти к нему шаг за шагом, спринт за спринтом. Суть в том, чтобы признать неопределенность, полностью принять то, что любой порядок и ценность верны только в конкретный момент. Все опять измениться. А потом еще раз. И еще.

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

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

Оценка: 3  /  4.2
Проектное управление. Метод SCRUM

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

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

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

Оценка: 4  /  4.2

Говорю сразу: мне книга понравилась. Собственно, моим ожиданиям она полностью соответствовала, поэтому не разочаровала. Но и не превзошла, поэтому не пять звезд.
Для меня были моменты, которые я не только запомнила, но и отдельно вынесла, чтобы не забыть, а время от времени возвращаться к ним.
Приятно было видеть знакомые системы и методы, которые изучали в университете, каждый раз улыбалась от понимания того, о чем идет речь.
Не знаю, насколько методика scrum получит распространение в России, но для меня книга оказалась полезной.

Оценка: 1  /  4.2
ДАВНО ЗАБЫТОЕ СТАРОЕ

И правильно было написано в Книге Екклесиаста... Ничего нового - все ДАВНО ЗАБЫТОЕ СТАРОЕ: - Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем. Бывает нечто, о чем говорят: "смотри, вот это новое"; но это было уже в веках, бывших прежде нас.

Оценка: 5  /  4.2
Познавательная и интересная книга

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

Оценка: 4  /  4.2

Моя оценка: 7/10

Плюсы:

Интересные факты из практики основателя (по его собственному мнению) методологии SCRUM. От истории про то как «осваивают» бюджеты в ФБР на разработку софта до оптимизации работы журналистов в «горячих» точках планеты. Просто про то, что такое SCRUM (Agile) как методика управления проектом. Есть дополнительные материалы и чек листы для возможности интегрировать в свою работу.

Минусы:

Автору 65+ лет, но не смотря на это, текст пестрит хвастовством 16-летнего. Под конец уже устаешь от многочисленных примеров «знаком с тем то», благодаря мне это…» и «Если бы не я, то…». Описание методологии SCRUM заняло бы брошюру в 20 листов, но автору было важно «продать» поэтому получилось 272 страницы.

Сухой остаток: Если вы управляете проектом и не знаете, что такое Agile/ Scrum - читать обязательно.

Оценка: 4  /  4.2

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

Эта книга - введение в скрам на примере многочисленных историй. В конце каждой главы есть тезисы. А в приложении - краткий план внедрения. Хорошая книга.

Оценка: 5  /  4.2

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

1 2

У вас есть ссылка на рецензию критика?

291 день
вызова
Я прочитаюкниг Принять вызов