Назвался практиком полезай в кузов.
Замечено (невооружённым глазом), но вооружённым мозгом место для оптимизации. В этом месте всегда есть потери. Это место называется “переход этапов/передача результатов работ”. РП - фича. Она же объект, который должен менять состояния.
Состояния фичи:
- создана
- готова к разработке (ready for dev)
- взята в разработку (work in progress)
- готова к ревью (code review)
- готова к тестированию (ready for test)
- готова к слиянию (ready for merge)
- готова к доставке на стенды (ready for delivery)
Сходу идея такая: сделать один глобальный чеклист на все состояния и положить его в общедоступное место.
Почему я не хочу разбивать чеклист на отдельные чеклисты по этапу? Потому что тогда они будут перезатираться, и ты видишь текущий, но не можешь проверить, что весь прошлый этап пройден правильно. Либо тогда придется в каждом новом критичные штуки из предыдущего дублировать. Но там ещё начнётся “не забудьте поменять чеклист, когда фича поменяла состояние”. А с глобальным чеклистом он один раз подставляется в описание (желательно автоматически) и будь добр заполняй. И взаимный присмотр потеряется, если чеклисты разделить.
Заготовка чеклиста
Ready for development
- в задаче описаны сценарии использования (use case)
- в задаче описаны технические решения по реализации
- из описания задачи понятно, что нужно сделать
- задача содержит все необходимые спецификации (схемы, контракты)
In progress
- задача переведена в In progress
- создана ветка в формате xy-123456-new-feature
- задача проверена по чеклисту ready for development
- коллеги проинформированы о смене статуса
Сode review
- сделан pull --rebase на dev (конфликты отсутствуют)
- добавлены тесты
- добавлена документация (doc, moduledoc, комментарии)
- коммиты содержат номер задачи (“[#1234567] Что сделано”)
- CI успешно пройден
- задача выполнена в полном объеме
- задача проверена на стенде разработчиком
- задача переведена в Code review
- коллеги проинформированы о смене статуса
- замечания в MRе отработаны (треды закрыты)
- ревью проведено (апрувы получены)
Ready for test
- если добавлена новая ENV переменная, она добавлена на стенды (через [задачу на devops](ссылка где создавать задачу))
- задача переведена в Ready for test
- понятно как тестировать (кейсы описаны)
- понятно как разворачивать (все ссылки приложены в задачу)
- ревью пройдено (весь прошлый чеклист заполнен)
- коллеги проинформированы о смене статуса
- MR в актуальном состоянии (нет конфликтов, нет отставания от базовой ветки)
Ready for merge
- подготовлены ветки в dev и в релиз
- ответственный смержил ветку в dev (достигнута договорённость, кто это делает разработчик или QA)
- задача переведена в Ready for merge
- проверено, что предыдущий чеклист успешно пройден
- сообщение в релизный чат отправлено
- задача закрыта
Формулировки и список пунктов будет уточняться с интересантами (непрерывно). Это меня волнует чуть меньше. Меня волнует что получилась простынь, даже чисто визуально. Как вы думаете такой объём испугает людей? Или какая разница, надо объяснять где чья часть и зачем всё это нужно. “30% на смерть проекта”!
Update. 19.09
Почистила заготовку чеклиста, не такая уж и простынь. Всем спасибо за комментарии.
Добавлю контекста. Я не целюсь в инженерный процесс “фичи” целиком. Давайте фичёй будет называться в нашем случае user story в таск трекере. В которой может быть одна и больше задач. Эти задачи могут быть назначены на разных разработчиков (в том числе разных по стекам: фронтенд, один бекенд, другой бекенд). Движение фичи по состояниям внутри таск трекера я в чеклисте затрагиваю только потому что “вроде все понимают, что нужно менять статус задачи (когда дороге к готовности мы продвинулись на очередной шаг), но банальные вещи проще всего забыть в потоке внешних раздражителей”. Таск трекер, как общедоступный операционный моделер сотрудника, я не вижу. Потому что это место куда смотрят менеджеры. Но работы делаются не там. С того момента, как фича/задача описана и назначается на исполнителя (разработчика), он уходит в свой операционный моделер (в репозиторий конкретного сервиса в git). Поэтому кстати и забывает двигать “карточки по доске”. И его пинает скрам мастер на дейли каждый день. При этом репозиторий это место работы ближайших смежников участвующих в разработке (QA, релиз менеджер, системный аналитик). У всех у них есть доступ, и все они на некоторых состояниях через этот моделер взаимодействуют с разработчиками.
Почему я хочу сделать чеклист именно в репозитории? Потому что 1) я могу его сделать (никого не спрашивая, не уговариваю, не ходя по кругам бюрократии) 2) его легко будет редактировать 3) он доступен внутренним интересантам, при взаимодействии которых я вижу регулярные косяки 4) там есть весь функционал из коробки (шаблон чеклиста подставляется в каждый MR, его всем кому нужно видно, видно кто делал изменения, когда, этот шаблон дешёво растащить по всем командам).
Как в моей голове выглядит по интересантам. Бизнес аналитик создал сторю. Внутри системный аналитик создаёт несколько задач на разработчиков. Первый порог - это описанная задача, которая уходит разработчику. Порог это потому что она может быть плохо описана, там не хватает разных штук в голове у системного аналитика (понимания нашего ПО целиком, мысли о нужных командах для реализации, внимательности и т.п.). На этом пороге, если работу аналитика не проверить, уже будет хождение кругами. Причём оно может быть даже на два шага вперёд. Если разработчик считает, что “вот ТЗ, моё дело сделать по ТЗ”. Такое тоже есть. Разработчики разные. Поэтому фактически первый чеклист (ready for development) это заход на то, чтобы разработчик перед тем как первую строчку кода писать, взял и проверил задачу. Сходил к аналитику. Предлагать ли аналитикам этот чеклист как этап их работы? Я не знаю. Его можно конечно скопировать в описание задачи в таск трекере, или пусть себе на стикер на монитор приклеют. Одинакового удобного решения для всех нет. Поэтому я делаю ставку, на “возвратное научение”. Кому понравится, куда-нибудь себе сохранят. Показать им, что “не обижайтесь, вы классные ребята, но мы вам больше не верим”, я думаю покажу. Ожидайте, что разработчики будут вам возвращать задачи на доработку, если они плохо описаны. Есть повод подумать о том, чтобы самим приходить показывать описание разработчикам, до того, как сказать “задача готова”. Статуса такого кстати в таск трекере нет. Я много раз про него заикалась, но не дотащила. Может быть надо дотащить.
Дальше три шага делает разработчик: разработку, готовность для ревью и просьба о ревью (к коллегам по стеку сходит), готовность для тестирования. Разработчик проверяет сам себя, перед тем как пойти к коллегам за ревью, и к QA с просьбой о тестировании. По чеклисту Ready for test QA может проверить разработчика. И по идее вынужден будет проверять, потому что задача не всегда прилетает на тестирование с пылу с жару.
Дальше есть непостредственно Test, но я его не тащу к нам. Сейчас кажется это излишним. Но если тестировщики захотят свой чеклист вставить, ноль проблем. Мне кажется у них там какой-то свой ещё моделер для тест-кейсов. Надо будет уточнить.
Предфинальное состояние это выливание на стейджинг. Ready for merge тут задействованы разработчик и QA, как подготавливающие материалы. И релиз менеджер, как тот кто потащит дальше. Т.е. опять разработчик и QA проверяют себя, что не прошляпили то, что должно быть готово. Релиз менеджер может проверить за ними непосредственно перед доставкой на стенд. Я думала о том, что можно ещё сэкономить внимание релиз менеджера и добавить пункт “чеклист пройден” в сообщение в релизный чат. Человеку, который пишет в чат это ещё раз обращает внимание на его чеклист. Релиз менеджеру по идее экономит лишний поход в репозиторий. Но там тоже будут возвратное научение. Написан про чеклист, а сам его не прошёл. Кто ты после этого?
Кого потеряли? Менеджеров. Бизнес аналитик не имеет доступа к репозиторию (слава богу). Скрам мастер. Продакт. Для них есть таск трекер, который по моему чеклисту должны не забывать обновлять. Т.е. они стоят в начале цепочки (появилась потребность в фиче, она вытащилась из беклога, отдана в какую-то команду разработки, бизнесовое описание составлено). Дальше фича попадет в черный ящик разработки. Из черного ящика, выезжает готовая фича в релизный чат (если мы внутри ящика не лажаем, но на это и ставка). На стейдже проверяет финально кто-то из этих менеджеров. И своей царской волей позволяет отправить наш ящик в продакшен к людям. Опять же идея в том, что если внутри команда разработки работает внимательно и слаженно, то возвратов из релизного чата уже не должно быть (в действительности). Либо должно быть крайне мало (в реальности).
Ещё забыла сказать! Это революция (техно-эволюция) снизу. Никакой политической воли на изменение всего конвейера у меня нет. Поэтому я делаю там, где мне доступно. А дальше буду думать, как это растащить во всем командам и через кого.
Update. 29.10
Всё идёт медленно. Обсудила идею с лидом QA, поддержал, добавили кусок про тестирование в чеклист. Дальше несколько недель не могла “поймать” нашего ИТ лида. Хотела ему сначала отдельно показать, а только потом презентовать в команду. В итоге рассказывала сразу и ему, и команде. Слили чеклист в общую ветку. Идёт тестирование. Поступил запрос на вынесение части для аналитиков в таск-трекер. Ищу можно ли там сделать шаблон чеклиста для определенных типов задач. Пока не находу. Нашла в редакторе описания задачи кнопку To-do list, но она очень криво вставляет текст. И через кнопочку его придётся из головы или откуда-то ещё копировать каждый раз, что плохо. Непонятно через кого и куда идти дальше. Я могу снова обратиться к лиду тестировщиков, показать что внутри команды чеклисты заполняются и мы хотим, чтобы тестировщики тоже за своей частью следили. А потом нужны какие-то соседские лиды.
