Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах — о том, как организовать слаженную командную работу.
Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.
Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…
Что такое Scrum. Суть методики
«Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят».
Те, кто занимается управлением проектами, да и просто управлением, хорошо знают, насколько сложно организовать слаженную командную работу. Из-за отсутствия слаженности постоянно нарушаются планы, происходит отставание от графика, бюджет проекта раздувается, деньги и время утекают сквозь пальцы, задачи разных подразделений дублируются, люди спорят и не помогают друг другу, хотя, казалось бы, их усилия направлены на достижение одной цели. Кроме того, заказчики часто бывают неудовлетворены окончательным вариантом созданного продукта.
Методика Scrum, которую разработали Джефф Сазерленд и Кен Швабер, призвана решить все эти проблемы. Scrum — это противоположность классическому поэтапному подходу, применяемому к реализации проектов. Методику Scrum взяли на вооружение многие компании как из технологических отраслей, откуда она сама родом, так и из традиционных и даже некоммерческих. Подход, лежащий в основе методики Scrum, можно применять в разных видах деятельности, в которых требуется коллективная работа.
Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.
Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:
- Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
- Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
- Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
- Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
- Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
- Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
- Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
- Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
- По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
- После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Недостатки традиционного подхода к управлению проектами
Как отмечает автор книги Джефф Сазерленд, у традиционного подхода к реализации проектов в виде каскадной модели, предполагающей поэтапное продвижение к цели, имеется масса недостатков. Весь процесс идет очень медленно, часто возникают непредсказуемые трудности и, более того, нередко бывает, что исполнитель создает продукт, который абсолютно не удовлетворяет заказчика.
Каскадная модель предполагает использование диаграмм Ганта — графиков, на которых обозначаются этапы работы и время на их выполнение. Ход проекта детально размечается и отражается каждый шаг работы. Предполагается, что каждая фаза проекта последовательно переходит в другую, — это и есть принцип каскада.
Изображение с сайта www.quickiwiki.com
«С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы — и делать их по-настоящему комплексными — они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны — без исключения».
Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».
В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое «верило» отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.
«Сегодня, как и в те годы, отчеты продолжают быть важнее действительности — а ведь они, судя по всему, призваны ее описывать, — но если вдруг всплывут несоответствия, то виновным назначают реальность, а не диаграмму».
Планы рассыпаются в прах. Альтернатива — это Scrum
В планах есть необходимость, но по убеждению Джеффа Сазерленда, следовать им крайне глупо, потому что при столкновении с реальностью все красивые таблицы и графики рассыпаются в прах. Поэтому так важно привнести в работу возможность изменений, открытий и реализации новых идей, что и происходит в Scrum. Применяя эту методику, можно на самом раннем этапе устранить ошибки, так как в Scrum работа ведется короткими циклами — спринтами, а также поддерживать постоянную связь с заказчиком, что исключает создание ненужного ему продукта.
Автор отмечает, что создавая свою методологию, он, прежде всего, смотрел на то, как работают успешные команды, а не слушал то, что они говорят.
Слово scrum («схватка») автор позаимствовал из игры в регби. Оно «обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. „Схватка“ представляет собой идеальную модель полного взаимодействия игроков». И это именно то, что требуется для успешной командной работы.
Изображение с сайта brendanmarsh.com
В отличие от традиционного подхода, предполагающего подконтрольность и предсказуемость, составление планов, таблиц и диаграмм, которые никогда не работают, методика Scrum дает возможность в четко обозначенные и непродолжительные циклы (спринты) добиваться поставленных целей.
«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот — недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости».
Когда все участники поделятся своими результатами работы, команда начинает разбирать все, что было сделано за спринт, но делая упор не на обсуждение продукта, а на то, каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-за чего мы продвигаемся не так быстро, как хотим?» — вот вопросы, которые они ставят перед собой».
Такой подход позволяет всем участникам эффективно взаимодействовать как с заказчиком, так и друг с другом, понимать правильность своего направления, соответствие последующей работы поставленным задачам, учитывать выявленные в спринте ошибки.
Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться «сверхэффективности», поднимая свою производительность на триста или четыреста процентов.
Философия scrum
В методике Scrum нашло свое отражение увлечение автором книги японскими боевыми искусствами. По его словам, в Японии к «Scrum не относятся как к сиюминутной причуде. Японцы расценивают Scrum как подход к решению вопросов, как образ действий, как способ существования бытия — в общем, как образ жизни. Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо».
Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда «ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства».
Суть командной работы в Scrum
Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:
- непрекращающийся поиск совершенства;
- автономность — способность к самоорганизации;
- многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.
На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа — группу «Альфа» (команда «А»). Каждая такая «команда „А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий „обычных“ армейских сил, заключается в том, что „зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому — ведь именно в таких „швах“ таится слабое место, из-за которого возникают ошибки».
Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.
Кроме того автор напоминает о «законе Брукса»:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше».
Главный в команде — это скрам-мастер. Его обязанность — обеспечивать короткие собрания, их открытость, помогать группе идти сквозь помехи, которые мешают работе, вести команду по пути постоянного совершенствования «и регулярно искать ответ на вопрос «Как нам делать еще лучше то, что мы уже делаем хорошо?».
Нет мультизадачности
Автор предостерегает от мультизадачности — на самом деле ее нет, наш мозг не может выполнять два действия одновременно, он просто переключается между задачами, а общее время выполнения каждой из них увеличивается по сравнению с тем, если бы мы выполняли их поочередно. Методика Scrum предполагает, что нужно поочередно выполнять все задачи, а не «сбалансированно вести пять проектов одновременно».
«Действуя традиционным методом, то есть пытаясь делать все и сразу, группа завершит свои три проекта до конца июля. Если группа подойдет к делу, вооружась гибкой стратегией, например, Scrum, и будет работать поочередно над каждым проектом, минимизируя затраты времени и сил на переключение контекста, она сможет закончить все к началу мая».
Никаких переработок
Уставшие сотрудники становятся более рассеянными и хуже выполняют свою работу. Недостаток энергии ведет к тому, что люди принимают больше импульсивных и неверных решений, и снижается их эффективность.
«Этот феномен окрестили „истощение эго“. Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения — вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль — наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия».
Вывод: в нерабочее время отдыхайте, полностью отдалитесь от работы, заряжайтесь приятными впечатлениями.
«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобы что-то сделать? Единственное, что имеет значение, — как быстро и качественно это было сделано».
Суть работы — поток
Scrum помогает попасть в «поток» — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя. Автор считает, что главное для успешной работы — достичь и управлять этим состоянием. «В своей работе вам нужно достичь главного — управления потоком, не требующего никаких усилий. В боевых искусствах или медитативных практиках мы достигаем чувства единения в движении, которое не требует усилий, — это энергия, беспрепятственно текущая сквозь нас. Когда вы смотрите на великих танцоров или певцов, то чувствуете, как они покоряются этой энергии. К достижению такого состояния мы должны стремиться в нашей работе».
Как его достичь? За состоянием потока стоит внутренняя дисциплина.
«Не должно быть ни одного движения впустую».
Скрам и счастье
Люди хотят быть счастливыми. Но Джефф Сазерленд уверен, что счастье — это не бездеятельное прозябание, а яркая, насыщенная и активная жизнь. Скрам вносит свой вклад в счастливую жизнь, так как помогает плодотворно работать и действовать.
В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку «Сделано», а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.
«Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее».
Элементы скрам
Спринты
Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: «Бэклог»; «В работе»; «Сделано». Перед каждым спринтом члены команды наклеивают в колонку «Бэклог» стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела «Бэклог» в колонку «В работе». После выполнения задачи — в колонку «Сделано». Таким образом, каждый видит, над чем сейчас работают другие участники.
Изображение с сайта nyaski.ru
Однако есть важное замечание — «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».
«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления».
Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.
Ежедневные собрания
Суть в том, чтобы они проводились стоя, каждый день, в одно и то же время, их длительность не превышала пятнадцать минут и на них участники задавали одни и те же три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
Делайте до конца
В Scrum важно научиться чувствовать ритм команды. Наихудший вариант — когда по завершении спринта что-то остается сделанным наполовину. Уж лучше вообще тогда не начинать это дело.
«Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен».
Планирование в Scrum
Как происходит процесс планирования в Scrum? Для начала нужно составить список всех вещей, которые влияют на вашу цель. После этого расставить их по приоритетности. В случае если вы не будете укладываться во временные и финансовые рамки, тогда вы легче сможете исключить последние пункты списка.
Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема — такса или ретривер? А может быть, дог?
Но в любом случае удобнее установить числовые значения. Например, «Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой».
Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».
Требования — это истории
Для того чтобы успешно и понятно для всех сформулировать список требований к продукту и составить бэклог, в Scrum применяется неординарный подход. Вместо простого списка заданий составляются пользовательские истории — короткие сюжеты, в которых содержатся пожелания пользователей конечному продукту.
«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.
Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:
- Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.
- Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.
- Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.
Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание».
Пользовательская история должна быть завершенной, независимой от разных обстоятельств, реализуемой на практике. Эти критерии говорят о готовности истории. Также важно, чтобы историю можно было оценить на предмет ее выполнимости.
Как планировать спринт
В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется — «планирование спринта».
«Все собираются вместе, просматривают список пользовательских историй, которые уже стоят в очереди на выполнение; выясняют, какое количество задач может взять на себя каждый участник группы; тщательно взвешивают, смогут ли они за этот спринт довести до полной готовности отобранные задания; смогут ли продемонстрировать заказчику сделанные единицы работ и показать ему готовые функции продукта; смогут ли сами себе в конце спринта сказать, что они со всем справились».
После этого команда дружно произносит: «Вперед!» — и принимается за работу
Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.
Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.
«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише».
Открытость во всем
Скрам предполагает прозрачность всех действий и процессов.
Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.
«Секретность — яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды».
Расстановка приоритетов
Эту диаграмму нужно иметь в виду каждому предпринимателю. Суть работы заключается в поиске золотой середины — сбалансированной концепции между тремя крайностями:
- Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
- Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
- Ваше главное стремление — большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.
Бэклог
Как уже отмечалось, бэклог в скраме — это список требований и функций продукта, упорядоченный по степени важности задач. Он может содержать и сотни заданий или несколько.
«Смысл составления бэклога представляет создание максимально полного перечисления требований, предъявляемых к функциям продукта. На самом деле никто и не собирается выполнять подряд каждый пункт, но такой документ, содержащий все, что в принципе могло бы быть включено в концепцию проекта, всегда должен находиться под рукой. Некоторые требования отбираются в первую очередь».
Как правильно расставить приоритеты?
«Для этого нужно выяснить, какие пункты списка:
- имеют самое большое значение для хода работ над проектом;
- важнее всего для заказчика или будущего потребителя;
- принесут максимальный доход;
- проще всего осуществить».
Джефф Сазерленд отмечает, что важно помнить в списке всегда есть задачи, которыми вы никогда не сможете заняться. Вам необходимо выбрать те, которые приносят максимальную пользу при минимальном риске.
Владелец продукта
В скраме предполагается три роли: скрам-команда — исполнители конкретных проектов; скрам-мастер — это тот, кто следит за ходом проекта и помогает команде решать проблемы, и владелец продукта — тот, кто решает вопросы концепции продукта и составляет бэклог.
«Скрам-мастер и команда отвечают за то, каков будет темп их труда и как быстро они закончат проект. Владелец продукта ответствен за то, чтобы результативная командная работа превратилась в результат, приносящий прибыль». Владельцу продукта необходимо отлично знать рынок и у него должны быть полномочия для принятия решений.
Это может быть слишком большой зоной ответственности для одного человека, поэтому на больших проектах может работать бригада владельцев продукта.
Минимизация рисков в скраме
Так как в скраме предусмотрена пошаговая сдача проекта, то это способствует минимизации рисков. Это помогает быстрее показывать клиенту продукт и получать от него обратную связь.
«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»
Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.
Как внедрить Scrum прямо сейчас
Джефф Сазерленд советует начать со сбора команды и составления бэклога. Нужно составить концепцию своего продукта и начать дробить его на задания. Не обязательно все требования сразу вносить в бэклог — можно выделить на это неделю. «Пока члены вашей команды проводят ежедневные собрания на ходу и первые спринты, вы сможете за это время составить довольно объемный бэклог, чтобы было чем занять команду на несколько спринтов вперед. Не забывайте почаще в него заглядывать, потому что команда начнет ускорять темп и будет выполнять больший объем работ, чем вы планировали в самом начале».
После этого составьте предполагаемый план действий: задайте вопросы: что вы можете осуществить на ближайшие несколько месяцев? Что хотите добиться к концу года? «Важно помнить, что это всего лишь стоп-кадр, так что не стоит слишком увлекаться планированием, просто набросайте варианты. Вы не составляете договор, обязательный к исполнению, а просто записываете собственные мысли, чего вам удастся достичь через какое-то время. Поверьте, картина изменится. Возможно, даже радикальным образом».
Рекомендуем к прочтению:
Мы пишем саммари — ключевые идеи из лучших книг жанра нон-фикшн.
Подписывайтесь на наш блог и следите за выходом новых полезных статей и идей для саморазвития!
Комментарии (26)
BloodJohn
15.12.2015 17:03+1Посоветуйте пожалуйста историй из РЕАЛЬНОЙ жизни в РОССИИ с факапами, людьми и историями.
Чтобы без смузи и фотографий из фотобанков.
makeright
15.12.2015 18:18Без смузи и с факапами рекомендую почитать блог scrum-студии Сибирикс)
Наверное, один из самых известных по данному направлению.
astenix
15.12.2015 18:15+1Книга ок.
Но лучше продумать недостатки scrum-подхода к управлению проектами.makeright
15.12.2015 18:19А в чем Вы видите недостатки данного подхода?
Мы в команде их пока не заметили. И было бы интересно узнать Ваше мнение.
vkalenov
15.12.2015 18:54+2C ходу: Низкая эффективность при наличии четко определенных требований. Легко «поломать», если участники (хотя бы один) не разделяют важности периодических мероприятий или 100% выполнения спринта. Заказчики очень долго привыкают к такому подходу — первая итерация всегда крайне болезненна. Заказчик, если требования меняются динамичнее, будет против фиксации состава sprint backlog. «Мы не используем наркоз, так как у нас Scrum-хирургия. Мы будем постоянно получать от вас обратную связь, особенно в первую итерацию».
astenix
15.12.2015 19:18+5Если рассматривать Скрам как механизм, то он очень требователен к предварительной настройке и к условиям эксплуатации. Почти так же, как древние автомобили по-сравнению с современными.
Поверьте сперва, что я фанат аджайла, и очень его люблю и ценю.
Также поверьте в то, что я готов высосать глаза через нос любому недомерку, который начнет говорить, что «если у вас скрам не работает, значит, вы неправильно его применяете». Пожалуйста, не говорите так никому и никогда, уважайте труд уборщицы.
К делу: у нас большая компания, делаем веб-магазины на основе нескольких платформ (это уже не первая компания подобного типа, в которой я работаю). Можем сравнить это со станцией тех-обслуживания, где собирают новые машины из деталек. Вроде бы все по-шаблону, но в каждом проекте или «что-то новое», или «что-то уникальное», бо веб-магазин сам по себе не имеет смысла, его надо интегрировать в уже работающую инфраструктуру клиента, отсюда постоянная нужда в программистах, тестировщиках да дизайнерах…
Скрам на проектах в кмопании применяется в разных пропорциях и видах. Где-то он был насильно внедрен «так хочет клиент», где-то до него доросли, где-то просто «решили попробовать».
Итак, какие обнаружились сложности и недостатки у скрама в глобальном плане:
Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
Это кто? Владелец продукта — глава совета директоров компании Adidas подходит на эту роль? Мы для адидаса магазины делали, например. Кто их владелец?
В учениях про аджайл в контексте product owner указывают на человека, к которому все члены команды имеют прямой доступ. И хорошо, мол, если он сидит прямо рядом с командой.
А ему там нужно сидеть, бо он нужен всем и в качестве источника принятия решений, и как замена всему тому, что мы называем «исчерпывающая документация» — требования, тесты, вот это вот всё.
Мы получаем на вход рассказы о том, как и что должно работать, затем сами решаем, как это будет реализовано (я тестировщик, поэтому в этот момент у меня генерируется плевательный яд, бо без ТЗ результат действительно ХЗ, тесты не на чем обосновывать), и постоянно нуждаемся в советах и корректировке относительно того, что и как МОЖЕТ и ДОЛЖНО быть реализовано.
Рассмотрите классическое "Я могу скормить банкомату мою карту и проверить количество денег на счету" — а как именно это делать? Приплясывать перед видеокамерой? Читать Упанишады в микрофон? Нажимать на клавиши на дисплее, или на клавиши на клавиатуре (ВНЕЗАПНО, клавиши в банкоматах и по краям дисплея, но и на передней панели, и они друг друга не дублируют). Можно всё. Что мы выберем? Кто это выберет? Кто возьмет на себя ответственность о принятии последнего решения? Вся команда, бо все должны быть самостоятельны в принятии решений? Нужен если не аналитик, то менеджер, который…
Внезапно, скрам-команде нужен менеджер…
И аналитик, чтобы требования продумывал. И еще аналитик, который будет продуманные требования записывать.
Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
А еще они должны быть кроссфункциональны. Заболеет программист — не беда, я возьмусь за клавиатуру. Не надо? Но… мы же… кроссфункц…
Ладно, что кроссфункциональны… Члены команды должны быть самостоятельны в принятии решений. Но в нашей культуре? В нашем менталитете «стоять за всех, своих не сдавать, начальникам не жаловаться»???
На западе действительно бывает сложно собрать единую команду из одиночек. Это доблесть для менеджера. Когда с детства каждый сам за себя, выживает сильнейший/хитрейший (пресловутое предложение «сообщайте нам о всех непорядках, которые заметите у ваших коллег, а им об этом сообщать не надо»), тогда действительно сложно собрать команду. Про это пишут книги, там это действительно сложная задача.
У нас менталитет с детства иной, у нас «команда против менеджера», ее собирать незачем, ей нужно уметь управлять. Нужно учиться ее не бояться, например. Нужно понимать, что решения командира все рассматривают как паттерны поведения, которые можно/нужно предусмотреть, использовать для своих нужд, да и просто взломать, если понадобится.
Неоднократно наблюдал, как западные (у нас других нет) заказчики не понимали, почему «команда не работает», «почему они все знают зарплаты друг друга», «почему они всегда замалчивают проблемы» — не уверен, что это нужно объяснять всем западным заказчикам, но понимать всё это им было бы полезно. Мы же учимся взаимодействовать с ними в разрезе культурных разниц.
Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
Ну да, нам нужен политрук. Или парторг. С сертификатом парторга.
Ибо у нас групповой менталитет-с. Вот в западном менталитете без скрам-мастера действительно сложно.
Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
Чота ржу, извините.
Бэклог — это те же «требования». Кто их продумывает и заранее записывает? Вы умеете работать с требованиями? Вам знаком эффект «чем больше и детальнее продумываешь требования, тем сильнее их количество стремится к бесконечности», а ведь это только требования, мы еще про их тестирование не подумали — знакомо?
Вам еще не нужен выделенный аналитик?
Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
Это да, это надо делать. Но личностно, а не коллективно (менталитет).
После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Ретроспектива — прекраснейший инструмент. Нужнейший. Она не только скраму присуща. В некоторых журналистских коллективах ретроспектива каждого номера не только рулит, но и по-настоящему полезна всем. В армии после боя полезно всем выжившим собраться и вслух порассуждать о том, почему они выжили. Что полезного сделали? Что делать и в будущем?
У нас ретроспективы поначалу проводятся очень активно и воодушевленно, но чем дальше, тем их меньше.
Пример (из неоднократно наблюдаемого):
— Значит, во вторних рухнула база, и мы не успели… А почему? А это у нас Дениска ковырялся, и потёр конфиги. Иди,
сукаДениска, сюда. Иди и всем пообещай, что больше ты так делать не будешь…
— (утирая слезы) Товарищи! Да я! Я обязуюсь! Отныне и впредь! Всегда!
— Иди, товарищ. Мы верим в то, что ты искренне раскаялся перед коллективом...
Знакомо?
Ибо менталитет-с. Не та почва, на которой скрам произрастал.
Планы рассыпаются в прах. Альтернатива — это Scrum
Эй, когда мы в спринт берем какие-то задачи — это тоже планирование! И эти планы тоже в прах обертаются.
Напоминаю, что я фанат аджайла, и очень его люблю и ценю.
Также напоминаю про высасывание глаз через нос.makeright
16.12.2015 14:57С удовольствием прочитал Ваш комментарий и личные впечатления о Scrum.
Спасибо большое!
hippoage
17.12.2015 06:36+1Немного типичных заблуждений о скраме:
1) Кроссфункциональность — это на уровне всей команды, а не каждого человека. Тестировщик не должен программировать вместо заболевшего программиста.
2) Скрам мастер должен быть выделенным человеком. Лучше всего «девочка» с гуманитарным образованием. Она отвечает за скрам-процессы и климат в коллективе. При это не принимает решений по сути. Идея в том, что не нужно делать из хорошего программиста плохого менеджера или скрам-мастера, а лучше его оставить программистом и взять отдельного человека в отдельную иерархию.
3) Владелец продукта готовит беклог и отвечает на миллиард вопросов ежедневно. Часто у него бывает своя команда. Там аналитики, дизайнеры и прочие маркетологи. Вопрос в том, что скрам не делался для заказной разработки проектов, а делался для длительной разработки продуктов. При заказной разработке владельца продукта и его команду нужно придумывать как отдельную структуру внутри фирмы-подрядчика.
4) Размер беклога не проблема. Проблема его отсортировать в порядке важности/очередности. Это даже хорошо, что заказчик видит, что еще есть что улучшать. Может, дозакажет сейчас или потом.
5) В самом скраме как именно оценивать не говорится. Предполагается, что как-то в чем-то каждый лично оценивает. Причем скрытно от других членов команды. Потом люди, давшие мин и макс оценки обсуждают почему у них такое расхождение. Это просто разная скорость или учтены разные вещи?
6) Разбор проблем на ретроспективе должен идти не поверхностно (покайся Дениска), а на несколько уровней вглубь (как сделать так, чтобы проблема в принципе не могла повториться; например, автодеплой на сервера).
7) Если планы рассыпаются в прах, то либо сработало слишком много рисков и на них заложили меньше времени, либо изначальные оценки были неверными (не разбиты задачи или оценки выполнения задач для senior, а делали junior). Обе проблемы скрам не решает. Скрам решает проблему с тем, чтобы делали именно то, что нужно заказчику, а не что-то другое.
В общем, обычно пытаются запустить скрам без скрам-мастера (выделенного человека без права принятия решений) и владельца продукта (выделенного человека, который постоянно принимает решения по требованиям к продукту), поэтому получается что-то странное.
d3sp
16.12.2015 12:32+1«Scrum. Революционный метод управления проектами»
Скорее всего, это подходит к проектам малого уровня.
Я пилотирую промышленные проекты серьезного уровня (10+М€), к ним скрам/ажиль итд просто неприменимы. Нужно четкое планирование, диаграммы Ганта, комитеты пилотажа, итд итп. Внешних каналов больше сотни (клиент, его прожект менеджеры, поставщики, субподрядчики, внутренние отделы продаж, закупок, логистики и так далее). Как этим можно управлять скрам командой в 7 человек? Никак.
«Scrum. Революционный метод управления проектами разработки программного обеспечения малых и средних масштабов» — может так стоило автору назвать книгу?
lexnekr
16.12.2015 13:01+2В книге без особых подробностей автор рассказывает, что якобы применял скрам в том числе для многомиллиардных проектов на несколько лет длинной (в том числе для ФБР).
Если же обратиться к другой, более практичной литературе, вроде упомянутого мною «scrum и xp заметки с передовой», то для больших проектов рекомендуется использовать скрам скрамов (т.е. когда команды объединяются в нечто вроде нейросети).
На самом деле, я тоже несколько скептически смотрю на всё это дело…
Не знаю, тут надо смотреть реальные кейсы в подробностях, окунаться в такое производство. А то может у них там не скрам, а звездец и хаос просто.d3sp
16.12.2015 13:08Скрам срамов… ради чего? Ради скрама, разве что…
Проецируя на мой опыт в промышленности (производство высокоточных станков для ВПК), я не могу представить применение скрама. Есть определенные требования контракта по ведению проекта, в том числе и майлстоуны, на которые завязаны транши оплаты. Не могу себе представить, как это можно делать с вайтбоардом со стикерами без диаграмм Гантта. А если бы и мог, то как убедить клиента из ВПК, что этот метод будет лучше, чем проверенный годами. Это не только подвергнет риску контракт, но и уронит лицо компании на и так уже нишевом рынке.
Поэтому я и думаю, что громкое название книги применимо только к производству ПО/веб проектам малого уровня.lexnekr
16.12.2015 13:46Я думаю, вы согласитесь, что есть много вещей, которые мы не можем себе даже представить (и тем более не можем представить себе их применение) пока не окунёмся в реальный пример.
Я вот тоже пока учился в ВУЗе не мог до конца понять КПУ, дозиметрию, курс элементарных частиц, кванты и т.п.
Не сказать чтобы понимание всех этих вещей пришло ко мне после полутора лет на реальном предприятии. Но понимание некоторых других (так же первоначально загадочных и абсолютно казалось бы глупых) появилось.
Опыт удивительная штука и творит чудеса.
Сейчас я работаю с крупным заказчиком в невероятно странных условиях. Для меня тоже принципиальны сроки, майлстоуны и т.п.
Но я вот для себя решил раздвинуть горизонт изученного. Прочитал на данный момент 5 разных книг о гибких методологиях (в основном Scrum), прошёл пару курсов на Coursera, пообщался с людьми… И не то чтобы я смог перевести свой процесс на рельсы скрама — это действительно невозможно (пока по крайней мере так кажется), но ряд разумных мыслей я уловил. И несколько процессов, которые мы перевели на аналоги таковых из гиких методологий (Беклог, короткие итерации и т.п.) видны.
В общем, я против того чтобы подобно автору преподносить скрам, как серебряную пулю и кремлёвскую таблетку. Но присмотреться к нему и взять для себя небольшой набор полезных практик считаю правильным. Это никак не противоречит стандартам PMBOCK.
makeright
16.12.2015 15:08Думаю, что Scrum можно применять везде. Все зависит от желания и возможностей.
Сам автор в книге приводит примеры реализации методики в школах, политике, сельском хозяйстве, строительстве.
Т.е. таких сферах, в которых представить работу по scrum, в принципе, очень сложно.vkalenov
16.12.2015 16:38+1Можно, как и водопад, v-модель и т.д., только зачем? Каждая методика разрабатывалась для решения конкретных проблем управления проектами, если такие проблемы в проекте есть, методика помогает, если нет, то работает принцип «Лучше как-то управлять, чем не управлять».
BloodJohn
17.12.2015 10:51> Думаю, что Scrum можно применять везде.
Когда у тебя в руках молоток, все задачи кажутся гвоздями. (с) Маслоу
vkalenov
16.12.2015 16:33Если требования гарантированно не меняются и достаточно детальны для выполнения работ, то «гибкие методики» не нужны. Если заказчику не нужно проверять гипотезу, то SCRUM не поможет, а будет мешать. Обычно берут лучшее, например, строгое проектное управление по созданию новой модели самолета, при котором на ранних этапах «создание проекта самого большого самолета» :) (с фиксированными сроками и бюджетом) кроссфункциональные команды работают по скраму. Как только майлстоун достигнут скрам «выключают» и продолжают идти «по ганту».
А ведь есть очень крупные и длительные проекты в которых все требования могут существенно меняться ежемесячно, и это никак нельзя предусмотреть. Там и живут скрамы скрамов.
makeright
16.12.2015 15:04Я тоже хотел отметить пример автора про ФБР.
У госструктуры был некий глобальный заказной проект на несколько миллиардов долларов.
Компания, взявшая проект, при анализе проекта использовала как раз те самые диаграммы Ганта, графики, отчеты и т.п.
Было распланировано все до мелочей: сроки, нагрузка, ресурсы.
Но по ходу реализации проекта начали возникать незапланированные заминки.
По итогам таких заминок проект задерживал срок сдачи на несколько лет.
И только внедрение скрам в команду разработчиков проекта помогло завершить проект с минимальными затратами.
Но я скорее соглашусь с Вами. Нет панацеи и единственно эффективной методики.
Все зависит от конкретного случая. Команды. Мотивации.lexnekr
16.12.2015 16:33Честно говоря пример с ФБР больше тянет на байку. Там очень много слишком сказочного автор описывает.
Даже при том, что я верю в эффективность scrum в отдельных проектах, в данном случае смахивает на враньё.
По крайней мере статья на ВИКИ больше похожа на рекламу — en.wikipedia.org/wiki/Sentinel_(FBI)makeright
16.12.2015 18:21Возможно в данном случае не обошлось и без художественного приукрашивания )
hippoage
17.12.2015 06:47Скрам для продуктов, а не проектов. Если непонятно что на самом деле нужно сделать (требования постоянно меняются, приоритеты задач постоянно меняются, так что непонятно что будет делаться через 2 недели, при этом фиксируются обязательства на итерацию) — скрам идеален. Он тяжело масштабируется, но масштабируется (например, что-то в районе 60 скрам-команд у аэрбэнби, 600 разработчиков за год съедают больше 10М чего угодно).
d3sp
17.12.2015 13:18Когда изначально закладывается Скрам культура в процессе создания стартапа, то и масштабирование возможно.
Меня побудило написать свой первый комментарий именно то, что методология Скрам представлялась как панацея для всех проектов.
По поводу «продуктов, а не проектов». Создание продукта — это и есть проект. Создание сервиса — это тоже проект. Продажа и производство линии станков — это тоже проект. Только они очень разные, начиная с контекста, заканчивая требованиями заказчиков. Для сложных проектов, в которых поэтапная оплата завязана на майлстоуны, гибкость скрама просто неприменима. Невозможно планировать ни финансовые, ни производственные потоки, ориентируясь на доску с бэклогом.
Да, в процессе продвижения проекта всегда случаются задержки. Для этого нужно внедрять с самого начала риск менеджмент, закладывая маржу (производственных ресурсов, оборотных средств итд).
Я видел проекты, в которых изначально при подписании контракта закладывался график оплаты пени (штрафов) за просрочку поставки оборудования. То есть контракт подписывался, и уже было ясно, что производственные мощности не справляются. В результате, новый СЕО отдал на субподряд 95% производства, оставив на внутреннем производстве только узкоспецифичное know-how.
Как бы с этим справился Скрам, я не вижу.hippoage
20.12.2015 14:41Продукт — не проект. Раньше выделяли 2 типа активностей: процессы (постоянная деятельность, например бухгалтерия или работа точки МакДональдса) и проекты (уникальная деятельность, например, открытие точки МакДональдса). Сейчас появилось мнение, что развитие продукта — это ни то, ни другое (постоянная деятельность стратегически, уникальная деятельность тактически). Ближе к проектам, но не то. В продукте важна перспектива и определение направления развития, а не сдача изначального ТЗ в срок/бюджет/качество. Скрам — организационный фреймворк, который показывает как ПМа в продукте можно разделить на Product Owner и Scrum Master, кто за что отвечает при взаимодействии со stakeholders и командой, как вполне эффективно организовать процессы.
Поставка оборудования — это не продукт, тут Скрам не помошник. Более того, Скрам про разработку ПО, а не общую организацию деятельности. А вот если бы выводили новую линейку оборудования на рынок, то можно было бы как-то попытаться приспособить Скрам к этому, но, опять же, скорее к прошивке для оборудования, чем к самому оборудованию (из-за сложности изменения физического производства).
lexnekr
Не хотел бы преуменьшать ваших заслуг в области пересказа содержания книги, но недавно уже была рецензия на эту же книгу — megamozg.ru/post/21106
P.S. кстати, прочитал и не могу рекомендовать. Уж лучше «scrum и xp заметки с передовой» — воды и лирики меньше, конкретики и пользы больше.
makeright
Вы дали ссылку на рецензию, т.е. на субъективное мнение читателя о книге.
В нашем посте мы опубликовали все ключевые идеи данной книги. Объективно. Без какой-либо привязки нашего мнения о ней.
По-поводу воды в книге совершенно с Вами согласен. Очень много отвлеченных примеров и рассказов из жизни. Во время чтения книги я все задавал себе вопрос: «Когда же автор все-таки начнет писать про scrum ?» )
В этом и недостаток нон-фикшн книг.