Citygile

version: post-draft от 11 ноября 2021

История версий:

• draft от 1 июля 2021

📢 DISCLAIMER

⛓️ Citygile находится в статусе черновика

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

Оглавление

Почему Citygile?

💡 Citygile — не альтернатива Agile, это правила, по которым Agile живет в Ситимобил и Ситидрайв

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

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

Мы решили систематизировать и унифицировать все практики в одну:

• прописать ожидания каждому артефакту процесса и дать единые имена;
• добавить общие рекомендации и best practices.

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

Критерии применимости

Мы выделяем три подхода к разработке программного обеспечения:

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

Для каждого из этих трёх подходов существуют методики разработки программного обеспечения. Методика, которая хорошо подходит под один подход — может навредить в другом.

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

💡 «С помощью Citygile нельзя построить мост»

Citygile не Scrum

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

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

Scrum Guide Russian, Ноябрь 2020, 14 страница

Не смотря на то, что Citygile в чем-то вдохновлялся Scrum и имеет с ним много общего, Citygile имеет фундаментальные различия со Scrum и поэтому не может считаться Scrum-like фреймворком или методологией.

Фундаментальные различия

Фреймворк Scrum намеренно неполный, и определяет только части, необходимые для реализации теории Scrum. <...> Scrum не предоставляет людям подробных инструкций, а вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей.

Scrum Guide Russian, Ноябрь 2020, 4 страница

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

💡 Не смотря на исчерпывающее руководство, мы придерживаемся Agile-ценности:

Люди и взаимодействие важнее процессов и инструментов.

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

Таким образом, Citygile — это не «yet another development methodology», а культура, объединившая в себя все накопленные практики и опыт, которые мы формализовали в одном документе.

Стоит отметить, что Citygile не даёт чётких и последовательных инструкций с чек-листами для своих артефактов, процессов и ролей — он описывает лишь ожидания от них и даёт необходимые советы. Несмотря на выполнение ожиданий, конечный образ процессов зависит от самих команд, которые используют Citygile.

Перед внедрением Citygile в своих командах, мы настоятельно рекомендуем прочитать этот документ несколько раз, и после внедрения возвращаться к нему для поиска ответов на возникшие вопросы.

Scrum Team состоит из одного Scrum Master, одного Product Owner и Developers. Внутри Scrum Team нет подкоманд и иерархий. <...> Scrum Teams являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint.

Scrum Guide Russian, Ноябрь 2020, 6 страница

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

Кросс-функциональность, это недостижимое требование, которое мы не в состоянии удовлетворить.

Наши команды не кросс-функциональные, а кросс-платформенные и состоят из инженеров различных платформ (iOS, Android, Back-end, Front-end), а также из Q.A. инженеров. Q.A. инженер не может выполнить задачу для iOS, а iOS-разработчик не сможет выполнить задачу для Android.

В каждой кросс-платформенной команде есть под-команды iOS, Android, Back-end, Front-end и Q.A. Помимо этого, команда выступает заказчиком для смежных платформенных команд (SysOps, DevOps, DWH), поскольку они не являются частью наших кросс-платформенных команд.

Также у нас есть платформенные команды (Platform Team и Q.A. Team), которые обладают только одним навыком.

Вся Scrum Team несет ответственность за создание ценного, полезного Increment в каждом Sprint <...> Каждый Sprint можно считать коротким проектом <...> ... вся Scrum Team совместно определяет Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц.

Scrum Guide Russian, Ноябрь 2020, 6, 9 и 10 страницы

Мы также работаем итерациями (спринтами).

💡 Спринт — это четко ограниченный по времени период, в рамках которого мы обязуемся выполнить часть запланированных задач.

Но, в отличие от Scrum, наши спринты могут не иметь явно формализованной цели.

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

Более того, наши спринты даже могут не выдавать новой пользы для заказчика. Пользу заказчик может получить только после реализации всей фичи, которая займет несколько спринтов.

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

Фундаментальное сходство

Не смотря на фундаментальные различия, у Citygile и Scrum есть фундаментальное сходство — мы не поощряем изменения идей или структуры Citygile и мы явно и открыто это проговариваем.

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

Scrum Guide Russian, Ноябрь 2020, 2 страница

Нельзя использовать какие-то части Citygile по-отдельности или комбинировать отдельные части с какими-то другими подходами. Вы либо применяете все артефакты, роли и процессы Citygile, либо получаете непредсказуемый процесс.

Так, например, нельзя взять оценку задач через CityPoint и применять ее не в итерациях, а в Kanban — ничего не получится. Если и использоваться CityPoint, то только в связке с итерациями, расчетом Capacity и наложением Focus Factor.

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

Структура команд

Когда мы говорим про команды разработки и тестирования, мы говорим о сотрудниках следующих должностей:

• iOS Developer
• Android Developer
• Back-end Developer
• Front-end Developer
• Q.A. Engineer

💡 Для упрощения повествования, далее, сотрудников должностей iOS Developer, Android Developer, Back-end Developer и Front-end Developer мы будем называть просто Developer. А сотрудников должности Q.A. Engineer будем называть просто Q.A.

Все сотрудники административно поделены на группы разработки и группы тестирования. Каждая группа объединяет сотрудников из одной платформы, например, группа iOS разработки или группа автоматизированного тестирования.

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

Помимо прочего, руководитель группы разработки отвечает за:

• найм и удержание сотрудников своей группы
• увеличение скорости разработки сотрудников группы
• стабильность сервисов и продуктов, которые делают сотрудники его группы

Помимо прочего, руководитель группы тестирования отвечает за:

• найм и удержание сотрудников своей группы
• увеличение скорости процессов тестирования своей группы
• полноту и глубину тестового покрытия задач своей группы

💡 Мы рекомендуем формировать группы разработки и тестирования не более чем из семи человек: руководитель группы и шесть сотрудников

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

Cross-platform Team

Кросс-платформенная команда — это команда, которая состоит из сотрудников различных по платформе групп разработки и тестирования.

Обычно, это команда, которая реализует продукты с UI.

💡 Важно, чтобы сотрудники одной платформы в кросс-платформенной команде находились в одной и той же группе разработки. Так, например, если в кросс-платформенной команде два Android-разработчика, то оба они должны находиться в одной и той же группе Android-разработки. Не может быть так, что один Android-разработчик из одной группы разработки, а второй Android-разработчик из другой группы разработки. Другими словами, у сотрудников одной платформы, в кросс-платформенной команде должен быть один руководитель группы разработки. Такое же правильно распространяется и на сотрудников из группы тестирования.

Кросс-платформенная команда может иметь различные конфигурации, например:

• iOS + Android
• iOS + Android + Q.A.
• iOS + Android + Back-end
• iOS + Android + Back-end + Q.A.
• Android + Back-end
• Android + Back-end + Q.A.
• Front-end + Back-end
• Front-end + Back-end + Q.A.

В кросс-платформенных командах, представителей каждой платформы мы называем «платформенной под-командой».

💡 Для увеличения bus factor, мы настоятельно рекомендуем собирать кросс-платформенные команды с минимум двумя сотрудниками в платформенных под-командах.

Маленькие команды проворнее больших — они лучше общаются и более продуктивны. Поэтому, мы настоятельно рекомендуем собирать кросс-платформенные команды не более чем из 9 сотрудников.

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

💡 Помните, что количество возможных коммуникаций в команде находится в квадратной зависимости от количества участников команды: (N х (N – 1)) / 2, где N – количество людей

Platform Team

Платформенная команда — это обычная группа разработки, которая состоит из сотрудников одной платформы, например только из Back-end разработчиков и руководителя этой группы разработки.

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

Кросс-платформенные команды могут иметь конфигурацию, в которой нет, например, Back-end разработчиков. Но не смотря на это, этим командам по прежнему нужны ресурсы Back-end разработки. В этом случае, эти команды прибегают к помощи Back-end Platform Team и разделяют ресурсы Back-end разработки с другими кросс-платформенными командами аналогичной конфигурации.

💡 Далее, для упрощения, мы будем использовать термин «платформенная команда» как в случае обозначения Platform Team, так и для обозначения платформенной под-команды, которая находится в рамках кросс-платформенной команды

Q.A. Team

Команда тестирования — это обычная группа тестирования, которая состоит только из Q.A. инженеров и руководителя этой группы тестирования.

Кросс-платформенные команды могут иметь конфигурацию, в которой нет Q.A. инженеров, также Q.A. инженеров нет и в платформенных командах. Но не смотря на это, этим командам по прежнему нужны ресурсы тестирования. В этом случае, эти команды прибегают к помощи Q.A. Team и разделяют ресурсы тестирования с другими командами.

Virtual Team

Виртуальная команда — это команда, которая состоит из сотрудников различных групп разработки и тестирования, которые находятся в различных отделах компании.

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

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

Виртуальная команда должна быть самодостаточна для реализации проекта, ради которого была собрана эта виртуальная команда. Другими словами, она не должна зависеть от других платформенных или команд тестирования.

Гонка за ресурсами

Идеальной конфигурацией команд являются кросс-платформенные команды, которые состоят из сотрудников всех необходимых специальностей, и команде не приходится прибегать к услугами Platform и Q.A. Team.

Но как показывает практика, нагрузка на разные платформенные под-команды в рамках нескольких кросс-платформенных команд распределяется не равномерно и случается так, что в одной кросс-платформенной команде Back-end разработчики сильно перегружены и работают на износ, а в другой кросс-платформенной команде Back-end разработчики сильно недозагружены. Такое сравнение допустимы и для Q.A. инженеров.

Для того чтобы сбалансировать нагрузку, мы можем вывести Back-end разработчиков из кросс-платформенных команд в Platform Team и эта Platform Team будет обслуживать интересы этих кросс-платформенных команд.

