Скрам в Битрикс24 есть и в облачной версии, и в коробке. В системе предусмотрены бэклог, спринты, канбан-доска, роли и статусы задач. Модуль ориентирован на небольшие команды и простые сценарии. Он предполагает взаимодействие с задачами внутри одного спринта без сквозной связи с несколькими проектами и поддержки задач, выходящих за пределы итерации.
При этом в сложной и параллельной разработке задачи часто переходят между спринтами, а одни и те же сотрудники задействованы сразу в нескольких направлениях. В таких условиях требуется видеть загрузку, сроки и трудозатраты целиком, а не в рамках отдельной доски или спринта.
Штатный скрам в Битриксе закрывает только базовые потребности. Integrator.Digital предлагает модифицировать модуль с учетом своего опыта и реальной практики разработки. Улучшить и адаптировать его под конкретные требования клиента, превратив в инструмент, подходящий под любые форматы команд и задач.
Scrum в облачном и коробочном Битрикс24
Основная логика Scrum в облачной и коробочной версии Битрикс24 совпадает. Различия связаны с возможностями расширения и изменением поведения системы при росте нагрузки и усложнении структуры проектов.
В облачной версии Битрикс24 любые доработки выполняются через REST API и приложения из Маркета.
Они позволяют:
добавлять альтернативные представления задач;
упрощать отдельные операции планирования;
выносить часть процессов во внешние интерфейсы.
Однако внутренняя модель остается прежней. Задача может быть связана либо с проектом, либо со Scrum, без возможности их объединения. Статусы, жизненный цикл и зависимости задач заданы платформой и используются в неизменном виде. Приложения подключаются поверх основной системы как отдельные экраны или слайдеры.
Коробочная версия Битрикс24 предоставляет расширенные возможности донастройки — модуль может быть встроен в общую систему управления задачами и проектами с учетом внутренних процессов команды. Она позволяет изменять связи между сущностями, расширять логику обработки задач и адаптировать систему под реальные сценарии разработки без клонирования данных и разрозненных интерфейсов, характерных для внешних надстроек и приложений. Ниже — несколько примеров доработок, актуальных для коробки.
Автоматизация работы со спринтами и задачами
В базовом скрам большая часть действий при работе со спринтами выполняется вручную. Создание спринта, перенос задач, изменение статусов, уведомления участников и фиксация изменений требуют постоянного внимания и дисциплины со стороны команды.
В коробке Битрикс24 эти действия можно автоматизировать. В процессе модернизации добавляются обработчики событий и правила обработки задач при изменении их состояния или состава спринта. Они позволят избавиться от рутины и зафиксировать общий порядок работы со спринтами.
Например, при старте спринта можно задать правила изменения статусов и приоритетов задач. При завершении итерации — автоматически зафиксировать состояние незавершенных задач и учитывать их в следующем спринте без дополнительного вмешательства. Аналогичным образом можно задать правила уведомлений, чтобы команда получала только сообщения, связанные с изменениями по задачам.
Улучшения устранят разночтения в работе со спринтами и закрепят общий порядок обработки задач и итераций.
Планирование спринтов из проектных задач
При планировании спринта важно видеть состояние задач до их включения в итерацию: есть ли по ней оценка, назначен ли исполнитель, к какому типу она относится и на каком этапе находится. В стандартной реализации Битрикс24 эта информация хранится в карточках задач и проектах, но при планировании спринта не выводится. Чтобы понять состояние задачи, приходится открывать карточки и сверять данные вручную.
В коробке это легко исправить. Необходимые поля задачи — оценка, тип работы, исполнитель, статус и другие технические атрибуты — можно добавить в представление планирования спринта. Они будут показаны сразу при формировании итерации, без переходов в карточки задач и проекты.
Представление задач тоже можно настроить под конкретный сценарий и сохранить как рабочий срез — с нужными полями, группировкой и порядком отображения. Такие срезы удобно использовать повторно: для подготовки спринта, контроля загрузки, просмотра проблемных мест или передачи актуального состояния руководителю.
В результате сокращается время на подготовку спринта, уменьшается количество дополнительных действий, а планирование и контроль выполняются на одном наборе данных без пересборки списков.
Связь задач и спринтов
В базовой реализации задача связана со спринтом — модель не учитывает схемы, в которой задачи не укладываются в одну итерацию и переходят между этапами без потери контекста.
В коробочной редакции модуль можно доработать так, чтобы задача не была привязана к одному спринту. При переходах между итерациями сохраняются связи и история изменений, а сама задача может выполняться дольше одной итерации. Спринт используется для планирования на определенный период.
Становится возможным:
переносить задачи между спринтами без создания копий и потери данных;
сохранять историю изменений, оценок и трудозатрат независимо от итерации;
работать с длительными задачами дольше одного спринта;
планировать спринты вокруг задач, а не подгонять задачи под спринт.
Подобная модель ближе к реальной практике команд разработки, в которой задачи проходят несколько этапов и не всегда завершаются в рамках одной итерации.
Длительные задачи и параллельная разработка
Команды, как правило, одновременно ведут несколько направлений. Одни и те же специалисты работают над разными задачами и проектами, а отдельные задачи продолжаются дольше одной итерации.
Ограничения встроенного Scrum проявляются на уровне учета и планирования:
задача не может полноценно существовать вне одного спринта;
перенос задачи в следующий спринт требует дополнительных операций или обходных решений;
списанное время остается привязанным к итерации, а не к факту выполнения задачи;
загрузка специалистов рассчитывается отдельно по каждому спринту и не аккумулируется целиком;
планирование спринта опирается только на текущую доску, без учета параллельных задач и проектов.
В коробочной версии это ограничение можно устранить доработкой: изменить модель связей между задачами и спринтами, добавить необходимые поля и настроить сквозной учет. В результате появится контроль задач, времени и загрузки без привязки к спринтам и с учетом фактической занятости специалистов.
Загрузка и трудозатраты
В штатной логике учет строится вокруг отдельных спринтов. Загрузка специалистов рассматривается внутри текущей итерации, а данные по времени и занятости разнесены по разным доскам. Плановые оценки привязываются к спринтам, списанное время фиксируется в задачах, и при параллельной разработке общую картину приходится собирать самостоятельно.
После доработки учет переносится на уровень задач. Оценки, списания и остаток формируют единый массив данных, который сводится по специалистам, проектам и периодам. Загрузка отражает фактическую занятость команды по всем назначенным задачам.
При этом в расчет попадают задачи не только текущей итерации, но и распределенные дальше. Перегруженность выявляется заранее, поэтому состав и объем спринта корректируют до его начала, а не постфактум.
Роли и доступ к данным
В Битрикс24 доступ к задачам, спринтам и данным учета определяется общими правами проекта. При росте команды и количества участников это приводит к смешению ролей: разработчики, аналитики и руководители видят один и тот же набор данных, независимо от своей задачи.
В коробочной версии можно доработать разграничение доступа. Отдельные роли получат доступ только к тем данным, которые им необходимы: задачам, оценкам, списаниям времени или аналитике. Управленческие представления и сводная информация будут отделены от разработчиков.
История изменений и технический аудит
В процессе разработки у задачи нередко меняются оценки, исполнители, статусы и приоритеты. Такие изменения могут происходить на протяжении нескольких спринтов и напрямую влиять на сроки и загрузку команды. Если история фиксируется только в рамках отдельных итераций, восстановить ход выполнения задачи и причины задержек становится затруднительно.
В коробочной версии учет истории можно организовать на уровне задачи. В этом случае переходы статусов, изменения оценок, перераспределение исполнителей и учет времени могут фиксироваться как единая последовательность, независимо от количества спринтов. Решение позволит разбирать задачи постфактум, анализировать причины неудач, перерасход времени и накопление технического долга без самостоятельного восстановления событий.
Типы задач и атрибуты
В реальной разработке задачи внутри Scrum не одинаковы по своей природе. Фичи, баги, технический долг, рефакторинг и поддержка по-разному планируются, по-разному оцениваются и по-разному влияют на загрузку команды. При этом в штатном модуле Битрикс24 все они находятся в одном поле и отличаются только названием и описанием.
Из-за этого при планировании и анализе задачи с разной природой оказываются в одном потоке. Баги, доработки, технический долг и поддержка учитываются одинаково, из-за чего искажается представление о структуре работ и распределении усилий команды.
В коробке тип задачи и технические атрибуты можно вынести в отдельные поля и учитывать при планировании, анализе и работе со спринтами. В этом случае характеристики задачи сохраняются на протяжении всего жизненного цикла и не зависят от смены спринтов и статусов.
Обычно выделяют следующие типы и атрибуты задач:
тип задачи — фича, баг, технический долг, рефакторинг, поддержка;
приоритет и критичность для продукта;
влияние на пользователей или инфраструктуру;
связь с техническим долгом или архитектурными ограничениями;
необходимость тестирования или ревью.
Атрибуты позволяют по-разному смотреть на один и тот же бэклог. Например, можно отдельно анализировать объем багов, видеть долю технического долга в спринтах или отслеживать, сколько времени команда тратит на поддержку по сравнению с развитием продукта.
Информацию можно использовать при планировании спринтов, распределении задач между разработчиками и анализе выполненных работ. Появляется более точное представление о структуре разработки и составе скрам-процесса.
Поведение статусов задач при работе со спринтами
В скрам статус задачи используется для отражения этапа выполнения: разработка, проверка, доработка, готово. Спринт задает временные рамки, а не жизненный цикл задачи. В реальной разработке задача может несколько раз менять статус и при этом выходить за пределы одной итерации.
Во встроенном модуле он жестко связан с текущим спринтом. При переносе задачи между итерациями часть контекста теряется: статус приходится пересматривать, а история изменений оказывается рассредоточена по разным спринтам. Особенно заметно это в задачах, возвращающихся на доработку или проходящих несколько этапов проверки.
В коробочной версии его можно рассматривать как независимую характеристику, не привязанную к конкретному спринту: задача сохраняет свой статус при переходе между итерациями, а спринт используется только как плановый период выполнения.
Обычно в таких случаях фиксируют следующие правила:
статус задачи не сбрасывается при переносе между спринтами;
переходы статусов сохраняются в общей истории задачи;
завершение спринта не влияет на статус незавершенных задач;
возвраты на доработку не требуют ручного восстановления состояния.
Все это позволяет работать со статусами как с частью жизненного цикла задачи, а не атрибутом конкретной итерации.
Экспорт данных
При использовании скрам в задачах накапливаются данные по разработке: оценки, списанное время, исполнители, проекты, периоды выполнения. Часто они требуются вне скрам-доски — для управленческого и финансового учета.
В стандартной коробке Битрикс24 данные по времени и загрузке доступны в задачах и спринтах, но не собираются в единый срез. Для получения сводной информации по трудозатратам и загрузке команды требуется ручная выборка и объединение данных из разных разделов.
Доработка позволит свести все показатели в единый структурированный экспорт, снимая необходимость их самостоятельной агрегации из разных разделов.
Решение охватывает следующие группы данных:
задачи с привязкой к проектам и спринтам;
исполнители и распределение задач по сотрудникам;
плановые оценки задач;
фактически списанное время;
детализация списаний по датам;
комментарии к списанному времени;
итоги по периодам, проектам и сотрудникам.
После доработки показатели выгружаются в виде таблиц для дальнейшей обработки и анализа.
Их можно применять для:
формирования управленческих отчетов по разработке;
расчета фактической себестоимости проектов;
анализа загрузки сотрудников за период;
подготовки отчетов для руководства;
сверки плановых и фактических трудозатрат.
Экспорт снимает необходимость самостоятельной выборки данных из задач и спринтов. Полученная информация может быть использована как в аналитике внутри Битрикс24, так и во внешних сервисах.
Причины изменений задач
Задачи часто меняются: корректируются оценки, сдвигаются сроки, переносятся между спринтами или возвращаются в работу. Во встроенном модуле изменения фиксируются как факт, без указания причин.
Доработка позволяет вынести причины изменений в отдельный атрибут задачи и указывать, почему оно произошло: недооценка, смена требований, внешняя зависимость, техническая сложность или другие основания.
Данные можно использовать при разборе спринтов и анализе планирования. Например, выявлять, где ошибки повторяются системно, а где носят разовый характер.
Портфели проектов
В стандартной логике модуля каждый проект обрабатывается изолированно. Планирование спринтов, приоритеты и ограничения задаются внутри проекта и не соотносятся с другими направлениями разработки. Межпроектные зависимости и конкуренция за ресурсы в модели не учитываются.
Доработка способна добавить портфели. Проекты можно объединять в общий контур, в котором фиксируются приоритеты и ограничения на уровне портфеля. Scrum внутри отдельных проектов сохраняется, но планирование и распределение ресурсов выполняются с учетом общих правил и приоритетов.
Портфель используют для согласования нагрузки и приоритетов между проектами. Планирование спринтов в каждом проекте выполняется с учетом ограничений портфеля, а перераспределение ресурсов не требует отдельной синхронизации между командами и досками.
В итоге: скрам используется как плановый механизм внутри проектов, а портфель задает общую структуру приоритетов и распределения ресурсов.
Единые правила учета и сопоставимость данных
Во встроенном модуле каждая команда и каждый проект могут настраивать задачи по-своему. Типы задач, статусы, наборы полей и правила учета времени отличаются от проекта к проекту. Данные не сопоставимы между собой и плохо подходят для сводного анализа.
При доработке коробки можно ввести единые правила учета для скрам-команд. Фиксируется общий набор типов задач, статусов и обязательных атрибутов, а также единая логика учета времени и оценок. Эти правила применяются ко всем проектам, участвующим в скрам, без изменения привычного способа работы внутри команд.
Единая модель приводит данные по задачам, времени и загрузке к одному формату независимо от проекта и команды. За счет этого экспорт, планирование портфеля и аналитика опираются на одинаковые показатели, а не на разные правила в отдельных проектах.
Как Integrator.Digital улучшает скрам в Битрикс24
Integrator.Digital предлагает доработку штатного модуля в коробке Битрикс24 под конкретные требования компании. Услуга включает гарантию результата, обучение сотрудников, консультации и последующее сопровождение.
Решение ориентировано на практическое использование скрам в компаниях с несколькими проектами, параллельной разработкой и повышенными требованиями к учету задач, времени и загрузки. Чтобы обсудить услугу — позвоните или напишите нам.
