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

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

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

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

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

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

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

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

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

Недавно открыл для себя канал Continuous Delivery и очень сильно проникся. Я переживал за то насколько можно будет совмещать CD с 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». Ок, я воспроизвёл на своём тестовом документе, слегка подкорректировал и скрипт и бекенд и добился работоспособности в новой парадигме.

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

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

Примерный текст ошибки для особо любопытных

empty attribute name for key dynamodb extendedRequestId: undefined, cfId: undefined,

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

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

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

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

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

Лично я, в ходе данного эксперимента, убедился, что

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

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

На мой взгляд отслеживание прогресса посредством https://habr.com/ru/post/709876/