Тут важно понимать, что после выделения Back-end разработчиков из кросс-платформенных команд, объём задач на Back-end платформу от этих кросс-платформенных команд не меняется, но теперь он оптимальнее распределяется между Back-end разработчиками одной Platform Team.

Поэтому гонки за ресурсами Back-end разработки у кросс-платформенных команд не может появиться.

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

Роли

Для генерации и доставки value до конечных пользователей необходима совместная деятельность двух команд — Discovery и Delivery.

Discovery Team состоит из Product Manager, Product Analyst и Designer. Основная задача Discovery Team — выработать и проработать продуктовую гипотезу, которая может принести value конечному пользователю или бизнесу в целом.

Точкой входа в Discovery Team является Product Manager — он отвечает за вектор развития продукта.

Проработанная продуктовая гипотеза, которая требует реализации, передается Delivery Team.

💡 Delivery Team — это всегда: либо кросс-платформенная команда, либо платформенная команда, либо виртуальная команда. Но ни как не команда тестирования.

Основная задача Delivery Team — принять от Discovery Team проработанную задачу (далее, Feature), согласиться с возможность ее реализации (или вернуть на доработку), дать предварительную оценку и взять в реализацию.

💡 Поскольку мы придерживаемся Agile-ценности:

Сотрудничество с заказчиком важнее согласования условий контракта

то совместная работа Delivery Team и Discovery Team строится на доверительных и партнерских отношениях.

Feature должна представлять из себя Product Requirements Document (далее, PRD), который должен включать в себя все необходимые артефакты (например прототипы, макеты или документацию для внешней интеграции). Дальнейшую техническую проработку и заведение задач в трекер берет на себя Delivery Team.

За каждую Feature, внутри Delivery Team, должен быть закреплен ответственный — Feature Lead, который отвечает за:

• техническую проработку Feature и передачу ее участникам команды для дальнейшей декомпозиции и заведения задач в Jira;
• трекинг заведенных задач в Jira;
• синхронизацию команды с другими смежными командами и Discovery Team в рамках этой Feature;
• координацию сроков выполнения Feature и ее поставку конечным пользователям.

💡 Мы осознанно не вводим роль системного аналитика в командах для анализа и детальной проработки требований Feature, посколько не хотим создавать посредников между Discovery и Delivery Team. Для нас важно, чтобы Delivery Team не просто закрывали тикеты, а погружались в предметную область бизнеса и даже в продуктовые метрики и финансовые показатели и заботились о том, как их фичи влияют на конечного пользователя. Мы считаем, что знание зачем мы что-то делаем позволяет делать это действительно хорошо и не поддаваться желанию делать это тогда, когда оно не нужно.

Главная задача для Feature Lead — «дотащить» Feature до production, при этом удовлетворить потребности Discovery Team.

В качестве Feature Lead может выступать любой Developer из Delivery Team с должным уровнем компетенций (hard и soft skills). У одной Feature может быть только один ответственный Feature Lead. Рекомендуется, чтобы в один момент времени у Feature Lead была только одна Feature в ответственности.

В кросс-платформенных командах, один из разработчиков может выполнять роль Cross Lead.

💡 Мы считаем, что роль Crosslead является необходимым опытом, для дальнейшего роста сотрудника в руководителя группы.

Cross Lead является главной точкой входа в Delivery Team для Discovery Team, и отвечает за:

• эффективность команды и организацию процесса работы;
• фасилитацию Citygile-встреч;
• а также выступает в качестве Feature Lead для всех задач команды и/или распределяет Feature Leading внутри команды.

💡 Когда мы говорим, что Cross Lead — это точка входа в Delivery Team, а Product Manager — это точка входа в Discovery Team, это не запрещает коммуницировать участникам Delivery Team с участниками Discovery Team напрямую. Наоборот мы за прямые коммуникации и минимизацию посредников там, где можно обойтись без них

В платформенных командах, роль Cross Lead выполняет руководитель группы.

Задачи

💡 Мы не хотим плодить сущности и создавать обильное количество типов задач, которые в конечном счете имеют одно и тоже действие — написание кода.

Мы используем следующие типы задач:

• Task как основной тип задач
• Sub-task для декомпозиции Task
• Bug для ведения дефектов
• Note для ведения заметок, исследований и напоминалок
• Epic для объединения Task, Bug и Note

Типы

Task

Основной тип задач команды. Итогом выполнения Task является вмерженный Merge Request.

Task описывает задачи, которые:

• привносят или улучшают текущую функциональность продукта;
• служат для избавления от технического долга, рефакторинг;

Рекомендуем реализовывать Task в течении одной итерации. Может содержать Sub-Task.

Мы всегда используем Specific и Measurable из методики «SMART» для описания Task и Sub-task, поэтому задача должна содержать конкретное описание того, что нужно сделать и любой исполнитель этой задачи может понять что нужно сделать, чтобы считать задачу выполненной.

Например, не «отрефакторить метод getptice», а «перевести все походы в mysql в методе getprice на redis». Когда мы говорим о «отрефакторить метод getptice», мы не обозначаем definition of done и не можем оценить, когда считать задачу выполненной. Во втором же случае, мы четко описываем результат, которого хотим достичь.

Sub-task

Внутренняя задача команды разработки. Видна только внутри карточки Task и не видна на борде команды.

Основное предназначение Sub-task — декомпозиция большой Task на маленькие Sub-task с оценкой для каждой. Сумма оцененных Sub-task и будет конечной оценкой для Task.

Команда может использовать связанные Task для декомпозиции большой задачи, вместо использования Sub-task.

💡 Мы хотим, что бы процесс Code Review проходил гораздо быстрее и приносил более качественный результат. Мы заметили, что маленький Merge Request проходит быстрее и собирает более качественные комментарии. Хорошей практикой является деление большой задачи на Sub-task с маленькими MR, которые впоследствии вливаются в ветку основной задачи.

Sub-Task имеет свой маленький flow и мы никак не отображаем их на доске — это внутренняя структура для Task, которая используется исключительно командой разработки.

Bug

Задача, которая используется для ведения дефектов и фиксирует несоответствие продукта установленным требованиям, которое должно быть устранено.

Рекомендуем исправлять Bug в течении одного спринта. Bug не может содержать Sub-Task.

💡 К сожалению, в каждодневной спешке очень много внимания уделяется поиску дефектов, а не их оформлению. Важно не просто найти дефект, но и грамотно его описать. Сделать это надо таким образом, чтобы другие люди смогли его понять и воспроизвести. Чем больше данных мы предоставим к дефекту, тем меньше времени потратит:

• разработчик — в попытке разобраться, о чем идет речь;
• тестировщик — в попытке воспроизвести заведенный дефект после фикса.

Любое описание дефектов должно содержать:

• Название, созданное по принципу «Где? Что? Когда?» Шаги воспроизведения — максимально детально расписанные шаги, по которым данный дефект можно воспроизвести.
• Фактический результат — описание того, что по версии автора дефекта является дефектом.
• Ожидаемый результат — описание того, что ожидает видеть автор дефекта. Приветствуется прикладывание источников правды — таких как ссылки на спеки / Figma.

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

Note

Особый тип задачи с примитивным flow. Не требует написания кода.

Основное предназначение Note — ведение заметок, для отслеживания их статуса.

Например, Note может быть использован, как:

• research членом команды по какому-то вопросу. Результат research, может приводить к заведению реальных Task или Bug или пополнению базы знаний проекта;
• задача смежной команде. Когда смежной команде ставится задача в их собственный проект и заводится Note, связанный с этой задачей;
• какое-то обязательное действие в конце итерации, которое нужно не забыть выполнить (например, включить feature toggle для новых фич).

В случае, когда Developer не может оценить задачу типа Bug, и для точной оценки ему необходима дополнительная информация, которую он может получить в результате исследования, то Developer может завести задачу типа Note для исследования и связать её с задачей типа Bug.

Epic

Все большие продуктовые задачи, от Discovery Team, Delivery Teamполучает в виде Product Requirements Document. После технической проработки этого документа, Delivery Team формирует Technical Specification Document. Большие технические задачи Delivery Team сразу формирует в виде TSD.

Каждая платформенная команда декомпозирует TSD до уровня задач типа Task и Note.

Epic используется как сущность, которая объединяет в себе все задачи, которые являются декомпозицией TSD.

Поскольку Epic содержит в себе конечный набор задач, то важна реализация всех задач из Epic в ограниченное время. Другими словами, мы не используем Epic для логического объединения задач из одной области с возможностью непрерывного добавления задач в этот Epic и отсутствия понимания когда он будет выполнен целиком. Для простой группировки задач, вы можете использовать другие инструменты своего task tracker, например labels.

Epic может существовать на протяжении нескольких итераций.

Если TSD подразумевает работу только одной платформенной команды, то Feature Lead заводит Epic (который мы называем Feature Epic) и платформенная команда крепит все задачи к нему.

Если TSD подразумевает работу нескольких платформенных команд, то Feature Lead заводит Feature Epic и есть три подхода прикрепления задач к этому Feature Epic:

• Платформенные команды, заводя задачи крепят их к этому Feature Epic;
• Каждая платформенная команда заводит под свою платформу Epic (который мы называем Platform Epic), и заводя задачи крепит их к этому Platform Epic. Platform Epic связывается с родительским Feature Epic;
• Смещанный вариант, когда, в зависимости от объёма задач, платформенная команда принимает решение крепить задачи напрямую к Feature Epic или через Platform Epic.

💡 Для того, чтобы быстрее получать feedback от конечных пользователей, мы настоятельно рекомендуем разбивать Feature Epic, который невозможно выполнить за один спринт, на несколько независимых Feature Epic, которые можно выполнить в рамках одного спринта.

Приоритеты

