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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum - это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента - прим. Автора) .

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии:)

Роли в Scrum

В классическом Scrum существует 3 базовых роли:
-Product owner
-Scrum master
-Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO - максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master - помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

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

Процесс Scrum

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum - определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint"а.

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

Схематическое изображение процесса приведено на следующем рисунке:

Важные, часто забываемые особенности

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

1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.

2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения .
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменения в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.

3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла зарание планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

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

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

Список использованных источников

The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
Психология управления, учебное пособие. (А. А. Трусь)
How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Заранее благодарю за указанные ошибки и неточности!

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

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile - в переводе с английского «гибкий». Вот основные принципы Манифеста:

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

В основе таких методологий лежит итеративный подход: когда разработка ведётся циклами (итерациями). После каждого цикла определяются планы по изменению продукта на следующий.

Различные гибкие методики существовали и до выпуска Манифеста. Как следует из его названия, применялись они в разработке ПО, и долгое время никто не пробовал использовать их в других сферах. Некоторые из гибких методологий, которые использовались до 2001-го года:

• DSDM с начала 90-х,
• FDD с 97-го,
• Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

Статью заметил Джефф Сазерленд, бывший военный лётчик США, занимающийся поиском новых подходов к разработке ПО. В это же время Кен Швабер, тоже разработчик, также искал новые подходы для оптимизации своей деятельности. В 1995-м году Сазерленд и Швабер объединяются и создают документ, отражающий основы методологии Scrum. В 2001-м они участвуют в создании Манифеста Agile.

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса - «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

• Работа над проектом состоит из спринтов (итераций), длина которых две–четыре недели. В течение спринта необходимо выполнить заданный заранее объём работ. Обычно это либо новая функциональность продукта, либо готовый продукт в целом, который в ходе следующих спринтов улучшается. Нельзя менять задачи в ходе спринта, спринт можно остановить только в исключительных ситуациях.
• Численность команды: четыре–десять человек. Такое ограничение обеспечивает максимальную производительность и сводит к минимуму отвлечения от работы и разговоры. Команда должна содержать всех необходимых для создания продукта специалистов.
• Задачи спринта излагаются в Product Backlog. Product Backlog составляется из пожеланий пользователей (user stories) - то, что заказчик или потребитель желает видеть в проекте.
• Каждый спринт начинается с планирования - на нём обсуждается, какие задачи нужно будет выполнить, завершается ретроспективой - оценка эффективности команды. Каждый день проходят 15-минутные собрания - члены команды, обязательно стоя, обсуждают: что удалось сделать вчера, что нужно сделать сегодня и что может этому препятствовать.
• Отсутствие многозадачности. Единовременно команда работает только над одной задачей.
• Помимо команды разработчиков обязательно присутствуют ещё две роли. Scrum-мастер, который следит за соблюдением принципов Scrum и убирает препятствия для эффективной работы, и Product Owner. Он взаимодействует с заказчиком и передаёт его требования команде.

Доска и Диаграмма сгорания задач

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart - Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали - количество подзадач, человеко-часов или Story Points - единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график - прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

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

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk - статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

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

Где применяется Scrum

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

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

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

Scrum и крупные компании

Герман Греф активно вводит Scrum в IT-сфере «Сбербанка». Там методология используется для поддержки «Сбербанк Онлайн» с 2013-го года. По гибкой методике это же приложение и создавалось. Несколько команд занимаются разработкой других различных проектов, таких как «Советы».

Легко ли внедрять Scrum в большие компании? Гибкая методология требует полного изменения рабочего процесса, а далеко не все сотрудники будут к такому готовы. Как правило, легче всего вводить «Скрам» постепенно, набирая работников, которые заинтересованы в проекте, желают изменить привычный график. Точно не стоит сразу переводить на новый режим работы всю компанию целиком.

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

Оценка Scrum

Scrum существует уже достаточно долго и за это время приобрела много сторонников и немало противников.

Преимущества

• Быстрое удовлетворение большинства требований заказчика или клиентов.
• Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
• Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
• Готовый продукт производится в быстрые сроки.
• Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.

Недостатки

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

