В Битворкс мы разрабатываем масштабируемые высокодоступные комплексные программные системы. Каждый проект по-своему уникален, и критерии качества продукта значительно отличаются от случая к случаю. Более того, качество является относительным понятием: заказчики, разработчики и конечные пользователи могут иметь разные ожидания от продукта, и очень важно добиться понимания и согласия между всеми заинтересованными сторонами.
Для того, чтобы всегда создавать продукты, которые бы соответствовали общепризнанным стандартам качества, максимально обеспечивали решение поставленных задач и в то же время оправдывали ожидания всех заинтересованных лиц, мы определили ряд высокоуровневых идеалов, в соответствии с которыми мы строим и используем эффективный процесс разработки.
За основу процесса разработки в Битворкс берется фреймворк Scrum, однако, по мере развития проекта, в зависимости от требований заказчика, специфики предметной области, имеющихся ресурсов и других факторов, в этот процесс вносятся коррективы для достижения максимальной эффективности и обеспечения соответствия обозначенным идеалам.
Для того, чтобы познакомить читателей нашего блога с тем, как устроен процесс разработки в Bitworks и какие решения мы принимаем для его оптимизации (а главное - почему), мы решили выпустить цикл статей, в котором на примере одного из наших проектов мы подробно расскажем о своем подходе к разработке программных систем.
В этом цикле статей мы хотим рассказать:
- О высокоуровневых идеалах и общепринятых стандартах, которые определяют не только процесс разработки, но и работу компании в целом.
- О ключевых этапах разработки, их связи между собой, их нюансах и возможных альтернативных подходах к их организации.
- Об участниках и других заинтересованных лицах процесса разработки, и о том как обеспечивается согласование их потребностей.
- О технических и методологических особенностях организации процесса разработки, которые обеспечивают гармоничное взаимодействие всех его отдельных компонентов.
На протяжении всего цикла в качестве показательного примера мы будем использовать один из наших текущих проектов. Без лишних церемоний, встречайте: Placeholder, биржа цифровой рекламы.
Конечно, проект не называется Placeholder (как бы это название ни подходило для системы, связанной с размещением рекламы): мы намеренно хотим обезличить продукт, чтобы не создавать неправильных ассоциаций и не разглашать информацию, которую нельзя разглашать.
Мы не будем вдаваться в подробности задачи, которую решает продукт Placeholder, не будем трогать специфику предметной области и технические детали реализации: мы сконцентрируем свое внимание именно на процессе разработки. Однако, для полноты картины мы укажем некоторые ключевые особенности Placeholder:
- Предметная область продукта - автоматизация бизнес-процессов в цифровом маркетинге.
- Целевой рынок продукта - США в качестве отправной точки, дальнейшие планы обсуждаются.
- Пользователями системы являются крупные издательства и рекламные агентства (реже - индивидуальные рекламодатели).
- Система взаимодействует со многими внешними системами, в том числе системами учета финансов, CRM-системами, blockchain.
- В проекте участвует отдельная (от Bitworks) продуктовая команда, которая занимается анализом требований, проектированием интерфейса, работой с клиентами и продвижением продукта.
Проект находится в разработке около двух лет и в данный момент готовится к публичному бета-релизу. На текущий момент команда Placeholder насчитывает 20 человек (без учета продуктовой команды).
В настоящей вводной статье цикла мы хотим обзорно рассказать об основных принципах процесса разработки в Placeholder, о его этапах, участниках и основных артефактах, для того чтобы в последующем более подробно рассмотреть эти элементы в обозначенном контексте.
Как и в случае с другими проектами Bitworks, изначально работа над Placeholder осуществлялась в рамках процесса, основанного на фреймворке Scrum. С течением времени под влиянием различных факторов (рост команды разработки, специфика взаимодействия с командой продукта и др.) строгое выполнение всех предписаний фреймворка Scrum стало невозможным, и процесс был значительно видоизменен.
Результирующий процесс формально нельзя относить к Scrum-у, однако, в его основе лежат многие принципы и практики, перенятые из фреймворка. Частично сохранилась и терминология: например, в процессе сохранилось название роли Scrum-мастера. В этой и последующих статьях мы уделим особое внимание отклонениям от Scrum-а и постараемся подробно рассказать, чем они были обусловлены.
Процесс разработки Placeholder является итеративным и инкрементным с использованием фиксированных спринтов (согласно определению спринта в Scrum-е) продолжительностью две недели.
В отличии от Scrum-а, в команде разработки Placeholder есть дальнейшее разделение на подкоманды:
- команда front end разработки,
- команда back end разработки,
- команда контроля качества (QA).
Во главе каждой из них стоит руководитель (Team Lead), который представляет команду на всех общих мероприятиях процесса.
Создание иерархии и разделение обязанностей являются грубым нарушением Scrum Guide-а, впрочем, как и превышение размера команды разработки более 9 человек. Сложность проекта и объем работы потребовали от участников более узкой специализации, а необходимость поддерживать высокий темп разработки привела к расширению команды, и в последствии к появлению ответственных по направлениям.
Помимо участников команд в проекте есть следующие роли:
- архитектор;
- технический писатель;
- специалист DevOps;
- Scrum-мастер.
Этапы одной итерации процесса разработки изображены на следующей диаграмме:
За состоянием проекта на каждом этапе следит Scrum-мастер. Он разрабатывает и утверждает стандарты, гарантирует соответствие процесса этим стандартам, оптимизирует отдельные этапы и процесс в целом. В этом смысле правильнее было бы называть его процесс-мастером (аналогично тому, как Scrum-мастер помогает следовать Scrum-у, процесс-мастер помогает следовать существующему процессу), но старое название прижилось и в итоге осталось неизменным.
В начале каждой итерации происходит обработка требований. Большинство требований попадают в проект в “сыром” виде: в их числе могут быть аналитические наработки команды продукта, “хотелки” пользователей, уточнения, возникшие на одной из предыдущих итераций, технический долг. Для того, чтобы требование стало задачей и попало в план итерации, необходимо:
- формализовать его;
- разбить на задачи;
- упорядочить задачи по приоритету.
В одной из последующих статей мы более подробно расскажем о возможных источниках требований, об инструментах, используемых для организации неформальных и формальных требований, о процессе формализации и декомпозиции требований, а также о работе с приоритетами в условиях большого количества заинтересованных сторон.
На основании результатов работы с требованиями руководители отделов составляют план итерации: формулируют задачи для инженеров, уточняют оценку, упорядочивают задачи с учетом их разделения по командам (back end, front end, QA) и составляют примерный график их выполнения.
После этого, в соответствии с планом, к работе над задачами приступают специалисты. Разработчики реализуют необходимую функциональность, проводят инспекцию кода (code review) и затем отправляют результат на проверку отделу QA. Специалисты QA проверяют функциональность на соответствие требованиям и либо принимают работу, либо отправляют на доработку. Этап непосредственной работы над задачами требует особого внимания и будет подробно рассмотрен нами в отдельной статье.
Специалист DevOps поддерживает несколько отдельных окружений с Continuous Integration, для того, чтобы иметь несколько независимых версий системы для разных участников процесса. В одной из последующих статей мы подробнее расскажем о том, какие именно окружения используются в Placeholder (и зачем), а также о других задачах DevOps и его месте в процессе разработки.
По завершению этого этапа параллельно начинаются работа над регрессионным тестированием всей функциональности системы, а также подготовка к демонстрации результатов итерации (обзору спринта), на которой все участники процесса впервые видят полную картину. По результатам демонстрации проводится ретроспектива спринта: сначала внутри каждой команды, а затем среди руководителей.
После этого начинается подготовка к релизу. Обычно это очень прямолинейный и исключительно организационный этап: все необходимые приготовления завершены во время подготовки к демонстрации, и остается лишь внести коррективы по ее результатам. Параллельно с этим команды приступают к новой итерации.
Параллельно с итеративным инкрементным процессом в Placeholder существует практика работы над промежуточными проектами. Введение проектного подхода в рамках итеративного процесса разработки является еще одним отступлением от Scrum-а, однако правильное распределение ресурсов и времени между задачами спринта и промежуточными проектами позволяет, помимо создания инкремента, также решать такие обособленные задачи, как доработка инфраструктуры и проведение аудита безопасности. Мы расскажем о промежуточных проектах подробнее в последующих статьях.
Применение прозрачности, инспекции, адаптации и других основополагающих принципов фреймворка Scrum, а также сохранение возможности вносить значительные изменения в процесс, позволяют команде Placeholder добиться максимальной эффективности в условиях постоянного роста проекта.