Дисклеймер: пока сам Shape up в боевых условиях не довелось попробовать, но на бумаге оно решает многие проблемы, которые меня бесят в организации процессов разработки. Некоторое время назад я мониторил забугорный рынок труда, на предмет удвоить а то и утроить свою ЗП на тот момент. В итоге я эту затею забросил через какое-то время, зато по ходу обогатился знаниями. В частности я наткнулся на компанию Process street, в блоге которой был описана методология Shape up. Там был описан очень заманчивый крючок для меня как для разработчика, так называемый 2х недельный cooldown(кулдаун) после 6 недельного цикла. "В эти 2 недели наши разработчики занимаются на проекте всем чем захотят!" Прям так и было написано, возможно без восклицательного знака.  Думаю многие разработчики знакомы с такой схемой планирования и выполнения внутренних работ Декларируем 20-30% обязательных внутренних работ в рамках спринта Планируемся с включением этого процента внутренних работ в спринт Ой что-то мы не успеваем сделать всё в рамках спринта, надо бы перепланировать мы Ну мы же не будем выкидывать фичи, которые мы пообещали уже? Выкидывает какую-то часть внутренних работ, если не все Притворяемся золотой рыбкой, и повторяем на следующий спринт И это ещё не самый худший вариант. Вполне может оказаться что разработка будет сродни работе на пекарне - заказчик ждёт свежие фичи с пылу с жару каждый релиз и чтобы ни следа вчерашних багов не осталось. Ну и заказчик обязательно запомнит тот раз, когда звёзды сойдутся и команда покажет фантастическую производительность, чтобы потом раз за разом подтверждать свой предрассудок о том что вы там все - ленивые жопы и не стараетесь.  Поэтому две недели каждые два месяца, когда мне не придется доказывать менеджменту, что вот этот рефакторинг надо сделать сейчас или там есть низкоприоритетные с точки зрения бизнеса баги которые жизненно необходимо фиксить сейчас, звучали более чем заманчиво. Особенно в свете того, что кто-то (basecamp) так годами делают свой продукт и до сих пор не отказались от своего процесса. Жёсткие ограничения по времени при гибкости размеров проекта "Почти готово" по завершении цикла равняется "Не готово совсем" и по дефолту ничего не доделывается В рамках цикла дизайнеры и программисты работают сообща и сами определяют детали реализации проекта в рамках поставленной задачи Нет централизованного бэклога. Проекты текущего цикла были сформированы в ходе прошлого цикла и на них была сделана ставка в ходе прошлого кулдауна, то есть за 2 недели перед текущим циклом На каждом проекте в каждую секунду времени у каждого заинтересованного участника существует некоторое количество идей о том что, где и как можно улучшить на проекте. Те идеи, которые в итоге будут взяты в работу, должны сначала пройти путь от состояния “сырой” до состояния “готовой”. Готовность идеи можно определить по: четко сформулированной проблеме, которую собираются решать четко описано, что предлагается сделать в качестве решения четко описано, что НЕ ЯВЛЯЕТСЯ частью предлагаемого решения и делаться не будет отдельно оговорены места, из-за которых сроки могут неконтролируемо съехать и даны четкие рекомендации на предмет того как этого можно избежать Для грамотного формирования идеи очень важны две концепции - “Scope Hammer” и “Аппетит”.  Аппетит - это время (а значит и деньги), которым готовы рискнуть, чтобы воплотить идею в том виде, в котором она представлена. Идентичный функционал вызовет кардинально разное отношение, у тех кто платит по счетам, если будет оценен в 6 недель работы и если будет оценен в 6 месяцев. Цикл, рекомендуемый авторами методики, составляет 6 недель и максимальный аппетит тоже соответственно 6 недель. Меньше можно, больше нельзя.  На этом месте я, пока не разобрался детально, малость завис. А как же любые фичи, которые очевидно не поместятся в 6-недельные ограничения? Я поначалу даже думал, что там в basecamp’е кодят какие-то боги, которые что угодно могут сделать за 6 недель. Но как оказалось всё несколько тривиальнее и там тоже занимаются ровно таким же поеданием слонов по частям что и везде.  Просто разбивают огромную фичу на имеющие самоценность части, которые можно сделать и выпустить в рамках отдельных циклов. Очень похоже на Scrum, но тут как мне кажется больше акцента на самоценность и пользу отдельных частей и этот акцент лучше выполняется. Scope Hammer. Вот, например, поход в магазин за продуктами. У тебя ограниченный бюджет и блюдо которое надо готовить, скажем рис с морепродуктами на 4 человек. Допустим ты набрал всё что нужно, чтобы приготовить идеальный рис с морепродуктами мечты, но есть одна проблема - бюджет превышен в полтора раза.  Что же делать, если больше денег достать не получится? Очевидно надо задействовать Scope Hammer! Креветки взять поменьше, рис попроще, от половины приправ отказаться, возможно. В итоге получится не такой изысканный деликатес как задумывалось, но 4 человека будут сыты. Самое главное - выполнить взятые на себя обязательства.  Возвращаясь в мир разработки ПО Scope Hammer’ом нужно работать постоянно и на всех этапах, чтобы отделять must-have фичи от nice-to-have фич Оформленные идеи называются pitch’и и выставляются на всеобщее обозрение с двумя целями - для сбора фидбеков и конструктивной критики, чтобы успеть доработать до начала фазы ставок и чтобы те кто будут впоследствии делать ставки смогли ознакомиться На этом шаге решается что будет делаться а что нет. Решают топы.  Что создает рабочую атмосферу очень ценного времени для каждого из участников. В basecamp это CEO, CTO продуктовый стратег (он же автор книги) и главный дизайнер. Основные причины, по которым могут не взять проект в работу такие: проблема, которую решает проект недостаточно значима в их глазах предлагаемое в целом не нравится предлагаемое решение не нравится в совокупности с заявленным аппетитом идея сыровата или даны недостаточно убедительные ответы на возникшую критику Дайте людям работать и пожинайте плоды. Очень важная штука это 6 недель без вмешательства в дела команды. В книге описаны очень подозрительные результаты, там команда из одного дизайнера и одного-двух программистов делает фичи и у них на core-команду из 12 программистов всего один тестировщик По умолчанию никто не даст времени доделать “почти готовую”© фичу и мы принимаем риск ничего не сделать за цикл, вместе с тем избавляясь от риска затратить на фичу в 3-5 раз больше времени чем мы изначально закладывали в оценке. По концепции Fixed time - Variable Scope, если ты не доделав must-have функционал берёшься за nice-to-have и не успеваешь - проблема очевидна и ты её не повторишь. Если ты не смог отказаться от каких-то nice-to-have фич и из-за этого зафакапил сроки - то же самое. Если не успели даже только must-have фичи запилить - это факап на стадии шейпинга.  По моему мнению такой риск стоящий, потому что представляет собой реальную ответственность за факапы, а соответственно возможность постоянно учиться на своих ошибках. Вот этот принцип согласно которому по умолчанию невыпущенное к концу цикла выбрасывается называется… См на картинку (Circuit Breaker - предохранитель) (Если что я не играл, но как-то раз наткнулся на стрим Майкера с Дримхака где БратОК затащил топ-1 и моя жизнь никогда не была прежней после этого) Scrum-команды, в которых мне довелось работать, такой работе над ошибками уделяли критически мало времени и по остаточному принципу. Пока работа идёт действует эффект Конкорда, когда работа наконец-то доделывается, хочется поскорее забыть весь этот кошмар. Скорее всего не только я один сталкивался с ситуацией когда задача занимала в разы больше времени чем предполагала её изначальная оценка. Я до недавних пор очень смутно понимал в чём разница задач где я не попал в оценку в разы и задач где я не попал в изначальную оценку совсем чуть-чуть. С теми которые попали в оценку всё понятно - мне просто повезло. Но вот когда я увидел данную метафору всё встало на свои места. Откуда и зачем эти демоны узнали про мой профессиональный опыт, чтобы так ловко его обобщить до сих гадаю. Мне тут в процессе подготовки статьи сказали что картинка может быть непонятна без контекста. Я не очень в это верю если честно, но решил подстраховаться Пожалуйста, помогите собрать статистику Допустим тебе надо собрать пакет документов для путешествия в страну “икс”. У тебя нет никакой предварительной информации по этому вопросу. Ты у подножия горы.  Сколько займёт сбор пакета документов?  ХЗ!  Успеешь за неделю?  ХЗ!  А за две?  ХЗ!  А если очень срочно  понадобится ускориться сможешь закончить в течение 2х дней?  Да не знаю я, отвяжись уже!!!  Окей, а когда будешь знать, когда сможешь закончить?  Когда все необходимые требования изучу детально, и про потенциальные подводные камни почитаю отзывы тех кто подобным занимался до меня. Дальше ты узнаёшь про все документы, которые нужны и среди них все кроме одного можно получить в течение одного дня прямо перед поездкой в посольство. Единственный заковыристый в получении документ - приглашение от кого-нибудь на должности как минимум мэра города в стране “икс”. Ты понятия не имеешь как даже на связь с кем-то таким выйти. Ты на середине склона или чуть выше. Сколько займёт сбор пакета документов?  Почти все документы можно за день собрать, а вот что с приглашением делать я пока ХЗ. Дальше ты выцепляешь какого-то публичного человека страны “икс” в твиттере, просишь пригласить в их чудесную страну, тебе отвечают “Ок, с радостью, ждите международную экспресс доставку письма со всеми печатями и подписями через 5-10 рабочих дней. Ты на вершине горы неизвестности. Сколько займёт сбор пакета документов?  От 5 до 10 рабочих дней, остальные я пока письмо жду изи соберу. Дальше надо только дождаться и собрать “легкие” документы. Ты скатываешься вниз по склону к окончательному решению задачи. Сбор пакета документов закончен. Только катастрофические события могут помешать тебе оказаться в стране “икс”... Все заключения чисто умозрительные на данный момент, так как у меня нет реального опыта работы по Shape up. Поэтому я буду искренне предвзят и перечислю плюсы и минусы данной методики на мой взгляд, как я их вижу в данный момент Pros Меньше ритуалов и planning overhead’а  Ответственность за результат, воспитанная реальным риском зафакапить сроки и ничего не выпустить по итогам 6 недель работы Больше свободы действий команды разработки и развязанные руки в плане конкретных деталей реализации Cons Какая-то новая непроверенная хрень, где программистам не то что разрешается е***нить 2 недели каждые 2 месяца, а их напрямую обязывают это делать  Некоторые программисты действительно будут бездельничать если им разрешить делать всё что им захочется P.S. Я по этой теме делал доклад в нашей небольшой и уютной компании и там возникла пара разумных моментов: Людям, которые работают по принципу заказчик сказал, что можно ничего не делать, значит буду ничего не делать две недели, такое не подходит. Они определённо есть возможно даже в большом количестве, но это не 100%. Basecamp - компания продуктовая, и Shape up сделан с учётом особенностей продуктовой разработки. А как же джуны в период кулдауна, им ведь сложно будет найти себе занятие? На первый взгляд да, но во-первых у них есть старшие товарищи, всегда готовые подсказать. А во-вторых, пойти разбираться в кодовой базе, посмотреть, поучиться и поэкспериментировать тоже вполне годное занятие в данный период. Независимо от уровня разработчика Детальное погружение в Shaping