company_banner

Гибкие процессы в IT команде

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


    Ситимобил — второй крупнейший агрегатор такси в России. За год мы выросли примерно в 10 раз и не собираемся сбавлять обороты. Такой быстрый рост накладывает некоторые ограничения: нам нужен очень короткий time-to-market (TTM), время от возникновения идеи до ее использования реальными клиентами должно быть как можно меньше. Из-за того что мы минимизируем TTM, мы не собираем релиз, а катим каждую задачу/фичу по отдельности. Также у такого подхода есть важный плюс — в случае проблем в проде сразу понятно, из-за какого изменения они возникли. Это позволяет сделать точечный откат задачи, а не всего релиза.


    Почему не Скрам


    В IT-индустрии уже несколько лет популярна методология Agile и ее разновидность Scrum (далее «Скрам»). Скрам пытаются так или иначе внедрить в каждой компании. И опыт внедрения у каждого свой, но, как правило, редко носит позитивный характер. Чаще наступает разочарование и откат к прежним процессам.


    На мой взгляд основные проблемы скрама:


    1. Фиксированные спринты.
      Редко получается закрыть спринт вовремя так, чтобы все было сделано. Как правило, остается какая-нибудь мелочь, которую недофиксили или недопроверили. Доработки переносятся на другой спринт, и чтобы успеть вовремя, команда берет меньше задач. Сбалансировать спринт по задачам, чтобы у всех была работа, сложно. Задачи RnD в целом плохо укладываются в фиксированные рамки. А главное, фиксированные спринты редко просит сам бизнес.
    2. Разнообразные митинги.
      В скраме очень много активностей: ежедневные митинги, планирование и ретроспектива каждого спринта. Часто эти встречи проводятся для галочки и больше утомляют, чем приносят пользу.

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


    Команда


    В становлении процесса ключевую роль играет команда и ее устройство. У нас в команду входят разработчики и тимлид. Опционально PM, QA, аналитики, дизайнеры. Команда должна восприниматься единой боевой единицей. Это серый ящик, на входе которого требования, а на выходе — продукт. Внутренняя организация полностью отдается на откуп команде, и внутри себя она может работать по любому процессу, который ее устраивает.


    Как у нас


    Наша команда выбрала процесс сильно похожий на Kanban. У нас много источников задач: найденная службой поддержки бага, новые фичи от продуктов, технический долг, фича смежной команды и т.д. Не важно, откуда пришла задача, она должна быть оформлена в таск-трекере, желательно самим автором. Любая поступившая задача проходит через несколько обязательных статусов: «Новая», «В работу», «Выполняется», «Тестируется», «Готова к деплою».


    Задачи движутся слева направо на доске, редко возвращаясь назад. Приоритет распространяется сверху вниз и справа налево. Для примера, выкатить задачу в прод приоритетнее, чем тестировать, а тестирование приоритетнее новой разработки. Колонка «В работу» по сути образует бэклог команды — приоритизированный линейный список задач на пару недель вперед. Как только разработчик разбирается со своей текущей задачей, он берет следующую сверху колонки.


    Задачи заранее не закрепляются за конкретным разработчиком, этот подход позволяет балансировать выполнение задач, повышает общее знание кода всеми разработчиками, повышает bus-factor. Мы стараемся бороться с узкой специализацией внутри команды. Каждый член команды должен уметь сделать любую задачу из бэклога. Если разработчик взял задачу себе, то он полностью контролирует ее движение по доске вплоть до ее появления в проде. Он же проверяет, как задача ведет себя в реальных условиях.


    Из встреч у нас есть ежедневные митинги, на этом митинге мы обсуждаем не только планы, проблемы и выполненные задачи, но также подходы к решению задач, предложения и вообще все, что волнует членов команды. Встреча редко занимает больше 30 минут для 4 человек. Ежемесячно мы проводим ретроспективу по скрам-образцу: что хорошего/плохого было, что мы с этим можем сделать, план повышения эффективности на следующий месяц. Выделенного планирования у нас нет, по необходимости устраиваем планирование, если начинаем разрабатывать крупную задачу.


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


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

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


    Итог


    Описанный процесс с небольшими вариациями я применял в нескольких командах и компаниях. Он зарекомендовал себя как наиболее гибкий и прозрачный для всех.


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


    Процесс постоянных улучшений — основа нашей команды.

    Ситимобил
    Компания

    Комментарии 18

      –3
      Фиксированные спринты.
      Редко получается закрыть спринт вовремя так, чтобы все было сделано.

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

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

      вы просто не разобрались зачем они нужны и для кого. ничего страшного )
        +3
        Да вроде как раз требует, тайм-боксинг спринтов — важная часть скрама.
        Правда там скорее позиционируется что цель спринта должна быть достигнута, а не таски закрыты, вы это имели в виду?

        На счёт митингов, с одной стороны согласен что «не разобрались», с другой, очень много кто «не разобрался», что тоже может быть неким провалом то ли в методологии то ли в описании, если все бьются об один и тот же угол, может его надо как-то спилить.
          0
          Скрам не требует обязательно успеть сделать и закрыть все задачи-стори. К этому стремятся, но это не самоцель.

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

          Я допускаю, что мог не разобраться )
          Мы проводим дейли-митинги ежедневно и ретроспективы у нас есть, но все же я призываю всегда проверять, что любые встречи несут пользу, а не проводятся потому что «здесь так принято»
          +1
          Мне кажется ключевое "мы не собираем релиз, а катим каждую задачу/фичу по отдельности"
          Не каждый проект или технологический стек может себе это позволить.
          Отличная статья, спасибо.
            0
            да, это наша особенность, по началу казалось дико, но со временем ощутил преимущества )
            +1
            «Логировать время по каждой задаче, не менее 75% рабочего времени» — это какие-то этапы не учитываются, например: вёрстка, тестирование?
            Лог времени в часах или каких-нибудь «попугаях»?
            Задачи вы оцениваете предварительно?
              0
              В трудозатраты записывается всё на что было потрачено время, разная деятельность просто маркируется типом работ (разработка, тестироварние, исследования и т.п.)
              Оценка в фактических часах с точностью до получаса.
              Предварительно оценка дается если ее просят, на постоянной основе оценка не проводится так как нет спроса на нее.

              +1
              Пришли почти к такой же схеме ) Это работает
                +1
                Немного не понятно по поводу не фиксированных спринтов. Т.е. пока все задачи не сделаны — спринт не закрывается? А если осталась продолжительная, линейная задача. Что в этом случае делает оставшаяся часть команды?
                  0
                  возможно я неточно выразился, нефиксированные спринты = нет дедлайна для всей команды.
                  есть приоритезированный список задач на неделю-две, по мере его разгребания накидываются новые с нужным приоритетом.
                  +2
                  Интересный подход, однако есть несколько вопросов:
                  1) Сколько человек в команде разработчиков? Как бы вы оценивали данный подход на командах от 10-15 человек?
                  2) Как происходит деплой? Если я правильно понял, то каждый чуть ли не самостоятельно создает релизную сборку, верно?
                    0
                    1) Мы придерживаемся правила «две пиццы» в размерах команд, то есть если команда не может перекусить двумя пиццами, то ее размер слишком большой. С большими командами не приходилось работать, но кажется, что от 10 человек естественным образом образуется две подкоманды.

                    2) Деплой полностью автоматизирован, если разработчик готов выкатить фичу, то он просто навешивает тег на мастер и пушит его. Дальше гитлаб сделает все сам, главное следить за логами, сентри и т.п.
                    0
                    Вот вопрос, как быть если над таской(стикер на доске) могут вести работу сразу два человека(допустим клиентщик и серверист). Как правильно провести декомпозицию? На сабтаски бить не по феншую. В общем не могу понять, может кто подскажет?
                      +1
                      Я не вижу проблему в сабтасках.
                      Также могут быть отдельные таски и выставлены отношения blocked by в них.
                        0
                        Еще вариант — настроенные колонки на доске:
                        todo -> backend -> frontend -> testing
                          0

                          при таких колонках не получится параллелить backend с frontend. IMHO, сабтаски лучше

                            0
                            Тогда вопрос, а что давать аналитику на анализ, и тестировщику на тест? Тоже делать сабтаски? Или таску? Если таску, то что делать с сабтасками по окончании работ с ними? P.S это не вопросы с подковыркой, просто пытаюсь понять как это делают более опытные коллеги.
                              0
                              Сабтаски закрываются как только сделаются, задача переходит в тестирование если все сабтаски закрыты.
                              Тут нет правильных/неправильных подходов, главное понять какой статус мы хотим отображать на доске и как это поможет управлять проектом.

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

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