Всем привет!

Наверняка многие слышали про практику TDD - Test Driven Development. У которой есть некие сложности с применением. Напомню, ее суть не только и не столько в том, что тест должен предшествовать коду, а в сокращении врени итерации - тест-код. Т.е. в идеальном случае надо делать так:
1) простейший тест
2) код с заглушкой, позволяющий пройти тест
3) новый тест
4) усложнение заглушки
...
N) финальный работающий код
И коммитить желательно почаще.

Самое сложное здесь - заставить себя не писать сразу кучу тестов или весь метод сразу. Или даже весь класс + ряд зависимых классов, а идти мелкими шагами.
Сам пробовал - сложно)
И от одного из создателей XP Кента Бека есть решение - TCR https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864
Расшифровывается как test && commit | | revert.

Суть в следующем:
1) к запуску тестов привязывается команда git
2) если тесты успешные - git commit
3) если тесты упали, то коммитить неработающий код нельзя, потому делаем revert в виде git reset --hard
Только хардкор!)
4) в паралльном потоке работает цикл
while (true) {
git pull --rebase
git push
}
синхронизируя изменения других разработчиков.

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

Пример использования на практике с реализацией shell скрипта "test && commit | | revert":
https://medium.com/@tdeniffel/tcr-test-commit-revert-a-test-alternative-to-tdd-6e6b03c22bec

Что думаете?

#Agile #XP #TDD #TCR

Всем привет!

Интересный и выглядящий логичным подход к оценке задач в Agile нашел вот тут https://www.youtube.com/watch?v=vk6dl7-3B5I
Наверное большинство тех, кто сталкивался с Agile, знает о Story Point.
В чем их проблема:
1) авторы методологии Scrum не предполагали использования Story Point для оценки задач внутри спринта
2) они плохо применимы для оценки задач разной природы: бэк-разработка, фронт-разработка, аналитика, тестирование - всей командой. Зато хорошо подходят для оценки сторей и эпиков, которые с течением времени становятся похожими
3) спринт имеет четкую дату окончания, а story point по определению не должен быть завязан на время. Да, есть burndown chart, он может показать что, что-то идет не так. Но не может показать что именно. На это тратится время команды на дейли\ретро
4) размер story point может быть разным у членов команды из-за разного бэкграунда, что снижает точность оценки
5) абстрактность story point не дает понимания сроков как для бизнеса, так и не способствует взаимодействию внутри команды для подстройки порядка задач для выполнения целей спринта

Альтернатива - capacity planning, о нем говорится в ролике. Эта техника решает все проблемы, указанные выше. Хотя и сложнее для внедрения.
Да, еще есть диаграммы Ганта, о них тоже говорится в ролике. IMHO можно считать данную технику гибкой версией Ганта

#agile #scrum

Всем привет!

Хочу сравнить разные способы оценки задач в разработке.

1) «честная» трудоемкость. Честная я взял в кавычки не потому, что она не реалистичная/оптимистичная. А потому, что на самом деле она в большинстве случаев не честная, т.к. не устраивает риски и фокус-фактор. Пример рисков: нечеткая постановка задачи, сломавшаяся локальная сборка, сломавшийся pipeline, неработоспособность стендов, проблемы у смежника, болезнь. В теории даже про то, что часть спринта попадает в отпуск можно забыть) Пример не учета фокус-фактора - часть времени участника команды тратится на Agile церемонии, на отдых в рабочее время, менторство, код-ревью, помощь коллегам, семинары, митапы...
Собственно, по этим двум причинам чистая трудоёмкость совсем не равна календарному времени. И поэтому это самый плохой способ оценки. Из плюсов - только простота.

2) оценка с учётом рисков и фокус фактора. Подходит для экспресс оценки задачи до передачи ее в команду. Это может быть или типовая задача для нескольких команд, например, миграция, или просто сложная и важная задача, еще не распределенная в команду.
Главный минус данной техники - зависимость от опыта конкретного эксперта и отсутствие учета особенностей команды. Но для экспресс оценки это не важно.
Особое внимание стоит обратить на прозрачность используемых повышающих коэффициентов. Иначе эти коэффициенты будут дублироваться на каждом уровне иерархии компании, что приведёт к экспоненциальному росту финальной оценки

