Мейнстримовый Agile пора выбрасывать на свалку истории!? Введение в Shape up

Дисклеймер: пока сам Shape up в боевых условиях не довелось попробовать, но на бумаге оно решает многие проблемы, которые меня бесят в организации процессов разработки.

Некоторое время назад я мониторил забугорный рынок труда, на предмет удвоить а то и утроить свою ЗП на тот момент. В итоге я эту затею забросил через какое-то время, зато по ходу обогатился знаниями. В частности я наткнулся на компанию Process street, в блоге которой был описана методология Shape up. Там был описан очень заманчивый крючок для меня как для разработчика, так называемый 2х недельный cooldown(кулдаун) после 6 недельного цикла. "В эти 2 недели наши разработчики занимаются на проекте всем чем захотят!" Прям так и было написано, возможно без восклицательного знака. 

Думаю многие разработчики знакомы с такой схемой планирования и выполнения внутренних работ

1. Декларируем 20-30% обязательных внутренних работ в рамках спринта

2. Планируемся с включением этого процента внутренних работ в спринт

3. Ой что-то мы не успеваем сделать всё в рамках спринта, надо бы перепланировать мы

4. Ну мы же не будем выкидывать фичи, которые мы пообещали уже?

5. Выкидывает какую-то часть внутренних работ, если не все

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

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

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

Главные отличия

1. Жёсткие ограничения по времени при гибкости размеров проекта

2. "Почти готово" по завершении цикла равняется "Не готово совсем" и по дефолту ничего не доделывается

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

4. Нет централизованного бэклога. Проекты текущего цикла были сформированы в ходе прошлого цикла и на них была сделана ставка в ходе прошлого кулдауна, то есть за 2 недели перед текущим циклом

Основные шаги и инструментарий

Шаг 1. Shaping и Writing Pitches

На каждом проекте в каждую секунду времени у каждого заинтересованного участника существует некоторое количество идей о том что, где и как можно улучшить на проекте. Те идеи, которые в итоге будут взяты в работу, должны сначала пройти путь от состояния “сырой” до состояния “готовой”. Готовность идеи можно определить по:

• четко сформулированной проблеме, которую собираются решать

• четко описано, что предлагается сделать в качестве решения

• четко описано, что НЕ ЯВЛЯЕТСЯ частью предлагаемого решения и делаться не будет

• отдельно оговорены места, из-за которых сроки могут неконтролируемо съехать и даны четкие рекомендации на предмет того как этого можно избежать

Для грамотного формирования идеи очень важны две концепции - “Scope Hammer” и “Аппетит”. 

Аппетит - это время (а значит и деньги), которым готовы рискнуть, чтобы воплотить идею в том виде, в котором она представлена. Идентичный функционал вызовет кардинально разное отношение, у тех кто платит по счетам, если будет оценен в 6 недель работы и если будет оценен в 6 месяцев. Цикл, рекомендуемый авторами методики, составляет 6 недель и максимальный аппетит тоже соответственно 6 недель. Меньше можно, больше нельзя. 

На этом месте я, пока не разобрался детально, малость завис. А как же любые фичи, которые очевидно не поместятся в 6-недельные ограничения? Я поначалу даже думал, что там в basecamp’е кодят какие-то боги, которые что угодно могут сделать за 6 недель. Но как оказалось всё несколько тривиальнее и там тоже занимаются ровно таким же поеданием слонов по частям что и везде. 

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

Scope Hammer. Вот, например, поход в магазин за продуктами. У тебя ограниченный бюджет и блюдо которое надо готовить, скажем рис с морепродуктами на 4 человек. Допустим ты набрал всё что нужно, чтобы приготовить идеальный рис с морепродуктами мечты, но есть одна проблема - бюджет превышен в полтора раза. 

Что же делать, если больше денег достать не получится? Очевидно надо задействовать Scope Hammer! Креветки взять поменьше, рис попроще, от половины приправ отказаться, возможно. В итоге получится не такой изысканный деликатес как задумывалось, но 4 человека будут сыты. Самое главное - выполнить взятые на себя обязательства. 

Возвращаясь в мир разработки ПО Scope Hammer’ом нужно работать постоянно и на всех этапах, чтобы отделять must-have фичи от nice-to-have фич

Оформленные идеи называются pitch’и и выставляются на всеобщее обозрение с двумя целями - для сбора фидбеков и конструктивной критики, чтобы успеть доработать до начала фазы ставок и чтобы те кто будут впоследствии делать ставки смогли ознакомиться

Шаг 2. Ставки

На этом шаге решается что будет делаться а что нет. Решают топы.  Что создает рабочую атмосферу очень ценного времени для каждого из участников. В basecamp это CEO, CTO продуктовый стратег (он же автор книги) и главный дизайнер.

Основные причины, по которым могут не взять проект в работу такие:

• проблема, которую решает проект недостаточно значима в их глазах

• предлагаемое в целом не нравится

• предлагаемое решение не нравится в совокупности с заявленным аппетитом

• идея сыровата или даны недостаточно убедительные ответы на возникшую критику

Шаг 3. Разработка

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

По умолчанию никто не даст времени доделать “почти готовую”© фичу и мы принимаем риск ничего не сделать за цикл, вместе с тем избавляясь от риска затратить на фичу в 3-5 раз больше времени чем мы изначально закладывали в оценке.

По концепции Fixed time - Variable Scope, если ты не доделав must-have функционал берёшься за nice-to-have и не успеваешь - проблема очевидна и ты её не повторишь. Если ты не смог отказаться от каких-то nice-to-have фич и из-за этого зафакапил сроки - то же самое. Если не успели даже только must-have фичи запилить - это факап на стадии шейпинга.

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

(Если что я не играл, но как-то раз наткнулся на стрим Майкера с Дримхака где БратОК затащил топ-1 и моя жизнь никогда не была прежней после этого)

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

Discovered Tasks

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

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

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

Пожалуйста, помогите собрать статистику

Подытоживание

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

Pros

• Меньше ритуалов и planning overhead’а 

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

• Больше свободы действий команды разработки и развязанные руки в плане конкретных деталей реализации

Cons

• Какая-то новая непроверенная хрень, где программистам не то что разрешается е***нить 2 недели каждые 2 месяца, а их напрямую обязывают это делать 

• Некоторые программисты действительно будут бездельничать если им разрешить делать всё что им захочется

P.S. Я по этой теме делал доклад в нашей небольшой и уютной компании и там возникла пара разумных моментов:

1. Людям, которые работают по принципу заказчик сказал, что можно ничего не делать, значит буду ничего не делать две недели, такое не подходит. Они определённо есть возможно даже в большом количестве, но это не 100%. Basecamp - компания продуктовая, и Shape up сделан с учётом особенностей продуктовой разработки.

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

Детальное погружение в Shaping