Яркая красная книга от Jeff Sutherland (rozetka) раз за разом попадалась мне на глаза в книжных магазинах и на расскладках. С обложки кричат о новизне и революционности. Интересно. Сам SCRUM, как пишут в википедии, появился в 1995 году. Книга от одно из его создателей.

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

SCRUM

После практики Пути Художника с мая 2015 использую для себя еженедельные отчеты. Знал, что методика SCRUM использует похожую идею, поэтому меня заинтересовала.

Как оказалось SCRUM в первую очередь фокусируется на командах и чтобы им помочь быть счастливыми и превосходными.

Ценно в SCRUMе – наблюдение. Именно с помощью наблюдения за своими действиями и происходящем команда становится все лучше и лучше и в итоге достигает такого состояния, когда все процессы как бы текут сами по себе, а люди работают так «словно на них снизошла благодать» (состояние 離 Ри из 守破離).

Agile

Методология SCRUM часто упоминается вместе с Agile software development принципами, которые больше свод философских правил и приоритетов.  Быстро загуглил. Манифест вышел в феврале 2001 и постулирует такие приоритеты:

1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Приоритет на lightweight development methods – легковесных методах разработки. Маленьких командах, прямому контакту с заказчиком и циклическом производстве рабочей версии продукта. Освобождении от бюрократии и описательности.

Очень четко все это пишут мои любиме разработчики ZenKit (en).

SCRUM как итерации

Писать длинные долгосрочные жесткие планы разработки в современном динамическом мире — гиблое дело. Диаграммы Ганта на весь проект не работают. Мы не знаем будущего, а особенно эмоций и желаний заказчика. Замысловатые отчеты бесполезны.

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

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

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

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

На каждой итерации — работающий продукт

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

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

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

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

Работа в неправильном направлении — пустая работа, которая тратит ресурсы всех. Опять же, в книги есть истории, когда люди месяцы своей жизни тратили в пустую.

Никто не обязан тратить свою жизнь на бессмысленную работу.

На каждом спринте мы занимаемся не только приращением ценности продукта, а и приращением самой работы — эффективности труда.

Регулярность спринта

Обычно цикл: неделя или две. Цикл называется спринтом, что в переводе: «бег на короткую дистанцию».

! все спринты имеют одинаковую длительность. Ощущение регулярного ритма.

Итерация — действия повторяются многократно. Только после нескольких итераций можно будет сказать насколько эффективно работает команда. Цель – затратить минимум времени на создание ценного для заказчика.

Решить до конца задачу за короткий срок, потом остановится и посмотреть что вышло. Сделанное за спринт наполовину — не сделанное вообще.

Заказчику нужен результат. Работающий. Его не волнует сколько вы на это времени потратили.

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

ПОБЕЖДАЕТ ТОТ, КТО БЫСТРЕЕ проходит циклы качественной разработки.

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

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

Что вам мешает в вашей работе?

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

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

Что делать?

Участники команд самостоятельно решают, как они будут выполнять свое дело. «А что лично ты сделал, чтобы помочь команде завершить текущий спринт?» Вчера, сегодня.

SCRUM – прозрачная идеология: все в команде знают дела друг друга, уровни зарплат, доходов, расходов по проекту.

Роли

Часто вводятся отдельные роли скрам-мастера (фасилитатор КАК) и владельца продукта (фасилитатор ЧТО).

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

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

На больших проектах работает бригада владельцев продукта.

! собственно, самое важно: иметь представление о том, откуда будет поступать прибыль, сколько ее будет и когда.

Придумывание

Желательно (владельцу продукта) без промедления набросать концепцию и от нее переходить к детальному ее описанию – разбивки на малые составляющие, а так же описанию хода работ. В начале набросать задач на пару спринтов вперед. И в момент начала движения еще их дописывать.

Это огромный документ (бэклог), в котором содержится всё, что в принципе могло бы быть включено в концепцию проекта и важно для заказчика и для потребителей. В нем будет полно задач, которые не подойдут и до которых у вас никогда не дойдут руки. В итоге вы запустите только 20%. Смысл — отобрать те, который принесут наибольшую пользу при наименьшем риске.

Что проще всего осуществить? Что принесет максимальный доход?