Приоритет	Описание
Highest	Задача не требует отлагательств и ее надо брать в работу прямо сейчас, прямо в активный спринт. Причем, работа над задачами с меньшим приоритетом в текущей итерации приостанавливается, пока не будет решена проблема из этой задачи. Скорее всего это какой-то массовый баг или краш, из-за которого страдают наши пользователи. Команда должна всеми силами минимизировать количество таких задач, обсуждая на ретро причину их появления и вырабатывая план их не появления.
High	Заказчик заинтересован, чтобы мы взяли эту задачу в следующую итерацию в первую очередь. Поэтому эта задача будет оцениваться раньше всех и на планировании первой пойдет в бэклог новой итерации.
Medium	Задача с обычным приоритетом. Войдет в итерацию в порядке очереди.
Low	Задача «на потом». Заводится, преимущественно, чтобы не забыть. Не требует детального описания и будет взята в работу, когда совсем нечего будет делать, если кто-то вспомнит что по ней вообще надо сделать.

💡 В вашем трекере задач может быть больше видов приоритетов, но для работы Citygile достаточно всего четырех.

Если во время очередной итерации у команды возникает задача приоритета Highest, то команда безотлагательно берет ее в работу. Причем, все и Delivery Team и Discovery Team понимают, что это приводит к сдвигу сроков поставки задач из текущей итерации и готовы на такой шаг.

Если во время очередной итерации у команды возникает задача приоритета High, которая не может ждать выполнения в следующей итерации, то Discovery Team должна выбрать не начатые задачи из текущей итерации с сопоставимой оценкой в качестве кандидатов на удаление из текущей итерации.

💡 Мы за фокусировку и против multitasking, поэтому не бросаем начатые задачи, чтобы переключиться на другие, хоть и более приоритетные. Все начатые задачи либо доводятся до конца, либо считаются «не требующими завершения» и удаляются из беклога.

Оценка

Мы оцениваем не сложность задачи, а время, которое необходимо потратить на ее реализацию инженером уровня Middle. Понятно, что инженер уровня Junior будет выполнять задачу дольше, а инженер уровня Senior — быстрее.

Мы оцениваем только чистое время разработки, которое должно включать:

• написание кода;
• написание unit-тестов;
• написание документации;
• self тестирование;
• self код ревью.

Такие факторы, как:

• код ревью коллегами;
• тестирование Q.A. инженером.

в оценку выполнения задачи входить не должны.

Для оценки задач мы используем абстрактную величину — CityPoint (далее CP), которая аналогична часам, но в оценке задач можно использовать только значения: 1, 2, 4, 8 и 16.

Citypoint (CP)	~ время	Описание
1	~ 0.5 часа	Мелкая задача которая ничего не стоит, например сходить за кофе
2	до 2х часов	Что-то надо поделать, например запилить кнопочку или фантик на пару часиков
4	до 4х часов	В день можно вытащить пару таких задач
8	до 1 дня	Задача точно отнимет весь рабочий день
16	до 2х дней	Объёмная задача, отнимет один день и перетечет на второй и его тоже отнимет

💡 Нет необходимости в точной оценке в часах. Главное для нас — понимание объема задач и объем, который мы можем гарантированно выполнить за итерацию. Если есть уверенность, что задачу можно выполнить за 3 часа — нет смысла декомпозировать ее на Sub-task в 1 и 2 часа, правильнее будет оценить всю задачу в 4 CP и точно уложиться в этот срок.

Минимальная оценка Task, Sub-task, Bug и Note — 1 CP

В случае, если есть желание оценить задачу меньше, чем 1 CP, то следует все равно поставить 1 CP.

Максимальная оценка Task, Bug и Note — 16 CP

В случае, если есть желание оценить задачу больше, чем на 16 CP, следует:

• декомпозировать Task на несколько Sub-task. Сумма всех Sub-task внутри этого Task и будет итоговой оценкой для Task
• декомпозировать Task на несколько независимых Task и оценить их в отдельности

Когда мы декомпозируем Task на Sub-task, то итоговая оценка Task будет являться суммой всех его Sub-task и может быть сильно больше максимальной оценки в 16 CP. Это приемлемо, главное, чтобы этот Task был точно выполнен одним разработчиком в пределах одного спринта. Если есть риск, что выполнение невозможно — необходимо разбить Task на несколько связанных Task со своими собственными оценками.

Максимальная оценка Sub-task — 8 CP

В случае, если есть желание оценить Sub-task больше, чем на 8 CP, то его следует декомпозировать на несколько Sub-task с максимальной оценкой 8 CP.

💡 Мы не берем в спринт неоцененные задачи

Поставка на Production

В своей работе мы выделяем два подхода доставки реализованных задач на Production:

• Continuous Delivery
• Build Delivery

Мы не можем релизить мобильные приложения каждые 10 минут, поскольку их релиз сопровождается модерацией в Сторах Приложений и постепенным обновлением у пользователей. Поэтому, Build Delivery — это единственный способ поставки мобильных приложений до Production.

Поскольку релиз Back-end и Front-end проектов не зависит от внешних факторов, то они могут выбирать для своей поставки на Production как Build Delivery, так и Continuous Delivery.

В случае Build Delivery, за счёт регрессионного тестирования, увеличивается качество релиза, но увеличивается Time To Market. В случае Continuous Delivery, уменьшается Time To Market, но увеличивается риск ошибок на Production.

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

Build Delivery

При Build Delivery, задачи проходят полный цикл разработки и тестирования, но выкладываются на Production не независимо друг от друга, а собираются в пачку, которую мы называем Релизной Сборкой и уже эта сборка целиком доставляется на Production.

До того, как сборка попала на Production, мы проводим над ней регрессионное тестирование.

При Build Delivery мы выделяем роль Release Manager — это переходящая роль у Developer's платформенных команд, которая включает в себя ответственность за координацию:

• сборки и раскатки релиза
• мониторинг и остановку раскатки релиза, в случае возникновения ошибок
• координацию сборки и раскатки хот-фикса, в случае остановки релиза

При Build Delivery, за регрессионное тестирование релизов отвечают руководители групп тестирования.

При Build Delivery приоритет задач позволяет увеличить шанс попадания задач в ближайшую сборку.

В случае Build Delivery мы используем Git Flow в качестве модели ветвления и слияния кода.

У нас есть master-ветка, содержащая актуальный для Production код. От неё отведена develop-ветка — ветка с кодом, который ожидает поставки на Production. Ветки для задач, разработчики отводят от develop-ветки.

Для каждого релиза, у нас есть точная дата, в которую мы отводим release-ветку от develop-ветки. Эта дата называется Feature Freeze.

Также есть точная дата, после которой начинается регрессионное тестирование release-ветки. Эта дата называется Code Freeze.

В период между Feature Freeze и Code Freeze, который составляет несколько дней, в release-ветку можно подливать исправления дефектов, которые были найдены в задачах, которые попадут в релиз. И запрещено подливать код, связанный с новыми задачами.

После релиза, release-ветка подливается в develop-ветку и master-ветку, после чего удаляется.

Цикл повторяется.

При Build Delivery, в случае задачи типа Epic, мы проводим тестирование всего готового Epic, а не отдельных задач, связанных с Epic, по мере их готовности. Для этого, от develop-ветки мы отводим epic-ветку. Прямой push в epic-ветку запрещен.

Когда Developer берет очередную задачу на выполнение, которая привязана к Epic, он отводит ветку для задачи от epic-ветки. Как только работа над задачей считается завершенной — Developer вливает ветку задачи в epic-ветку, после чего ветку для задачи удаляет.

Во время работы над Epic, мы регулярно подливаем свежий код из develop-ветки в epic-ветку.

Как только работа над Epic считается завершенной, код из epic-ветки вливается в develop-ветку, а сама epic-ветка удаляется.

Continuous Delivery

При Continuous Delivery, задачи проходят полный цикл разработки и тестирования, и могут быть независимо от остальных задач доставлены на Production.

При этом подходе, команда может непрерывно доставлять решения задач на Production в течении всего спринта, сразу после их тестирования. Но если задача была решена прямо перед завершением спринта, то Q.A. могут не успеть протестировать её в рамках этого спринта и её тестирование будет произведено позже, в рамках следующего спринта.

Таким образом, тестирование задач идет с запозданием завершения спринтов. Для нас это приемлемо.

В случае Continous Delivery каждый Developer самостоятельно доставляет свой код на Production и выполняет ровно те же функции, что и Release Manager в Build Delivery.

При Continous Delivery приоритет задач позволяет сформировать очередность поставки задач на Production в рамках спринта.

В случае Continuous Delivery мы используем GitHub Flow, как модель ветвления и слияния кода.

У нас есть master-ветка, содержащая актуальный для Production код.

Когда Developer берет очередную задачу на выполнение, он отводит ветку для задачи от master-ветки. Как только работа над задачей считается завершенной — Developer вливает ветку задачи в master-ветку и производит deploy на Production. После этого, ветка задачи удаляется.

В отличие от Build Delivery, при Continuous Delivery, в случае задачи типа Epic, мы не используем epic-ветку, как промежуточное хранилище кода между задачами и Production, а отводим ветки для задач сразу от master-ветки и в неё же вливаем.

Артефакты

Product Requirements Document

Discovery Team отвечает за разработку Road Map развития продукта. Концептуально, Discovery Team должен представлять видение развития продукта на ближайший год. Видение на ближайшие пол года должны быть сформированы тезисно. Видение на ближайший квартал должны быть оформлены в виде высокоуровневых задач.

Таким образом, чем уже горизонт планирования Discovery Team, тем четче сформированы конкретные цели, которые Delivery Team способна реализовать. PRD — это проработанные высокоуровневые задачи, которые могут быть реализованы Delivery Team.

💡 Мы настоятельно просим Discovery Team посвящать Delivery Team в весь Road Map развития продукта

PRD (Product Requirements Document) составляется Discovery Team и, помимо прочего, содержит информацию о верхнеуровневых функциональных требованиях к продукту (или его частях). Он отражает как продукт будет выглядеть, и как он будет работать.

