Введение
Об авторе
Меня зовут Леонид «Лео» Царев. Я бывший программист на .Net (18+ лет опыта), последние 10 лет я тимлид/архитектор/руководитель. Сейчас я директор департамента разработки в компании Цифра / Цифровая Индустриальная платформа. То, о чем я буду писать, основано на моем опыте работы в компаниях Цифра/ЦИП, Fortis (monopoly.online) и Ланит-Терком. Вопрос баланса между тем, как дать свободу творчества программисту и необходимую гибкость в разработке, но сохранить контроль и сбалансированное принятие решений в архитектуре, меня беспокоил все это время.
TL;DR
Уже в двух компаниях при моем участии был внедрен процесс обязательного технического анализа по задачам для программистов. Смысл технического анализа в том, что перед тем, как взять задачу в работу, программист пишет небольшой (от полстранички) документ про то, как он планирует это сделать, и показывает коллегам/архитектору/тимлиду/тестерам/whatever. Этот документ предназначен для согласования важных деталей реализации перед написанием кода.
Велосипеды
Возможно, эта статья не описывает каких-то уникальных открытий. Многие скажут «да мы всегда так делали». Многие обратят внимание, что схожая практика есть в 12 пунктах Джоэла Спольски.
Окей. Я всего лишь хочу поделиться своим жизненным опытом, потому что для меня и компаний, которые я встречал на жизненном пути, он был нетривиальным.
Многие отмахнутся от этой идеи как от ненужной бесмысленной бюрократии. Повеяло архитекторами, корпорациями, архитектурными советами и 500-страничными проектами, которые никто не читает? Клянусь, я сам был таким, поэтому вам особо нужно это прочитать.
Предыстория
Ненависть к архитектуре
Когда-то давно, во времена waterfall, написание документации, технических проектов и прочего было обязательным. Многостраничные документы предваряли написание любого кода. Их писали мудрейшие архитекторы на основании других многостраничных документов и спускали с неба простым программистам, причем писали долгие месяцы. Потом программисты долгие месяцы кодировали, потом тестеры долгие месяцы тестировали и выясняли, что пользователю нужно совсем другое. Вспомнили эти вайбы? Мы давно отвергли все это к чертям. Наступил agile, scrum, новый век.
Мы все разговариваем, много и часто. Знаем, что надо быстро программировать и быстро менять. У нас нет времени писать такие многостраничные документы до программирования — в нашем двухнедельном цикле. Преимущества коротких итераций известны всем — такой продукт быстрее развивается, больше подходит пользователям, в нем меньше ошибок, мы делаем меньше ненужной работы. Соответственно, двухнедельные итерации — счастье.
Не нужны эти документы — не нужны и архитекторы. Не нужны замшелые 50-летние старики, которые не умеют программировать, которые мыслят блок-схемами и архитектурными диаграммами, но ни черта не понимают в ORM, kubernetes и паттернах проектирования. Даже когда я сам стал, по сути дела, архитектором, я избегал этого титула как огня и потребовал, чтобы меня записали главным разработчиком. Чтобы подчеркнуть, что я вообще-то умею программировать, могу читать и писать код. В общем, умею не только писать документы.
Нет, конечно, по сложным задачам так уж и быть, нужно нарисовать план на доске, потом может даже перенести его в вики. Но это может одна задача из пяти, не больше.
Эта ненависть распространилась и на всю документацию вообще. Я запрещал своим программистам описывать схему базы данных (посмотрите в коде XML-комментарии к классам, описывающим сущности) и схему API (посмотрите в swagger UI). Документация не нужна!
Код-ревью
Как и многие коллеги, я фанат код-ревью. Нет, я СТРАШНЫЙ фанат взаимного код-ревью. Там, где его не было, я его вводил, а там, где было, — с радостью погружался. Мне никогда не надо было убеждать в полезности этой практики, и до сих пор я убежден, что соблюдение правила «четырех глаз» (каждый код перед попаданием в релиз должны увидеть хотя бы два человека — автор и ревьюер) является необходимым условием для качественного кода. Википедия обозначает следующие преимущества код-ревью:
повышение качества кода и его поддерживаемости (включая читаемость, стиль и проч.)
более раннее нахождение багов
обмен знаниями
взаимная ответственность
нахождение лучших решений.
Из этого, как ни странно, самым важным я считаю обмен знаниями. Поэтому я противник «иерархических» схем ревью (лид ревьюит всех, его не ревьюит никто) и настаиваю на том, чтобы самый юный джун тоже получал свою долю выступлений в качестве ревьюера.
Мы применяли код-ревью для всего — от исправления стиля («Лёнина висячая запятая» стала притчей во языцех) до обсуждения серьезных архитектурных проблем. Один из больших плюсов код-ревью — это ломка распространенной схемы «индивидуального владения сервисами»: схемы, когда за каждый сервис отвечал ровно один разработчик, и только это разработчик вообще в принципе когда-либо читал код этого сервиса (а иногда только на его локальной машине можно было в принципе сервис собрать).
Код-ревью объединил нас в команду — мы читали код друг друга, мы знали, что творится, мы могли пофиксить баг в коде товарища. У нас был один стиль и один уровень требовательности — ведь разрешалось залезть в чужой pull request непрошенным, и наезд на ревьюера — «как ты поставил аппрув, ты что не читал» было страшным обвинением. Код-ревью очень хорошо работал для нас.
Оффтоп: проверять код стайл на код ревью — зряшняя трата сил! Не делайте так!
Карьера, и как я стал проблемой для команд
Контора росла, мы масштабировались. Я был хорош (как мне кажется и сейчас) в код-ревью, и хорошие разработчики стояли в очередь — ведь я давал полезные замечания. Я начал захлебываться в ревью. Особенно когда вместо одной «моей» команды у меня появилось две, три, четыре «моих». Со своими тимлидами, конечно, сначала подчиняющимися мне неформально, а потом и формально.
Естестественно, я начал экономить свое время. Понятно, что я ревьюил не все подряд, а только важное. Но в какой-то момент важного стало многовато, и закапываться во все важное времени не хватило. Я копил очередь, влетал с замечаниями в последний момент, ругался, заставлял все переделывать. Разработчики начали ворчать — опять Леня докопался.
Тестеры стали выть — часто они уже протестировали многое, а тут по итогам ревью прилетела пачка замечаний (здравомыслящих, а иногда прямо и умных, важных), и соответственно пошла пачка правок. Надо делать ретест.
Ко мне появились претензии со стороны тимлидов/менеджеров команд и владельцев/менеджеров продукта. Сроки срывались. Все чаще на скрам-митингах «Лёнины замечания» становились причиной срыва спринта. Все чаще программист мне говорил «а давай не будем переделывать, почти сдали уже, нет сил». Что-то перестало работать.
Следующий шаг, который пришел к нам в голову — борьба за хорошие описания к PR. Если в PR хорошо описано, что сделано, можно понять, следует ли внимательно читать и писать замечания. Это стало работать лучше. Но дальше в нашу голову пришла крамольная мысль. А что, если писать сначала, что планируется, а потом уже делать?
Новый процесс
Итак, собственно новый процесс выглядел так: приступив к работе над задачей, программист читал требования и на основе них писал максимально краткий текст «как я буду реализовывать задачу». В этом документе он освещает:
В какие компоненты он планирует внести изменения или добавить новые компоненты (джобы и т.д.)
Внешние контракты, если они есть (между системами, между беком и фронтом, какие поля будут в БД, в сообщениях Rabbit/Kafka и т.д.)
Миграцию, обратную совместимость, возможность отката
Изменения в развертывании
Что потенциально сломается и что надо будет протестировать
Как мы будем писать автотесты на задачу
Этот документ ревьюится (полный аналог с ревью кода). После завершения ревью — у нас есть план по задаче. Происходит нарезка тасок и они пускаются в работу.
Теперь мы — (а) договорились, что делаем (б) повышаем контроль архитектора и лида над происходящим (в) повышаем прозрачность изменений для тестера и других членов команды (г) минимизируем риск переделок (д) уменьшаем количество конфликтов.
Итог от внедрения этого документа оказался сногсшибательно позитивный. Сроки перестали срываться, ревью и переделки после него стали занимать гораздо меньше времени, перестали происходить неожиданные для всех изменения в важных архитектурных компонентах.
Эффективное использование времени архитекторов
Гигантский мой личный плюс: я смог, сохранив достаточную для себя степень контроля над происходящим, высвободить гигантское количество времени (для работы с людьми, разработки планов масштабных архитектурных изменений, и даже вернулась возможность совмещать с лидством микрокоманды). Такие же плюсы подмечали и остальные архитекторы.
Обратите внимание, в отличие от традиционной схемы «архитектор/системный аналитик проектирует, программист реализует», тут это проектирует программист. Это сохраняет принципы условной взаимозаменяемости agile команд и не превращает работу программиста в «закодировать, что умные парни велят».
Ну и для архитекторов это очень важно. Никто из технарей не хочет превращать свою работу в рутинное расписывание типовых задач. Крутые парни не хотят это делать. Если мы заставляем архитекторов лично расписывать каждую задачу, нам требуется слишком много архитекторов — и их придется набирать из аналитиков, не самых сильных программистов и даже (видел такие варианты) — техписов. Работа архитекторов не «описывать все задачи» — работа архитекторов в этом аспекте «отвечать и контролировать техническое совершенство задач». И теперь мы можем просить у архитекторов не только рутины — можем требовать от них и ожидать, что у них будет достаточно времени на креатив, на инициативные предложения и т.д.
Разумеется, архитекторы могут проектировать какие-то сложные задачи сами. Но они не должны проектировать их все. И, что самое важно, они обретают доверие к остальным членам команды
На следующей работе, в качестве директора по разработке — человека, который стоит над архитекторами, я тоже приобрел гигантский плюс. Я могу контролировать самое важное, смотреть и вмешиваться в изменения, которые затрагивают важнейшие компоненты системы — при этом не трогая рутинные задачи, но зная, что их контролируют архитекторы
Другие плюсы
Ответственность программиста
Программист в этой схеме не может свалить ответственность на архитектора. Как и в случае код-ревью, он писал этот документ (код), его была задача найти оптимальное архитектурное решение. С него можно спросить за результат. Он не кодирует по придуманному кем-то сценарию — он его придумывает.
ADR
Паттерн ADR (Architecture Decision Record) говорит о том, что приняв важное решение, надо записать его с аргументами, чтобы вспомнить через год. Фактически в этом подходе мы получаем этот паттерн «бесплатно» — ведь по каждой задаче мы записали, что и как решили. «Почему» тоже получается автоматически — часто в ходе дискуссии в комментариях. Повторяющийся паттерн диалога: «А почему так? — Так как вот почему. — Согласен, вынеси в текст», — этому немало способствовал.
Spike/discovery фаза и плюсы для планирования
Классический подход scrum: если не знаешь, сколько сделать задачу, возьми небольшое время для изучения (spike), — в этом подходе очень хорошо проявляется. С недельными итерациями подход «Вася берет на неделю технический анализ такой-то фичи и эти три бага» очень хорошо работал. Разработка этого документа (даже вместе с ревью) занимает примерно понятное время. Разработка и тестирование фичи по этому документу — тоже примерно понятное время. Мы превратили одну неопределенную задачу в две гораздо более определенных.
Разумеется, разработка документа может завершиться неудачей — придумано и написано совсем не то, что нужно, на ревью документа это стало понятно. Но даже если так, то со второй итерации, второй попытки, задача точно возьмется.
Менеджеры стали гораздо спокойнее относится к мысли «нужно договориться с архитектором, как будем делать» — потому что это стало понятной задачей, понятного скоупа, с артефактом на выходе. Менеджеры стали спокойнее относится к код-ревью — потому что исчезла угроза «на ревью выяснилось, что надо переделать все».
Контроль стека технологий
Стало гораздо меньше протащенных левых библиотек с непонятными лицензиями, велосипедов, дублирующих то, что уже реализовано платформенной командой и прочего. Стало меньше решений «хочу попробовать новую технологию». Это все нельзя было затащить тихой сапой под предлогом «че уж теперь, переделывать что ли». Это плюс.
Product Owner не могут в стратегическое видение
Одна из метрик, которые мы стали собирать, — это соотношение между задачами, которыми мы взяли на анализ, и теми задачами, которые реально пошли в работу. Нормально, когда после анализа, узнав оценку, PO отказывается брать задачу в план. Но у одного PO мы обнаружили аномальное соотношение между этими типами задач — и похоже это коррелировало с отсутствием у PO видения и понимания, куда следует двигаться его продукту, с тем, что он разбрасывается, не зная куда бежать. Это было донесено до его руководителей, подтвердилось и (вкупе с другими проблемами) привело к соответствующему кадровому решению.
Путь в лиды и архитекторы
В этой схеме деятельность программистов похожа на то, чем занимаются лиды и архитекторы. Как и они, программисты проектируют и ревьюят архитектуру других. Самый юный джун видит, как принимаются архитектурные решения, учится их обосновывать, учится задавать вопросы. Мы учим программистов заниматься архитектурой. Собственно, качество проработки этих документов налицо, мы понимаем насколько хорошо мыслит человек — и постепенно после внедрения этой схемы мы стали гораздо меньше брать лидов со стороны: у нас появилось понимание и путь как растить их на месте.
Вовлечение тестеров и других команд
Тестеры в этой схеме стали гораздо больше вовлечены. Хорошие тестеры стали задавать вопросы «а как мы смигрируем данные», «а почему планы на реализацию расходятся с требованиями», «какие автотесты ты планируешь написать» ДО того, как программист начнет писать. Теперь оказывалось, что «оценка не учитывает автотесты», не за день до сдачи. Для тестеров чтение технического анализа оказалось на той же фазе, что и тестирование требований (ваши тестеры же тестируют требования? — если нет, пусть немедленно начнут).
Другие программисты — особенно в том случае, если задевали «их» модули (формально индивидуальное владение кодом было у нас ликвидировано, но все равно есть люди, которые лучше понимают в этих областях) — могут дать очень ценную инфу и советы по реализации. В типовой agile команде невозможно никакому программисту ревьюить ВЕСЬ код, который пишут его коллеги (но некоторые контрол-фрик лиды пытаются). Но в типовой agile команде возможно лиду читать ВСЕ теханализы своей команды, а обычному программисту — читать БОЛЬШУЮ часть теханализов своей команды. Таким образом команда становится командой.
Делая фичи, которые затрагивают другие команды, стало гораздо проще решать эти вопросы. Вместо «вы полезли в наш код какого хера» получилось «вот какие согласованные ВАМИ изменения затрагивают вас».
Вообще Confluence и его аналоги делают процесс расширения ревьюеров очень простым. Тегнуть «@Вася тут будем вашу API вызывать» — очень просто и полезно.
RFC и процессы
В какой-то момент мы так увлеклись процессом написания документов, что обнаружили, что процесс «написать документ, добавить в него галочками всех, кто заинтересован и предложить им окнуть» подходит не только для задач, но и для:
изменений процессов
изменений настроек ПО (Jira, Teamcity, etc)
организационных изменений (конфигураций команд, кадровых перемещений).
изменений регламентов, кодстайла и т.д.
Старый бюрократический принцип «согласования приносимых на подпись руководителю документов» работает ОЧЕНЬ хорошо. Моим почти универсальным ответом на вопрос «у меня вот такая идея, которая в твоей власти, давай так сделаем?» — стало «вот какие у меня мысли, но прошу создать документ в Confluence и отправить на общее обсуждение». Это прямо огненно! Естественно, по большинству таких документов почти всегда понятно, кто принимает финальное решение, но ситуаций «директор департамент принял, поговорив с одним начальником отдела, некоторое решение, а другой начальник отдела охренел» — стало сильно меньше. Давать заднюю приходится мне как начальнику гораздо реже, и мне это нравится. Ну все остальные плюсы валидны (например, от вопросов и наездов по проекту регламента технической поддержки отбивается от возмущенных продуктовых команд — начальник тех поддержки, он же составляет финальный документ и я его только согласую).
Канал с RFC/теханализами
Сейчас у нас есть общедоступный (на весь департамент разработки, на 200+ человек) канал в мессенджере, куда скидываются все теханализы. Даже читая заголовки, можно примерно понять, что происходит в разработке. А при желании — в любой теханализ можно прыгнуть в комментарии и причинить пользу.
Смена программиста
Идеально, чтобы анализ и реализацию делал тот же человек. Но вообще написанный анализ позволяет: (а) легче передать задачу другому человеку, если первый уйдет в отпуск (б) проще отдать часть задачи (в) пойти по принципу «миддл проектирует, джун реализует».
Общие знания делают людей в команде более взаимозаменяемыми — что хорошо с точки зрения agile.
Аналоги
Технический проект / «проект программных средств»
В целом большие дяди про нас подумали все давно. Национальный стандарт ГОСТ-12207-2010 «Информационная технология, Системная и программная инженерия — Процессы жизненного цикла программных средств», он же ISO/IEC 12207:2008 “System and software engineering — Software life cycle processes” гласит «7.1.4.1 Цель процесса детального проектирования программных средств заключается в обеспечении проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования».
Другое дело, что ГОСТ написан так, как будто это классический waterfall процесс от начала до конца. Но ничего в тексте ГОСТа не препятствует работе по итерациям (ну или я такого не нашел).
Джоэл Спольски и Software specification
В знаменитых 12 пунктах Джоэла необходимость написания спецификаций есть. Статья о необходимости ее написания — тоже. Правда, фактически тут речь про документы, которые пишут аналитики (или говоря на жаргоне Microsoft — Program Manager). Я скептически отношусь к этому, вернее считаю — что этого недостаточно. Выделенная роль для анализа бизнес-требований, составления функциональных требований — дело хорошее. У аналитиков (как бизнес-, так и системных) есть много возможностей и умений погружаться в предметную область и формировать ТРЕБОВАНИЯ к продукту. Требования это «система должна хранить и обрабатывать эти данные», например. Но хранить их в такой БД или в такой, раскладывать по таблицам так или так — это обычно не то, что умеют и любят выбирать аналитики. Скорее всего у них недостаточно компетенций, чтобы писать в своих требованиях — решения. Так мы тоже пробовали — оказалось, что они сначала пишут там ерунду, а потом хорошие аналитики начинают это делать под диктовку программиста. Нет уж, лучше два документа.
Intent to implement
Это процесс существует в разработке крупных Open Source проектов, например браузеров (Chrome, Firefox). Его можно сформулировать — планируешь сделать крупное изменение, напиши письмо (примерно такое) сначала. Ну и этот процесс является обязательным для всех web-visible изменений.
Полный аналог — это всякие Cassandra Enhancement Proposals и аналоги в процессе разработки в Kafka/Kubernetes etc.
Минусы
Программисты не могут в текст
Внезапно очень много программистов не умеют писать тексты. Им приходится этому учиться, иногда с болью и скрипом. Впрочем, в моей практике, это довольно хорошо коррелирует с остальными качествами программиста — те программисты, которые хорошо пишут технические тексты, хорошо и программируют. Те, у которых в текстах каша, — каша и в коде.
А те, кто хорошо пишут код, быстро учатся писать хорошие тексты.
Хорошее требование — чтобы миддл, а тем более сеньор программисты за испытательный срок написали и утвердили хотя бы один теханализ. С неспособными это сделать приходится расставаться.
Сроки как бы затягиваются
Нет, они не затягиваются. Формально то, что занимало одну итерацию «запрограммировать» теперь может занимать две «анализ, потом программировать». Cycle time растет.
В реальности простые задачи можно взять в одну итерацию (и на анализ, потом реализация) если нам кажется, что мы успеем. А если мы сейчас не успеваем это сделать, скорее всего и раньше не успевали. Ну и у нас была заложена возможность сказать «задача простая, тегаю архитектора в комментариях и делаю без анализа». Чем дальше, тем меньше мы ей пользовались.
Опасным местом тут является две итерации ревью (сначала дизайна, потом кода). В одной из команд переживали за занятость своего архитектора и потребовали ввести правило «архитектор должен согласовать или написать замечания по делу за два дня. Если он этого не сделал, то анализ считается согласованным». В целом это оказалось скорее придуманным опасением.
Да, есть эта пауза, где написал теханализ и ждешь ревью. Но практика показывает, что эта пауза отлично заполняется багами или доделками по код-ревью предыдущей задачи, другим теханализом. В целом возможно с определенным риском готовить часть коммитов по этой задаче (с той частью, которая скорее всего расхождения не вызовет).
По итогу во многих наших командах сейчас наличие теханализа является частью Definition of Ready — увеличение Cycle time окупается предсказуемостью и ростом общей производительности.
Расхождение документа и кода
В процессе реализации код и документ могут разойтись. Это опасно (как и любые два источника правды). Как избежать этой опасности?
Во-первых, по итогу реализации проверить, что реализация соответствует документу, — обязанность ревьюера (да и тестера там, где он это может). Так мы закрываем страхи контрол-фрик архитекторов (а что, если он напишет нормальное решение, а сам наговнокодит? а?) Впрочем, несколько личных выборочных проверок с залезанием в код всех успокоила.
Во-вторых, можно и нужно внести изменения в документ в процессе. Если они незначительные, можно просто уведомить ревьюеров, если значительные — это срыв, необходимо уйти на новый круг пересогласования. Но такое вообще-то бывает значительно реже, чем в традиционном подходе.
Менеджеры очень переживали за эти «срывы» — мол, что будет если к концу задачи окажется, что она сделана не по документу, а архитектор потребует вернуться к документу? или окажется, что нужно делать новую реализацию и согласовать ее быстро не удастся? Мы даже накидали какой-то процесс, мол, если случается прямо факап, то образуется техдолг, который команда пофиксит в следующей итерации по процессу с новым техрешением, а священные сроки менеджера останутся в безопасности. В реальности таких кейсов не возникало.
Заключение
Надеюсь, этой статьей я повеселил почтенную публику, а также заронил в ее голову мысль о том, что писать техническое решение буквами на русском языке прежде, чем писать код — это не так больно, достаточно в духе agile и чрезвычайно полезно. Буду рад вашим комментариям.
Постоянная ссылка на статью
Комментарии (66)
Kerman
01.07.2024 13:19+6В процессе реализации код и документ могут разойтись.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
leotsarev Автор
01.07.2024 13:19+2На самом деле тут у нас есть варианты.
Если есть незначительные изменения, то проще всего поправить теханализ в процессе реализации и уведомить ревьюеров. Или вообще не править теханализ (например, новое строковое поле в сущности может вообще не упоминаться в анализе, если это не меняет никаких публичных API за границами команды).
Если речь идет про кардинальные изменения по итогам прототипирования, это две задачи в пайплайне (сделать прототип, сделать вторую итерацию) и каждая задача претендует на теханализ.
В каких-то случаях можно написать прототип без теханализа — ну типа сделать мокап UI и показать, получить фидбек, уточнить задачу и идти в полноценную задачу
leotsarev Автор
01.07.2024 13:19Но да. В теории могут быть проекты, где эти вопросы, которые обычно обсуждаются в теханализе — поддерживаемость кода, масштабируемость, архитектура — не важны, а важно быстро согласовать и выдать прототип. В этом случае процессы эти вводить не нужно :-) С соответствующими эффектами.
Kerman
01.07.2024 13:19+5Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
leotsarev Автор
01.07.2024 13:19> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
iRumba
01.07.2024 13:19Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
А как же "попробовать"? Что, если надо проверить гипотезу на практике? Что, если в результате исследования оказжется, что это вообще невозможно сделать? Например, используемый инструмент работает не так, как ожидалось, а свой писать слишком долго?
Я неоднократно сокращал время на разработку тем, что реализовывал всякие полезности. И эти полезности я мог описать уже после реализации. Просто у меня было предчувствие, что все должно получиться. :)
В противном случае, разработка пошла бы по очевидному, но при этом длинному пути.
farafonoff
01.07.2024 13:19В процессе анализа можно сделать прототип, на анализ они вон и целый спринт могут выделить
leotsarev Автор
01.07.2024 13:19Почему целый спринт? Вася в этом спринте делает фичу, а Петя делает анализ фичи для следующего спринта и фиксит пять багов.
leotsarev Автор
01.07.2024 13:19> Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Хех. В анализе обычно как раз и нужно смотреть на границы между блоками. Вот есть такое API у связанного блока как вам нужно или нет? Если нет — то вы на анализе должны это увидеть, и подзадачу выделить. И кстати там же «похоже с ходу не выйдет, код надо рефакторить».
leotsarev Автор
01.07.2024 13:19Еще добавлю. Рефакторить все подряд под бизнес задачами — плохая практика. Полная непредсказуемость. затягивание сроков, нестабильность, гигантский объем затронутого функционала на ретест. Но от нее отказаться можно только, если мы сможем добиться, что сторька будет решаться несколькими связанными задачами: анализ, рефакторинг блока А с добавлением новых функций, рефакторинг блока Б с добавлением новых функций, создание нового блока В. Каждую сдаем и выпускаем отдельно, тестеры счастливы.
Нужно научиться «продавать» менеджерам и бизнесу эту необходимость. И теханализ тут доп. аргумент — чтобы это сделать, надо предварительно зарефакторить блок А. Почему? А вот документ, мы его все обсудили и согласны. С большим архитектором согласовано.
Kerman
01.07.2024 13:19+2Рефакторить все подряд под бизнес задачами — плохая практика.
В ERP-системе возрастом свыше 10 лет основная когнитивная нагрузка - это как раз бизнес-требования кого-то там когда-то. "Кто-то там" уже лет 5 назад уволился, другие люди по-другому думают, жизнь поменялась, поменялись требования. Ну и с приходом нового функционала старые блоки тоже начинают работать несколько иначе. Это нужно учитывать.
Собственно, рефакторинг обычно - это рефакторинг бизнес-логики. Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать. Ещё рефакторинг UI. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.
leotsarev Автор
01.07.2024 13:19Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать.
Жесть! А так если что получается взять и написать теханализ с «чтобы это реализовать, мы планируем выкинуть такой-то функционал, а вот этот упростить». И получить галочку от владельца продукта. Или от аналитика, который со всеми все согласует и возьмет на себя ответственность.
Kerman
01.07.2024 13:19+1Так я о том как раз говорю, что на этапе предварительной архитектуры это просто не видно. Это становится понятно на середине пути. Ну просто старая фича с новой не дружит. А иногда всплывают сотрудники со знаниями, которые не учтены ни мной, ни бизнесом. А ещё я просто не помню, что я писал, к примеру 8 лет назад и почему. И это тоже всплывает во время работы.
Ещё хуже планировать, когда берёшься за чужой легаси-проект. Там вообще непредсказуемые нежданчики выползают. И никто не может объяснить, почему так сделано и зачем.
Оно можно, конечно, на архитектора стрелки перекидывать. Моя проблема была в том, что я и архитектор.
leotsarev Автор
01.07.2024 13:19+1Где-то эту гонку легаси, в котором хрен разберёшься без залезания в код, надо остановить.
sshikov
01.07.2024 13:19+1Остановите. Я бы с удовольствием на это посмотрел, только этого не будет скорее всего.
У меня был замечательный опыт, когда реализация задачи, выраженная тремя строками кода (задача тоже была сформулирована несложно и кратко) через три месяца в проме чуть не вызвала убытки. После чего приняли решение реализацию откатить, а аналитики ушли на подумать на еще три месяца.
Потому что вам выше сказали - в больших легаси системах никто не знает, где отвалится жопа, если на пузе отвинтить гайку. В моем случае были задействованы четыре системы в двух сетевых зонах, соединенные примерно тремя шинами. Каждая с логикой. И вы можете сколько угодно залезать в код этих семи систем (шины - они тоже системы), только вы все равно не поймете бизнес логики, которая находится в шести системах из семи.
Ну то есть, я бы в целом скорее согласился с изложенными в вашем тексте мыслями, но в данной ветке комментариев вас пытаются убедить, что не всегда так можно. Иногда никто не видит системы в целом, нет такого архитектора в компании.
leotsarev Автор
01.07.2024 13:19Так, а по вашему из этой ситуации невозможно выйти? :-)
sshikov
01.07.2024 13:19Во многих случаях - да, невозможно. Во всяком случае быстрого простого способа выхода нет.
leotsarev Автор
01.07.2024 13:19Быстрого простого нет. Но вообще есть. Самое лучшее время начать описывать что происходит было в начале проекта. Следующее лучшее время сейчас :-)
sshikov
01.07.2024 13:19Какого проекта? Ну вот смотрите, в моем совершенно реальном примере задействованы 7 систем. Никакого такого проекта, который бы изначально предполагал, что их будет вот ровно столько и они будут делать вот такие вещи - его отродясь никогда не существовало. Одна из систем - это некий "фронтенд" к АБС Диасофт, который работает коннектором к шинам - потому что оная АБС никогда не предусматривала, что ее будут с кем-то так соединять.
То есть, вся вот эта архитектура - продукт многолетнего развития, начало которого я не застал, потому что это было возможно где-то в 90-х. То есть, этому всему, или самым старым из систем, возможно лет 30. Вы думаете, там остался кто-то из тех, кто изначально их проектировал? И грубо говоря, сегодняшнее (на самом деле я оттуда ушел лет 7 назад) состояние таково, что у каждой из 7 систем есть архитектор, но нет никого, кто мог бы это переварить все целиком. В том числе и потому, что целиком это слишком сложно. Вы думаете, почему аналитики на пару месяцев удалились? Потому что аналитики оного Диасофта ничего не знает о системе источнике Мюрекс. И вряд ли быстро сможет узнать, потому что она большая и сложная сама по себе. И наоборот так же.
Ну и да, сейчас это никому не нужно, по большому счету. Оно как-то развивается, и бизнес это как-то устраивает. А будет ли лучше - никто не знает, а проводить такой эксперимент слишком дорого. Всем хочется лучше - но никто не знает верного пути туда.
dabel1k0v
01.07.2024 13:19+8А вы молодец, заставили таки программистов написать ТЗ. Но с другой стороны, какой тогда толк от архитектора и менеджера?
leotsarev Автор
01.07.2024 13:19+1Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.
dabel1k0v
01.07.2024 13:19В моём понимании ТЗ это документ, на его основе можно посчитать бюджет, например. Так что менеджер может для написания не нужен, но для понимания, что будет делать разработка и сколько это стоит наверное имеет смысл.
nikolz
01.07.2024 13:19+1По-моему мнению, ТЗ это не только для расчета трудоемкости (стоимости), но и то, что конкретно должна делать программа, как ее и на каких данных тестить и что является критерием приемки ее заказчиком. Ну и конечно сроки и бюджет.
Вообще-то,в СССР был ГОСТ на ТЗ для программ. А сейчас очевидно все сами изобретают велосипед.
leotsarev Автор
01.07.2024 13:19Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
dabel1k0v
01.07.2024 13:19Почему аналитик не может это очевидно, он же никогда их не реализовывал. Сл-но эта роль тоже под вопросом, без бекграунда разработки или глубоких знаний предметной области
leotsarev Автор
01.07.2024 13:19+1Обычно аналитик как раз за предметную область и то, как с ее языка переводить на язык требований
dabel1k0v
01.07.2024 13:19Это какой-то фантастический пока для меня человек. Но тут возможно имеет место быть именно предметная область. Без навыков разработки/администрирования делать нечего
leotsarev Автор
01.07.2024 13:19+23.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
dabel1k0v
01.07.2024 13:19+2Я нахожусь в такой ситуации, что я ведущий разработчик (тим/тех лид, называйте как хотите), у меня есть 2 архитектора (второго наняли недавно), идущие как раз по описанному вами выше сценарию, и всё, то что вы написали у меня имеет место быть.
Роль консультирования/надзирания тоже я выполняю (в силу компетенций) вот и получается имею 2х людей, которые не пишут документы, не пишут код и фиг пойми чем занимаются.
Всё равно всё как раз лежит на разработке, они просто записывают наши задумки, не более, причём особо не вдаваясь в детали.
leotsarev Автор
01.07.2024 13:19+1Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
dabel1k0v
01.07.2024 13:19С записыванием мыслей пофиксил, стараюсь настраивать на генерацию собственных. Я выбрал неблагодарный путь обучения, хотя это не моё желание, надо было конечно нанять разработчика.
Для себя понял, что есть какие-то отклонения, но не то, чтобы они прям такие критичные и по большей части завязаны на коммуникацию между людьми, т.к. всегда будет чего-то не хватать.leotsarev Автор
01.07.2024 13:19Т.е. планируете заставить их все же придумывать все за вас? Думаете удастся? Я думаю нет.
dabel1k0v
01.07.2024 13:19Да хотя бы записывать научились в своих этих прямоугольниках ;) Нужно не заставить, а как вы, объяснить им полезность этого мероприятия, если это вообще возможно. В чём я сомневаюсь пока.
perlexed
01.07.2024 13:19+1Спасибо за статью! Я тоже в нашей компании начал в эту сторону склонять коллектив после того как на одном проекте начал зашиваться на код ревью, особенно после того как разраб уходил на несколько дней корпеть над задачей, а возвращался с MR на 50 файлов, половину изменений в которых нужно было отменять. Постепенно пробую распространить похожую практику на другие команды )
Batalmv
01.07.2024 13:19+1Классная статья, плюс и даже подписался
Идея, когда исполнитель должен "расказать" публично что будет делатьЮ, принципиально меняет отношение к вопросу. Можно сидеть, слушать, кивать, задавать вопросы - но ситуация меняется в корне, когда надо рассказать, как это будет от и до
Теперь надо думать, как это внедрить
Спасибо
SergeyPo
01.07.2024 13:19+3Waterfall описанный адептами Аджайл и Скрам и прочих -- не более чем маркетинговая страшилка. Этот вариант когда сначала ТЗ писали год, потом программировали два и т д конечно был, в случае разработки софта для спутников и самолетов и аналогичного оборудования, а разве там можно по другому? Так вот, вместо того чтобы работать рационально, как собственно люди делают зачастую даже интуитивно, менеджерам продали эту идею, что ну вообще не нужно ТЗ, документации и т д -- есть же великий Аджайл и прочее, все как то отрефакторят по ходу дела. Естественно, когда без качественного осмысления как правильно делать задачу, начинают делать что то, а потом переделывают, а потом снова переделывают, и в итоге тратят в пять раз больше времени, чем если бы было потрачена может всего 1 неделя на обдумывание архитектуры. А уж не описывать структуры БД может только оптимист, который никогда не работал с БД с сотнями таблиц. В общем, автор понял с опытом -- модные менеджерские технологии которые утверждают что ТЗ или документация не нужны, и все можно на следующем шаге отрефакторить и поменять -- не более чем набор красивых слоганов.
RH215
01.07.2024 13:19Waterfall описанный адептами Аджайл и Скрам и прочих
Waterfall как плохая практика описан за 30 лет до Agile Manifesto.
ну вообще не нужно ТЗ, документации
А причём тут скрамы с аджайлами? Отсутствие ТЗ и документации допустимо только в методе разработки "бардак на проекте".
SergeyPo
01.07.2024 13:19Ну так если Waterfall был описан как плохая практика за 30 лет до Agile Manifesto, зачем тогда во всех маркетинговых материалах по Agile и Скраму написано какой он плохой и как они с ним борятся?? Ну это как если бы создатели Питона или C# писали что они создали свои языки чтобы девелоперы не писали на ассемблере -- абсурд же, да?
leotsarev Автор
01.07.2024 13:19Ну БД с сотнями таблиц ныне считается антипаттерном. А так все правильно.
SergeyPo
01.07.2024 13:19+3И как же модно поддерживать непротиворечивость данных и атомарность транзакций в системах, где структуры данные не укладываются в пару десятков таблиц?
leotsarev Автор
01.07.2024 13:19А надо между сотнями таблиц, то есть десятками разных сущностей поддерживать непротиворечивость?
Как правило бизнесу в большинстве случаев достаточно eventual consistensy. Главное понять, где достаточно, а где нет :-)
Как вообще жить в таких системах моднейше можно прочитать в книгах по DDD. Эта моднота придумана кажется 30 лет назад :-)
AlexanderS
01.07.2024 13:19Так само название статьи как бы не просто намекает, а прямо вопит о том, о чем вы пытаетесь сказать)
Krasnoarmeec
01.07.2024 13:19+2А кто отвечает за срыв сроков, если в середине проекта выяснится, что проблема на много глубже, чем предполагалось? Архитектор, который не до конца понимает сложность фичи, или программист, который упустил в своём документе что-то важное?
VADemon
01.07.2024 13:19+1Чем эта ситуация отличается от ревью "да тут всё надо переделать, иначе в прод не пойдет!"?
Может я как-то иначе интерпретировал посыл статьи, но для меня предложенный здесь вариант -- озвучивание намерения, мыслей; набросок, черновик. Когда лучше заранее (не в конце ревью) услышать от коллеги, что через соседний модуль нечто делается просто, так-то и сяк-то. ("вот как просто оказывается! а мне теперь еще и переписывать >:/" гневно-соглашающийся смайлик)
Автор не единожды подчеркивает неформальность, это не строгий ТЗ на 15 страниц. А "мне кажется придется делать вот так, затронуть тех. Всё сходится?" И если мелочи меняются, обновляется текст, потому что он -- мотивировка на обычном языке. Если нечто большее, то опять за помощью, в дискуссии к тексту.
Я вижу в этом какого-то рода асинхронное парное программирование. Нет не парное, но приближенное к тому, что рядом был кто-то, кто с тобой согласился или внес пару корректур в твою задумку.
Krasnoarmeec
01.07.2024 13:19Мне непонятно в чём "плохость" услышать на ревью что модуль чем-то плох. Ревью же делается раз в неделю. За следующую неделю и исправится.
Как я понял текст, погер делает некие заметки по которым составляется архитектура и ТЗ. Мой вопрос был по поводу того, кого винить, если прогер ошибся в своих прикидках, а архитектор уже одобрил ТЗ и отослал заказчику. В статье о заказчиках вообще ни слова. Вроде как прогеры кодят для своего удовольствия, а архитектор талантливо указывает им путь в светлое будущее.
leotsarev Автор
01.07.2024 13:19Почему в середине проекта? В середине спринта.
Ну да, надо повторно уйти на теханализ. Такое бывает, и это ничем не отличается от «на ревью выяснилось что все надо переделать», только реже случается.
Krasnoarmeec
01.07.2024 13:19Ок. Кто виноват, если в спринте посередине проекта выяснится, что заказчику надо будет заплатить как минимум вдвое больше? И да, реальную сумму мы пока не знаем.
Отличие от ревью и "надо всё переделать" в том, что после ревью надо переделывать работу за неделю, да и то малую её часть. А в случае с глобальной ошибкой, надо будет пересматривать и архитектуру и менять код. Полностью.
leotsarev Автор
01.07.2024 13:19Все верно. В каком случае проще совершить глобальную ошибку в архитектуре? Если мы проверяем и обсуждаем ее заранее, до написания кода, или все изменения в архитектуре окажутся видны другим членам команды только на код ревью?
leotsarev Автор
01.07.2024 13:19А если вы продаете заказчику каждую задачу в отдельности (представляю такие контракты, это обычно типа поддержка какой-то системы и идёт поток мелких доработок), то вам каждую задачу надо оценивать. Соответственно и анализировать.
karrakoliko
01.07.2024 13:19По итогу во многих наших командах сейчас наличие теханализа является частью Definition of Ready — увеличение Cycle time окупается предсказуемостью и ростом общей производительности.
Как продавать это менеджерам которые не в состоянии видеть ничего дальше 1 спринта? Они не видят общего роста производительности, они видят что сегодня ты че то там думаешь, а мог бы и код писать
leotsarev Автор
01.07.2024 13:19Можно через оценки. А давайте все задачи оценивать, чтобы знать когда мы их сделаем. А для оценки нужно текстик написать небольшой. А если программист неправильно оценит, пусть за ним архитектор проверит....
todmax
01.07.2024 13:19+1Не нашел пункта про работу по "унижению" программистов за плохой код. Термин не мой, его неоднократно упоминали сами разработчики, ссылаясь на работу код-ревьюера, отдельно отмечая его эффективность.
Tiendil
01.07.2024 13:19В продолжении темы поделюсь парой своих постов.
Как у нас в команде практиковалось написание RFC: https://tiendil.org/ru/posts/two-years-writing-rfc-statistics с графиками, статистикой и комментариями.
Про мышление письмом в целом: https://tiendil.org/ru/posts/thinking-through-writing
gleb_l
Почему полезно перед экзаменом писать шпоры, даже если потом не брать их с собой? Потому что они содержат сжатую мысль и план ответа.
Предполагаемую же имплементацию можно и не (только) записывать, а заслушивать исполнителя перед группой - но сверяться с аудиозаписью, и даже транскрипцией гораздо менее удобно. Зато в аудиопризнании есть динамика и интерактив, как в игре в подкидного дурака - синфазные с докладчиком члены команды могут тут же накидать вводных, критики, или идей, которые тут же можно использовать. Когда задачи уже растащили по углам, и возвращаются обратно с листочками - все уже гораздо более спокойно )
leotsarev Автор
Мы пошли не путем «устная презентация с письменной шпорой», а путем «написать документ, и если нужно его презентовать». По итогам презентации можно поправить документ.