Что для нас качественный бэклог? Под самим словом бэклог будем понимать список задач, в частности пользовательских историй, которые должна реализовать команда разработки в определенные сроки. Как правило, появляются они в результате декомпозиции функциональности.
Что касается качества, то его основным критерием здесь будет результат выполнения этих задач. Другими словами, если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным. О нем и поговорим. На связи Владислав Филимонов, инженер-аналитик КОМПАС-3D.
Тезисно, для качественного бэклога необходимо, чтобы:
Аналитик знал, чего хочет от команды.
Команда понимала, что от нее хочет аналитик.
Договоренности между аналитиком и командой были зафиксированы в удобной форме и своевременно актуализировались
Задачи были приоритизированы (был план Б).
Были учтены взаимосвязи и риски.
Результат работы можно было спрогнозировать и проконтролировать
Про каждый из этих тезисов поговорим немного поподробнее, но для начала, пару слов о нашем процессе разработки.
Процесс разработки КОМПАС-3D
Мы работаем по гибкой Agile методологии с использованием Scrum. Наша разработка движется итерациями длительностью по 3 недели. Итерации объединены в технические релизы длительностью по 4 итерации каждый. Для выпуска полноценной версии продукта, как правило, у нас уходит несколько таких технических релизов (обычно 3-4). Первую итерацию каждого технического релиза мы полностью посвящаем планированию. На ней проводятся основные обсуждения будущей функциональности между аналитиками и командами разработки, делаются прототипы, происходит декомпозиция на пользовательские истории и, собственно, наполняется бэклог. Прототипирование позволяет проверить готовность сторонних модулей например, математического ядра C3D, определить дополнительные зависимости и лучше оценить трудоемкость. Поэтому данный этап очень влияет на качество бэклога, и именно в итерацию планирования мы прорабатываем большую часть требований.
Пожарная автолестница, ООО «Пожарные системы» (г.Тверь)
Декомпозиция требований
Как мы уже определили, один из критериев качества требований — это прогнозируемость их реализации. Поэтому все наши сущности разработки должны иметь реальные сроки.
Сама функциональность (фича) по срокам реализации должна укладываться в один технический релиз, а каждая из ее составных частей (пользовательских историй) не должна превышать одну итерацию разработки. Таким образом, каждую итерацию мы получаем некий прирост пользовательской функциональности, который закодирован, протестирован и может быть оценен с точки зрения ожидаемого результата. Если на этапе декомпозиции мы пониманием, что размер фичи или какой-либо истории не соответствует срокам стандартной реализации, это служит поводом для пересмотра декомпозиции. Часть функциональности может быть выделена в отдельную фичу, а история разделена на несколько.
Если говорить о подходе к декомпозиции, то мы используем вертикальное разбиение. Поэтому, как правило, одной из первых историй почти всегда является создание минимально работающей команды. Остальные истории, можно сказать, добавляют команде новые возможности и обеспечивают взаимодействие ее результата с другими частями системы.
Пользовательские истории
Пользовательская история — это форма представления требований аналитиком для передачи разработчикам. И так как истории являются основными составляющими бэклога, в какой-то степени качество зависит именно от них. Поэтому мы стараемся делать их так:
Единообразно, по единому шаблону, где зафиксированы решения, представлены макеты и написаны критерии приемки, выполнение которых является обязательным условием для завершения работы над этой задачей. Иногда критерием приемки может быть выполнение некоторого заранее известного сценария на уже имеющейся модели. Такие сценарии мы выносим в специальный раздел «Тестовые сценарии». Их выполнение также является обязательным для закрытия истории.
У всех историй есть единое место хранения. У нас это специальный раздел в системе хранения данных, структурированный по компонентам и более мелким частям продукта. Это важно, чтобы требования не дублировались, иначе будет риск при их актуализации получить противоречия. Однако для удобства мы используем плагин, позволяющий связать страничку из вики-системы с задачей в системе управления задачами и отображать там требования.
Размер пользовательской истории должен быть небольшим. Несмотря на то, что критериев приемки бывает много и список требований должен быть достаточно полным, мы стараемся не делать истории большими. Так как чем больше требований, тем сложнее контролировать результат их выполнения и появляется риск пропуска какого-то из требований.
Решения, принятые по вопросам, возникающим в ходе разработки, фиксируются в критериях приемки разрабатываемой истории.
Дополнительным инструментом для того, чтобы обеспечить полноту требований и ничего не забыть, являются чек-листы. Как правило, мы составляем их на часто повторяющиеся в разных фичах истории. Например, если посмотреть на процессы задания параметров при запуске различных команд в КОМПАС, можно найти много общего: элементы управления, подсказки, отображение результата в рабочей области, использование размеров, характерных точек и т.д. В чек-листе на описание процесса у нас содержится более 80 проверок (аналитических вопросов), по которым можно пробежаться, чтобы ничего не забыть.
Наши чек-листы были составлены совместно с тестировщиками, в т.ч. с учетом тех вопросов, которые наиболее часто возникали в ходе разработки, и требований, пропуск которых выявлялся только при подведении итогов реализации. Таким образом, в них содержится избыточное количество проверок, благодаря чему они являются довольно универсальными.
Планирование историй с учетом рисков
Как бы красиво ни писали в разных статьях про то, что истории должны быть независимые, на практике это выглядит нереализуемо. По крайней мере, у нас всегда получается так, что есть одна или нескольких основополагающих историй, без которых дальнейшая разработка невозможна. Хотя в дальнейшем истории по наращиванию функциональных возможностей в рамках одной фичи вполне могут быть независимы.
В целом, когда разработка возможна в рамках одной команды, спланировать все достаточно просто. Как правило, такое бывает, когда реализация затрагивает только функциональную часть КОМПАС, т.е. не требуется доработок на стороне ядра C3D и новых возможностей от интерфейса системы. Однако так бывает не всегда, и периодически приходится планировать реализацию сразу в нескольких командах. В этом случае, помимо времени, требуемого на реализацию, стоит учитывать и время на передачу результатов работы от одной команды другой, и риск блокирующих ошибок, который может потребовать доработок от команд-соисполнителей и заблокировать работу второй. Чтобы минимизировать такие ситуации, мы стараемся передавать между командами только полностью завершенные задачи, т.е. те, где завершены этап и кодирования, и тестирования. На это уходит достаточное количество времени, и, как следствие, реализация связанных между собой задач в рамках одной итерации — это всегда риск. При планировании работ в разных командах в одной итерации, есть вероятность того, что вторая команда не получит изменения от первой. По возможности, связанные задачи должны быть в ближайших итерациях, но не в одной. Это позволит на момент старта второй итерации знать, в каком состоянии результаты работы первой команды, и в случае чего своевременно внести корректировки в план.
Приоритизация пользовательских историй
Еще один инструмент управления рисками, это приоритизация требований. Используется он для создания некой погрешности ожидаемого результата. Есть известный подход MoSCow, в котором все требования делятся на 4 уровня важности, но в нашу привычку вошло деление на 2-3 уровня в зависимости от размера функциональности и, собственно, количества историй. Делим мы их на обязательные, важные и желательные.
Обязательные – те, которые обеспечивают выполнение основного пользовательского сценария.
Важные – те, которые сильно влияют на функциональные возможности и удобство взаимодействия с новой функциональностью.
Желательные – те, которые добавляют вспомогательные функциональные возможности или немного улучшают процесс взаимодействия. Допускается, что при возникновении проблем в разработке, историями данного приоритета можно пожертвовать.
Выбранный приоритет также влияет на то, в какую итерацию будет выполняться задача: чем он выше, тем раньше должна быть выполнена задача. Помимо значимости для пользователя, на приоритет историй также могут влиять зависимости между командами, если у истории есть зависимые, то ее приоритет выше и делать ее нужно раньше.
Изменения требований
Один из всегда актуальных вопросов в обеспечении качества бэклога - это изменения требований. Как бы мы ни старались этого избегать, на практике это практически невозможно. Требования всегда эволюционируют, изменяются, а иногда и вовсе удаляются. Как я писал ранее, большая их часть формируется на этапе прототипирования, т.е. к моменту, когда мы только начинаем техническую проработку (разработку прототипа), подробных требований может не быть. К этому моменту обычно есть только проработка Технического предложения, из которой можно понять основной набор сценариев работы, требуемый пользователям, и гипотезы, как это может быть реализовано в КОМПАС. После реализации прототипа определяется основной вариант реализации, и в соответствии с ним в требованиях появляется много конкретики.
Несмотря на то что пользовательские истории мы стараемся прорабатывать достаточно подробно, в ходе разработки часто требуется что-то скорректировать. Наиболее частые причины изменений - это:
Нашли непредусмотренный сценарий использования при тестировании.
Нашли технические ограничения в коде.
Пришло предложение от пользователей.
Пришли новые идеи по улучшению, после реализации некоторой части функциональности и аналитической оценке результата.
При возникновении таких ситуаций, когда есть желание или необходимость изменить требования, мы стараемся делать следующее:
Оценить необходимость этих изменений (возможно, изменения могут привести к регрессу или неожиданному поведению в других сценариях работы)
Если изменения точно нужны, оценить объем.
Зафиксировать изменения и внести корректировки в процесс разработки:
Бывает, что изменения касаются одного условия в коде и их трудоемкость минимальна. В таких случаях требование нужно просто добавить в критерии приемки пользовательской истории, в рамках который будет выполняться и тестироваться данное изменение.
Если изменение большое (не может быть выполнено в рамках текущей итерации) и требует серьезной доработки. Нужно выделить его в отдельную пользовательскую историю или техническую задачу. После чего приоритизировать относительно других работ с учетом зависимостей и пользовательской ценности. В соответствии с приоритетом можно пересмотреть планы ближайших итераций, иногда вытеснить работы ниже приоритетом. Если новых требований много, но с пользовательской точки зрения они являются логически отделимой доработкой функциональности, их можно вынести в отдельную фичу.
В редких случаях может быть так, что требуемые изменения противоречат большей части ранее выполненных работ по функциональности. Тогда работа над функциональностью может быть прекращена, а дальнейший план пересмотрен. Как правило, быстрое возобновление работ по той же теме невозможно, т.к. требует переработки большого количества требований.
Важно, чтобы требования по итогам разработки были актуальны и соответствовали тому, что было реализовано в продукте.
Контроль прогресса и результатов
Решение о готовности функциональности (завершении работ над фичей) обычно принимает аналитик, который ее ведет. И так как работ, выполняемых параллельно, может быть достаточно много, для отслеживания результатов и своевременного принятия решений мы используем:
Странички для отслеживания работ, это может быть либо отдельно созданная страничка, куда информация подгружается через плагины, либо страничка аналитики в системе управления задачами, где отображаются все фичи, которые ведет аналитик, и для каждого из них список входящих в него историй и задач с актуальными статусами, командой разработки и номерами итераций, где они должны выполняться.
На каждую функциональность мы создаем отдельный чатик в рабочем мессенджере, чтобы любой из участников разработки мог по мере появления вопросов, сразу его задать либо инициировать обсуждение.
В зависимости от количества команд, в которых разрабатывается функциональность, аналитик также может участвовать в ежедневных митингах с командой, либо еженедельных совещаниях по компоненту, где участвуют лидеры команд, занимающиеся одним направлениям в разработке продукта.
Ну и конечно, мы, аналитики, сами визуально оцениваем и функционально проверяем на рабочих задачах то, что получается непосредственно в продукте.
А вообще, помимо всех инструментов, не стоит забывать самого важного, что для прогнозируемого и ожидаемого результата не стоит пренебрегать личным общением с разработчиками, это позволяет не только лучше погрузиться в контекст выполняемой работы, но и узнавать об особенностях реализации и технических нюансах системы.
Всем отзывчивых коллег, интересных задач и, конечно, качественного бэклога!