3) story points. О минусах этой методики писал ранее https://t.me/javaKotlinDevOps/104
Плюсы: учет особенностей команды (velocity), оценка непосредственно исполнителями, согласование внутри команды.
Хорошо работает для оценки story, кроме первого релиза, т.к. со временем у опытной команды story должны стать похожими. Также хорошо работает и для задач внутри спринта при выполнении 2 условий: команда fullstack разработчиков и участники примерно одного уровня. Ну или когда в команде для большинства участников выполняются эти условия. Иначе мы получим, что из 8 человек, оценивших задачу по бэк разработке, только 2 примерно понимают ее трудоёмкость) Или в команде из 1 сеньора и 4 джунов оценки будут сильно смещены к уровню джунов, и сеньор часть времени будет «курить бамбук»)

4) capacity planning.
Решает большинство проблем story points. Вводится коэффициент фокус-фактора, причём оценка даётся со стороны исполнителя. Вводится коэффициент «сеньорности» для учёта разницы в опыте. Команда делится на группы: бэк, фронт , аналитики, тестировщика, оценка идёт только внутри группы. Сразу видно, когда не хватает трудоёмкости конкретной группы, например, тестировщиков, для выполнения задачи «под ключ» за спринт. Т.к. оценка в человеко-часах - проще понять, где затык внутри спринта и больше личной ответственности. При этом все плюсы story points сохраняются.
Соответственно, хорошо подходит для оценки задач внутри спринта.

5) диаграммы Ганта.
Главный плюс - учёт взаимозависимостей задач и наглядное представление точки во времени, куда сходятся все задачи.
Главный минус - сложность и необходимость ПО. Сфера применения: макропланирование на несколько команд для сложных интеграционных задач.

#planning #agile

Всем привет!

Agile сейчас стал мейнстримом. Большинство из моих знакомых работают в Agile командах, почти все соискатели на собеседованиях либо работают по Agile, либо как минимум знают, что это такое.
И Agile, в частности SCRUM, как самая распространенная его реализация - это очень крутая и полезная методология.
Хороша она как следует из названия гибкостью - т.е. развитие продукта можно корректировать каждые две недели, а не раз в квартал или полгода. С учетом скорости изменений в современном мире - это killer feature.

Но как говорится есть нюанс.
У SCRUM (Agile) есть фундаментальный косяк. Изначально методология разрабатывалась под процессы одной команды. 7-10 человек. Так сказать сферическая команда в вакууме.
Команда тесно взаимодействует с бизнес-заказчиком, целиком отвечает за продукт, вовлечена в процесс и итеративно выдает результат. Предлагаю рассмотреть ответственность команды за продукт.
Когда команда одна - да, она за него 100% отвечает. А если команда - часть большой компании? Где продукт выводится в рамках какого-то большого мобильного приложения или сайта, т.е. канала. Канал, а точнее подразделение, за него отвечающее, предъявляет ряд требований к продуктам. У компании есть своя платформа, обязательная к применению. Плюс ряд таких же обязательных требований по архитектуре, надежности и кибербезопасности, выполнение которых контролируется. Единые требования по дизайну и текстовкам. В конце концов в компании множество источников данных, т.к. активно используются микросервисы. И при этом запрещено дублирование бизнес-критичного функционала, т.е. за доработками нужно идти к смежникам. Замечу, что в последнем требовании нет ничего плохого, та же DDD (надеюсь я пока не надоел вам с ней) требует того же.