«Сложность не в том, чтобы решить чего ты хочешь достичь — намного труднее понять, что ты можешь выполнить».

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

С каждым следующим спринтом продолжать наращивать ценность.

Приоритеты задач

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

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

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

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

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

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

В SCRUM никто не распределяет задачи сверху. Решает команда. Владелец продукта не может просто отдать распоряжение команде что кому делать – он должен пояснить и доказать свою точку зрения.

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

Когда для клиента создается достаточная ценность – все прекращают работать.

Инструменты

Что сейчас принесет проекту наибольшую ценность?

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

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

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

Принцип прозрачности работы предполагает, что скрам-доска это открытая структура — любой (и из другой команды) может зайти и посмотреть чем тут люди заняты и что к чему. Команда в каждый момент знает что было уже сделано и что еще нужно сделать – может самоорганизововаться.

Любой человек может посмотреть на каком этапе сейчас находится реализация спринта.

Персоны

Много о персонах в книге Алана Купера «Психушка в руках пациентов», о ней я еще напишу.

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

Почему этот персонаж хочет эту вещь? Почему она ему нужна? Для чего?

Как инструмент, продукт будет ему служить. Что его будет радовать в момент использования. Что ему нравится, а что его раздражает (и другие эмоции). Где он им будет пользоваться. Что он использовал до этого, чтобы решить эту свою задачу?

Будучи (таким-то), (Имя) хочет (желания и потребности), так что (поведение).

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

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

Проблемные места

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

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

Ошибка означает расхождение с реальностью. Команда должна быть готова посмотреть в лицо реальности. Если люди работают долго сами по себе, они могут (и скорее всего) потерять связь с рынком и реальными потребителями.

Командное счастье

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

Единица анализа SCRUM — команда. Команды движут миром. Хорошая командная динамика в малых группах, это 7+-2 человека. Внутри команды — тесные дружеские отношения без интриг, скрытых мотивов и психологических игр. Работник должен не только хорошо работать в команде, а еще и быть счастливым в этот момент.

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

Задавать вопрос коллективу: «Что сделает вас счастливее?». И всем вместе выполнить это на следующем спринте.

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

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

Назовите вещь, которая может сделать вас счастливее в следующем спринте?

Индекс счастья должен соотносится с метрикой производительности иначе что-то не так. (!) Падения уровня счастья происходи на несколько недель раньше падения динамики производительности. Анализируя только производительность без метрики счастья вы не узнаете о будущем снижении темпа настолько заранее.

Отдых

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

Никаких ночных переработок, заданий по выходным. На отдыхе — отдыхать.

Героические усилия — признак ошибки при планировании объема работ.

Работая меньше часов в состоянии собранности легче принимать правильные решения и успевать делать больше результативного качественного.

Команды работают автономно

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

А вместе они, даже самая маленькая команда, делают все от начала и до конца без четкого разделения труда /избавились_от_всех_должностей. Вот это команды мечты – магическая согласованность действий (как смотреть футбол на стадионе).

У каждого со временем вырисовывается динамика и специализация решения задач.

Мониторим и поддерживаем атмосферу сотрудничества (как улучшить?), взаимного уважения и обмена обогащающими идеями без осуждения. СКРАМ стремится создать блестящую команду – абсолютно согласованную и подхватывающую друг друга.

Командная поддержка

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

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

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

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

В итоге команда должна решить как лучше с этим справится. Спринт завалит не человек, а завалит команда.

Зачем работать

Взаимодействие с средой определяет поведение

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

Не ищете дурных людей, ищите вредные системы. Которые вознаграждают плохое поведение. Люди – создания системы.

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

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

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

Все будет лучше

Люди, работающие по методологии  SCRUM, это люди смотрящие в более прекрасное будущее. Они работают чтобы увеличивать удовольствие в мире своими действиями. Делать проекты, которые доставляют удовольствие прямо сейчас и при этом подготавливающие еще более приятное будущее — удовольствие будет вечным.

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

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

Процветающих определяет общая черта – наполненность жизнью и воодушевлением. Они не просто счастливы, они используют свое счастье, чтобы получать результаты.

Учится

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

Люди хотят развиваться и открывать для себя новые горизонты.

Вывод

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