PRD необходим, чтобы дать Delivery Team общее представление о разрабатываемом продукте и о целях разработки отдельных его функций.

Требования могут быть представлены как в форме одного документа, так и в форме комплекта документов или набора артефактов:

• прототипы интерфейсов (wireframes)
• UI макеты
• схемы, диаграммы
• документация для внешней интеграции
• аналитические события и порядок запуска экспериментов

Мы не регламентируем какой-то конкретный формат описания для PRD, но точно ожидаем, что после его прочтения Delivery Team получит ответы на следующие вопросы:

• Какую проблему мы решаем?
• На основании чего мы поняли, что это проблема?
• В чем важность решения этой проблемы?
• Как мы хотим решить эту проблему?
• Почему именно такой подход решит эту проблему?
• Как мы поймем, что проблема решена?

Тем не менее, важно, чтобы PRD содержал все необходимые артефакты, которые позволят Delivery Team его реализовать.

💡 Мы настоятельно рекомендуем привлекать Delivery Team к формированию PRD для получения ранней обратной связи

Technical Specification Document

TSD, Technical Specification Document — это документ, который составляется Delivery Team и является декомпозицией и технической проработкой PRD. Он позволяет увеличить скорость работы команды, снизить риски и связанную с ними стоимость внесения изменений в продукт.

Процесс формирования TSD называется feature leading, за который отвечает Feature Lead — им может быть любой разработчик из Delivery Team. В процессе работы над TSD, Feature Lead организует встречи и обсуждения, но чтобы не потерять целостность процесса, при этом, единолично отвечает за структуру TSD и получение всех необходимых согласований.

Для разработчиков, feautre leading — это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта. Мы хотим чтобы наши сотрудники росли, поэтому привлекаем к проработке младших специалистов и оказываем им всяческую поддержку при проработке TSD.

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

Мы не рекомендуем в рамках TSD пытаться произвести детальное проектирование — это может привести к неизбежным ошибкам и очень сильно увеличит этот процесс во времени.

Основная задача TSD описать поведение частей системы, которые будут привнесены или изменены и зафиксировать контракты обмена данными. Это позволит разработчикам различных платформ понять что от них требуется и выполнять эти требования параллельно и независимо друг от друга.

Во время работы над TSD, Feature Lead может подключать руководителей групп разработки тех платформенных команд, которые будут этот TSD реализовывать для консультации и получения ранней обратной связи.

Декомпозиция

Мы не пишем спецификацию для всей продуктовой задачи разом, а делим её на составляющие и уже для них описываем спецификацию.

Существуют два основных подхода к декомпозиции задач:

• горизонтальный
• вертикальный

В случае «горизонтальной» декомпозиции, задачи разбиваются по типу работы для каждой платформы — часть задач на Back-end, часть на Front-end и так далее. В этом случае, сама по себе реализация каждой части работы не приводит к конечному результату — чтобы выпустить готовую функциональность, необходима реализация всей совокупности связанных задач всеми участниками процесса.

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

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

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

В случае «вертикальной» декомпозиции прорабатывается участие каждой платформы в каждом Модуле, а после описывается связь и последовательность Модулей между собой.

Что считать за Модули, в каждом TSD принимает решение Feature Lead, но обычно это могут быть:

• новый экран или группа новых экранов, в случае мобильных приложений
• новая страница или группа новых страниц, в случае web-приложений
• flow потока данных, которое может включать получение, валидацию, обработку, сохранение и возврат данных, в случае серверных приложений
• новые элементы на существующих экранах/страницах или группах существующих экранов/страниц, в случае мобильных и web-приложений

Мы никак не ограничиваем Feature Lead в выборе уровня абстракции Модулей при декомпозиции. Главный критерий правильно проведенной декомпозиции — полученные Модули максимально изолированы друг от друга и могут быть реализованы и протестированы независимо друг от друга.

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

Если входящая задача очень большая и её реализация выходит за рамки одного спринта, то Feature Lead предлагает Product Manager сгруппировать Модули в наборы Модулей. Причем, выделяется основной набор Модулей в виде MVP (Minimum Viable Product), который реализовывается и доставляется на Production в первую очередь. И альтернативные наборы Модулей, которые улучшают и расширяют основной набор и могут реализовываться и доставляться на Production последовательно в рамках последующих спринтов.

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

Что считать за Блоки, в каждом TSD принимает решение Feature Lead, но обычно это могут быть:

• различные элементы или блоки элементов в рамках одного экрана или страницы
• различные процессы обработки входящих данных в рамках flow обработки данных

После того, как Модули и Блоки в них определены, происходит описание спецификации для каждой атомарной сущности — Блока или Модуля без Блоков.

Для простоты повествования, далее, мы будем использовать Блок как атомарную сущность, которая может подразумевать под собой как сам Блок, так и Модуль без Блоков.

Спецификация

Спецификация описывает как Блок должен выглядеть и функционировать.

Если функциональность блока базируется на коммуникации со внешним сервером, например при UI компоненте или сторонней интеграции, то необходимо описать:

• URL-адрес запроса
• схему запроса
• схему успешного и ошибочного ответа

Если это существующий URL, в котором меняются или дополняются какие-то поля ответа или запроса, это необходимо явно обозначить.

Для каждого поля схемы необходимо описать:

• имя и тип
• описание назначения
• все возможные значения и их описания, для enum-типа
• обязательность

Необходимо приложить примеры возможных ответов и запросов.

Если Блок представляет из себя последовательность коммуникаций с внешними серверами или инфраструктурными сервисами, то эту последовательность обходимо отобразить в виде UML Sequence Diagram.

Описание функционирования Блока должно включать в себя:

• позитивные сценарии, которые подразумевают что клиент достиг своей цели при использовании Блока
• негативные сценарии, которые описывают любые отклонения, возникающие при использовании Блока

Если Блок представляет из себя UI компонент, который отображает данные, которые приходят с сервера, необходимо описать как он будет себя вести, если:

• данные в процессе получения
• возникла ошибка при получении данных
• получены некорректные данные

Если Блок представляет из себя UI компонент, который отображает данные, которые приходят с сервера, необходимо описать маппинг схемы ответа сервера на UI элементы Блока.

Если Блок представляется из себя UI компонент, который позволяет отправлять данные на сервер, необходимо описать как он будет вести себя, если:

• данные были указаны некорректно
• указаны не все запрашиваемые данные
• сервер вернул ошибку

Необходимо описать события, генерируемые функциональностью Блока, которые необходимо отправить в аналитическую систему.

Необходимо описать связь Блока с запускаемыми a/b тестами.

Предварительная оценка

После того, как произведена спецификация Модулей, им необходимо дать предварительную оценку реализации.

Стоит понимать, что эта предварительная оценка необходима лишь для понимания Product Manager объёма каждого Модуля, возможности сравнения Модулей между собой по оценке и возможности урезания (feature cutting) функциональности Модулей, оценка которых вышла за ожидаемые рамки.

Полученные оценки никоим образом нельзя использовать при глобальном планировании задач проекта или например, строить на их основе Диаграмму Ганта.

Для вычисления ожидаемого значение продолжительности реализации Модуля мы используем технику «PERT» (Project Evaluation and Review Technique).

Для каждой платформы, которая участвует в реализации Модуля мы выставляем три оценки:

• O — оптимистичная оценка длительности реализации
• M — наиболее вероятная оценка длительности реализации
• P — пессимистичная оценка длительности реализации

Мы используем «Человеко-дни» и «Человеко-недели» в качестве единиц измерения оценки длительности реализации. Для маленьких Модулей можно брать человеко-дни, а для больших — человеко-недели.

После полученных оценок, рассчитать предварительную оценку реализации можно по формуле:

$$ Estimation = \frac{O + 4M + P}{6} $$

Допустим, наш Модуль состоит из набора задач для двух платформ — Front-end и Back-end.

Для Back-end:

• оптимистичная оценка — 1.5 человеко-недели
• вероятная оценка — 2.5 человеко-недели
• пессимистичная оценка — 5 человеко-недель

Итого, предварительная оценка Back-end части Модуля будет:

$$ \frac{1.5 + 4 * 2.5 + 5}{6} $$

2.6 человеко-недель

Для Front-end:

• оптимистичная оценка — 3 дня
• вероятная оценка — 5 дней
• пессимистичная оценка — 10 дней

Итого, предварительная оценка Front-end части Модуля будет:

$$ \frac{3 + 4 * 5 + 10}{6} $$

5.5 человеко-дней

Все полученные предварительные оценки, вместе с набором трёх оценок должны быть зафиксированы в TSD около каждого Модуля.

Для получения оценок, Feature Lead может подключать руководителей групп разработки тех платформенных команд, которые будут этот TSD реализовывать.

Если Product Manager не согласен с величинами оценок Модулей, Feature Lead может предложить ему возможности урезания функциональности Модуля для сокращения оценок реализации.

Композиция

Спецификация каждого Блока собирается в единый документ. К документу прикрепляется ссылка на PRD.

Чтобы TSD было легко читать, он должен иметь чёткую и последовательную структуру.

Зависимость Модулей можно отобразить в виде UML Use Case Diagram.

После завершения работы над TSD, Feature Lead создаёт Epic в трекере задач и в его описании прикладывает ссылку на TSD. К этому Epic платформенные команды будут крепить задачи типа Task в рамках дальнейшей декомпозиции TSD на встрече Grooming.

Feature Lead передаёт TSD руководителю группы тестирования для дальнейшей проработки и составления тест кейсов, по которым будет производиться тестирование.

TSD должен быть всегда актуальным, поэтому, если в процессе реализации происходят какие-то изменения спецификации, Feature Lead должен незамедлительно вносить их в TSD.

Согласования

Перед началом разработки, TSD должен получить согласования всех руководителей групп разработки тех платформенных команд, которые будут этот TSD реализовывать.