Итог такой - команда не отвечает за продукт на 100%, т.к. у нее куча смежников, выставляющих свои требования. А значит ломаются многие базовые Agile принципы, например, выпускать релизы, доставляющие реальную бизнес-ценность, каждый спринт становится проблематично.
А что SCRUM - в своей исходной версии он этот вопрос никак не регламентирует.
Как в анекдоте - к пуговицам претензии есть?)
Да, есть другие фреймворки для масштабирования Agile - Scrum of Scrum, SAFe, LESS... Вот небольшое их сравнение https://vc.ru/hr/100292-freimvorki-masshtabirovaniya-agile-na-kompaniyu Еще есть Sbergile https://habr.com/ru/companies/sberbank/articles/547036/. Последний подсказывает нам, что в теории другие большие компании также могут заводить свои фреймворки. Отсюда главный минус такого подхода - получаем зоопарк фреймворков, которые в целом похожи - https://habr.com/ru/articles/726302/ - но естественно имеют и отличия.

Итого: главный минус SCRUM - он изначально создавался под условно "стартапы" из одной команды. При этом ИТ рынок формируют компании с тысячами и даже десятками тысяч разработчиков: Google, Microsoft, Amazon, Yandex, VK, Сбер.

#agile #scrum

Всем привет!

В продолжение темы Agile.

Как решение данной проблемы можно было бы предложить даже в большом enterprise работать как множество независимых Agile команд.
В теории это возможно если:
1) в организации мало требований и стандартов, команды имеют высокую степень автономности
2) существующие проверки автоматизированы, степень автоматизации стремится к 100%
3) процедура приемо-сдаточных испытаний автоматизирована или отсутствует
4) команды разрабатывают функционал End To End - от фронта до БД
5) сопровождение ПРОМ находится в команде, как вариант - разработчики отвечают за сопровождение
6) допускается, хотя бы временно, дублирование реализации, если команда, разрабатывающая целевой функционал, не готова доработаться вовремя

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

Для больших компаний, переходящих от водопада к Agile приходится придумывать что-то свое или искать подходящий фреймворк. Фреймворков много, какой лучше подходит - не понятно....

#agile

Всем привет!

Я уже подымал тему готовых архитектурных решений, а точнее их отсутствия в большинстве случаев https://t.me/javaKotlinDevOps/134
Хочу развернуть тему с другой стороны.

Стоит ли тратить силы на поиск целевого архитектурного решения?

Написал эту фразу, и понял, что не всем она может быть понятна) Расшифрую. В больших компаниях ака "кровавый enterprise" есть некий список разрешенных технологий и архитектурных принципов. Оформленный в виде техрадара, карты технологических стеков и сборника архитектурных стандартов. Это и есть целевая архитектура.

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

Так вот - а надо ли его искать? Несмотря на то, что ответ вроде бы очевиден, хотел бы подсветить несколько потенциальных проблем.

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

К чему это приводит? Мы потратили время на выбор и реализацию "целевки", а через год нам говорят - переделывайте. Отрицание, гнев, фрустрация. Обида на архитекторов. Причем даже если архитектор признает ошибку (и вообще эта ошибка была) - вряд ли он поможет переписать код. Обида на менеджеров - да они издеваются что ли, вечно меняют правила игры, вечная миграция... Желание сменить компанию...

Поэтому видится, что есть более надежный подход.

1) смириться с тем, что все течет, все меняется, и миграции будут всегда

2) искать целевые решение, но всегда держать в уме, что это целевое решение на данный момент

3) разделить весь код на ядро и инфраструктурный код. Ядро стараться писать на чистой Java \ Kotlin, с минимальным использованием фреймворков. Особенно, внутренних, которые еще не доказали свою стабильность. Внешние интеграции закрывать - предохранительный слой (anticorruption layer), шлюзы (gateway), адаптеры.

4) очень важно - уметь и хотеть быстро выпускать релизы, разбивать любые доработки на небольшие инкременты. Это можно сделать как улучшением качества проектирования, увеличением покрытия тестами и автотестами, так и различного рода договоренностями со смежниками, (не забываем, что мы в "кровавом enterprise")

Если вам показывался знакомым последний пункт - то да, это Agile. Или то самое снижение Lead Time (LT), о котором любят говорить менеджеры. И не только говорить) Но в данном случае они правы.