Дэйв Томас, один из авторов Манифеста, считает, что Agile-методологии так и не получили воплощения. Вместо этого были придуманы наборы жёстких правил (как в Scrum), а слово «Agile» превратилось в бессмысленный маркетинговый термин.

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

Обучение Scrum

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

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

Джеффа Сазерленда.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг.

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

Программы для управления проектами

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

1. JIRA. Это приложение позволяет с удобством управлять проектами разной величины. Применяет шаблоны не только Scrum, но и Kanban. Доступно на мобильных устройствах, отправляет e-mail-уведомления и обладает ещё рядом полезных функций. Для Open Source проектов JIRA бесплатна.
2. Version One. Платформа для организации деятельности при различных Agile- и DevOps-методологиях. Визуализирует рабочие процессы, планирует спринты и релизы. Присутствуют Доска, Диаграмма сгорания и другие средства визуализации. Позволяет команде или командам коммуницировать между собой. Version One была первой программой, выпущенной для гибких методик, и до сих пор остаётся одной из лучших.
3. Taskify.us. Это интерактивный вариант Доски. Довольно простое приложение, которое, тем не менее, отлично выполняет свои функции.
4. Trello. Ещё одна интерактивная Доска, но с гораздо большими возможностями. Базовый вариант программы включает обычный Desk с карточками, в которых задача может быть очень подробно расписана. При потребности можно подключить дополнительные опции: календарь, голосование, «старение» карточек.
5. SprintGround. Таск-менеджер, оптимизированный под Agile-методики. Распределяет задачи, выводит информацию об эффективности команды на графиках, позволяет получать User stories.

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

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

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

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

Планирование

В начале спринта Скрам команда проводит спринт планирование для:

• Общение по определению объема работ, которые предполагается сделать во время этого спринта;
• Выбор элементов Бэклога продукта, которые могут быть завершены в один спринт;
• Подготовка спринта, определение необходимых работ, чтобы закончить некоторые элементы Бэклога продукта;
• Определение тайм-боксов – четырех-часовых лимитов на двухнедельные спринты (пропорциональная продолжительность для остальных спринтов);
  • В течение первой половины, вся скрам-команда (а это команда-разработчиков, scrum-мастер, а также product owner- владелец продукта) выбирают работы-задачи из Бэклога, которые могут быть достигнуты в этом спринте;
  • Во второй половине команда разработчиков декомпозирует работы (задания), необходимые для предоставления этих элементов Бэклога продукта, в результате чего подтверждается спринт;
    • Некоторые элементы Бэклога продукта могут быть разделены или переориентированы если выявленные работы, не достижимы в этом спринте.

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

Ежедневный scrum в начинается в одной и той же комнате. Это централизованное расположение помогает команде начать вовремя. Каждый день во время спринта команда проводит ежедневный скрам (обычно стоя) с конкретными руководящими принципами:

• Ежедневный скрам. Все члены команды разработчиков должны готовиться. Ежедневный Скрам…
  …начинается точно по времени, даже если некоторых членов команды не хватает;
  …должен начаться каждый день в одном и том же месте и в одно и то же время;
  …ограничен (timeboxed) пятнадцатью минутами.
• Могут присутствовать посторонние, хотя обычно только команда scrum обменивается мнениями о текущей ситуации;
• Особенностью ежедневного скрам-митинга является то, что каждый участник группы отвечает на 3 локоничных и простых вопроса:
  • Мои вчерашние выполненные задачи? Каким образом я помог команде-разработчиков достигнуть цели-спринта?
  • Какие я ставлю себе задачи на сегодня, чтобы нам совместно достичь цели-спринта?
  • Наблюдаю ли я какие-либо ограничения, мешающие мне или команде разработчиков достигнуть цели-спринта?

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

Обзоры и ретроспективы

Команда проводит два мероприятия в конце спринта: обзор и ретроспектива спринта.

Действия команды во время обзора спринта:

• Обзор работ, которые были выполнены и планирование работ, которые не были завершены;
• Представлена готовые работы для заинтересованных сторон (например демо)

Руководящие принципы для обзора спринта:

