Как мы починили свой процесс и стали меньше отвлекаться

    В прошлом году наша команда прошла через жесткий слом процесса разработки, но смогла восстановить его и сделать еще лучше: понятней, приятней и продуктивней.

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


    1. Дежурный разработчик


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

    Каждый день один из нас заступает на дежурство. Приоритетная и эксклюзивная задача дежурного разработчика — работа с обращениями службы поддержки. Нормально, если из-за наплыва заявок дежурный не написал ни строчки кода, но не комильфо, если оставил новые заявки на следующий день (они достанутся его коллеге).

    Для простоты атрибуты власти дежурного (см. картинку) передаются каждый день по часовой стрелке следующему разработчику (никаких графиков дежурств).

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

    2. Единая точка входа в команду


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

    Это простое, даже капитанское правило защищает команду от гиперактивных менеджеров по работе с клиентами, желающих срезать углы и решить свой вопрос «по-быстрому», а заодно прокачивает продукт-оунера и службу поддержки.

    3. Фиксированные дни для обсуждений


    Любые обсуждения, в которых участвует команда, проводятся строго в отведенные дни недели (вторник и четверг в нашем случае). На эти же дни назначены регулярные обсуждения/оценка (груминг) новых фич с продукт-оунером, а также планирование следующего спринта.

    При таком подходе выделенные дни в пределе могут быть полностью заняты обсуждениями и переключениями между ними (и снова ни строчки кода), но взамен мы получаем гарантию, что в остальное время сможем сфокусироваться на разработке.

    4. Обсуждение — задача с оценкой


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

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

    5. Резервы продукт-оунера


    Мы используем Scrum с двухнедельными итерациями. Это означает, что с начала спринта список задач в нем фиксирован и в штатном случае не должен меняться.

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

    Резерв выглядит как задача без описания, но с оценкой в story points. Количество резерва определяется продукт-оунером с учетом потенциальных потребностей. Его может не быть совсем, если в спринте не осталось места. Максимальное количество резерва ограничено, в нашем случае это три задачи с разной оценкой:

    • XS (~3 идеальных человеко-часа) — 2 задачи
    • S (~6 идеальных человеко-часов) — 1 задача

    Неиспользованный продукт-оунером резерв за день до демонстрации превращается в тыкву сгорает. Этим гарантируется, что востребованный резерв можно успеть реализовать и включить в релиз. Команда использует сгоревший резерв на техническую задачу по своему усмотрению, либо удаляет его из спринта (в последнем случае story points не начисляются).

    6. Done-консилиум


    Раньше у нас были сложности с определением завершенности задачи (Definition of Done), особенно с пунктом «Вся команда согласна, что задача выполнена».

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

    Done-консилиум гарантирует, что вся команда довольна итоговым решением задачи.

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

    7. Передача кода


    Когда Done-консилиум закончился, а автор внес необходимые правки, задача переходит другому разработчику. Он проводит code review и самостоятельно устраняет найденные замечания или проводит рефакторинг.

    Этой практикой достигается общее владение кодом и погружение в задачи коллег, сокращается время на исправление замечаний по code review. Кроме того, здесь работает эффект свежего взгляда и второй головы, что часто помогает выявить неочевидные проблемы.

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

    Какие из подходов/практик используются в вашей команде?
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 19
    • +1
      Как вы смогли такого достигнуть? У нас анархия и не знаю как это изменить.
      • 0
        В нашем случае эти штуки сформированы самой командой в ответ на имевшуюся у каждого боль.

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

        Или у вас анархия в самой команде?
        • 0
          И в команде и руководстве отделом в целом, ответственный за задачи (замещающий продукт-оунера) не имеет возможности или желания уделять время продукту.

          Поэтому спускаются задачи: «поломалось что-то в аналитике», а команда организует работу. Думаю, что проблема в том, что каждый хочет сделать как можно меньше своей работы, договоренности из-за этого нарушаются (н.р. сервер может прислать данные в другом формате).

          Пробовал брать на себя роль человека, который организует команду по некоторым задачам. Стало чуть лучше, но пока не смог достигнуть нужного эффекта.
        • 0
          Пару раз по шапке за профуканые сроки получите — и или измените строй, или уволитесь.
        • 0
          Какими системами пользуетесь?
          • 0
            Для спринтов и задач — Jira, для обращений поддержки — Asana. Или вы о каких-то других системах?
          • 0
            1. Разве определение завершенности задачи это не прерогатива product owner? Не совсем понятно, зачем вся команда должна быть довольна. Доволен должен быть бизнес (овнер и кастомеры).

            2. Исправление чужого кода в рамках code review это же дикий overhead по трудозатратам. Влезть со «свежим взглядом» в большую задачу и пытаться ее отрефакторить, вместо того чтобы передать обратно автору, который с головой в контексте и все исправит втрое быстрее? То ли у вас очень мягкие требования по эстимейтам (заложено гораздо больше реально необходимого времени), то ли процедура на практике работает не так, как вы описываете.
            • 0
              1. Да, все правильно сказали. Но мы сталкивались ситуацией, когда-то кто-то из команды уже после код-фриза или прямо на демонстрации понимал, что в задаче коллеги можно было бы еще что-то важное учесть.

              А вся команда должна быть довольна, чтобы ни у кого не было ощущения, что кто-то рядом запилил какую-то фигню (пусть и рабочую), с которой теперь жить :-)

              2. Вы правы, погружение в контекст требует времени больше, чем исправление самим автором, поэтому на практике глубина погружения может быть разной (в зависимости от загруженности).

              По моим ощущениям, оверхеда не больше, чем при парном программировании, для которого как раз не всегда достаточно времени.
              • 0
                Скажите, пожалуйста, а как происходит процесс ревью? Ревьювер просто берет и молча доделывает/переделывает код или сначало идет обсуждения непосредственно с автором на тему «почему сделано именно так, а не иначе» и уже после достигнутого консенсуса/компромиса начинается рефакторинг?
                • 0
                  Если ревьювер вносит какие-то мелочи, то просто берет и вносит. Если у него гениальная идея, как все переписать с нуля, то тут стоит задуматься над целесообразностью.

                  Изменения «средней тяжести» валидируются с автором. До или после во многом зависит от уровня погружения в код ревьювера и автора. Опытный в этой части кода ревьювер может что-то переделать и потом рассказать автору.

                  У нас есть нерешенная проблема: нет четкой границы, когда ревью с косметическими правками превращается в полную переработку авторского решения. Нужен какой-то объективный критерий, по которому можно оценить — стоит ли сейчас вносить это изменение или можно выпустить фичу в таком виде в релиз.
            • 0
              Слишком сложно. Дайте мне 2 выходных, 1 день обсуждений и 4 дня спокойной работы — все, не нужно усложнять.
              «Done-консилиум» — это да, тут минусов нет, одни прелести.
              • 0
                4 дня спокойной работы
                — вот как раз их и не дадут вам, если не пойти на компромиссы как в статье...(
                • 0
                  Я как разработчик хочу творить пока не добил определенный пласт работы, а не болтать. С другой же стороны менеджеры хотят направлять и быть в курсе происходящего. Да и идея с суппортом хороша, хоть и реализуема только в идеальном мире, так как вопросы в тикетах обычно далеко не только о ПО.

                  Вот и выходит, что в данном случае компромисс, то есть взаимные уступки, это как раз один день.
                • 0

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


                  Это дает прирост производительности сейчас, но копит неразгрумленные задачи. Нормальный компромисс, когда PO и команда немного расходятся в понимании, что можно и что нужно успеть в очередном спринте.

                  • 0
                    Я не спорю, каждому свое. Лично мне хватило бы, даже многовато, одного дня в неделю с обсуждениями.
                • 0

                  У вас, получается, действует правило "кто нашел, тот и сломал"? Качество код-ревью от этого не страдает? Ведь приходится из своей задачи "вынырнуть", чтобы качественно починить чужой код.
                  Про оверхед, сравнимый с парным программтрованием, интересно замечено.

                  • 0
                    Как уже писал, глубина погружения на практике может быть разной: кто-то пару проверок добавит, кто-то лишнего уберет, а кто-то обсудит с автором и отрефакторит API.

                    Мы как раз с классическим код-ревью ощущали проблему с выныриванием и заныриванием: автор запилил фичу и хочет пилить следующую, но остальным некогда поревьювить, потому что у них тоже фичи интересные, но когда они посмотрят, то автор уже начал новую и ему снова переключаться обратно.

                    Сейчас ревьювер один и он посмотрит тогда, когда ему будет удобно, но при этом не начнет новую задачу, пока не поревьювит. Автор же сразу переключается на новую задачу.
                  • 0
                    7. Передача кода

                    А бывает, что второй программист, который делает code review, плохо разбирается в коде и ломает то, что работало? У нас исправляет тот, кто написал код, и в моих code review было много комментов, где люди не понимали, как это работает и зачем я добавил этот кусок кода.

                    6. Done-консилиум. 7. Передача кода.

                    А почему не наоборот? У нас сначала code review, потом тестировщики проверяют, а потом уже демо. Если окажется, что код кривой и его надо переделать, то вы проводите демо и Done-консилиум ещё раз?
                    • 0
                      Да, бывает. Как раз в тех местах, где с первого взгляда непонятно, что так специально было сделано и есть какой-то дикий нюанс бизнес-логики, внешнего API, legacy-кода, а не просто продолбали. Специальной защиты от этого нет: явно отразить в коде эту особенность, добавить на нее тест, написать комментарий в конце концов. Никто не запрещает привлечь автора и попросить разъяснить непонятное.

                      Done-консилиум это еще не итоговое демо по результатам спринта, а внутренняя мини-демонстрация. Автор еще будет вносить изменения после него, поэтому ревьювить код рано. Done-консилиум обеспечивает минимальное погружение в выполненную задачу — без этого нельзя нормально выполнить ревью.

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

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

                    Самое читаемое