Если в рамках задачи мы работаем с чувствительными или персональными данными, то перед разработкой, TSD необходимо согласовать с департаментом Информационной Безопасности.

Процессы

Большинство процессов Citygile носят характер встреч, так как данная методология основана на качественных коммуникациях.

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

Feature Review

Результат: принятые на техническую проработку задачи Длительность: не регламентируется Регулярность: по необходимости Участники: Discovery Team и Delivery Team Ведущий: Product Manager

Всю цикличность спринтов Citygile можно отразить в следующих пунктах:

• Для того, чтобы запустить спринт — нужно набрать в него оцененные задачи
• Для того, чтобы получить оцененные задачи — нужно провести Grooming (о нем расскажем дальше)
• Для того, чтобы провести Grooming — нужно иметь TSD (проработанные на основе PRD) и/или небольшие продуктовые задачи
• Для того, чтобы получить небольшие продуктовые задачи и/или PRD — нужно провести Feature Review

На встречу Feature Review, Discovery Team приходит с продуктово-проработанными задачами. Задачи могут представлять из себя:

• Небольшие продуктовые задачи, например небольшие доработки или улучшения текущей функциональности, которые Discovery Team оформляет в свободной форме
• Feature, которые Discovery Team оформляет в виде PRD

💡 Мы не налагаем каких-то определенных требований для оформления небольших продуктовых задач, но точно требуем, чтобы они были зафиксированы письменно. Product Manager может использовать тип задач Note для заведения таких небольших задач. Delivery Team проработает эти Note и заведет для них Task и Bug, а сами Note удалит.

Все небольшие продуктовые задачи и все PRD должны быть отсортированы Product Manager по приоритету, с которым они должны поступать в техническую проработку и уйдут на реализацию.

💡 Приоритезация продуктовых задач может зависеть от усилий, которые Delivery Team потратит на их реализацию («Effort» из фреймворка приоритизации RICE), поэтому на этой встрече Delivery Team должна быть готова дать Product Manager хоть и сильно грубую, но предварительную оценку по каждой продуктовой задаче. Конечно же, более детальная оценка может быть получена только после технической проработки.

В случае, если Delivery Team представляет из себя кросс-платформенную команду и интересы этой команды обслуживают Platform и Q.A. Team, то CrossLead может пригласить на встречу руководителей групп разработки и тестирования.

Delivery Team детально изучает задачи, задает уточняющие вопросы, предлагает улучшения и изменения.

Если по предварительной оценке реализация Feature выходит за один спринт, то Delivery Team рекомендует Product Manager разбить её на этапы поставки в рамках каждого спринта, чтобы выпускать её на рынок итерационно и получать ранний фидбек от пользователей.

💡 Чтобы встреча проходила эффективнее, мы настоятельно просим Product Manager заранее высылать команде задачи для ознакомления

Если у задачи есть жёсткий dead line, то Product Manager должен проинформировать об этом. Если предварительная оценка реализации задачи с учётом её планирования в будущих спринтах выходит за этот жёсткий dead line, то Delivery Team и Product Manager должны проработать уменьшение содержания задачи (feature cutting), чтобы уменьшить срок реализации задачи и сформировать планирование будущих спринтов так, чтобы задача обязательно была выпущена к указанному dead line.

💡 Если и после feature cutting выпуск задачи не укладывается в жёсткий dead line, то Product Manager может проработать возможность реализации задачи силами несколько команд

Те задачи, которые Delivery Team не готова взять в работу (например, из-за отсутствия необходимой информации), возвращаются на дополнительную продуктовую проработку и Discovery Team вернется с ними на следующей встрече.

Те задачи, которые Delivery Team готова взять в работу, уходят на техническую проработку:

• Небольшие задачи могут быть технически проработаны и оценены прямо на встрече Grooming
• Для Feature, оформленных по PRD, необходима техническая проработка, оформленная по TSD. В этом случае, за этой Feature закрепляется Feature Lead, результатом работы которого будет TSD

💡 Важно, после того, как Delivery Team взяла задачу в техническую проработку, она не должна меняться

Мы допускаем, что во время технической проработки продуктовой задачи, у Delivery Team могут возникать дополнительные вопросы, которые не были обсуждены на встрече Feature Review. И не смотря на то, что Product Manager не является членом Delivery Team в прямом смысле этого слова, он должен быть рядом и доступен Delivery Team для уточнений, помощи и ответов на различные вопросы.

Grooming

Результат: набор оцененных задач Длительность: 5%-10% времени спринта Регулярность: по необходимости Участники: платформенная команда Ведущий: руководитель группы разработки

Планирование нового спринта должно проходить быстро и просто. Чтобы это было возможным — беклог платформенной команды должен содержать оцененные задачи на ближайшие один-два спринта.

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

Эта встреча руководителя группы разработки и платформенной команды в случае Platform Team или платформенной под-команды в случае Cross-platform Team, которая может включать:

• декомпозицию и заведение новых задач
• удаление неактуальных задач
• оценку и переоценку задач
• техническую проработку задач, для более точной оценки
• уточнение требований к задачам

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

• получения небольших продуктовых задач после встречи Feature Review
• получение проработанного TSD от Feature Lead
• готовность команды проработать задачи связанные с техническим долгом к следующему спринту

💡 Руководитель группы разработки может заранее пригласить Product Manager на эту встречу, если необходимо обсудить тонкости реализации той или иной задачи

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

Декомпозиция и заведение новых задач

Все небольшие продуктовые задачи и проработанные TSD должны превратиться в полном объёме в реальные задачи типа Task.

Команда совместно на встрече изучает небольшие продуктовые задачи и проработанные TSD и на их основе понимает какую именно работу нужно выполнить и в каком объёме. Вся работа заводится в трекер в виде задач типа Task.

Каждая заведенная задача должна быть максимально самодостаточна и изолирована от других задач.

Описание задачи должно быть максимально чётким, конкретным и понятным для каждого участника команды, чтобы исключить различные интерпретации и недопонимания.

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

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

Бывают случаи, когда конечная реализация задачи зависит от исследования, которое необходимо провести перед выполнением задачи. В этом случае, мы рекомендуем завести задачу типа Note, описать в ней план необходимого исследования и связать её с основной задачей типа Task. После того как исследование будет завершено, снова собраться командой, завершить описание основной задачи типа Task и оценить её.

После того, как все необходимые задачи заведены, команда устраивает Planning poker для оценки заведенных задач. Во время оценки, команда может дополнять и уточнять описание к задачам. Какие-то задачи могут быть декомпозированы на несколько задач.

Допускается устраивать Planning poker после заведения каждой задачи.

🚧 Planning poker

Покер-планирование — это консенсусная оценка задач командой, которая будет эти задачи реализовывать.

Стоит помнить, что мы оцениваем не сложность задачи, а время, которое необходимо потратить на ее реализацию инженером уровня Middle. Понятно, что инженер уровня Junior будет выполнять задачу дольше, а инженер уровня Senior — быстрее.

Покер-планирование проводится следующим образом:

Каждому участнику раздается колода карт со значениями City Point: 1, 2, 4, 8 и 16. И карта со значением «?», которая символизирует оценку больше 16 CP или невозможность поставить оценку задаче.

1. Начинается обсуждение очередной задачи: она зачитывается, команда задает друг другу вопросы, выясняет детали, если это необходимо.
2. Каждый член команды делает свою оценку, кладя карту рубашкой вверх.
3. После того, как все члены команды сделали оценку – все карты переворачиваются и оценки сверяются

Если оценки всех участников одинаковы — консенсусная оценка заносится в беклог.

Если кто-то из участников выложил карту со значением «?», то значит есть риск того, что описание задачи не раскрывает всю суть задачи и объём работы, который необходимо выполнить. Описание задачи уточняется

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

Уточнения в виде аргументов, с которыми согласна вся команда, появившиеся в процессе обсуждения задачи фиксируются в описании задачи.

После обсуждения проводится второй раунд оценки.

Обычно, разброс оценок снижается с каждым последующим раундом, и сходится к консенсусной оценке.

Описание задачи должно уточняться до тех пор, пока не будет понятно каждому члену команды.

Для нас важно, чтобы каждый участник команды понимал всю суть задачи и объём работы, который необходимо выполнить, чтобы реализовать задачу. Поэтому для нас важна именно консенсусная оценка, а не оценка большинства. И тем более мы не допускаем давления авторитетных членов команды, которому все начинают невольно подчиняться и ставить оценки, уже не вдумываясь в суть.

Оцененные задачи поднимаются на верх беклога.

💡 Для покер планирования, который проводится в online-режиме, мы рекомендуем использовать сервис https://planningpokeronline.com/

Planning

Результат: запущенный спринт Длительность: не более часа Регулярность: перед началом спринта Участники: Delivery Team и Product Manager Ведущий: CrossLead

💡 Мы настоятельно рекомендуем использовать минимум одну и максимум две недели в качестве размера спринта

Planning — это встреча, на которой собирается Delivery Team и Product Manager для формирования и запуска нового спринта.

К началу этой встречи, в беклоге должен быть подготовлен список задач, которые Delivery Team готова брать на реализацию. Все подготовленные к планированию задачи должны иметь оценку в City Point и корректный приоритет, который был получен от Product Manager для небольших продуктовых задач и PRD на этапе Feature Review.

Расчёт Capacity

Для того, чтобы оценить какое количество задач Delivery Team готова взять в следующем спринте, необходимо рассчитать Capacity (от англ. «вместимость») — это максимальное количество CP, которое команда может выполнить за спринт.

В кросс-платформенных командах, платформенные под-команды не могут быть взаимозаменяемы, поэтому мы не можем считать Capacity для всей команды в целом и считаем его отдельно для каждой платформенной под-команды. В платформенных командах мы рассчитываем Capacity для всей команды.

