Чтобы проверить Shape up в реальном проекте я решил продолжить решать кейс обработки результатов пульс‑опроса для наших HR'ов. В предыдущей серии я обрисовал требования к переносу функционала из гугл‑таблицы, обрабатываемой скриптом во внутри корпоративное приложение. По условиям у меня 80 рабочих(!) часов и ни в коем случае нельзя ухудшать UX.
Эксперимент вышел не совсем «чистый» — я был в качестве человека‑оркестра и могу быть предвзят в своих оценках. Тем не менее опыт вышел достаточно интересный.
Краткий дневник разработки
День 1 - осталось 72 часа работы
День помучившись с независимым деплоем бэкенда, в основном связанным с тем что я кроме Heroku не знал бесплатных мест куда деплоить мелкие приложухи за бесплатно можно, а лезть к DevOps'ам и вписываться в нашу инфраструктуру пока не хотелось, мне это оверхедом виделось на тот момент.
В итоге я нашел Cyclic — идеальное решение. Скопипастил репозиторий, связал его с аккаунтом и он деплоится на каждый коммит. Идеально. Немного потупив с express'ом заставил в итоге работать связку гугл‑скрипта и этого бэкенда как я задумывал.
Итоги дня: стоило тщательнее поисследовать вопрос на этапе шейпинга, немного пообщаться с нашими бекендерами перед началом работ. Это помогло бы сэкономить полдня, но в целом ничего страшного не произошло.
День 2 - осталось 64 часа работы
Недавно открыл для себя канал Continuous Delivery и очень сильно проникся. Я переживал за то насколько можно будет совмещать CD с Shape Up. В теории, они друг другу не мешают, на сколько я могу судить и отказываться от одного в пользу другого не надо.
Работать без необходимости регулярно отчитываться перед менеджментом прикольно, хотелось бы такой опыт в масштабе команды попробовать. Хилл‑чарты, на мой взгляд, предоставляют достаточно информации, чтобы отслеживать ход работ, не вмешиваясь без надобности.
Итоги дня: окончательно разобрался с бекендом и разобрался с переходом на страницу аналитики.
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». Ок, я воспроизвёл на своём тестовом документе, слегка подкорректировал и скрипт и бекенд и добился работоспособности в новой парадигме.
Фейл второй - неведомая неподконтрольная мне фигня
Когда дошла очередь до продовского документа, ДинамоДБ наотрез отказалась принимать в себя продовские данные, выдавая ошибку.
Примерный текст ошибки для особо любопытных
empty attribute name for key dynamodb extendedRequestId: undefined, cfId: undefined,
Вот её я уже воспроизвести не смог и осталось только признать, что я не уложился в заявленный аппетит. Главной причиной я бы назвал недооценку слабости своей экспертизы в бекенде. Shape up на стадии shaping предполагает возможность обратиться к техническим экспертам, но к сожалению я этого не сделал до того, как приступил к реализации. О чем в итоге пожалел.
Тут по-хорошему на арену выходит концепция circuit breaker (предохранитель) и, как правило, такие проекты не доделываются. Доделываются только тогда, когда проект важный и оставшаяся работа соответствует двум критериям:
Во-первых, оставшиеся задачи должны быть только из категории маст-хэв.
Во-вторых, оставшиеся задачи должны быть на этапе реализации, без капли неопределнности и нерешённых вопросов. "На спуске", если выражаться в терминах Хилл-чартов
Мне оставалось только задеплоиться на прод — это, разумеется, тру маст хэв. Со вторым пунктом сложнее, потому что причина, из‑за которой оно не заработало, мне так и осталась неведома. По этим критериям необходимо «сушить весла».
Если бы я находился в условиях реальной 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 эти очень крутые фичи есть из коробки, он мне ни на йоту не перестал нравится, даже не смотря на мой фейл со сроками.
