Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров
7 команд и ни одного менеджера — думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1–2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.
Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3–4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен хранение и управление данными осуществляется с помощью BIM-Server Pilot
Взаимодействие со сметными системами
Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Обмен данными
Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv)
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
«Пусть лучше падает приложение, чем спроектированное здание»
— Шутка архитектора
Итак, наш департамент разработки состоит из 28 разработчиков, 3 продуктовых аналитиков и 6 тестировщиков. Каждая команда включает продуктового аналитика, тестировщика и четырех разработчиков. Мы следуем всем обязательным активностям скрама — спринты, планирование, ретро, демо, ежедневные стендапы. Более того, мы используем некоторые фишки из SAFe (Scaled Agile Framework) для синхронизации работы нескольких команд — еженедельные синхронизации команд, ретро релиза раз в 3–4 месяца. Есть у нас и не совсем обычная активность — мы ее называем груминг (grooming), на которой разбираем бизнесовую фичу вместе со всей командой и аналитиком и получаем список всем понятных требований к фиче и критериев готовности (DoDs).
Грумить или не грумить, вот в чем вопрос
В классическом скраме, как вы знаете, существует активность «Планирование», на которой обязательно присутствует продуктовик (product owner), команда разработки, тестировщики и другие заинтересованные (stakeholders). В процессе планирования вырабатывается цель спринта, состав фич или стори (user story) для разработки. Присутствие product owner«а — обязательное условие успешного планирования, ведь только он может ответить на нестандартные вопросы о фиче, которые приходят в голову опытным (и не только) разработчикам при осознании цели фичи и в процессе декомпозиции ее на задачи.
Здесь кроется первый подводный камень классического скрама — как сделать возможным присутствие продуктовика на планировании 7-ми команд в один день? Может, есть возможность рассинхронизации команд и проведения планирования в разные дни? Получается, что product owner проведет 7 дней из 14, выделенных на спринт, на планированиях. Кроме того, в такой рассинхронизации становится непонятным, как проводить демо, на котором хочется показать интегральный результат работы всех команд?
Мы решили эту проблему. Планирование проводится только командой. На планировании команда занимается декомпозицей заранее подготовленных и разгрумленных фич, для которых уже сформированы критерии готовности. Таким образом, на планировании каждый в команде (если он/она внимательно слушали и активно участвовали в груминге) знает, что именно нужно сделать в той или иной фиче. Это экономит время product owner«а и позволяет синхронизировать планирование команд и проводить их в один день.
Особенность нашего скрама заключается как раз в проведении специальных активностей — грумингов фич. На них присутствует product owner, вся команда, которая будет разрабатывать фичу, тестировщики, технические писатели и все заинтересованные. Продуктовик рассказывает, о чем будет фича, как это должно выглядеть и основные сценарии использования. В процессе груминга любой присутствующий может задавать любые вопросы касательно функционала, сценариев использования, краевых условий. Как правило, несмотря на подготовленность фич от product owner«а, постоянно возникает 2–3 ключевых вопроса от присутствующих, которые могут отразиться на аналитике фичи и повлиять на ее конечный вариант. Кроме того, по вопросам, не принципиальным для аналитики, разработчики могут сами принять решение, как именно реализовать тот или иной функционал. Длительность активности зависит от сложности фичи и длится от 30 минут до 5 часов.
База знаний формируется, в том числе, из таких настенных записей
Таким образом, получается достаточно дорогая активность по трудозатратам. Но это единственный минус грумингов, плюсы которого очевидны и в значительной степени перевешивают время, затраченное на обсуждение. Некоторые плюсы я уже упоминал, пройдемся по ним еще раз:
- Нет необходимости присутствовать продуктовому аналитику на планировании всех команд, что позволяет синхронизировать планирование. Груминг же проводится накануне спринта, где планируется работа над фичей, в удобное для всех участников время.
- Вся команда погружена в процесс обсуждения функциональности и тонкостей работы фичи. Это позволяет избежать известного расхождения ожидания и факта реализованного функционала. Кроме этого, коллективное обсуждение выявляет неточности и неоднозначности в изначально сформулированной фиче, выявляет ошибки аналитики за счет неожиданных вопросов присутствующих (а такие вопросы есть почти всегда).
- На выходе формируется полный и понятный всем список требований и сценариев использования фичи. Разработчики будут проверять код по основным моментам функционала, а тестировщики будут писать интеграционные тесты, зная сценарии поведения системы.
Сами себе менеджеры
Спринты разработки у нас длятся десять рабочих дней. Между спринтами есть день для демо и ретро и день для планирования следующего спринта. В результате спринты не привязаны к дням недели, а только к абсолютному количеству рабочих дней.
У каждой команды есть командный чат в телеграм, который позволяет оперативно обсуждать все вопросы разработки, организации активностей, а также вопросы политики и религии. Проведение ретро, ежедневных стендапов, планирования, как правило, инициируется разными разработчиками, у кого есть время написать в чат. Ответственным за проведение активности может быть любой разработчик, кто пожелает. Назначаем время активности, собираемся командой и обсуждаем. Как правило, в каждой команде есть опытный тимлид, который также обладает хорошими soft skills, что позволяет не уводить обсуждения в сторону. Хотя, в каждой команде soft skills хорошо развиты у большинства разработчиков, что позволяет конструктивно обсуждать вопросы и сводить к минимуму время, затрачиваемое на не конструктивные обсуждения. Результатами большинства обсуждений становятся записи на маркерной доске, фото которой бережно хранятся в архивах чата и в облачном хранилище для истории.
Планирование
Задачи на планировании оцениваются в абстрактных рабочих часах, которых в рабочем дне мы оптимистично полагаем целых пять. То есть, если на задачу по оценке уйдет день, то мы оцениваем ее в пять часов. Используем для оценок покер планирования. Если оценки расходятся, как правило, это говорит о том, что кто-то из участников знает больше, чем другие. Таким образом, выравнивается понимание контекста задачи и, как следствие, переоценка задачи.
Почему мы не используем для оценки попугаев или story points? Со временем мы пришли к выводу, что команде важно правильно оценивать скорость разработки, чтобы давать правдоподобные обещания по разработке фич в очередном релизе. Основной критикой оценки в часах является зависимость от опытности разработчика и степени его знакомства с участком кода. В это же время story points позволяют оценивать объем работы без привязки к конкретному разработчику. Но что произойдет, если в очередном спринте задачу в, например, 3 story points возьмет новичок? Он потратит на нее 3 дня, в то время, как опытный управится за 1 день. Таким образом, скоуп спринта перестанет быть привязанным к временным рамкам спринта. Мы же в процессе планирования выравниваем именно время на задачу. Бывает, что опытный разработчик оценивает задачу в два часа, а неопытный — в пять часов. После обсуждения окончательной оценкой скорее всего станет пять часов. Таким образом, мы потенциально завышаем оценку задачи, но зато защищены от невыполнения обязательств по разработке скоупа спринта.
Помимо декомпозированных задач, для фичи обозначается багпул (bugpool), который также оценивается, в том числе тестировщиком. Смысл его состоит в обозначении степени неопределенности для потенциальных багов в фиче. Кажется, что можно принимать неопределенность всегда за 30–50%. Тем не менее опыт показывает, что неопределенность зависит от контекста самой задачи. Например, баги в задаче, связанной с нетипичным использованием GUI или неизвестной части Qt, наверняка станут головной болью. В это же время фича на расширение известного функционала понятна и предсказуема. Это позволяет нам иметь запас часов в спринте на починку багов, помимо основной оценки времени на разработку.
Ретро
Закончить рассказ хочется на самой позитивной активности спринта. Ведущий ретро, как правило, выбирается по правилу: кто дольше всех не вел ретро. На ретро мы составляем список позитивных и не очень моментов. Как правило, в части плюсов бывают записи вроде «Показали на демо 3 фичи», «Починили сложный баг», «Отметили день рождения команды». В части минусов встречаются наоборот «Не успели доделать фичу», «Нашли невоспроизводимый баг», «Нашли архитектурную проблему». По каждому минусу, как правило, проходит бурное обсуждение, которое выливается в конструктивные предложения и соответствующие улучшения. Особенно приятно перечитывать предыдущие ретро и видеть, как с каждым спринтом мы не возвращаемся к прежним минусам.
На каждом ретро настроение отличное, но некоторые минусы бывают очень серьезными: «Даня недостаточно настойчив»
На посошок
На повестке остались не освещенными вопросы проведения синхронизации команд, демо, планирования релиза, ретро релиза. В следующих статьях обязательно расскажу об этом и о многом другом.
Присоединяйся к нашей команде разработчиков без менеджеров. Попробуй нашу BIM-систему — спроектируй дом своей мечты.
Анатолий Осокин, ведущий инженер-программист, Renga Software.
