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

Кросс-функциональное взаимодействие

Дизайн

Возможно каждый из вас сталкивался с ситуацией когда ты оцениваешь задачу по одному макету, а в приступив к нему, макет выглядит уже несколько иначе. Ну вот и мы не исключение. Чтобы максимально избежать таких ситуаций, мы предприняли два простых шага. Со стороны дизайна мы используем версионирование макетов, а со стороны разработки мы делаем скриншоты тех экранов, которые должны пойти в разработку.

На что это повлияло? У разработки появился сильный аргумент в решении споров по оценке и составе фич.

Следующая зона роста, с которой мы активно работаем в вопросе взаимодействия с дизайнерами, это уровень проработки дизайна. То, что очевидно разработчику, не всегда очевидно дизайнеру. Для упрощения взаимодействия мы составили простой чеклист, что необходимо «отрисовать», который включает в себя обработку ошибок, состояния загрузки, роли и т. д.

На что повлияло? Мы стали тратить меньше времени на грумминги задач, так как избавились от части очевидных вопросов ещë до самого грумминга.

Бекенд

Тут краеугольным камнем стал контракт, а именно наименования полей и их обязательность. Вроде ничего нового, можно было бы решить этот вопрос Swagger`ом, но там контракты появляются после раскатки, что нам не подошло. Возможно, есть более совершенные решения, о которых я с радостью почитаю в комментариях и, наверное, возьму на вооружение, но для себя мы решили это простым и тривиальным способом: стали фиксировать в «Истории» к задаче.

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

Тестирование

Представьте, каково было моë удивление, когда мне сказали, что в компании нет ручного тестирования. Тесты существуют исключительно как UI и UNIT. В планах, конечно же, интеграция Zephyr, но как временную альтернативу сделали шаблоны с чеклистами в Confluence, в которых проставляем работоспособность функциональности. Не то чтобы это решение, которым стоит хвастаться, но за неимением ничего...

Командные ритуалы

Дейлики

Далеко не во всех командах, но кое-где к этому были вопросы. Если загуглить, сколько длится дейлик, то это 20-30 минут, но я считаю, что длительность идеального дейлика — 5-10 минут, а дальше уже по необходимости. То есть далеко не всегда в проблемы серверной части стоит посвящать фронт/дизайн, и наоборот. Решаем это таким образом: выносим список проблем и заинтересованных в их решении, и остаëмся после встречи. Если это не решается за отведëнные полчаса или требует проработки с другими командами, то собираем отдельную встречу. Казалось бы, всë и так понятно, но по своему опыту скажу, что далеко не всем.

Грумминги

Тут стоит уточнить: у нас классический SCRUM.
Когда я пришëл в команду, у нас было по два грумминга на неделе, и да, это грумминги, а не планирование. Проблема заключалась в том, что не хватало чëтких требований, а также критериев приëмки и готовности задачи.

Что же мы ввели и на что это повлияло?
Начну с процесса «готовки» задач. Начинается всë с постановки и описания бизнес-истории, далее задача передаëтся на «отрисовку» дизайнеру и груммится отдельно с ним. Результаты выносятся на грумминг с разработкой, где по необходимости вносят коррективы и отправляют на повторный грумминг. После определения готовности и приëмки задачу отправляют в беклог, где она и ожидает оценки, которая происходит на планировании.

На что повлияло? Казалось бы, и тут всë очевидно, но не всегда и не для всех. Процессы стали прозрачнее и понятнее, а релизы — более предсказуемыми.

Ретроспектива

В команде отсутствуют scrum-мастера. Ранее у нас в командах ретроспектива проходила достаточно сухо, в классическом исполнении «Mad‑Sad‑Glad», в последнем же квартале стали практиковать новые форматы, что, конечно же, повлияло на продуктивность этих ретро, иначе говоря — странно делать одно и то же и ожидать разных результатов.

Опыт

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

Выводы

Самое главное что я для себя вынес - наличие процесса это лучше чем его отсутствие и то, что нельзя построить что-то новое не поломав прежнее.