Введение
С развитием прикладных решений 1С многие команды разработки задумываются об использовании методологии agile. Теперь для автоматизации бизнес-процессов в крупных организациях недостаточно одного-двух программистов. Как правило, команда разработки 1С состоит из Project-менеджера, Аналитиков, Тимлида, Разработчиков, Тестировщиков и, возможно, Тех. поддержки. Project-менеджер составляет планы проектов, распределяет деньги, управляет сроками, настраивает коммуникации, общается с заказчиками, согласовывает требования. Аналитики - собирают требования бизнеса; ставят задачи программистам; настраивают, тестируют и презентуют разработанные фичи. Разработчики пишут новые или дорабатывают существующие конфигурации; разрабатывают пользовательские интерфейсы; создают структуры баз данных. Тестировщики занимаются ручным и автоматизированным тестированием; пишут сценарии тестирования. Специалисты тех. поддержки решают срочные пользовательские обращения. Это может быть как разработчик, так и консультант. Подробнее об обязанностях и компетенциях специалистов 1С поговорим в следующей публикации.
Конечно, конфигурации тоже не стоят на месте. Используются новые инструменты при разработке, такие как EDT, Sonar Qube, GIT. Развиваются приемы тестирования. В некоторых командах можно встретить практику разработки через тестирование (TDD). Сценарное тестирование (BDD) используется еще чаще.
При развитии платформы, инструментов разработки, усилением команд напрашивается подход с применением практик agile. Возникает потребность частичной поставки фич заказчику; эффективного планирования команды; гибкости к требованиям клиента; прозрачности в этапах работы. Как известно методология гибкой разработки успешно закрывает эти вопросы. В данной заметке я попытаюсь показать подходы agile в командах 1С на примере методологии scrum.
Церемонии/Ритуалы
Коммуникации в agile команде организованы, в основном, по средствам запланированных встреч. Такие мероприятия называются церемониями, ритуалами, митингами и тд. Рассмотрим подробнее несколько популярных встреч, присутствующих практически в любой команде agile.
Планирование - встреча, на которой команда распределяет задачи по разработчикам. Как правило, аналитики заранее составляют пул задач для разработки (беклог). Это могут быть как сложные проекты, разбитые на этапы, так и мелкие доработки с сервис-деска, либо баги.
Ежедневный стенд-ап - это собрание (созвон) когда каждый член команды рассказывает остальным что удалось совершить за прошедшее время. Также на такой встрече обсуждаются плановые задачи текущего дня, разбираются накопившиеся за прошедший день вопросы. На встрече присутствуют все члены команды.
Обзор спринта (Sprint Review) - встреча по обзору выполненных задач. На доске agile(о ней поговорим позже) ставится фильтр на колонку "Выполнено", после чего происходит мини-демонстрация и обзор задач. На данной встрече могут присутствовать как члены команды, так и внешние сотрудники - руководство, клиенты и др.
Ретроспектива спринта - заключительная встреча, обозревающая проделанную работу команды со стороны. Что получилось? Что не получилось? Команда анализирует и оценивает собственный прогресс, а также анализирует что можно улучшить. Как правило участие во встрече принимают только члены команды.
Помимо вышеперечисленных мероприятий существует еще масса других: PBR, Backlog grooming, 1:1 и т.д. Agile - гибкая методология, поэтому команды могут сами определять состав мероприятий.
Одно из любопытных мероприятий, практикующее в некоторых командах - Покер планирования (Planning Poker). Встреча посвящена оценке задач. В покере по методу Planning Poker участвует вся команда во главе с менеджером проектов - это одно из условий. Руководитель раздаёт всем участникам по колоде специальных карт. Можно использовать реальные карты. Для удалённой команды подойдут онлайн-сервисы. Правила оценки при этом не изменятся. Процесс игры следующий: берется задача из беклога, зачитывается ведущим встречи, после чего разработчики одновременно и независимо вскрывают карту со своей оценкой. Если все карты близки по значениям, команда оценила задачу примерно одинаково и можно на этом закончить. Если карты с оценками отличаются, то каждый член команды объясняет свое решение в выборе. Обычно реальность находится где-то посередине. Таким образом история оценивается обоснованно и объективно.
Основные процессы в Scrum
Оценка задач
Разберемся подробнее с основными процессами agile на примере scrum. После постановки задач аналитиками, от разработчиков требуется оценка. В agile командах часто используется подход относительных размеров оценки задач. Определяется задача на оценку 1 - это история, которую невозможно, либо не нужно декомпозировать. История, которой присвоена оценка 2 будет в два раза больше чем история, которой присвоена оценка 1 и тд. Какой-то явной формулы для определения размера истории не существует. Оценка в таких условных единицах - это, скорее, сочетание трудоемкости разработки функции, сложности ее разработки, риска, присущего разработке и тп. Чаще всего в качестве пунктов оценки задач используется последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Пункты 8,13,21 стараются декомпозировать на более мелкие, однако иногда оставляют так как есть. В качестве примеров рассмотрим оценки задач, применительно к 1С разработке. Задача на 1 пункт - это может быть разработка какого-нибудь элементарного варианта отчета; добавление реквизита объекта; добавление новой роли; описание документации АПИ и тд. Оценка 2 может присвоиться задаче, например, по заполнению первоначальных данных; по разработке не сложного внешнего отчета, обработки, печатной формы; небольшой доработке правил КД, написанию несложного юнит-теста и тд. Оценка 3 ставится задачам еще тяжелее. Например, на разработку отчета по нескольким источникам; разработку несложного АПИ; доработку типовой логики расчета среднего заработка в отпусках/командировках; анализ и отладку типовой ошибки расчета себестоимости и тд. Пятерка присваивается задачам, реализация которых предусматривает некоторые особенности. Например, до конца не принята архитектура разрабатываемого процесса; не описан желаемый интерфейс; нет уверенности, что разработка обойдется только "проверенными" инструментами; сложная логика процесса и тд. Оценки 8, 13, 21 говорят о высоком риске и большой неопределенности задачи, либо о большой сложности. Как правило их стараются разбить на более мелкие истории. Так, например, задача по рефакторингу процесса Скидок в Рознице имеет большие риски и высокую степень неопределенности. Помимо фикса легаси-кода, возможно придется модернизировать архитектуру. Еще один пример - выгрузка данных по номенклатуре. Например, заказчик требует выполнить задачу, используя некий брокер сообщений. В таком случае, оценка задачи может составить 13 пунктов, однако декомпозируя выгрузку на: разработку триггера; обработку и формирование сообщения выгружаемых данных; непосредственную выгрузку; написание документации, историю получится разбить на пункты 3, 3, 3, 1. Таким образом, зная скорость работы команды и сложность задач, оцененную в пунктах определяется приблизительный срок проекта.
Scrum-доска
Планирование, распределение и оценка задач происходит на Scrum-доске (Рисунок 1). Scrum-доска похожа на многоколоночный список элементов, позволяющий команде разработчиков:
- отслеживать все задачи, которые необходимо решить, работая над текущим проектом;
- контролировать процесс работы. Наблюдать за сотрудниками и грамотно распределять между ними задачи/функции;
- следить за прогрессом текущего спринта. Чтобы задачи вовремя попадали в список выполненных;
- проводить аналитические совещания с целью обсудить успехи команды.
В бэклог добавляются истории от аналитиков. В колонку "Сделать" переносятся задачи на разработку. "В работе" показывает какими задачами сейчас занят разработчик. "Сделано" - выполненные задачи. Доска может быть гибкой. Часто команды добавляют свои колонки, либо удаляют не нужные. Например, 1С-разработчики с развитием инструментов используют еще статусы "На ревью", "В тестировании".
Рисунок 1 - Scrum-доска
Спринты
Итерацией в Scrum называют отрезок времени, в течение которого команда готова предоставить новые фичи клиенту. По-другому итерации называют спринтами. Размер спринта по большей части зависит от специфики проекта и обычно составляет от одной недели до 2х месяцев. Универсальной длины, подходящей всем командам не существует. Каждая команда должна исходить из конкретной ситуации при подборе длины. В число факторов, влияющих на это решение, входят:
- длина релиза;
- уровень неопределенности;
- простота получения обратной связи;
- продолжительность сохранения неизменности приоритетов;
- готовность продолжать работу без получения внешней обратной связи;
- издержки итерационного подхода;
- быстрота появления ощущения острой нехватки времени.
Количество выполненных пунктов в одну итерацию зависит от укомплектованности команды, а также от скорости работы. Перед запуском спринта планируются, приоритизируются и распределяются задачи проекта. После разработки, задача передается аналитику (в 1С часто именно аналитики выполняют пользовательское тестирование). Далее задача закрывается аналитиком, после чего фичу можно передавать в продакшн. По окончании спринта команда проводит анализ выполненных задач - ретроспектива. Невыполненные по каким-либо причинам задачи переходят на следующую итерацию.
Перепланирование
В рамках итерации команде нередко приходится отклоняться от плана. Возникающие баги, срочные задачи, незапланированные отсутствия сотрудников вынуждают к перепланированию спринта. Методология agile это предполагает. Команда должна быть готова к появлению срочных задач, к смене приоритезации историй и к багам. Смена приоритетов задач, включение новых требований в итерацию, исключение историй из беклога - все это способствует качеству разрабатываемого продукта, а также лояльности клиента. Как итог спринт закроется без некоторых фич, но будут удовлетворены просьбы клиента и исправлены замечания. Однако не следует проводить переоценку только потому, что прогресс идет не так быстро, как ожидалось. Переоценка требуется, когда изменяется относительный размер одной или нескольких историй. Таким образом, не следует увлекаться процессом переоценки. Когда выясняется, что одна или несколько задач оценены неправильно относительно других, нужно стараться переоценивать как можно меньше объектов, ограничиваясь лишь сопоставлением относительных оценок.
Гибкая разработка - залог успеха
В заключении отметим основные преимущества подходов agile. Гибкая разработка приводит к непосредственному общению команды с бизнесом. Учитываются приоритеты историй, но в то же время команда готова оперативно подстроиться под новые требования. Разработка проекта сводится к серии коротких итераций, которые обычно длятся несколько недель. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности. Приоритизация, оценка в пунктах и перепланирование позволяют минимизировать риски и неопределенности. 1С разработка прекрасно подстраивается под описанные практики и подходы.
Основные плюсы:
- Нет нужды составлять длинное ТЗ - вместо этого формируется гибкий список задач на основе желаний клиента.
- Бюджет гибкий - если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
- Меньше бюрократии - нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.
P.S.: Публикация подготовлена по книге "Agile: оценка и планирование проектов" Майк Кон.
