Всем привет!

Наверняка многие слышали про практику 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