• Недоделанные работы не могут быть продемонстрированы;
• Рекомендуемая продолжительность – два часа для двухнедельного спринта (пропорционально для других длительностей спринтов)

В ретроспективе спринта, команда:

• Размышляет о прошлом спринте;
• Определяет и согласовывает процесс непрерывного совершенствования действий.

Руководящие принципы для ретроспектив спринта:

• В ретроспективе спринта лишь два главных вопроса: что было хорошего во время спринта? Что можно улучшить в следующем спринте?
• Рекомендуемая продолжительность – 1-1,5 часа на двухнедельный спринт(пропорционально для других длительностей спринтов)
• Это событие закреплено за скрам мастером

Дополнительно

Следующие мероприятия обычно выполняются на практике, хотя и не рассматриваются всеми как основная часть методологии scrum:

Уточнение Бэклога

Уточнение Бэклога (некоторые называют груминг Бэклога) – это непрерывный процесс пересмотра элементов Бэклога и проверка того, что в нем правильно расставлены приоритеты и он составлен таким образом, который позволяет говорить о том, что задачи достаточно четкие и исполняемые для команды.

Элементы Бэклога:

• могут быть разбиты на несколько более мелких;
• критерии приемки могут быть уточнены;
• зависимости, последователи и подготовительные работы могут быть определены и согласованы при техническом согласовании.

Хотя данная практика не входит в основной скрам, уточнение Бэклога было принято как способ управления качеством элементов Бэклога, с рекомендуемым объемом до 10% времени спринта.

Скрам скрамов

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

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

Работа построена по аналогии с ежедневным скрам-митингом, и каждый представитель готовит свои ответы на следующие четыре вопроса:

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

Как Джефф Сазерленд прокомментировал,

С тех пор как я изначально дал определение скрам скрамов (Кен Швабер работал в IDX в то время со мной), я могу точно сказать, что скрам скрамов – это не “Мета Скрам”. Скрам скрамов, каким я его использовал, несет ответственность за предоставление рабочих версий софта от всех команд в конце спринта, или за релизы во время спринта. Ответственность за это несет Мастер скрам скрамов. Так скрам скрамов – это механизм более оперативной поставки ПО.

Что такое Scrum. Суть методики

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

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

Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

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

2. Затем нужно собрать « Команду » , в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.

3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.

4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название « Бэклог продукта » . Он может развиваться и изменяться на протяжении всего срока реализации проекта.

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

6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание , на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — « наращивать динамику производительности » .

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

8. Ежедневно проводится скрам-собрание . По выражению Джеффа Сазерленда « это пульс всего процесса Scrum » . Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: « » , « » , « » .

9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.

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

Недостатки традиционного подхода к управлению проектами

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

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, « каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „ окопные “ организационные идеи остаются популярными и по сей день » .

В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое « верило » отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.

Философия scrum

В методике Scrum нашло свое отражение увлечение автором книги японскими боевыми искусствами. По его словам, в Японии к « Scrum не относятся как к сиюминутной причуде. Японцы расценивают Scrum как подход к решению вопросов, как образ действий, как способ существования бытия — в общем, как образ жизни. Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо » .

Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда « ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства » .

Суть командной работы в Scrum

Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

непрекращающийся поиск совершенства;

• автономность — способность к самоорганизации;
• многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.

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

Кроме того автор напоминает о «законе Брукса»:

« Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше » .

Главный в команде — это скрам-мастер . Его обязанность — обеспечивать короткие собрания, их открытость, помогать группе идти сквозь помехи, которые мешают работе, вести команду по пути постоянного совершенствования « и регулярно искать ответ на вопрос « Как нам делать еще лучше то, что мы уже делаем хорошо? » .

Нет мультизадачности

Автор предостерегает от мультизадачности — на самом деле ее нет, наш мозг не может выполнять два действия одновременно, он просто переключается между задачами, а общее время выполнения каждой из них увеличивается по сравнению с тем, если бы мы выполняли их поочередно. Методика Scrum предполагает, что нужно поочередно выполнять все задачи, а не « сбалансированно вести пять проектов одновременно » .

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

Суть работы — поток