Перед расчётом Capacity необходимо рассчитать количество идеальных рабочих дней команды — это то количество дней, в рамках которых команда будет сосредоточена на решении задач следующего спринта. Для расчёта количества идеальных рабочих дней необходимо для каждого сотрудника, из количества рабочих дней спринта отнять отвлекающие факторы, которые представляют из себя:

• полное отсутствие сотрудника
• деятельность, которая может не иметь конкретный Definition of Done
• регулярную операционную деятельность сотрудника
• деятельность, которая может не иметь точной оценки

Отвлекающими факторами могут являться, к примеру:

• отсутствие сотрудника (day off, больничные, отпуска)
• дежурства
• менеджерские обязанности
• собеседования

Так, например, руководитель группы разработки, помимо выполнения задач команды может проводить собеседования и проводить 1-2-1 с сотрудниками своей группы. Эту деятельность проще считать в процентах и учитывать при планировании каждого спринта. Понятно, что когда такая деятельность начнёт приближаться к 100%, то такому руководителю проще выйти из команды и полностью сосредоточится на обязанностях руководителя.

Аналогично и feature leading, если есть возможность проработку новой Feature сформировать в виде задач типа Note и дать им оценку в City Point — то лучше поступить именно таким образом. Если же Discovery Team ведет продуктовую проработку задачи и им нужно постоянно привлекать Feature Lead в своей деятельности, то лучше эту деятельность заложить в виде процентов и учитывать при планировании каждого спринта, пока ведется такая проработка.

В рамках кросс-платформенной команды, давайте попробуем рассчитать количество идеальных рабочих дней для платформенной под-команды из 5 Back-end Developer для двухнедельного спринта (10 рабочих дней), где:

• Влад — Руководитель группы Back-end разработки, который также выступает как Back-end Developer в этой кросс-платформенной команде. У Влада масса менеджерских обязанностей и написанию кода он может уделять лишь 60% своего времени. Следовательно, из 10 рабочих дней, только 4 дня Влад сможет потратить на решение задач команды — это и будет количество идеальных рабочих дней Влада в этом спринте;
• Сергей выполняет роль Cross Lead в этой кросс-платформенной команде. Выполнение обязанностей этой роли отнимает у Сергея 30% времени. Сергей решил съездить к родственникам и взял 1 day off в первую неделю спринта. Итого, рабочих дней у Сергея в этом спринте — 9 дней, но треть времени он занят выполнением обязанностей роли Cross Lead, следовательно количество идеальных рабочих дней Сергея в этом спринте будем считать за 6;
• у Андрея отпуск, который выпадает на первую неделю спринта, и поэтому он будет доступен только одну неделю. Также, Андрей выступает в качестве Feature Lead одной очень большой, сложной и неопределенной задачи и совместно с Product Manager прорабатывает её уже целых два спринта. Проработка будет длиться ещё неопределенное время, и пока эта неопределенность не ушла, команда решила закладывать 20% времени работы Андрея на проработку этой задачи. Таким образом, количество идеальных рабочих дней Андрея в этом спринте будет 4;
• у Ивана выпадает дежурство на первую неделю спринта, команда закладывает на эту деятельность 20% времени сотрудника в неделю, что составляет один рабочий день в неделю, следовательно количество идеальных рабочих дней Ивана в этом спринте будет 9;
• у Марата аналогичная ситуация, как и у Ивана, только дежурить он будет вторую неделю спринта, следовательно количество идеальных рабочих дней Марата в этом спринте также будет 9.

Казалось бы, у нас 10 рабочих дней и 5 Back-end Developer, а значит идеальных рабочих дней в спринте на всю под-команду у нас должно быть 50, но это не так.

Когда, на встрече Planning, мы создадим такую табличку:

Сотрудник	day off отпуска больничные	дежурства	management	feature leading	Количество Идеальных Рабочих Дней
Влад	0	0	6	0	4
Сергей	1	0	3	0	6
Андрей	5	0	0	1	4
Иван	0	1	0	0	9
Марат	0	1	0	0	9

и сложим количество идеальных рабочих дней каждого сотрудника, то получим 32 — это и будет количество идеальных рабочих дней платформенной под-команды (из возможных 50), которые она будет сфокусирована на задачах спринта.

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

💡 Хоть это и не является рекомендуемой практикой, но если все-таки есть острая необходимость, то на этом этапе, команда может заложить несколько дней на Support — это прилетающие незапланированные задачи и критичные баги, которые не могут ждать следующего спринта и заставляют команду выполнять незапланированную работу

Помимо отвлекающих факторов, которые мы учитываем для каждого сотрудника в отдельности, есть ещё отвлекающие факторы, которые распространяются на всю команду в целом, например:

• регулярные встречи
• Code Review
• переключение контекста между задачами
• незапланированные коммуникации и обсуждения

Не смотря на то, что фокус любого участника команды должен быть направлен на выполнение спринта, абсолютно без встреч обойтись невозможно. Поэтому мы используем Focus Factor — это некий коэффициент, отражающий отношение производительности существующей команды к производительности «идеальной» команды.

Для сработавшихся и стабильных команд Focus Factor держится на уровне 70%-80%, молодые команды могут попробовать начать с 50%. Платформенные команды и под-команды должны непрерывно работать над максимизацией этого значения.

Влад, Сергей, Андрей, Иван и Марат давно работают вместе и заметили, что при Focus Factor 75% они держат хороший темп — все задачи из спринта всегда закрываются и в редких случаях в активный спринт приходится докидывать задач.

Таким образом, умножив полученные выше 32 идеальных рабочих дня на 8 часов в дне и умножив на Focus Factor 0,75 мы получим 192 CityPoint— это и есть Capacity этой Back-end под-комманды — максимальный объем задач, которая Back-end под-команда готова взять и выполнить за следующий спринт.

Для кросс-платформенной команды мы проделываем эту же операцию расчета Capacity для оставшихся платформенных под-команд.

Расчёт Focus Factor

Есть два подхода к вычислению объёма задач следующего спринта:

• расчет Capacity с наложением Focus Factor
• Velocity

Velocity (от англ. «скорость») вычисляется в конце спринта как сумма абстрактных оценок задач (в Citygile мы используем CityPoint) по всем полностью завершенным задачам спринта. Для оценки объёма работ следующего спринта, обычно, берется среднее Velocity последних 2-3 завершенных спринтов команды.

У нас не бывает двух, а тем более трех, похожих спринтов подряд — кто-то уходит в отпуск, кто-то берет day off, кто-то дежурит и после каждого завершения спринта, наш Velocity обычно ни о чем не говорит и точно не может служить базой для расчета объёма работ следующего спринта. Поэтому мы выбрали расчет Capacity с наложением Focus Factor, как метод расчета объёма задач следующего спринта.

Также и Focus Factor — это эмпирически вычисленная величина и она не может строиться на основе статистических данных прошлых спринтов.

Каждая команда подбирает Focus Factor на основе ощущений темпа своей работы. Хорошим значением Focus Factor является 75%, и в какие-то моменты времени команда может придерживаться его, а в какие-то опускаться немного ниже этого значения.

💡 Стоит помнить, что в кросс-платформенных командах, у каждой платформенной под-команды должен быть свой Focus Factor

В вашем первом спринте мы рекомендуем начать с Focus Factor 50% — вы точно закончите спринт раньше срока и должны быть готовы докинуть в спринт еще задач. Во втором спринте, по ощущения от первого, вы можете повысить Focus Factor до 60% или сразу взять 70%. В третьем и последующих спринтах, по ощущениям от предыдущих, вы будете либо повышать, либо понижать Focus Factor, пока не придете к такому Focus Factor, который отражает максимальный, но при этом, комфортный темп вашей команды.

Мы точно можем сказать, что Focus Factor не может быть равен или быть больше 100%. В ситуациях, когда ваша команда сильно перевыполняет план по спринту — обратите внимание на оценку задач, скорее всего вы стали переоценивать старые и лёгкие для вас задачи.

🚧 Поставка на Production

Поставка решения задачи на Production, помимо написания кода, включает в себя проведение Code Review, Demo, тестирование, правок после тестирования и самого процесса релиза.

Когда мы оцениваем задачи, в их оценку мы закладываем только написание кода и ничего более. И если Code Review и Demo заложены в Focus Factor команды, то тестирование точно нигде не отражено. При этом, ни одно наше решение не будет доставлено на Production без участия Q.A. инженеров.

При Build Delivery мы точно хотим попадать в дату Code Freeze. Для этого нам необходимо заложить немного времени на тестирование последних задач из спринта и на исправление в них дефектов, тем самым закончив разработку чуть раньше, чем закончится сам спринт. Дата, в которую мы заканчиваем решение задач и после которой занимаемся только тестированием и исправлением дефектов называется Feature Freeze.

Таким образом, вся разработка и тестирование ведется от начала спринта и до даты Feature Freeze. После Feature Freeze и до Code Freeze ведется оставшееся тестирование и исправление найденных дефектов. После Code Freeze начинается регрессионное тестирование и релиз новой сборки.

В этом случае, при расчете Capacity, в качестве рабочих дней, мы закладываем не все рабочие дни спринта, а дни от начала спринта и до даты Feature Freeze.

Формирование спринта

После того, как все Capacity рассчитаны происходит наполнение спринта задачами в рамках Capacity платформенной команды или платформенных под-команд в случае кросс-платформенной команды.

Реализация задач спринта может зависеть от задач, которые были поставлены смежным командам (например, SysOps, DevOps, DWH или смежным партнерам). Мы берем в спринт только те задачи, которые не имеют внешних блокеров или мы уверены, что блокер будет разрешен в рамках спринта ко времени взятия задачи в реализацию.

Какие именно задачи войдут в следующий спринт, решают Cross Lead и Product Manager. Для Product Manager важнее взять побольше продуктовых задач, для Cross Lead важнее взять побольше технических задач — задач, которые сокращают технический долг и исправляют дефекты.

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

