Разработка свободная от ритуалов. Как я зафейлил, но не разочаровался в Shape up

Чтобы проверить Shape up в реальном проекте я решил продолжить решать кейс обработки результатов пульс-опроса для наших HR'ов. В предыдущей серии я обрисовал требования к переносу функционала из гугл-таблицы, обрабатываемой скриптом во внутри корпоративное приложение. По условиям у меня 80 рабочих(!) часов и ни в коем случае нельзя ухудшать UX.

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

Краткий дневник разработки

День 1 - осталось 72 часа работы

День помучившись с независимым деплоем бэкенда, в основном связанным с тем что я кроме Heroku не знал бесплатных мест куда деплоить мелкие приложухи за бесплатно можно, а лезть к DevOps'ам и вписываться в нашу инфраструктуру пока не хотелось, мне это оверхедом виделось на тот момент.

В итоге я нашел Cyclic - идеальное решение. Скопипастил репозиторий, связал его с аккаунтом и он деплоится на каждый коммит. Идеально. Немного потупив с express’ом заставил в итоге работать связку гугл-скрипта и этого бэкенда как я задумывал.

Итоги дня: стоило тщательнее поисследовать вопрос на этапе шейпинга, немного пообщаться с нашими бекендерами перед началом работ. Это помогло бы сэкономить полдня, но в целом ничего страшного не произошло.

День 2 - осталось 64 часа работы

Недавно открыл для себя канал Continuous Delivery и очень сильно проникся. Я переживал за то насколько можно будет совмещать CD с Shape Up. В теории, они друг другу не мешают, на сколько я могу судить и отказываться от одного в пользу другого не надо.

Работать без необходимости регулярно отчитываться перед менеджментом прикольно, хотелось бы такой опыт в масштабе команды попробовать. Визуализация прогресса разработки в виде холма, где ты сначала поднимаешься по склону неопределенности, потом спускаешься по склону имплементации</p>" data-abbr="Хилл-чарты">Хилл-чарты, на мой взгляд, предоставляют достаточно информации, чтобы отслеживать ход работ, не вмешиваясь без надобности.

Итоги дня: окончательно разобрался с бекендом и разобрался с переходом на страницу аналитики.

Cyclic немножко больнючий потому что сбрасывает состояние, а я в in-memory storage складываю данные.

День 3 - осталось 56 часов работы

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

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

Итоги дня: я спокойно по ТДДшке сделал утилитки для шкал и вывел данные в сыром формате на страницу.
Комментарий из будущего: Здесь уже стоило задуматься о тестовом деплое на прод

День 4 - осталось 48 часов работы

Итоги дня: по большому счету, с этого момента я уверен, что успею сделать всё основное для этого проекта, вопрос только в том сколько nice-to-have фич я успею туда запихнуть.

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

День 5 - прошла половина времени 40 часов ещё есть

Итоги недели: половина времени прошла, осталась пара сложных логических вещей и противная верстка, но выглядит так как будто мне не придётся адски овертаймить и прочее. Я ещё не по Shape up’овски делаю, потому что сейчас уже можно было бы выкладывать что-то на прод пользуясь техникой Dark Launching.

Было бы круто посчитать в деньгах, сколько времени разработчиков экономится на отсутствии встреч и, соответственно, денег заказчика. Сравнить со Скрамом. Жаль, что я слишком ленивый для этого.

День 6 - осталось 32 часа работы

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

Итоги дня: пришлось ненадолго вернуться к бекенду и напилить ручки для записи и считывания результатов беседы 1-на-1 с HR'ом.

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

День 7 - осталось 24 часа работы

Перевёл бэкенд на ДинамоДБ, который cyclic даёт почти из коробки (npm пакет установить и 2 строчки коннекта к базе в коде) Вывел сводку по всем индексам и добавил на фронте и беке возможность