Еще пример - фондовый рынок и диверсификация. Диверсификация считается основным принципом разумного инвестора, и означает, что нельзя "класть все яйца в одну корзину". Т.е. нужно покупать разные классы активов: акции, облигации, вклады, кэш, золото, недвижимость. Причина - сложно угадать, что именно "выстрелит". В случае кода сложно конечно реализовать диверсификацию прямолинейно: часть данных хранить в PostgreSQL, а часть - в Oracle. Да и не нужно. Но предусмотреть возможность замены поставщика - нужно.

#agile #arch #arch_compromisses

Таска или баг - в чем разница?

Недавно прочитал интересную мысль у Егора Бугаенко - https://www.yegor256.com/2025/05/25/bug-driven-development.html
И как всегда, она не только интересная, но и провокационная)

Суть - давайте откажемся от типов задач, и все, в т.ч. и таски сделаем багами. Мотивация - баги в любом случае нужно править, а таски - ну такое. Таску можно поморозить в бэклоге на несколько месяцев, а потом выкинуть под соусом: уже неактуально.
Да, вопрос можно ли такое сделать конкретно в вашей организации - оставляю за скобками. Раз нельзя, то нельзя)

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

Но с другой стороны - мотивированная команда здесь первична. Если команда не хочет брать таску - она отобьет ее в любом виде. CR, таска, баг. Т.е. улучшить Lead Time и навести порядок в бэклоге это не поможет. Если команде удобнее работать только с багами - ок. Но продвигать такую практику как решение проблем - сомнительно, не ок)

#task_management #agile

Agile мир победил, микросервисы оказались сильней)

Вот данные из моей любимой книжки по разработке.

Процентное соотношение проектов по размеру команды:

Размер команды  | Доля
----------------|------
1–3 человека    | 25%
4–10 человек    | 30%
11–25 человек   | 20%
26–50 человек   | 15%
>50 человек     | 10%

Источники: Beck and Perkins (1983), Highsmith (2002), Boehm and Turner (2003)

Медиану можно оценить ~9, среднее ~19, но среднее мало информативно из-за сильной правой асимметрии (маленьких команд сильно больше, чем больших).

Я бы из него сделал вывод, что микросервисы были всегда, просто раньше назывались по-другому — например, SOA (Service Oriented Architecture).
Но конечно ситуация меняется (хотел написать «не могла не измениться», но вспомнил свой же пост про двойное отрицание))).

А вот более современные данные, не такие подробные.

В исследовании Rodriguez et al. (JSS, 2012) на базе 951 проекта — 75% имели команду менее 10 человек. Медиана = 5, среднее ≈ 7.9.

Если сравнить 2003 и 2012 годы — медиана уменьшилась почти в 2 раза: 9 → 5.

Ещё есть данные опроса пользователей JetBrains (2024) https://www.jetbrains.com/lp/devecosystem-2024/

Размер команды  | Доля
----------------|------
1 человек       |  8%
2–7 человек     | 49%
8–12 человек    | 22%
13–20 человек   | 10%
21–40 человек   |  6%
>40 человек     |  5%

Медиана ≈ 6 человек, среднее ≈ 11. Примерно то же, что в 2012, только как ни странно числа стали чуть больше). Зато видно, что больших команд стало в 2+ раза меньше.

По моему опыту (кровавый enterprise) медианный размер команды на данный момент выше, ближе к 9. Но то, что 80% команд укладываются в 12 человек — сходится.
В 2003 году было ~60%.
Т.е. мы пока одной ногой шагнули в новую эру) enterprise требует жертв. Но тренд понятен.

О причинах — часть уже назвал: Agile и микросервисы. Ещё — улучшившийся инструментарий: IDE и фреймворки/библиотеки под любую потребность. А сейчас ещё и AI.

Так что думаю, что к 6 людям в команде мы все скоро придём. Будет ли меньше? В теории да: ВП, аналитик, 1–2 разработчика, тестировщик.

P.S. Т.к. в таблицах процент команд, а не процент людей - в командах более 12 человек все еще работает более 50% разработчиков. Было - более 80%. Интересно кто это?

