Home

Автор: Чистяков Вадим
Оригинальная публикация

Фича = задача и далее по тексту :-)

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

Как правило, разработка получает от продакт-менеджера техническое задание на разработку новой или исправление старой функциональности. Например, это выражено в виде PRD, который может содержать ссылки на Figma, список требований, ссылки и прочие полезности, необходимые для реализации задумки. Исходя из этих входных данных, разработчики могут имплементировать задачу и отдать на тестирование в QA команду. По завершению этих циклов задача готова к релизу.  

После разработки

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

Проблема, присущая многим

После того, как задача реализована, наблюдается тенденция, что она пропадает из поля видения разработки. На первых этапах в продакшене она может быть закрыта Feature toggle или доставляться до пользователей через A/B тестирование. Часто бывают ситуации, что не так-то просто раскатить фичу, реализованную несколько месяцев назад, и, тем более, через A/B тестирование. Обсуждения в мессенджерах или на митингах не решают проблемы быстро. Прежде всего, как мне кажется, это происходит из-за отсутствия наглядности процесса работы с уже реализованными фичами и наличия проблем с ними. В том числе, мы перекладываем ответственность за эти действия друг на друга. Таск трекер для разработчиков/тестировщиков зачастую не содержит статусов после "Done".     

Почему это вообще является проблемой?

Процессы устроены таким образом, что задачи = гипотезы и проверять их хотят через А/B тесты. Нередко тесты запускают последовательно, ведь аналитики тоже имеют ограниченный ресурс и фокус. При таком подходе некоторые тесты встают в очередь на "раскатку" и будут доступны пользователю спустя несколько месяцев, хотя исходный код был вмержен в предыдущие релизные версии приложения. Основные этапы отладки и тестирования могут стать неактуальными из-за длительного временного простоя, выпуска других аффектящих фичей и изменений на backend'e, в таком случае требуются доработки и выпуск новой версии сайта или приложения. Но, как мы помним, у задачи статус "Done".

Что нам делать в таком случае? 

Наверное, можно вернуть тикет в таск-трекере в статус "In progress" и провести задачу по циклу заново, но, на мой взгляд, так делать не совсем корректно. Так как мы уже решили однажды проблему, описанную в задаче, а сейчас нужно решить другую задачу, и мы предъявляем к ней другие требования. Следовательно, лучше создать еще одну и в ней отобразить проблемы, которые возникли при выпуске первой, и пройтись с ней по привычному циклу: 

Но решает ли этот процесс базовую проблему? Думаю, что нет.   

Корневая проблема заключается в том, что общепринятые статусы в таск-трекере (Jira, Trello) для разработки не отображают полный жизненный цикл фичи.  

Как можно это поменять? 

Шаги до разработки я не буду детально описывать, так как они в меньшей степени влияют на исходную проблему. 

Предлагаю формализовать этот процесс. Как вариант, завести доску в Jira со статусами, начиная от идеи до деинтеграции ненужной фичи. 

Кто-то может возразить: зачем разработчикам вообще следить за этими процессами? Ведь мы пытаемся взять на себя чужую роль release manager'a или project manager'a. Попробуем в этом разобраться. 

Что, если задача после релиза будет перетекать на другую доску? Хотелось бы увидеть статусы и некий прогресс, а также назначенного исполнителя на том или ином этапе.

Возможные пункты, которые могут присутствовать у нашей новой задачи:

• Дата релиза

• Версия приложения для ios/android

• Инфо по A/B тесту

• Cроки проведения

• Описание группы А и группы B  

• Результаты A/B теста

Допустим, с таким workflow:   

Попробуем разобрать каждый статус отдельно и определимся, какие данные для каждого статусы наиболее релевантны.  

• Released. Фича есть в продовой версии (номер версии). Закрыта ли Feature toggle'ом? Может быть ситуация, когда задача со стороны клиентской разработки готова, но backend или админка не отдает актуальные и нужные данные (актуально для Backend Driven UI или Server Driven UI подходов);

• Opened for all. Фича доступна всем с определенной версии приложения (сайта). Означает, что она не проходила A/B тестирование и стала доступна всем с момента релиза или включения FeatureToggle'a;

• Waiting for A/B. В очереди на тестирование гипотезы. Следует добавить прогнозируемое время попадания в тест, условия прохождения теста, тестовые группы, ожидания от теста;

• In A/B testing. Тест гипотезы в активной фазе. Можно указать время проведения и наблюдения за текущим тестом. Накапленные аналитические данные;

• Successful A/B. Тест пройден успешно. Хотим оставить фичу в приложении и расширить покрытие или вообще сделать доступной всем. Результаты по тесту, дальнейшие шаги. Например, задача будет дорабатываться или переписываться более качественным образом. Если задача будет исключена из А/B тестирования и доступна всем, переводим в статус Opened for all;

• Failed A/B. Результаты по тесту, дальнейшие шаги по тесту. Из этого статуса может попасть в Legacy или Dead;

• Legacy. Не поддерживается, требует удаления из приложения. В задаче нужно подсветить, какие шаги нужны для "выпиливания". Можно прилинковать задачи по удалению кода, feature toggle'ов, etc;

• Dead. Не доступна с какой-то версии, даты "смерти". В этом статусе следов от задачи уже нет в кодовой базе.  

Что мы, как разработчики, можем вынести для себя из этого подхода?  

По статусу задачи и информации, приложенной к ней, мы сможем сформировать дальнейшие шаги. Прежде всего, мы сможем понять, что происходит с уже готовыми фичами, делать выводы на основе данных от A/B тестирования и прогнозировать их будущее. Например, в случае успешных тестов обосновывать проведение рефакторинга в соответствующих участках приложения и добавление в спринт технических задач, которые помогут развивать и поддерживать фичу, а также формировать технический долг на несколько спринтов вперед. В случае неуспешных, своевременно убирать ненужный и "висячий" код из проекта, снижая тем самым стоимость поддержки лишнего функционала. 

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

Данный подход придает открытость работе всех членов команды. Мы всегда сможем найти ответственного стейкхолдера, например, при разгребании легаси. 

Дойдя до этой точки, можно пойти дальше и попробовать автоматизировать рутину, добавив изменение статуса задач по некоторым условиям.  

Допустим:  

• Тикет попадает в статус “Falied А/B”;  

• Запускается скрипт, который создает новый тикет на деинтеграцию feature toggle; 

• В тикете заполняются необходимые параметры, назначается исполнитель; 

• Приходит оповещение на почту; 

• Profit! 

Как итог 

Прежде всего, задачи не должны пропадать и растворяться в небытии после этапов разработки. Отсутствие прозрачности процесса создает представление о том, что некоторые задачи делаются “в стол”, “для галочки“ или чтобы симулировать бурную деятельность. Тем самым снижается мотивация делать новые классные фичи. Мне бы хотелось видеть результаты проделанной работы, радоваться результатам и делать из этого выводы.  

Обсудить в форуме