Итоги дня: С точки зрения бизнес-логики проект закончен. Осталось 3 дня работы, за это время мне надо задеплоить, отрефакторить свой код и причесать всё с точки стилей.
Комментарий из будущего: Здесь определенно нужно было сначала задеплоить на прод, а потом возвращаться к рефакторингам и украшательству

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

День 8 - осталось 16 часов работы

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

День 9 и 9,5 - осталось 4 часа работы

Итоги дня: Ещё спустя 1,5 рабочего дня занятий рефакторингом и стилями, фичи приведены к завершённому виду.

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

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

А в новом году началось веселье

Фейл первый - слишком большой размер JSON'а

Тут мне первый аукнулось нежелание вписаться в нашу инфраструктуру. Оглядываясь назад мне наверно стоило чуть больше поресерчить на стороне Cyclic, а не бросаться переписывать логику.
Суть проблемы оказалась такова: В моём тестовом документе было 10 строчек а в боевом 54. Это совсем не большой JSON, но этого хватило чтобы воткнуться в “413 Request Entity Too Large”. Ок, я воспроизвёл на своём тестовом документе, слегка подкорректировал и скрипт и бекенд и добился работоспособности в новой парадигме.

Фейл второй - неведомая неподконтрольная мне фигня

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

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

Тут по-хорошему на арену выходит концепция circuit breaker (предохранитель) и, как правило, такие проекты не доделываются. Доделываются только тогда, когда проект важный и оставшаяся работа соответствует двум критериям:

Во-первых, оставшиеся задачи должны быть только из категории маст-хэв.
Во-вторых, оставшиеся задачи должны быть на этапе реализации, без капли неопределнности и нерешённых вопросов. "На спуске", если выражаться в терминах Визуализация прогресса разработки в виде холма, где ты сначала поднимаешься по склону неопределенности, потом спускаешься по склону имплементации</p>" data-abbr="Хилл-чартов">Хилл-чартов

Мне оставалось только задеплоиться на прод - это, разумеется, тру маст хэв. Со вторым пунктом сложнее, потому что причина, из-за которой оно не заработало, мне так и осталась неведома. По этим критериям необходимо "сушить весла".

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

Но так как подготовка "следующего Shape up'овского цикла" происходила строго в моём воображении, одобрение закончить функционал было получено с удивительной легкостью.

Фейл третий - АПИ общения с гугл-таблицей, осталось -5 часов

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

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

Это отняло у меня ещё где-то 4-6 часов. Самое главное, что последняя попытка выкатить на прод вечером пятницы оказалась успешной и человек, который мог проверить и уронить эту гору с моих плеч ещё не ушёл домой на тот момент.

Выводы по итогам эксперимента

Вывод №1 - При первой возможности деплойся на прод

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

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

Вывод №2 - Свобода самостоятельно размечать области работ на задачи идёт процессу только на пользу

Талантливые люди не приходят в восторг от мысли побыть “кодобезьянамм” или "погонщиками тикетов". Планирование заранее не позволяет увидеть реальность, с которой ты столкнёшься по ходу дела.

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

• Надо как-то отфильтровать целевого юзера по id в нашем внутреннем приложении

• [Nice-to-Have] Ежедневные апдейты данных в автоматическом режиме

• [Scope] Parsing answers logic

• [Scope] Indices calculating logic

• [Nice-to-have] Logic Documentation and architecture

• [Scope] Логика зоны потенциальной фальсификации

• [Scope] Styling "The polished look"

Вывод №3 - Хилл-чарты, моя любовь с первого взгляда, прошедшая проверку временем

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

Лично я, в ходе данного эксперимента, убедился, что Хилл-чарты вкупе с to-do листами вполне способны давать полное представление о ходе разработки и прогрессе команды. Плюс в отличие от Burndown чартов у них нет "идеальной траектории" и не может быть искушения подгонять реальность под неё.

Совсем напоследок

В эти самые минуты множество команд по всему земному шару сталкиваются с тем, что на простом языке называется "Слишком много безосновательно общих встреч", а если по-умному то "Planning overhead".

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