P.P.S. Станет ли медианным значением 1 — ВП, который с помощью AI пилит и тестирует сервисы сам? ...Где-то да, уже сейчас. Но массово — может помешать Skynet. Или поспособствовать — сидишь себе в матрице, вайб-кодишь с AI микросервисы.

#book_review #agile #ai #microservices

Что такое Agile для разработчика?

Возьмем SCRUM, как наиболее типичный его вариант.

IMHO конечно.

Это не церемонии - Daily, планирование, ретро, демо.
Не наличие Scrum мастера в команде.
Это красивый burn-down chart и velocity.
Не poker planing и оценка в story point.
Не работа с досками.
И даже не работающий инкремент каждую неделю.

База - это две вещи:

1) навык декомпозиции задач.
Который приводит к небольшим инкрементам.
А конечные цели:
- минимум зависимостей от других
- маленькие PR = быстрое ревью и вливание
- инкрементная интеграция кода = возможность вливания в целевую ветку и отправку на тестирование без ожидания других доработок.

2) точность оценки задач.
Не важно в чем - в story point, человеко-днях или в конкретных датах.
Оценка, кстати, зависит от декомпозиции, т.к. мелкие задачи можно оценить точнее, а потом оценки просуммировать.
Конечная цель - совпадение прогнозируемых сроков с реальными.
В данном случае речь про сроки этапа разработки, за соблюдение сроков интеграции со смежниками отвечает PO, DL и команда в целом.

Не всегда эти цели достижимы на 100%, но ставить их нужно. Если их себе ставить, то навык рано или поздно появится.

И традиционные ответы на не заданные вопросы)
Вопрос: "А разве это не навыки сеньоров?"
Ответ: когда-то возможно да, но с учетом последних тенденций (не могу не вставить AI в пост) кажется всем надо повышать уровень "сеньорности".

#agile

Чем нам конкретно поможет AI?

В данном случае я говорю про помощь в разработке.
Уже писал про написание, а главное поддержание актуальности в документации https://t.me/javaKotlinDevOps/565

Теперь пришло время поговорить про другую важную штуку - TDD.
Что это - Test Driven Development - я думаю знают все.
Знают, но не используют.
Почему?

Особенно хочу подчеркнуть один момент.
С кем бы я не говорил на эту тему - общаясь по работе или на собесах - никто не сказал: "Да фигня этот ваш TDD".
Все знают, все пробовали, но никто не применяет на работе.
Почему?

Ответ видится таким.
Есть задача. Есть ограниченное время. Которое можно потратить на проектирование, кодирование, тесты, отладку, документирование.
Есть такой закон с немного странным названием - закон Паркинсона.
Он гласит: «Работа заполняет всё время, отведённое на неё».
И он применим в ИТ) Увы(

Так вот - что в первую очередь будет выкинуто, чтобы успеть вовремя?
Очевидно документирование и тесты. А оптимизировать тесты (и документацию) проще, если они запланированы на самый конец. И прощай TDD(
Да, все понимают, что тесты - это хороший способ документировать код, это помощь при будущих рефакторингах, это сетка, предотвращающая сползание в легаси.
А TDD - способ гарантировано иметь тесты и тестируемое Java API.
Но ... нет времени.
А далее сервис медленно, но верно превращается в легаси.
Вспоминается грустный анекдот: "... А чё тут думать! Трясти надо!"

К чему я веду?
AI уже берет на себя большУю часть кодирования. AI быстро пишет код.
AI не лень писать тесты.
Точнее как - конечно же лень, любая LLM модель натренирована на получение быстрого результата, это экономика.
Но вопрос решается правильным промтом (контекстом или скилом если быть точным).
И режимом рассуждений (reasoning), предотвращающим забывание агентом правил игры.
Собственно, уже есть фреймворки, например, упомянутый мной https://t.me/javaKotlinDevOps/589 superpowers, в котором TDD встроен как обязательная часть процесса разработки:
brainstorm-планирование-TDD-ревью-commit.

Итог: документирование и TDD - две вещи, которые разработка с AI перемещает из области "надо, но мы не успеваем" в базовую практику.

#ai #tdd #agile #documentation