Scrum помогает попасть в « поток » — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя. Автор считает, что главное для успешной работы — достичь и управлять этим состоянием. « В своей работе вам нужно достичь главного — управления потоком, не требующего никаких усилий. В боевых искусствах или медитативных практиках мы достигаем чувства единения в движении, которое не требует усилий, — это энергия, беспрепятственно текущая сквозь нас. Когда вы смотрите на великих танцоров или певцов, то чувствуете, как они покоряются этой энергии. К достижению такого состояния мы должны стремиться в нашей работе » .

Как его достичь? За состоянием потока стоит внутренняя дисциплина,

« Не должно быть ни одного движения впустую » .

Скрам и счастье

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

В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку « Сделано » , а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.

Элементы скрам

Спринты

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

Однако есть важное замечание — « ничто не переносится в колонку „ Сделано “ до тех пор, пока эта часть проекта не будет опробована клиентом » .

« Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „ блокируются “ . Никто не имеет права их менять или вносить добавления » . Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.

Ежедневные собрания

Суть в том, чтобы они проводились стоя, каждый день, в одно и то же время, их длительность не превышала пятнадцать минут и на них участники задавали одни и те же три вопроса: « Что ты делал вчера, чтобы помочь команде завершить спринт? » , « Что ты будешь делать сегодня, чтобы помочь команде завершить спринт? » , « Какие препятствия встают на пути команды? » .

Делайте до конца

В Scrum важно научиться чувствовать ритм команды. Наихудший вариант — когда по завершении спринта что-то остается сделанным наполовину. Уж лучше вообще тогда не начинать это дело.

« Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен » .

Планирование в Scrum

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

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи « в собаках » . Эта проблема — такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, « Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой » .

Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол.

Требования — это истории

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

« Представьте, что вы составляете „ пожелание пользователя Amazon.com “ . Пробный вариант выглядит так: „ Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время “ .Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин :Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание » .

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

Как планировать спринт

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

После этого команда дружно произносит: « Вперед! » — и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

« Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише » .

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

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

Владелец продукта

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

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

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

Минимизация рисков в скраме

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

« Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»

Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.

Все слышали об Agile («аджайл»). Если ещё недавно кто-то мог не знать этого слова, то в январе этого года сам Герман Греф, руководитель Сбербанка, стал атаковать страну из всех орудий своим евангелизмом гибких подходов к управлению, и сейчас Agile прозвучал уже для всех.

Scrum («скрам») - практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

Вы, вероятно, хотели бы знать больше об Agile и Scrum, чтобы быть в теме. Мир IT уже невозможно представить без Agile, и эта «зараза» стремительно распространяется на традиционные офлайновые бизнесы.

Чтобы быть в курсе, вы можете прочитать новую книгу Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Это займёт несколько дней. Альтернативный способ быстрого чтения умных американских бизнес-книг - прочитать краткую выжимку , пересказ, саммари от нашего партнёра - компании Smart Reading. Это займёт полчаса, и вы обязательно усвоите все ключевые идеи без воды.

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

Познакомьтесь с ключевыми принципами Scrum, и, возможно, тема заинтересует вас настолько, что не прочитать книжку Сазерленда вы уже не сможете.

Люди важнее процессов

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

Scrum - это про счастливых сотрудников, а не про бесконечно стройные и дорогие процессы.

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

Продукт важнее документации

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

Scrum - это про смысл, а не про создание максимума бумажек ради создания максимума бумажек.

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

Scrum - это про понимание и сотрудничество, а не про юристов и прикрывание мягкого места.

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

Способность меняться важнее следования планам

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

Scrum - это про науку и смысл, а не про веру и необоснованные надежды.

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность - это научный подход. Надежды на правильность больших планов - это, скорее, похоже на религию.

Должности и титулы не важны - важно то, что вы делаете

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

Scrum - это про доверие, а не про силу и насилие.

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

Лайфхакер и Smart Reading предлагают попробовать этот новый способ быстро узнавать всю суть очень умных, но весьма толстых книг. На сайте Smart Reading вас ждёт ещё несколько сотен саммари великих книг, которые, возможно, вы никогда полностью не прочтёте.