Юрий Дручинин, платформа «Сфера»: Как эффективно управлять задачами разработки ПО при отказе от ИТ-продуктов зарубежных вендоров

Юрий Дручинин: Уход зарубежного поставщика стал неприятным событием для немалого количества организаций в России. Это объясняется тем, что компании пытались с помощью Jira максимально автоматизировать процесс производства ПО. Несмотря на то, что это точечный инструмент, реализующий 3-4 базовых функции конвейера разработки ПО, большинство крупных игроков дорабатывали его под свои задачи, растягивая до 10-12 функций. Так, с помощью Jira закрывали не только управление задачами и контроль сроков, но и, например, управление релизами и контрольными точками. И это была повсеместная практика.

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

Впрочем, по поводу Jira есть хорошая новость: отечественная альтернатива имеется. Это продукт «Сфера.Задачи», входящий в платформу производства ПО «Сфера». Бета-версия продукта вышла в декабре, и мы точно знаем, что у него гораздо больше возможностей, чем у Jira из коробки, в плане гибкости конфигурирования под целевой процесс заказчика. Кроме того, использование «Сфера. Задачи» избавляет бизнес от необходимости работать с ломаной версией продукта, выискивать способ оплатить его со счетов в иностранных банках.

Юрий Дручинин: С необходимостью разработки цифровых продуктов сталкивается и малый бизнес, и корпорации. И каждая из компаний заинтересована именно в построении конвейера, чтобы можно было бесшовно переходить от постановки задачи к работе с требованиями, далее – связывать задачи с кодом, проводить релизные сборки, оформлять тестовую документацию, осуществлять CI/CD и многое другое.

Изначально наш продукт ориентирован на enterprise-сегмент: технологический стек, архитектура, соответствие требованиям ИБ, подход к интеграциям, возможность развертывания в облаке. Сейчас реализована базовая функциональность и идет активное добавление инструментария, к которому привыкли пользователи таких продуктов. Дмитрий Бородачев, DатаРу Облако: Наше преимущество — мультивендорная модель предоставления облачных услуг

При этом «Сфера.Задачи» не просто сразу конфигурируется под процессы заказчика, но и автоматически повышает зрелость процессов. Да-да, именно так: появление «Сфера.Задачи» будет толкать компанию к оптимизации процессов разработки, особенно, если этот продукт будут использовать в комплекте с другими инструментами платформы «Сфера».

Юрий Дручинин: «Сфера.Задачи» – один из множества плотно интегрированных друг с другом продуктов платформы «Сфера», которая позволяет управлять разработкой комплексно. Она обеспечивает возможность получить все инструменты на соседних участках конвейера и не терять время на «перенос детали» от одного станка до другого на руках.

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

В целом зрелый конвейер подразумевает реализацию примерно 70 (!) функций – от оформления идеи, через разработку и до всех этапов эксплуатации. В части инструментов управления платформа «Сфера» позволяет работать с бэклогом разработки, релизным планированием, прохождением контрольных точек. По сути, это набор автоматизированных проверок, встроенных в DevOps-пайплайн системы, некоторые узловые моменты оценки качества, например, предрелизная проверка и т.д. Там же реализована функция разработки сложных документов, предусмотренных ГОСТом, таких как описания архитектуры информационной системы или требования к информационной системе. Их отдельная разработка и согласование даже в небольших компаниях требует очень много времени и ресурсов.

Юрий Дручинин: Во-первых, мы с MVP-версии продукта взяли за основу принцип конструктора. Если в системе появляется какая-то сущность, мы сразу предполагаем, что нам может понадобиться выстроить жизненный цикл объекта, включить его в иерархию и установить взаимосвязи с другими объектами. В Jira реализован ограниченный набор типов задач (issue types), включая: эпик (крупная инициатива в рамках одного продукта), фича (часть инициативы, которая поставляет ценность клиенту), история (описание части функциональности, несущей ценность), задача (один или несколько видов работ), дефект (bug). Сервис предполагает их жесткую иерархию и не позволяет выстроить иерархию проектных областей. Донастройка ПО возможна, но технически ограничена.

Сравните со «Сфера.Задачи», где есть возможность строить иерархии пространств, отражающие функциональную структуру компании: команда – стрим – департамент. Значительно меняется подход и к горизонтам планирования. В Jira все просто – там предусмотрен один-единственный горизонт планирования, который называется «спринт». Это позволяет выстраивать нужный процесс в соответствии с методологией Agile, чего достаточно для небольших компаний. Но крупным компаниям нужно больше – реализовывать организационное управление на принципах Scaled Agile Framework (SAFe). Выручает программный инструмент, который подразумевает сложную иерархию горизонтов планирования, не только спринтов, но и суперспринтов: квартальных, полугодовых или любых других временных отрезков. Причем, внутри одной команды могут быть как задачи уровня суперспринта (эпики, фичи), так и задачи уровня спринта (истории, задачи, дефекты).

У задач любого типа могут быть подтипы, которые внешне не отличаются, но несут дополнительную логику. Еще один пример, задача Технического долга требует подключения к ней, помимо Исполнителя и Владельца, Эксперта Архитектуры или Эксперта ИБ. В Jira такую логику нужно было дополнительно программировать, а в «Сфера.Задачи» – делается без проблем на уровне конфигурации. Кроме того, в «Сфера.Задачи» могут быть учтены даже такие виды линейной деятельности, которые в спринт вообще не планируются. Так, мелкие задачи типа встречи или звонка можно реализовывать на уровне Kanban-доски вне привязки к какой-либо спринтовой активности. И в «Сфера.Задачи» их тоже можно отслеживать.

