Автоматизация workflow небольшой команды разработки (Часть 2)

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

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

    На протяжении 4-х лет у нас выработался следующий формат команды разработки:
    • 1 Project Manager, он же Product Manager, он же Delivery Manager.
    • 4-5 программистов
    • 1 Team lead
    • 3-4 QA
    • 1 Аналитик
    • 1 Техпис (иногда он же и аналитик в одном лице).

    В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

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

    Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

    Перейдем к сути.


    Как мы работали ранее с использованием только Jira и SVN:
    1. На словах получили задание от заказчика или высокого руководства.
    2. ПМ создал конкретную задачу в JIRA.
    3. Программист выполнил, залил в SVN и протолкнул в JIRA на тест.
    4. Тестировщик попросил лида собрать билд.
    5. Качнул новый билд и давай тестить задачи.
    6. Плохие опять на пункт 3, хорошие — в «Закрыто».
    7. В конце версии техпис описывал все, что получилось.
    8. Лид собрал все в кучу и приготовил инсталлятор.
    9. ПМ спаковал и передал заказчику.

    После сложного пути проб и ошибок, спустя 3 года мы пришли к следующему процессу.


    Постановка задачи


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

    В случаях, когда задача не односложная, собирается мини-совещание из ПМ, тимлида, QA-лида и аналитика. После обсуждения и придумывания, что и как будем разрабатывать, обычно сразу дробим это на логически завершенные небольшие задачки (не дольше работы 1-го дня программиста) и грубо прикидываем сроки на реализацию (для планов для высшего руководства).

    Аналитик садится и вдумчиво излагает постановку в Confluence. После этого данную постановку согласовывает с ПМ, а тот при необходимости с высшим руководством.

    Затем на основании этой постановки создается задача в Jira.
    Часто задачи сразу появляются в Jira минуя этап с Confluence.

    Любая задача, которая появляется в Jira сразу попадает на шаг “Постановка задачи”. На данном этапе заполняются такие данные как:
    • тип задачи (новая функциональность, изменение функциональности, ошибка, тех. работы, документация)
    • версия (обычно текущая в разработке)
    • компоненты (например: админка, интерфейс, главная, финансы, отчетность...)
    • описание задачи

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

    Ревизия постановки


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

    Также на этом шаге ПМ принимает решение нужно ли реализовывать вообще данную задачу. Или нужно ли ее реализовывать именно в эту версию.

    На этом этапе есть два варианта workflow: вернуть назад на постановку (доработку описания) или продвинуть дальше в работу.

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

    Ожидание работ




    При выборе этого шага я настроил экран, в котором надо задавать исполнителя, поле “Программист” и планируемое время.

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

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

    В работе


    Нажимая на кнопку “В работу”, задача переходит в состояние “В работе” и благодаря плагину “Automated Log Work for JIRA” автоматически запускается счетчик логирования времени, который останавливается и сохраняет набежавшее значение при переводе задачи в другие статусы. На этом шаге программист может:
    • Приостановить работу (ожидание работ);
    • На ревизию кода;
    • На ревизию постановки (не понял, что требуется делать или есть технические препятствия к реализации именно в такой постановке);
    • На тестирование (не смог воспроизвести).

    Чтобы работала связка FishEye+Crucible+Bitbucket+Jira, при комите программист обязательно в комменте должен указать номер задачи (PRJ-343).

    У нас в команде договоренность, что мелкие правки типа подвинуть кнопку правее или раскрасить зелёный зеленее, можно сразу бросать на сборку. Иначе — ОБЯЗАТЕЛЬНО на ревизию кода.

    Итак, бросаем задачу на ревизию кода, и при этом ответственным назначаем тимлида.

    Ревизия кода


    На этом шаге тимлид в специальной секции Development в Jira смотрит какой именно комит был сделан программистом и нажимает специальную кнопку “Code Review”.



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

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

    Программист в этом случае в секции Development видит Code Review и его статус. При переходе на этот Code Review опять же открывается Crucible, где программист может наглядно увидеть, где именно он налажал.

    При переводе на шаг “Ожидание сборки”, тимлид выбирает ответственным тестировщика, который указан в спец поле, либо если оно не заполнено, то QA-лида.

    Ожидание сборки


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

    Поэтому обычно у нас тестировщики договариваются и, если никто не против, собирают себе свежую версию ресурса.
    Делают они это с помощью Jenkins. В нем созданы по три сборки на каждый проект: сборка для тестов, сборка для разработки, сборка БД.

    В сборке исходников настроен следующий алгоритм:
    1. Вытащить свежие исходники из Git.
    2. Скопировать их на FTP.
    3. Найти все задачи в Jira на шаге “Ожидание сборки” и перевести их на ожидание тестирования.
    4. Разослать письма.

    В сборках БД все тоже самое, только вместо шага 3 выполняется следующее с помощью ssh команд на сервере:
    3.1. Отрубить все коннекты к БД.
    3.2. Удалить БД.
    3.3. Восстановить БД прошлой версии.
    3.4. Прокрутить на ней все скрипты новой версии.
    БД у нас собирают крайне редко, только когда тестировщик видит в измененных файлах sql скрипты.

    Ожидание тестирования


    На этом шаге могут быть задачи, которые уже были в тесте, а могут быть и в первый раз. Если задача уже в тесте была, то тимлид уже ответственным ставит именно того тестировщика, который вернул задачу в работу.
    Иначе все задачи скапливаются у QA-лида. Он смотрит на пул задач и нагрузку каждого тестировщика, и определяет кому назначить задачу на тест. Более того, сразу же определяет и тестировщика для парного тестирования.

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


    С данного шага, задачу можно перевести практически на любой шаг workflow. Тестировщик может:
    • вернуть задачу на постановку (чтобы ПМ определил нужно ли прямо сейчас или вообще исправлять, то что нашлось при тестировании);
    • вернуть на ожидание работ программисту;
    • отправить описание ReadMe (и назначить ее на техписа);
    • протолкнуть на парное тестирование (и назначить ее на соответствующего тестировщика)
    • перевести на ревизию функциональности (автоматом назначится ПМ).

    Так же как и с шагом “В работе”, на этом шаге автоматически запускается счетчик времени, который логирует затраченное на работу время.

    Ожидание парного тестирования


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

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

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

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


    Если на этом шаге обычно уже можно считать, что задача почти закончена. И очень часто, когда поторапливают с выпуском версии, его можно пройти формально.

    ReadMe


    После успешно проведенных тестирований уже окончательно определена функциональность и ее реализация. И вот теперь этой задачей занимается техпис. Обычно все задачи, кроме совсем незначительных или тех, которые сами сломали в процессе работы над версией, мы помечаем меткой “ReadMe”.

    Парный тестировщик, если видит эту метку отправляет задачу на шаг “ReadMe” и назначает на техписа.
    Техпис в специальном поле описывает очень кратко Release notes по этой задаче. Обычно это оповещение пользователя об изменении функциональности или исправлении ошибки, или о появлении новой функциональности и как ей пользоваться.

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

    Ревизия функциональности


    При переходе задачи на этот шаг, триггеры Jira автоматом назначают ответственным ПМ-а.
    На этом шаге ПМ проверяет работу всей команды в целом. Было ли реализовано то что хотели, именно так как хотели, нормальное ли описание в ReadMe и т.д.

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

    Ценность данного шага заключается в том, что хороший ПМ или ДМ после выпуска и звонка заказчика с фразой “что вы наделали?”, должен знать как именно реализовали задачу, как назвали кнопки, тексты сообщений, нюансы алгоритмов и смело ответить “сам дурак”. А не мяться и гадать, а как же они сделали ту форму и чего в ней кнопка задизейблена…

    Закрыто


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

    Рабочий стол


    Для удобства в Jira были разработаны рабочие столы для каждого проекта с четырьмя гаджетами:
    1. Мои задачи на всех шагах. Это список всех шагов workflow и с количеством задач напротив каждого, где я отмечен программистом или тестировщиком. Т.е. смотря на этот гаджет, я сразу могу видеть сколько моих задач сейчас на тестировании, разработке или постановке. Я могу понимать примерный объем моих задач.


    2. Я ответственный. Список задач, которые ждут моего решения. Пока я их не обработаю, никто другой у себя их не увидит.
    3. Сколько задач на каждом. Список всей команды разработки с количеством задач на каждом. Используется лидами для ориентирования кто больше загружен.
    4. Статистика по двумерному фильтру. Подробно видно на ком и на каких шагах сколько задач прямо сейчас.

    Еще с помощью GreenHopper я настроил такую доску:

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

    Выпуск версии


    При выпуске версии, мы выгружаем из Jira все задачи версии в виде двух колонок: компонент и поле ReadMe. Вот и получается у нас ReadMe сгруппированное по разделам.
    С помощью “Scroll HTML Exporter” мы экспортируем страницу хелпа в Confluence и все ее дочерние страницы в набор html файлов, которые внутри выглядят так же красиво как в Confluence и ссылаются друг на друга.

    Итоги


    Вот по такому workflow мы уже работаем несколько лет, иногда его дорабатывая и дотачивая.
    Но в целом он очень удобен.

    Для ПМ тем, что в любой момент времени видно, кто именно и на каком шаге держит задачу.
    Для разработчиков удобно видеть только свой объем работ.

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

    Подробнее

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

      0
      Т.е. нет такого человека, без которого рабочий процесс может остановиться.

      А как же вариант форсмажора/болезни человека? Рабочий процесс не может быть остановлен по определению, а только заторможен. Болезнь того же тимлида автоматически сдвигает все работы, разве нет?
        0
        Нет, его обязанности автоматически принимают другие.
        ПМ — распределяет задачи и советуется с другими программистами — для оценки сроков.
        Ревизию кода выполняет либо другой квалифицированный программист, либо вообще любой программист (джуниоров у нас нет, а увидеть чужой гуанокод способен любой).
        Так что процесс затормаживается только условно. Критических работ, которые просто не делаются потому что ждут тимлида — нет.
        +1
        Очень интересная статья. По ходу прочтения возникли вопросы:

        1) Сколько по времени обычно занимает задача в работе(шаг 4)?
        2) Как много шагов проходит задача до завершения? (всего их 10, но с учетом повторений 50?)
          +1
          1) мы стараемся формировать задачи так, чтобы её разработка не превышала раб дня.
          2) вот по этому критерию мы и определяем качество работы программиста. Чем больше раз тестировщики возвращают задачу, тем хуже её реализовал программист. Хороший программист все делает чётко с первого раза. Конечно это не учитывая дополнительные возвраты из-за хотелок тестировщиков или ПМ-а. А вот различать типы возвратом Jira, увы, не умеет.
          Наша средняя статистика показывает около 5-и возвратов. Но это так… Средняя температура по палате…
          +1
          как техпису было бы интересно почитать про автоматизацию процесса документирования. но чето у вас эта тема не раскрыта. но опять же, как техпис, скажу, что вам нужно что-то делать с рисованием схем\диаграмм, хотя бы разъединять входящие\исходящие стрелки, а то вообще ниче не понятно. или все связи двунаправленные или все данные для процессов только входящие, а исходящих нету. такие процессы-кадавры, all in :)
            0
            Это картинка из Jira. Живой воркфлоу. Она такая, какая есть :)
              0
              В JIRA можно диаграммы workflow рисовать красивыми.
              0
              Да, схема показана средствами Jira.
              Ну на самом деле у нас есть ещё один тип задач — документация. Для него у нас настроен стандартный workflow. Когда техпис видит задачу с типом «новая функциональность» или «изменение функциональности», он создаёт задачу типа «документация» и по ней отражает эту задачу во всех документах.
              А документация тестируется тем же тестировщиков, который тестировал основную задачу.
              0
              Насколько детально вы описываете требования? Если задача идет сразу без этапа постановки в Jira, не возникает ли проблем у тестировщиков типа «как это тестировать, требований нет»?
                +2
                Стараемся детально. Потому что при разночтениях сильно затягиваются сроки разработки из-за возвратов.
                Часто мы создаём задачи без постановки в Confluence, но постановка в Jira — обязательна. Правда бывает так, у меня не хватает времени на ревизию постановки, приходится верить, что все все правильно поняли на словах.
                Ну а у тестировщиков даже с нормальной постановкой вопросов хватает.
                  0
                  Если описание задачи «годное», то это и есть требования :)
                  0
                  благодаря плагину “Automated Log Work for JIRA” автоматически запускается счетчик логирования времени, который останавливается и сохраняет набежавшее значение при переводе задачи в другие статусы

                  Время логируется так, как-будто программист работает над задачей 24 часа в сутки или есть какие-то условия, что из суток логировать только 8 часов (или что-то подобное)?
                    0
                    Я натыкался на специализированные плагины, где можно настраивать рабочие часы, но сразу же их отмел т.к. часть программистов у нас ходит на одно время, а часть на другое.
                    А еще, ко всему прочему, кто-то может в какой-то день задержаться и поработать дольше.
                    Так что нет. Кнопку «В работе» надо отжимать всегда когда уходишь домой и утром опять нажимать.
                    +3
                    В JIRA одной из картинок видно, что с таском связано 17 комитов? За счёт чего достигнуто? Интеграция с crucible?

                    У нас интеграция со Stash, комиты отражены в JIRA только если в тексте комита есть названия таска (AGILE-33, BUG-123).

                    У вас просто принято за основу писать в каждый комит таск или это достигнуто за счёт других фич? Или так работает интеграция с crucible (учитываются все комиты в ветке, которая была создана из таска)?
                      0
                      Да. Я уже писал в 1й части — это из-за интеграции с FishEye и Bitbucket. И что в тексте комита должно быть название таска.
                      Вот так выглядит всплывающая форма при нажатии «3 commits»
                      (Данные из FishEye)

                      (Данные из Bitbucket)

                      А вот так, при нажатии на «2 reviews» (Данные из crucible )
                      0
                      А как у вас с регрессионным тестированием?
                        +1
                        Регрессионное тестирование обычно производится, когда все задачи версии закрыты. Программисты ответвляются в Git вновую ветку и начинают работы над следующей версией, а тестировщики проводят регресс.
                        У нас в Confluence есть статьи с чек-листами. Тестировщики обычно закреплены за определенными сферами проетка и проходят по этим чек-листам.
                        При найденных косяках обычно лид сразу же определяет по какой задаче это было сломано и задача переоткрывается.
                        После выпуска версии программисты начинают работы над следующей, а тестировщики тем временем актуализируют чек-листы.
                          0
                          У вас все проекты в Git помещаются?

                          Что делаете с тяжелыми фалами, если это фотошоп-дизайн, например?
                            0
                            Ну да. На текущий момент у нас 15 живых проектов. Все в гите.
                            Ну так как у нас контора не дизайнерская, а софтверная, то продуктом нашей работы обычно не бывают большие файлы.
                            Если это не продукт нашей разработки, а какой-то материал необходимый для разработки, то выкладываем мы его на наш внутренний ФТП, а в Jira даем на него ссылку.
                        0
                        Я правильно понял, что задача, проходя по workflow, периодически меняет исполнителя, и кто на каком этапе что делал можно понятьтолько по логу?

                        Является ли это проблемой? Нет ли желания видеть, чья задача? В каком виде в Jira видно, кто чем и насколько был загружен за какой-то период времени?

                        У закрытых на любом предыдущем этапе задач исполнителем назначается диспетер? Автоматически? На исполнителях-диспетчерах висят задачи пачками, те их раскидывают по исполнителям очередных этапов, и задачи возвращаются обратно исполнителям-диспетчерам?
                          0
                          1. Да.

                          2. Нет не является. Чья задача на текущий момент? Потому что тим лид хочет видеть какого программиста задача (кто указан в поле программист), а QA лид хочет видеть какой тестировщик за нее отвечал (кто указан в поле тестировщик). На дашборд выводили для каждого список задач, ассигнованых сейчас на него. Плюс для ПМ-а список всех членов комманды с кол-вом задач на текущий момент на них назначенных. Если надо было проанализировать прошлое, использовали доп плагин.

                          3. Выше в статье писал, Диспетчерами являются только ПМ, тимлид и QA-лид (последний только если тестировщик на задачу еще не определен). Потом все уже знают всех кто с этой задачей связан и переводят на них напрямую.

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

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