Жизненный цикл задачи после разработки

[Julia_cat]

Очень полезная статья! Подсвечены важные моменты ?

[AndGry]

Проблема актуальная, да.

Но решение выглядит как-то громоздко и контринтуитивно.

Лично я, когда уже завершаются все доработки и трогать код постоянно не требуется, помечаю его как fixed (даже каталог, чтоб не спутать) и описываю в ChangeLog основное, что нужно помнить. И потом, когда внезапно нужно что-то переделать, снимаю fixed, и по новой. Если это уже Legacy или Dead, указываю в том же ChangeLog. Хотя не знаю, может в коллективной работе не получится всех заставить вести ChangeLog, я-то все в гордом одиночестве пилю )

[titanium007]

Насчет громоздко может быть, но как раз-таки пришли к этому интуитивно, основываясь на часто встречающихся проблемах. Подход опробован на достаточно больших и долгих проектах и разношёрстных командах

[zaitsevyan]

На некоторых моих проектах это решалось изменением типа задач, а именно использованием эпиков для фич, или отдельной Story для фичи к которой линковались все остальные. И задача для разработчика была именно разработать и замержить.
А дальнейшая раскатка, A/B тестирование, сбор результатов и аналитики - это уже были совершенно отдельные задачи для других людей которые линковались все к тому же эпику/истории фичи. И если необходима дополнительная разработка - создавалась новая задача для разработчика. Главное правило - если пулл реквест замержен - задача для разработчика закрыта. Если нужны исправления - открыть новую задачу / баг репорт

[titanium007]

Все правильно, так и есть. Я хочу в акцентироваться на том что какой-то глобальный эпику/сторик должен пройти весь флоу. Прибинтованные задачи для аналитиков/дизайнеров/разработчиков могут иметь отличный форкфлоу в таск трекере