company_banner

Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли

    Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

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

    image

    В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.


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

    Назвали мы все это компонентами. Стало более понятно, какие задачи, когда делать. Благодаря фильтрам удалось сократить количество задач, висящих каждый день на разработчике примерно до 20. Ориентироваться в них стало гораздо легче.

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

    Несмотря на все эти изъяны, было ясно, что движемся мы в правильном направлении, просто нужно пойти еще дальше. И тогда мы решили попробовать Agile Board. У нас в JIRA уже был установлен прекрасный плагин Green Hopper, который умеет делать Scrum и Kanban.

    Как гласит Википедия, Scrum — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

    Там же есть очень хорошая картинка, которая это все объясняет:

    image

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

    Готовим рабочее место


    Начали мы с малого — навели порядок в JIRA. Вместо кучи компонентов и версий, мы оставили:

    • компонент «Верстка: инфраструктура»;
    • компонент «Верстка: интерфейс»;
    • опциональные продуктовые или технологические компоненты, например: платформа – iOS, продукт – подвал;
    • версия backlog;
    • продуктовые версии для запусков.

    Кроме этого мы ввели некоторый набор правил про написания и компоновку задач:

    • краткий и четкий заголовок, лучше с глаголом;
    • минимально необходимое и четкое описание задачи со всеми необходимыми данными, желательно без ссылок на внешние источники;
    • должны быть указаны компонент и версия
    • задача измеряема и конечна;
    • отказываемся от гигантских родительских задач, вроде «Запуск нового интерфейса картинок»;
    • родительские задачи используются для задач, которые можно сделать за неделю;
    • все сабтаски у родительских задач действительно являются декомпозицией задачи;
    • используем механизм линковки задач, если они связаны друг с другом.

    Настраиваем Agile Board


    Прежде всего, надо выбрать тип: Scrum или Kanban.

    image

    Затем необходимо наполнить его данными.

    image

    Мы сделали фильтр, который является источником данных для нашего Agile Board. Этот фильтр отбирает проектные задачи с компонентами про верстку, с проставленной версией «backlog». Backlog значит, что мы должны сделать эту задачу в ближайшие пару спринтов.

    В соответствии с workflow работы над задачами необходимо добавить новых колонок и назначить на них соответствующие статусы.

    image

    По умолчанию есть три колонки: to do, in progress, done. У нас их больше:
    • to do – задачи, которые нам осталось сделать в рамках текущего спринта;
    • in progress – задачи, которые мы делаем прямо сейчас;
    • on review – задачи, в которых мы прямо сейчас ревьювим реализацию;
    • commited – задачи, которые уже запрограммированы, но не готовы к тестированию;
    • testing – задачи, которые готовы к тестированию или тестируются в данный момент;
    • done – выполненные задачи.


    Последние две колонки могут быть совмещены в одной. Например, сейчас у нас в одном из проектов нет колонки «testing», а есть сразу «done».

    Настраиваем группировку задач. По умолчанию группируются по assignee. Нам это вполне подошло.

    image

    Настраиваем цвета карточек, чтобы можно было визуально отличать баги от фич.

    image

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

    image

    Estimation, working days и issue detail view мы пока не используем.

    • Estimation необходим для оценки задач на этапе планирования, чтобы более лучше в дальнейшем планировать.
    • Working days позволяет задать рабочие дни на проекте.
    • Issue detail view поможет выводить дополнительные поля в предпросмотр задачи.


    Используем Agile Board


    Мы приняли длительность спринтов в одну неделю. Соответственно, на первой проектной синхронизации мы набираем задач на неделю и берем их в работу. Происходит это на вкладке Plan.

    image

    Наполнить спринт можно двумя способами:
    • просто растянуть блок вниз, захватывая из бэклога необходимые задачи;
    • перетянув drag&drop’ом задачу из backlog в спринт.

    Задачи в backlog можно сортировать как вам угодно простым перетаскиванием. Мы занимаемся этим раз в неделю с проектными менеджерами – до встречи про синхронизацию.

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

    image

    Когда спринт наполнен — стартуем его. Далее можно работать с вкладкой Work.

    image

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

    В этом режиме можно также посмотреть детальное описание любой задачи, изменить статус задачи drag&drop’ом (перетащить из in progress в on review). Эту вкладку мы просматриваем на синхронизации в середине недели, обсуждая прогресс задач.

    В начале новой недели мы завершаем спринт и переходим на вкладку Report. При этом мы сразу видим, сколько задач мы сделали, а сколько нет. Незавершенные задачи попадают наверх backlog, они будут сделаны в рамках следующего спринта в первую очередь. Кроме этого, есть несколько отчетов, например:
    • sprint report;

      image

    • control chart.





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

    image

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

    Вслед за нами команды еще нескольких сервисов Яндекса перешли на такой формат планирования задач. Мы рекомендуем этот подход всем крупным командам разработчиков. Если у вас есть более одного источника задач, а к их решению нужно привлекать программистов из других команд, по нашему мнению, Agile Board — самый оптимальный вариант.

    Яндекс

    480,00

    Как мы делаем Яндекс

    Поделиться публикацией
    Комментарии 57
      +4
      Мы рекомендуем этот подход всем крупным командам разработчиков.

      Крупные — это >10 человек? Или >100?
      Сколько, кстати, размер вашей команды?
        0
        Сейчас 14 человек, включая меня. К конечному варианту пришли, когда нас было человек 7.

        Влияет не только размер команды, но и количество задач, которые необходимо решать.
          +1
          Не смотрели на Targetprocess?
          www.targetprocess.com/product/
            +1
            Нет, не смотрели. На картинках выглядит хорошо. Интересно хорошо ли справляется с большими нагрузками.

            Обязательно поиграюсь с trial-версией.
              0
              Цены очень негуманные (25 per user / month).
          +1
          А как вы решаете задачу синхронизации Jira и доски. У вас это каждый раз делают исполнители задач или есть просто ввыделенный человек который синхронит?
            0
            На физической доске висят крупные задачи. В JIRA одна задача из доски может быть представлена 10-20 более маленькими задачами. На физической доске такая детализация не нужна, иначе будет очень много визуального шума.

            Крупные задачи двигает модератор после общения с представителями интерфейсов.
            0
            Поэтапная доска с заданиями — это до внедрения или после?
              +1
              История решения проблемы большого количества маленьких интерфейсных задач началась задолго до появления физической доски. Однако к использованию agile board в JIRA мы пришли после.

              Оба процесса продолжают развиваться.
              0
              Мы пришли к похожему подходу, только у нас еще есть в workflow status Delay, для отложенных задач.
              И да, Jira тормоз :(
                +2
                Дайте ей больше хипа ;)
                  0
                  У нас SaaS.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    У нас на 10 человек команды раньше был OnDemand, но он тупой для СНГ. Перешли на Hosted. Сейчас на виртаульном KVM тазике Xeon 3GHz x 4 core, 4GB DDR3 RAM крутится OpenVPN server, JIRA, Confluence, Crowd, Stash и Bamboo (но его будем переносить на отдельный аппарат, конфликтный он).
                    +1
                    Аналогично, но у нас задач поменьше и народу то же. Используем Trello. Один из любимейших task менеджеров, если бы они продавали футболки с логотипами, я бы ее обязательно купил.
                      +2
                      А почему выбрали именно Trello? Что в нём нравится больше всего?
                        +1
                        Бесплатно, приложения под iOS и Andoid, очень удобный в плане добавления задач, комментариев, файлов, чек листов, голосований. Если у вас над проектом не больше 6-7 человек работает, то самое оно. Из минусов — все не у вас на сервере.
                          +2
                          Из минусов — все не у вас на сервере.

                          Для нас это существенный минус. JIRA мы используем только на своих серверах.
                            0
                            упс, продублировал 9zloy случайно
                        0
                        Трелло хорош, но для больших команд не подходит

                        medium.com/the-content-factory/e8eb96d7a701
                          0
                          Вы правы, но, если нужно наглядно и долго объяснять, чем этот продукт лучше того, то действительно ли он лучше? Но Трелло, точно не подходит для больших команд или долгих разработок.
                            0
                            Ну можно и в двух словах объяснить: он позволяет планировать и трекать, хорошо работает с большим объемом данных и имеет меньше ограничений. Но без деталей это как-то звучит не очень убедительно :)

                              +2
                              Я то вам и в первый раз поверил.
                            +2
                            низкий поклон вам за ссылочку
                            0
                            Можно заказать принт на футболке :)
                            0
                            Стало более понятно

                            было ясно, что движемся мы в правильном направлении, просто нужно пойти еще дальше
                            Спасибо за статью… всегда нравились люди, которые осмысливают свои действия. Приятно читать.
                              +2
                              У нас redmine. Выбран давно в силу возможностей и бесплатности. Сейчас хочется иметь доску как в вашем примере. Это очень наглядно. Нравится Trello.

                              Но вот для редмайна такого простого инструмента нет. А съехать не сильно получается, т.к. в редмайне накоплена большая история по проектам, таскам и wiki. И хочется остаться на чем-то бесплатном. Такие дела (

                              За статью спасибо )
                                0
                                А как же Redmine backlogs? Вполне удобный плагин… www.redminebacklogs.net/
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Ryzhaja, stdob — спасибо за наводку ) Смотрел летом плагины — эти просмотрел. Попробуем поставить
                                      0
                                      Мы совсем недавно выпустили плагин Redmine Agile, который позволяет вести примитивную доску и строит базовые диаграммы.

                                      Может быть будет полезно
                                      +1
                                      Класс! Радует, когда видишь, что в Яндексе делают так же, как и мы у себя :)
                                        –4
                                        Очень здорово!

                                        Если не секрет, для мелких задач все еще используете наши постики? :)
                                          0
                                          Не совсем понятно как планирование происходит, когда нет оценок для задач.
                                            0
                                            А, если не секрет, как решаются проблемы, когда одна задача ломает другую, уже оттестированную, и когда вообще гонятся регрессы? Или используется только автотесты? Что бывает с тасками, которые не прошли тестирование и не укладываются в спринт, в какой момент принимается решение, что они в спринт не войдут?
                                            И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?
                                              +1
                                              А, если не секрет, как решаются проблемы, когда одна задача ломает другую, уже оттестированную, и когда вообще гонятся регрессы?


                                              Полные регрессы происходят при подготовке релизов. Отдельные задачи проходят code review и тестирование перед вливанием в стабильную ветку. Стараемся делать атомарные изменения, чтобы ничего не взрывалось.

                                              Что бывает с тасками, которые не прошли тестирование и не укладываются в спринт, в какой момент принимается решение, что они в спринт не войдут?


                                              У нас все задачи проходят тестирование, кроме совсем тривиальных syntax fix'ов. У нас, как правило, нет жестких deadline'ов, поэтому когда мы понимаем, что не успеваем сделать задачу, то просто переносим её в следующий спринт.

                                              И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?


                                              Задачи бэкэнда вёрстки живут в нашем спринте. Есть другой уровень «бэкенда», который живёт отдельно. Но мы не начинаем делать интерфейсы, пока этот уровень не готов хотя бы частично.
                                                0
                                                Спасибо.
                                                Про «не прошли тестирование» я имел ввиду были зафейлены на финальных регрессах, например.
                                                  0
                                                  Возможны две ситуации. Если позволяет время и другие ресурсы — чиним. Если нет, то отрываем из релиза, чиним без спешки, выкатываем в следующий раз.
                                              +1
                                              Вы бы объяснили, что такое Kanban заодно, раз уж на скриншотах всё по-английски. (Если кратко, Kanban — это без чёткого деления на спринты по неделе-две, для проектов где задачи прибывают ВНЕЗАПНО и СРОЧНО, a lá russe)

                                              В JIRA есть плагин с русской локализацией, в том числе для JIRA Agile (так сейчас называется Grasshopper). Там можно и без English knowledge работать.
                                                0
                                                Ходят слухи, что у вас жира окончательно перестала справляться и вы что-то внутренее пилите. Правда?
                                                  –1
                                                  Да, мы разрабатываем замену. Если хотите подробностей, приходите к нам работать.
                                                    0
                                                    У вас на скришотах старючая JIRA, может именно поэтому она у вас тормозит? Последние версии очень даже быстро работают.
                                                      0
                                                      Не уверен, что в 6.* сделали что-то революционное в плане скорости. Мы сейчас работаем на 5.2.2
                                                  0
                                                  Есть такой вопрос, а что вы делаете, когда становится понятно, что
                                                  формулировка задачи неправильная
                                                  , вешаете её на постановщика обратно?
                                                    0
                                                    вешаете её на постановщика обратно

                                                    Да, вешаем со статусом «Need Info». Мы стараемся брать в работу только исследованные и понятные задачи, в которых есть все необходимые данные, информация о внешних зависимостях.
                                                    0
                                                    Сама методология Scrum замечательна.
                                                    А вот Agile Board — это костыль.
                                                    Почему?
                                                    А потому, что он, по сути, является фильтром для задач. Если бы у списка задач был гибкий, удобный фильтр, то не потребовалось бы делать отдельное решение на отдельной странице в виде Agile Board.
                                                    По сути, это напоминает некий отфильтрованный список, наложенный на недельный календарь.
                                                    Хочется взять мою бритву Оккама и отрезать лишнее.
                                                      +2
                                                      Можете пояснить мысль как-то подробнее? В чем проблема фильтра Agile Board?
                                                        0
                                                        Проблема?
                                                        Да нет никакой проблемы. Это зависит от точки зрения.
                                                        — Вот есть список задач (в терминологии Scrum — Резерв проекта, далее в скобках будет терминология Scrum, хотя я не вижу смысла ее использовать).
                                                        — Задачам задается приоритет, и весь список можно выстраивать по приоритету Немедленный, Срочный, Нормальный, Высокий, Низкий.
                                                        — Периодически, из списка задач (Резерва проекта) выбираем задачи для релиза (Спринта).
                                                        — Список задач можно отсортировать таким образом, чтобы показывать только задачи релиза (Спринта) или показывать их сверху списка задач (Резерва проекта).
                                                        — Далее, в рамках списка задач релиза (Спринта) их можно сортировать по статусам Новая, В работе, Тестирование, Выполнена.
                                                        Все это делается с помощью стандартного фильтра того же Redmine, не пойму, зачем сюда еще Agile Board вставлять.
                                                          0
                                                          борд показывает данные в двух измерениях, в отличие от обычного списка. Это гораздо нагляднее. Кроме того, статусов может быть больше трех, тогда разница в визуализации работы очень заметна.
                                                            0
                                                            Статусов может быть сколько угодно, в Redmine вы сами определяете их количество.
                                                            А диаграмма Ганта, по моему мнению, куда как нагляднее, чем Agile Board.
                                                              0
                                                              Диаграмма гантта отвечает на вопрос, какие задачи в каких состояниях? Это два разных инструмента. Молоток нагляднее отвертки? Хмм…
                                                                0
                                                                Ну сделайте прогрессбар внутри задач на диаграмме, если вам это важно.
                                                                Наглядность борда, при большом количестве задач, весьма сомнительна. Впрочем, это касается и таблиц. Наглядность она только при малом количестве задач работает.
                                                      +1
                                                      Всегда было интересно а где при ваших объемах вы сохраняете все «Nice to have»-задачи, и в чем ведете (если ведете) roadmap продукта.
                                                        +1
                                                        Чтобы не было недопонимания. Под «nice to have» задачами что понимается?
                                                          0
                                                          Идеи, которые не получили детального описания, или домыслы, которые еще не были исследованы.
                                                          То есть задача еще не получила полноценного User Story и у вас есть только сообщение пользователя (а при исследовании вы понимаете что у определенной группы пользователей и почему)
                                                          — Ребята сделайте кнопку удаления фотографии справа.

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

                                                          После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.
                                                        0
                                                        После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.

                                                        Зависит от задачи очень сильно. Бывают, что предложенные (внутри, снаружи) идеи попадают в спринт, а затем и в релиз. Обычно нужно больше времени на исследовать, сделать прототип.
                                                          0
                                                          Что изменилось за почти 4 года? Где-то рассказывали, наверняка. Поделитесь ссылкой или новой историей?

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

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