Юрий Дручинин: Нет, затачивать ничего не нужно. Управление процессом, которое осуществляется в рамках «Сфера.Задачи», очень точно кроится под текущий процесс заказчика. Не нужен Scaled Agile? Отключаем эти возможности. Не нужны суперспринты? Отключаем суперспринты. И в этом «урезанном» варианте вы получаете аналог коробочной Jira, но не санкционный.

Однако с развитием бизнеса начнут ощущаться технические ограничения «коробки». Если появится желание ввести, скажем, работу с Product Increment (PI) по SAFe или квартальное планирование, то эти возможности надо просто включить. Обратите внимание: вы остаетесь в парадигме ваших командных забегов, у вас не меняется оргструктура, но появляется возможность вести разработку с поэтапной сборкой, планировать крупные фичи и отслеживать их исполнение на больших горизонтах планирования.

Иными словами, вы получаете инструмент, который изначально сконфигурирован под вас, но еще и сильно на вырост. Прямо из коробки вы можете создать процесс любой сложности, хоть enterprise уровня, хоть SMB, но самое главное – то, что он может расти вместе с вами. «Сфера.Задачи» растет и взрослеет вместе с вашим процессом. Отмечу, что в наших планах – создание готовых типовых конфигураций, что сделает жизнь менеджеров разработки еще более комфортной.

Юрий Дручинин: Здесь нужно отделить методические аспекты от технологических.

За мотивацию, целеполагание отвечает методология «Сферы», которая может поставляться, как в комплекте, так и отдельно от инструментов. Что же касается инструментальной базы, то в «Сфера.Задачи» есть интересная функциональность: ассистент планирования и ассистент производительности. Так, при планировании и работе с бэклогом система подсказывает пользователю, например, как загружены ресурсы в его команде, как их грамотно распределить, как оценены задачи и т.д. Кроме того, определенным образом подсвечивается профиль спринта. Например, лидеру команды или менеджеру проекта ассистент планирования указывает на то, что в бэклоге лежат дефекты, блокирующие дальнейшее движение разработки. Он же выявляет интеграционные зависимости по задачам между соседними командами и сигнализирует, если один из коллективов рискует сорвать сроки по выполнению задачи, на которые ориентируются несколько других команд.

Юрий Дручинин: Инструмент «Сфера.Задачи» будет поставляться клиентам в двух вариантах. Для заказчиков enterprise-уровня предоставляется on-premise решение, которое устанавливается на мощностях заказчика: на корпоративных серверах или в частном облаке. В этом случае внедрением и настройкой решения занимается наша компания.

Второй вариант – это SaaS-решение, которое работает на наших вычислительных мощностях. Если заказчику необходимо перейти на «Сфера.Задачи» с какого-либо другого инструмента, то мы обеспечиваем необходимый инструментарий для миграции. В настоящий момент реализованы средства перехода с Jira. Но в нашем бэклоге есть задача на разработку модулей сопряжения с другими таск-трекерами, которые могут стоять у заказчика, в частности, JetBrains YouTrack, Trello, Asana, GitHub. Мы планируем бесшовный и максимально безболезненный переход с того инструмента, с которым ранее работал клиент, в «Сфера.Задачи».

Юрий Дручинин: Мы уже работаем над этими задачами. Но в первую очередь обеспечивается интеграция с другими продуктами «Сферы», которые эти потребности закрывают. Я имею в виду «Сфера.Исходный код», «Сфера.Оркестрация» для организации CI/CD, «Сфера.Дистрибутивы и библиотеки». И, конечно, будем обеспечивать интеграцию с популярными инструментом типа BitBucket, Gitlab, GitHub.

В продуктовой стратегии «Сфера.Задачи» учтено развитие возможности самостоятельно (точнее, вместе с канальным приложением «Сферы») встать в любой конвейер разработки. Если клиент хочет заменить только Jira, но оставить open source Wiki-движок для работы с документами и СПО-менеджер репозитория для управления исходным кодом, то команда интегрирует «Сфера.Задачи» с этими рыночными инструментами.

Юрий Дручинин: Отдельные таск-менеджеры почти не конкурируют друг с другом в части функциональности: управление бэклогом, Kanban-доски, Scrum-доски, проектные области и, в общем-то, все. Но дьявол скрывается в деталях. Как это приложение масштабируется и конфигурируется под нужды заказчиков? Как оно устанавливается в его среду и соответствует ли требованиям информационной безопасности? Как оно интегрируется со служебными сервисами, которые уже присутствуют в компании?

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

Один из актуальнейших вопросов – согласование продуктовых особенностей со службой информационной безопасности компании, ведь нас интересуют не просто формальные вопросы отказоустойчивости или масштабирования по нагрузке. В центре внимания конкретные вопросы ИБ, связанные с размещением ПО в различных контурах, обеспечением безопасности данных и т.д. Далеко не каждый отечественный продукт закрывает эти вопросы, а «Сфера.Задачи» точно сможет пройти все аудиты корпоративной службы ИБ и успешно проинтегрируется с той средой безопасности, которая развернута в каждой средней и крупной компании.

По вопросам организации демонстрации инструмента «Сфера.Задачи» обращайтесь к коммерческому директору платформы производства «Сфера» Максиму Кутузову, mkutuzov@t1-consulting.ru