В нашей компании создается большой программный продукт. ПО тестируется, обнаруживаются новые баги, выкладываются тикеты. И всё это продолжается и продолжается. Иногда когда смотришь на Stream-ленту, кажется, что она бесконечна, ты делаешь один тикет, на его месте появляется ещё два. Так было до сегодняшнего дня.

Итак, в начале немного теории. Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с добавленными возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Главные действующие роли в Scrum:

ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster);

Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональную Команду (Scrum Team), состоящую как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

На протяжении каждого спринта, 15-30 дневного периода (длительность определяется командой), создаётся функциональный рост программного обеспечения.

Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

Мы захотели понимать, сколько работы мы делаем, и сколько работы осталось делать. В поисках подходящей методологии управления проектом я наткнулся на Scrum. Ну как наткнулся, я давно о нём знал, и всегда хотел внедрить, НО был ряд факторов, которые не давали этого сделать:

1. В конце каждого спринта (итерации) должен быть работающий продукт. А у нас продукт находится в стадии разработки.
2. Очень хорошим подспорьем для первого пункта является наличие автотестов. У нас их нет.
3. Скрам хорошо работает, когда можно оценить объем работы. Наш проект сейчас активно отлаживается, новой работы как таковой нет, а вот оценить время исправление того или иного бага очень затруднительно. Иногда можно весь день просидеть анализируя его и за пять секунд исправить.

Тем не менее мной было принято решение о переходе на Scrum и запуске первого (тестового) спринта. Во-первых были проанализированы текущие тикеты. Некоторые из них были забракованы как неактуальные (invalid), некоторые как уже готовые (fixed)Ю другие же мы протестировали вместе с коллегой. После этого количество тикетов уменьшилось в несколько раз.

Далее я выделил те тикеты, над которыми не будет работать непосредственно команда (они связаны с внешней интегрируемой системой), а также те из ник которые связаны с реализацией нового функционала (они просто висели в куче). Всех их я отправил в этап (milestone) Спринт X. X значит, ХЗ когда он начнется. Дышать стало легче. Затем настало время определиться с временем, которые программисты затратят на выполнение тикетов. Измерять всё в часах трудно, поэтому мастера Scrum’а советуют сделать так. Выбрать одну небольшую (но и не маленькую) задачу, время работы над которой обозначить как 1 Story Point. И измерять всю другую работу в этих story point’ах. Меряем в попугаях, ага. Это нужно, чтобы отвязаться от часов, т.к. потом получится, что один час в системе вообще никак не будет связан с одним часом реального времени. Ну так вот, я выбрал такую задачу, измерил остальные относительно её и дал тикетам приоритет важности. После этого распределил тикеты на ближайший спринт и следующий за ним. Длину спринта мы взяли одну неделю, чтобы было проще работать.

Вообще первый спринт это своего рода сбор статистики, первоначальных данных, поэтому все оценки ну ооочень примерные. В конце спринта (в следующую пятницу) мы сделаем ретроспективу, и спланируем следующий спринт.

В конце рабочего дня программист заполняет StandUp Report (Scrum Daily Meeting) и после этого у меня будет отчеты всех сотрудников, на основе которых можно будет сделать командный отчет. Также очень важно, чтобы при фиксации тикетов разработчики писали реально затраченное время на этот тикет. Из этих цифр в последствии и будет образовываться статистика, и можно будет планировать работу команды дальше.

Что будет дальше? Время покажет. А мы в понедельник совершим наш первый забег 🙂