Для Cross Lead и Product Manager важно договориться о порядке закрытия технических задач. Мы выделяем два подхода:

• Delivery Team каждый спринт берёт технические задачи, наравне с продуктовыми задачами. Cross Lead и Product Manager договариваются о процентном соотношении этих типов задач (например, 80% Capacity на продуктовые задачи и 20% на технические)
• Delivery Team чередует продуктовые спринты, которые содержат только продуктовые задачи и технические спринты, которые содержат только технические задачи. Cross Lead и Product Manager договариваются об интервале технических спринтов (например, 2 спринта продуктовых и 1 спринт технический)

Отношение порядка устранения технических задач может варьироваться от команды к команде или от спринта к спринту и зависеть, например, от уровня legacy самого продукта.

Закрытие спринта

После того, как новый спринт сформирован, перед его запуском необходимо закрыть текущий активный спринт.

Задачи в текущем спринте могут находиться в следующих статусах:

• ожидающие, работа по ним ещё не была начата
• в работе
• выполненные

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

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

После проведения ревизии, текущий активный спринт закрывается и все задачи, находящиеся в статусе ожидающие и в работе переходят в новый спринт.

Команда запускает новый спринт.

Важно понимать, что объём незавершенной работы текущего спринта никак не затрагивает Capacity нового спринта — он идёт поверх Capacity нового спринта. Такую незавершенную работу можно рассматривать в виде долга, который команда берет из прошлого спринта в новый.

Появление такого долга вполне допустимо, задача команды следить за не увеличением этого объёма. Если долг растёт, то мы рекомендуем команде обратить внимание на качество оценки задач или пересмотреть Focus Factor команды.

Daily

Результат: план действий на рабочий день Длительность: не более 30 минут Регулярность: каждый рабочий день Участники: Delivery Team Ведущий: Cross Lead

💡 Каков бы не был маленьким проект, какова бы не была проста задача — мы за синхронизацию всех заинтересованных лиц и за фиксацию измененных договоренностей

Задача Delivery Team — реализовать все запланированные в спринте задачи.

Во время выполнения спринта могут возникать события, которые могут препятствовать его выполнению, например:

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

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

Встреча должна быть всецело направлена на достижение выполнения спринта и должна укладывается в оговоренные временные рамки. Чтобы соблюсти эти ограничения, команде рекомендуется проводить Daily не в форме свободной дискуссии, а выработать какой-либо удобный для себя конкретный формат и придерживаться его на каждом Daily.

Например, неплохо себя зарекомендовал формат, при котором каждый участник команды за максимум 2 минуты отвечает на следующие 3 вопроса:

• Что я сделал вчера, что помогло нам приблизиться к выполнению спринта?
• Что я сделаю сегодня, чтобы приблизить выполнение спринта? Нужна ли мне помощь в этом?
• Вижу ли я какие-либо препятствия, которые могут помешать мне достичь выполнения спринта?

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

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

По необходимости, Delivery Team может заранее звать участников Discovery Team на следующую встречу Daily.

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

Demo

Результат: обратная связь по реализованным задачам Длительность: не регламентируется Регулярность: по необходимости Участники: Discovery Team и Delivery Team Ведущий: Feature Lead

PRD описывает решение проблемы или пользу, которую получит пользователь. TSD описывает техническую реализацию PRD. В этой схеме легко допустить ошибку, когда фокус Delivery Team с решения основной проблемы смещается на соответствие TSD.

Для того, чтобы минимизировать эту ошибку, Delivery Team проводит встречу Demo для Discovery Team, на которой демонстрирует результат своей работы по продуктовым задачам, до того, как они попадут на Production.

Для того, чтобы встреча проходила эффективнее, Delivery Team может заранее собрать необходимые сборки продукта или развернуть его на тестовой площадке и передать все доступы Discovery Team.

На этой встрече,

• для Product Manager важно выявить расхождения реализации с решением поставленной задачи или убедиться что их нет
• для Product Analyst важно убедиться в корректности собираемых метрик и корректности проводимых экспериментов
• для Designer важно выявить расхождения реализации с установленными guidelines или убедиться что их нет

По итогу демонстрации реализации Feature, Delivery Team имеет список правок, требующих исправления и их приоритет.

Delivery Team должен дать предварительную оценку этим правкам. На основе этой оценки и приоритетов правок, Product Manager принимает решение о сроках поставки Feature.

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

Цель Delivery Team сокращать количество правок в рамках каждого спринта и попадать в ожидания Discovery Team.

Retro

Результат: план улучшений эффективности работы команды Длительность: около часа Регулярность: в конце спринта Участники: Discovery Team и Delivery Team Ведущий: любой участник команды

Одна из основных целей любой Delivery Team — полностью выполнять запланированные спринты. Если по каким-то причинам, полностью выполнить запланированный спринт не удалось, то выяснение причины и пути её устранения должна быть главной темой на встрече Retro.

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

Мы не обязываем команду проводить Retro после каждого спринта, напротив, команда должна самостоятельно подстроить регулярность проведения Retro под себя.

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

Команды, переходящие из стадии norming в performing уже решили свои проблемы и могут проводить Retro, например, раз два спринта. При недельных спринтах, такие команды могут проводить Retro даже раз в месяц.

Главное для нас — понимание всеми участниками команды о регулярности и датах этих встреч.

В концепции Бережливого произовдства (lean production), всё, что не добавляет ценности продукту расценивается потерями, которые на японском языке называются «Му'да» (Muda, 無駄).

Для нас, мудой являются:

• ожидание
• коммуникация
• переключение контекста
• лишняя функциональность
• незавершенная работа
• баги
• over engineering

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

Сокращение муды — это постоянный и непрерывный процесс совершенствования, которого мы достигаем с помощью японской практики Кайдзен (Kaizen, 改善).

Наша цель — становится лучше каждый спринт:

• точнее оценивать задачи
• эффективнее и качественнее проводить командные встречи
• качественнее и быстрее проводить code review
• качественнее и продуктивнее коммуницировать внутри и во вне команды

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

Цель встречи — помогать команде стать лучше, для этого команда должна быть открыта в общении и вести откровенный разговор, в том числе, о неприятных вещах. Мы должны честно и открыто признавать и обсуждать все проблемы не для поиска виноватых, а для оптимизации процессов.

Мы не устанавливаем жёстких временных рамок для этой встречи, поскольку её продолжительность зависит от следующих факторов:

• время, прошедшее с прошлого Retro. Чем оно больше, тем больше команда успевает сделать и тем больше материала для обсуждения;
• размер команды. Чем команда больше, тем больше надо времени, чтобы у каждого её члена была возможность высказаться и тем больше функциональности команда успевает сделать;
• наличие проблем. Со временем, команда решает проблемы и ретроспективы сокращаются по времени.

Мы не регламентируем какой-то конкретный формат проведения этой встречи, потому что он может быть специфичен для команды. Более того, он может регулярно меняться, чтобы не наскучать команде.

Тем не менее можем предложить следующий план для проведения встреч:

• Анализ прошлого плана улучшений. Удалось ли достичь выполнения плана улучшений с прошлой встречи? Что осталось не выполнено и почему? Что не актуально из невыполненного?
• Обсуждение прошедшего спринта. Как прошел последний спринт в отношении людей, взаимодействий, процессов, инструментов и критериев готовности? Что было хорошо и помогало работать? Что мешало? Что или кто может помочь работать лучше? Высказаться обязательно должен каждый участник команды.
• Агрегация. Все озвученные проблемы фиксируются текстом в виде списка.
• Мозговой штурм. Команда выявляет предположения, которые помогут решить возникшие трудности и сделать работу команды еще эффективнее.
• Формирование плана улучшений. На основе идей мозгового штурма, команда определяет наиболее полезные для повышения эффективности улучшения в процессе своей работы и фиксирует их текстом в виде списка. Такие улучшения затем реализуются в кратчайшие сроки и становятся частью культуры команды.

💡 Мы настоятельно рекомендуем использовать принцип «MECE» (Mutually Exclusive, Collectively Exhaustive) для формирования плана улучшений эффективности команды.

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

💡 Мы очень ценим формализацию накопленных знаний, поэтому достигнутый опыт делаем новым стандартом команды

Процесс разработки

Мы не накладываем жесткого ограничения на конечный вид workflow, и именование статусов, но workflow точно должен иметь промежуточные статусы со следующим смыслом:

• To Do, задача ожидает назначения Developer и взятия в работу
• In Progress, Developer выполняет работу над задачей
• Blocked [in development], Developer не может продолжить работу по задаче ввиду внешних блокеров
• Code Review, код по задаче написан и находится на рассмотрении коллег
• Waiting To Test, Developer решил провести задачу через процедуру тестирования и она ожидает тестирования
• Testing, Q.A. выполняет тестирование задачи
• Blocked [in testing], Q.A. не может продолжить работу по тестированию задачи ввиду внешних блокеров
• Ready, задача готова войти в релиз
• Done, задача вошла в релиз
• To Rework, задача вернулась на доработку к Developer
• Canceled, задача была снята с выполнения

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

На каждом этапе процесса разработки могут появляться сотрудники с различными ролями, которые помогают в выполнении задачи. Например, на этапе тестирования — это Q.A., а на этапе Code Review — это Ревьюверы.

Не смотря на обилие ролей и ответственностей, самый главный принцип, которого мы всецело придерживаемся заключается в том, что именно Developer ответственен за все фазы реализации задачи от взятия её в работу, до корректной её работы на Production.

Так, например, для нас, Q.A. и Ревьюверы — это лишь помощники у Developer, которые позволяют заметить то, чего не заметил Developer при решении задачи, но никоим образом они не являются конечными ответственными за качество и стабильность решения задачи.

