Комментарии 25
До того, как берете тикет в спринт планируйте что именно в API он изменит
Вы не учитываете один простой вариант задач: когда нужно ваш существующий API (это не обязательно именно API, это то, чем кто-то пользуется, например, формат файла) в результате разработки упростить, или сделать удобнее. И мы заранее не знаем, как именно. Т.е. это исследовательская задача, цель которой попробовать разные варианты, и выбрать лучший. Причем если бы он заранее был очевиден — такой задачи вообще бы не стояло, а так обычно на входе есть пара идей — но они представляют из себя компромиссы, т.е. у каждой видны достоинства и недостатки.
правило один “тикет один PR” все же существенно упрощает управление командой
С точки зрения управления зачем вам уменьшать число PR? Ради чего?
уровне PR контролировать что вошло в релиз
Вот это — не очень хорошее объяснение. Вот у нас скажем JIRA интегрирована с PR, и я считаю что так и должно быть. Поэтому мы просто знаем, что PR по задаче были, и было их скажем два. Ну так и что? В релиз должны войти либо оба, либо ни одного. Не особо видно, где правило одного PR что-то там упрощает. Если у вас что-то может в релиз не войти — это всегда так или иначе сложности.
когда нужно ваш существующий API (это не обязательно именно API, это то, чем кто-то пользуется, например, формат файла) в результате разработки упростить, или сделать удобнее. И мы заранее не знаем, как именно
В таком случае надо сделать отдельную задачу на решить как упростить, закомитить драфт новой доки, посмотреть на это с коллегами и взять в следующий спринт. Там в статье про это немного есть.
С точки зрения управления зачем вам уменьшать число PR? Ради чего?
там прям ниже пример. Атомарность изменений это прям краеугольный камень в больших системах.
Без примера статья не работает совсем.
Поделитесь опытом.
Бизнес говорит: "мы хотим, чтобы можно было настраивать минимальное и максимальное количество часов брони нашей штуки".
Реализация фичи "сделать так, чтобы период времени, выбираемым пользователем в форме, был не меньше чем X и не больше чем Y, в случае неверного значения вывести ошибку, X и Y должны определяться в админке" затрагивает кучу всего и везде, от юзер интерфейса до бд.
До какой степени разумно дробить эту задачу?
Как поступили бы вы?
Так это не работает. Надо на архитектуру смотреть, на то как команда работает. Какие внешние условия.
Я к тому, что реальный пример надо рассматривать вот прям с командой, диаграммой компонент и если речь идет о незнакомой системе, то прям с кодом.
Если ответ реально интересне, а не для докопаться, то могу дать совет - нарисуйте диаграмму компонентов, data flow и потом на ней стрелочками нарисуйте как пойдут изменнения и где изменения надо делать одним махом.
Поймите правильно - на прошлой неделе вот буквально разбирал похожее с одной из команд. При том что я знаком с системой и у меня под рукой был исходный код, в режиме звонка с показом экрана это заняло больше часа.
Если только добавить настройку в админ (как у вас и написано), то это один тикет и вполне простой, без изменения БД. Если реализовать саму возможность брони, то это другое дело.
Большой/маленький аккаунт
Лучше писать - большой/мвленьний проект. Делеко не у всех есть аккаунты.
Прилагательное "гранулярный" имеет обратное значение - состоящий из зёрен, мелких комочков, гранул, существующий в виде гранул. Надо заменить на другое слово.
Estimates responsibly / minor developers infinity
Заголовок не понимается, от слова совсем. Надо поменять. И вообще, лучше или все заголовки по-русски, или все по-английски.
не знает, как ее делать и не знает, как ее делать
Ааа? Что это было? Вообще, в тексте много нестыковок по падежам, числам и т.д. Надо почистить.
Насчёт один PR для одного тикета. Часто разработчик делает много (реально много) PR-ов в Dev ветку по разным причинам:
1) знает, что эти же файлы кто-то меняет сейчас и не хочет потом возиться с проблемами слияния.
2) после первого PR-а выяснилось, что что-то реализовано не так, чего не было указано в описании тикета, или разработчик просто ошибся, дальше идёт исправление, потом ещё исправление и так далее.
Насчёт слов "улучшить" и других, буквально на последнем проекте это было просто бичем в моей работе. Например мне давали такие тикеты "страница такая-то реализована плохо, надо улучшить". На вопрос, что конкретно плохо и что улучшить, был ответ "ну ты поиграйся с функционалом, сам поймёшь". Просто ужас ужасный)
Насчёт один PR для одного тикета. Часто разработчик делает много (реально много) PR-ов в Dev ветку по разным причинам:
Вот это для меня важный урок который я выучил лет 5 назад во время работы над большим репозиторием. Так как вы описываете можно работать только в очень сильно контролируемом окружении. Т.е. вы точно должны быть уверены, что PR пойдет в прод. А если нет? Будете откатывать частями?
Просто как пример - процедура ревью PR может быть такая
Я делаю фичу в ветке, тестирую, показываю команде
Апрув
Создаю PR строго на то что показывал
PR рассматривают, скажем дня 2. Оставляют комментарии, я что-то в PR фикшу
PR проходит серию сканов скажем сонаром
После всего этого делаем merge
.. далее идет несколько веселых шагов но я про них не буду
Частичный PR c "полработы" буедт послан нафиг на шаге 1.
Это несколько занудно но на большом объеме дает гранулярность и предсказуемость изменений.
UPD чистить надо, но я что-то забодался и понял что надо публиковать либо сейчас либо после отпуска который будет фиг знает когда, в ноябре наверное. Долго мариновать статью плохо. Давайте считать что кому надо через chat GPT прогонят. Я в общем все равно не для рейтинга пишу, а чтобы потом эти статьи коллегам как туториал давать. Такое прикладное писательство
Спасибо что в открытый доступ выкладываете, очень интересно с практической точки зрения! А то по таким темам много воды и диванных теоретиков.
Да тут беда в том что сейчас писательство статей вышло в довольно специфический жанр и то что я пишу в общем пользы мне почти не приносит. Так экономия времени, чтобы была возможность команде ссылку послать.
А то что пишется с профессиональными целями - пишется несколько иначе и про другое. Так то у меня тема вообще ни разу не хайповая.
Частичный PR c "полработы" буедт послан нафиг на шаге 1.
Это несколько занудно но на большом объеме дает гранулярность и предсказуемость изменений.
И опять, несмотря на объяснение, я вижу, что термин гранулярность используется неправильно. Для гранулярности как раз чем больше PR-ов, тем лучше - больше гранул. А у вас же атомарность, скорее, в смысле внешняя неделимость изменений по конкретному тикету в Dev ветке.
Насчёт множества PR-ов, я тоже немного спутал - было много их в ветку самого тикета (feature-branch). Но и в dev бывало, что фиксили потом какие-то неожиданно всплывшие проблемы.
Прилагательное "гранулярный" имеет обратное значение - состоящий из зёрен
:-) как раз это и имеется ввиду. Изменения не паста которая давится из тюбика, а гранула одна за другой.
Мне кажется вы в погоне за тикетами упустили работу бизнеса, в частности:
Где простите Epic о котором вы вскользь упоминаете (путь пользователя от появления потребности до его удовлетворения)
Где у вас спряталась Story. Она позволит Epic разбить на понятные куски (декомпозиция, которая должна прийти от РП или PO)
Где стандартный пул задач при разработки любой системы по любой методологии (бизнес анализ, системный анализ, база данных, бэк, фронт, тестирование)
Мне кажется это более чем достаточно, данный подход сработал в команде 40 человек, уверен у вас он так же сработает
Статья немного про другое. Все о чем вы говорите можно делать сильно по разному и не во всех проектах есть РП и РО (не знаю, даже, что это значит).
PO это владелец продукта, исправился)
Ну обычно после прочтения пары учебников как раз то о чем вы пишете внедярется. Но вот дальше может начаться цирк с конями т.к. наличие эпиков и PO не гарантирует того что в эпиках не будет ереси. Собственно моя статья тоже не гарантирует, но я стрался дать какие-то более конкретные критерии.
Скажу за себя, я Epic прям заполняю
Пишу шаги по бизнес процессу (нарезаю Story)
Всегда оформляю сам процесс и согласовываю с заказчиком (мера необходимая, позволяет сформировать рамки реализации)
Ещё из грехов, Баги от поддержки связываю с Epic, так мониторю настроения пользователя)
Скорее всего так делают не все( Наверное в связи с этим негативный опыт
Ну вот глядите - заполнили вы Эпик, Story расписали. Система у вас состоит из скажем 20 сервисов и еще скажем 5-и библиотечных репозиториев. И то что расписано в эпике отражается на скажем 4-х из них.
Если от эпика не сделать фазу планирования - что где и как менять то получается месиво даже при идеальных эпиках.
Все это дело сильно еще зависит от архитектуры и предметной области. Если у вас 3-х звенка и какое-то form/data driven приложение то истории определяют реализацию на 90%. А если платформа с дюжиной интеграций, на микросервисах, то там все намного интереснее
А почему PO по-английски и тут же рядом некий РП по-русски? Сидишь тут и гадаешь, "кто все эти люди".
Прочитав статью так и не понял, как вы все делаете. Для работы вам нужно четко понимать для чего используется эпик, какие типы задач есть, кто какие артефакты заполняет и для кого, чтобы каждый, кто получил задачу мог проследить от куда она взялась и кто является источником информации для ее выполнения.
Хотелось бы увидеть что-то вроде:
Эпик - в эпике описывается бизнес функция для реализации. Часто в качестве описания в эпик погружают копипасту из ТЗ. Ответственный PM.
PM, добавляет в него задачу для BA на разработку постановки.
BA написав постановку добавляет задачу на SА, если он есть.
SA в свою очередь добавляет задачу на лида разработки.
Лид разработки уже делит задачу на отдельные задачи по команде разработки. А когда все задачи закрываются добавляет задачу на тестирование.
Тестировщик добавляет баги, баги закрываются и т.д., пока эпик - т.е. функция, полезная для Заказчика не будет готов и не уедет в релиз.
Спасибо, это прям хорошее замечание, если с силами соберусь - в выходные добавлю к статье.
То о чем вы пишете это ортогональное изменение. Можно как вы описываете, можно еще десятком других способов.По опыту скажу, тот способ который у вас описан не самый эффективный в нем есть много подводных камней. Скажем SA у вас являет узким местом во всей этой системе. Но это не существенно.
Я пишу о том, что вне зависимости от того как вы эти тикеты туда сюда по доске двигаете и каких они у вас имеют типы, разбиение задач на тикеты должно быть определенного качества.
В строго иерархических системах, особенно в inhouse этот аспект не виден т.к. там часто роль равна фамилии и качество такое, какое оно есть.
Публикации
«Правильные JIRA issues». Как правильно разбивать задачи на тикеты