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

Тезисы из книги Джеффа Сазерленда "Scrum. Революционный метод управления проектами". Мой рейтинг 7/10. Отличная книга для тех, кто не знает ничего про SCRUM. Для меня оказалась простой и очевидной.

SCRUM – это методика, помогающая команде вести совместную работу. Чаще встречается в ИТ командах, но принцип и опыт использования переносится любую команду. Суть методики: создать поток создания ценности и убрать препятствия на этом пути.

В команде выделяют три роли:

• Команда
• SCRUM мастер – помогает команде достичь поставленных целей
• Владелец продукта – решает каким будет продукт

В основе SCRUM методики работа равными интервалами времени – спринт (sprint). На каждый спринт владелец продукта выбирает задачи с командой, а SCRUM мастер помогает команде закончить их. В конце спринта фиксируем результат работы и каждый член команды отвечает на три вопроса:

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

Владелец продукта решает какие задачи закроют потребности клиентов, а SCRUM мастер отвечает за команду и достижение целей.

Команда

Люди выполняют работу с разной скоростью и производительностью: одни решают задачи быстрей, а другие медленней. Разница производительности людей достигает 10 раз. А с командами дело обстоит еще круче: разница производительности команды достигает 100 раз. Сработанный коллектив работает на порядки быстрее. Поэтому важно уделать внимание построению команд.

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

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

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

Время

Работа разбивается на равные временные интервалы – спринты. Чаще выбирают длину спринта от 1 до 3 недель. По окончанию спринта важно показать готовый к работе результат. Если задача не укладывается в один спринт – ее следуют разделить на 2 подзадачи. Не берите на спринт задачи, которые точно не успеете выполнить.

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

Каждый день проводится короткая встреча со всеми членами команды. Длина встречи не больше 15 минут и проводится в одно и тоже время. Каждый член команды отвечает на три вопроса:

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

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

В конце каждого спринта каждый участник и группа оценивает себя:

• Что было хорошо?
• Что пошло не так?
• Что улучшить в следующем спринте?

Планируйте реальность

Все задачи, баги и пожелания записываются в единый список – backlog.

Детально планируйте только следующий спринт, остальные задачи только крупными мазками. Сложность выполнения задач оценивается в стори поинтах (story point): 1,2,3,5,8,13,21. Чем сложнее задача, тем менее точно будет предсказание.

Команда использует покер-планирования для оценки сложности:

• Выбираем задачу
• Каждый участник выбирает число из ряда 1,2,3,5,8,13,21
• Если расхождение меньше двух соседних чисел, то считаем среднее. Это и будет сложность задачи.
• Если расхождение больше двух соседних чисел, то человек объясняет свою оценку. После этого повторяем оценку: каждый член команды выбирает число, считаем среднее.

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

Задачи записываются в формате пользовательской истории (user story): покупатель в магазине хочет складывать книги в корзину и покупать их разом. Дальше пользовательские истории разбивается на конкретные задачи к исполнению.

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

Приоритеты

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

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

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

Потери это приступление

В работу берут только задачи, которые принесут пользу. Не беритесь за выполнение всего и сразу. Действуете поступательно: выполняйте задачи, которые дают конечный результат.

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

Если задачу выполнили на 50% – задачу не выполнили. Лучше было не брать такую задачу в работу: потратили рабочее время без результата.

Если при выполнении заметили ошибку – исправьте сразу. В будущем исправление этой же ошибки займет до 20 раз дольше.

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

Если сотрудник спасает проект и перерабатывает – это ошибка менеджмента.

Планировать задачи полезно, но слепо следовать плану – глупо. Команда постоянно адаптируется: наблюдает за своим прогрессом, находит ошибки на ранней стадии, проверяет вектор развития.