Developer всецело отвечает как за качество решения, так и за его стабильность. Developer выступает в качестве Q.A. при реализации задачи и отдаёт на Code Review уже стабильное и протестированное решение, в котором он уверен.

Статусы

To Do

В активном спринте, Developer выбирает задачу с самым высоким приоритетом в статусе To Do, у которой не проставлен исполнитель. Либо берет задачу с самым высоким приоритетом в статусе To Do, в которой он указан как исполнитель.

Если такой задачи не нашлось, он обращается к Cross Lead для выбора задачи из бэклога.

В выбранной задаче, Developer указывает себя в качестве исполнителя и переводит её в статус In Progress.

При Build Release, если задача привязана к Epic, Developer создаёт epic-ветку и создаёт для неё Merge Request с префиксом WIP: (Work In Progress), если она еще не создана.

Epic-ветка имеет вид:

epic/номер-задачи-краткий-заголовок-задачи

например,

epic/PMO-3-car-classifier-page

Далее, Developer создаёт ветку для задачи, которая имеет вид:

тип-задачи/номер-задачи-краткий-заголовок-задачи

например,

task/RMBE-505-add-subclient-for-geo-request

bug/RMBE-475-do-not-send-push

Если Developer делает Sub-task для Task, то он отводит ветку для этого Sub-task от ветки основного Task и эта ветка имеет вид:

sub-task/RMBE-478-fix-deep-link

Developer создаёт Merge Request для ветки, с префиксом WIP:

Заголовки к Merge Request должны иметь вид:

[идентификатор задачи] краткое описание задачи

например,

[RMBE-505] add subclient for geo request

Мы используем метод Squash для вливания кода ветки в основную ветку проекта, поэтому необходимо внимательно относиться к именам Merge Request, поскольку именно это имя будет выступать в качестве description к единому Squash-коммиту.

In Progress

Developer решает задачу.

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

Если во время работы у Developer возникают вопросы по выполняемой задаче, то он согласует их с Feature Lead.

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

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

При Continuous Delivery, после того, как Developer считает, что работа над задачей завершена, он может инициировать Demo с Discovery Team для получения обратной связи по реализации задачи. При Continuous Delivery, мы рекомендуем устраивать Demo именно на этом этапе, чтобы к моменту Code Review и тестирования задачи все правки от заказчиков уже были внесены. При получении правок, Developer фиксирует их в комментарии к задаче и возвращается к реализации задачи. Процесс повторяется.

После того, как Developer считает, что работа над задачей закончена, он переводит её в статус Code Review.

После передачи задачи на Code Review, Developer может брать новую задачу на выполнение только при условии, что в данный момент на ревью у него нет больше других задач. Если у Developer на ревью уже есть задача и текущая реализованная задача будет второй задачей на ревью, то Developer необходимо завершить ревью текущих задач и только после этого он сможет брать новые задачи на выполнение.

Blocked [in development]

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

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

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

После этого, Developer начинает следить за разрешением блокера задачи и по необходимости «пушить» его скорейшее разрешение.

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

Именно Developer является инициатором необходимых действий для снятия блокера и возможности дальнейшей работы над задачей.

Code Review

Developer снимает префикс WIP: с Merge Request.

На ревью Merge Request автоматически назначаются два Ревьювера:

• Руководитель группы платформенной разработки
• произвольный Developer из платформенной группы разработки

Если у Ревьюверов не возникает вопросов и предложений по реализации задачи, то они ставят Approve.

Если у Ревьюверов есть что предложить или уточнить — они пишут комментарии к участкам кода Merge Request.

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

Эта процедура может происходить несколько раз, пока Developer не получит от Ревьюверов проставленные Approve.

Стоит помнить, что именно Developer берет на себя ответственность за то или иное выбранное решение, поэтому по большому счету, во всех спорных ситуациях, преимущество имеет Developer, а не Ревьюверы. Исключения составляют только те участки кода, которые оказывают влияние на стабильность работы проекта — тут преимущество за мнением Руководителя группы разработки.

Помните, что Code Review — это не место для спора. Поскольку мы профессионалы, комментарии в Code Review должны быть максимально короткими и по делу, а также иметь дружеский характер и не содержать никакой агрессии и высокомерия. Мы не поддерживаем попытки отстаивать свою точку зрения или защищать свою позицию в рамках Code Review.

Для нас, процесс Code Review, в первую очередь, это возможность:

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

Цель Developer получить от всех Ревьюверов Approve — это и является пройденным Code Review.

Именно Developer является инициатором общения с Ревьюверами для скорейшего прохождения Code Review.

После того, как Code Review пройдено, Developer принимает для себя решение, нужно ли тестирование для данной задачи или она может быть поставлена на Production без тестирования.

Если Developer считает, что задачу необходимо протестировать — он переводит её в статус Waiting To Test.

Если Developer считает, что задача не требует тестирования, то переводит её в статус Ready.

Если по каким-то причинам, выясняется, что решение задачи не выдерживает никакой критики или задача в корне решена неверно, то Developer переводит задачу в статус To Rework и начинает выполнение задачи снова.

Waiting To Test

Если Delivery Team имеет в своём составе Q.A., то любой свободный Q.A., в активном спринте, выбирает задачу, ожидающую тестирования, с самым высоким приоритетом, у которой не проставлен Тестировщик. Либо берет задачу, в которой он указан как Тестировщик.

Если Delivery Team использует ресурсы Q.A. Team для тестирования задач, то Руководитель группы тестирования назначает Q.A. на задачи, ожидающие тестирования.

В выбранной задаче, Q.A. указывает себя в качестве Тестировщик и переводит её в статус Testing.

Testing

Q.A. тестирует задачу.

Q.A. разворачивает ветку с задачей на тестовом стенде, в случае Continuous Delivery или собирает тестовую Сборку с веткой задачи или целиком epic-веткой, в случае Build Delivery.

Все спорные ситуации Q.A. согласовывает с Developer. Если спорную ситуацию не удается разрешить, то Q.A. и Developer обращаются к Feature Lead. Q.A. фиксирует комментариями к задаче все разрешения спорных ситуаций.

По итогу тестирования, Q.A. фиксирует результат тестирования как комментарий к задаче.

При отсутствии дефектов, Q.A. переводит задачу в статус Ready.

При наличии дефектов, Q.A. согласует их с Developer. Если Developer считает дефекты не критичными и готов их сразу исправить, то он исправляет их и сообщает об этом Q.A. для повторного тестирования. Если Developer считает дефекты критичными и он не готов их быстро исправить, то он просит Q.A. перевести задачу в статус To Rework, чтобы вернуться к исправлению дефектов позднее.

Именно Developer является инициатором общения с Q.A. для скорейшего прохождения процесса тестирования.

Blocked [in testing]

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

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

В этом случае, Q.A. пишет комментарий к задаче, который включает в себя причину блокировки задачи и информацию о том, что должно произойти, чтобы задача вернулась из этого статуса и переводит задачу в статус Blocked. Пока блокер не разрешен, Q.A берется за тестирование другой задачи.

После этого, Developer начинает следить за разрешением блокера задачи и по необходимости «пушить» его скорейшее разрешение.

После того, как блокер разрешен, Developer информирует об этом Q.A. Q.A. возвращает задачу в статус Testing и продолжает тестирование задачи.

Именно Developer является инициатором необходимых действий для снятия блокера и возможности дальнейшего тестирования задачи.

Ready

К этому моменту, решение задачи завершено — оно качественное и стабильное. Решение готово к поставке на Production.

В случае Continuous Delivery, Developer вливает ветку с кодом в основную ветку проекта и доставляет решение на Production.

После поставки решения на Production, Developer с помощью мониторингов следит, как решение ведет себя в Production-среде. Если решение ведет себя стабильно и выдерживает нагрузку, то Developer переводит задачу в статус Done. Иначе, Developer выполняет откат решения и переводит задачу в статус To Rework.

В случае Build Delivery, если задача привязана к Epic, то Developer вливает ветку с кодом в epic-ветку. Если же задача не привязана к Epic, то Developer вливает ветку с кодом в develop-ветку. После этого, Developer переводит задачу в статус Done.

Вливание ветки с кодом происходит исключительно методом Squash.

Done

В этом статусе, все работы по задаче успешно завершены.

В случае Continuous Delivery, задача успешно доставлена до Production.

В случае Build Delivery код задачи успешно влит в epic- или develop-ветку.

To Rework

В активном спринте, Developer выбирает задачу с самым высоким приоритетом в статусе To Rework, у которой он проставлен как исполнитель.

Developer переводит задачу в статус In Progress и начинает работу над ней, повторно проходя все статусы процесса разработки.

Цель Developer — минимизировать попадание задач в статус To Rework.

Canceled

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

Developer пишет комментарий к задаче, который включает в себя информацию о причине по которой задача потеряла актуальность и переводит её в статус Canceled.

🚧 Релиз Epic

В случае Build Delivery и использования Epic, мы отводим epic-ветку от develop-ветки и все задачи из Epic вливаются в epic-ветку.

При завершении очередной задачи из Epic, Developer, видя, что это была последняя незавершенная задача из Epic — информирует Feature Lead о завершении задач из Epic.

Поскольку, в случае Epic, мы не тестируем задачи из Epic по отдельности, то нам необходимо тестирование всего Epic целиком. Feature Lead инициирует тестирование готового Epic.

Если Delivery Team имеет в своём составе Q.A., то они переключаются на тестирование Epic. Если же Delivery Team использует ресурсы Q.A. Team для тестирования задач, то Feature Lead информирует Руководителя группы тестирования о необходимости тестирования Epic.

Q.A. тестируют задачи из Epic.

Developer, который создал epic-ветку, снимает с неё WIP: и вливает в develop-ветку.

Вливание epic-ветки в develop-ветку происходит без метода Squash, чтобы не потерять историю задач по Epic.