Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров

    7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.



    Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?

    Подробнее о семействе продуктов Renga (Осторожно, маркетинг!)
    Renga Architecture – система для архитектурно-строительного проектирования. Программа создана для максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания и информационной модели, и быстрая компоновка чертежей согласно стандартам СПДС и многое другое.

    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 часов.



    База знаний формируется, в том числе, из таких настенных записей

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

    1. Нет необходимости присутствовать продуктовому аналитику на планировании всех команд, что позволяет синхронизировать планирование. Груминг же проводится накануне спринта, где планируется работа над фичей, в удобное для всех участников время.
    2. Вся команда погружена в процесс обсуждения функциональности и тонкостей работы фичи. Это позволяет избежать известного расхождения ожидания и факта реализованного функционала. Кроме этого, коллективное обсуждение выявляет неточности и неоднозначности в изначально сформулированной фиче, выявляет ошибки аналитики за счет неожиданных вопросов присутствующих (а такие вопросы есть почти всегда).
    3. На выходе формируется полный и понятный всем список требований и сценариев использования фичи. Разработчики будут проверять код по основным моментам функционала, а тестировщики будут писать интеграционные тесты, зная сценарии поведения системы.

    Сами себе менеджеры


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

    У каждой команды есть командный чат в телеграм, который позволяет оперативно обсуждать все вопросы разработки, организации активностей, а также вопросы политики и религии. Проведение ретро, ежедневных стендапов, планирования, как правило, инициируется разными разработчиками, у кого есть время написать в чат. Ответственным за проведение активности может быть любой разработчик, кто пожелает. Назначаем время активности, собираемся командой и обсуждаем. Как правило, в каждой команде есть опытный тимлид, который также обладает хорошими soft skills, что позволяет не уводить обсуждения в сторону. Хотя, в каждой команде soft skills хорошо развиты у большинства разработчиков, что позволяет конструктивно обсуждать вопросы и сводить к минимуму время, затрачиваемое на не конструктивные обсуждения. Результатами большинства обсуждений становятся записи на маркерной доске, фото которой бережно хранятся в архивах чата и в облачном хранилище для истории.

    Планирование


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

    Почему мы не используем для оценки попугаев или story points? Со временем мы пришли к выводу, что команде важно правильно оценивать скорость разработки, чтобы давать правдоподобные обещания по разработке фич в очередном релизе. Основной критикой оценки в часах является зависимость от опытности разработчика и степени его знакомства с участком кода. В это же время story points позволяют оценивать объем работы без привязки к конкретному разработчику. Но что произойдет, если в очередном спринте задачу в, например, 3 story points возьмет новичок? Он потратит на нее 3 дня, в то время, как опытный управится за 1 день. Таким образом, скоуп спринта перестанет быть привязанным к временным рамкам спринта. Мы же в процессе планирования выравниваем именно время на задачу. Бывает, что опытный разработчик оценивает задачу в два часа, а неопытный – в пять часов. После обсуждения окончательной оценкой скорее всего станет пять часов. Таким образом, мы потенциально завышаем оценку задачи, но зато защищены от невыполнения обязательств по разработке скоупа спринта.

    Помимо декомпозированных задач, для фичи обозначается багпул (bugpool), который также оценивается, в том числе тестировщиком. Смысл его состоит в обозначении степени неопределенности для потенциальных багов в фиче. Кажется, что можно принимать неопределенность всегда за 30-50%. Тем не менее опыт показывает, что неопределенность зависит от контекста самой задачи. Например, баги в задаче, связанной с нетипичным использованием GUI или неизвестной части Qt, наверняка станут головной болью. В это же время фича на расширение известного функционала понятна и предсказуема. Это позволяет нам иметь запас часов в спринте на починку багов, помимо основной оценки времени на разработку.

    Ретро


    Закончить рассказ хочется на самой позитивной активности спринта. Ведущий ретро, как правило, выбирается по правилу: кто дольше всех не вел ретро. На ретро мы составляем список позитивных и не очень моментов. Как правило, в части плюсов бывают записи вроде “Показали на демо 3 фичи”, “Починили сложный баг”, “Отметили день рождения команды”. В части минусов встречаются наоборот “Не успели доделать фичу”, “Нашли невоспроизводимый баг”, “Нашли архитектурную проблему”. По каждому минусу, как правило, проходит бурное обсуждение, которое выливается в конструктивные предложения и соответствующие улучшения. Особенно приятно перечитывать предыдущие ретро и видеть, как с каждым спринтом мы не возвращаемся к прежним минусам.



    На каждом ретро настроение отличное, но некоторые минусы бывают очень серьезными: “Даня недостаточно настойчив”

    На посошок


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

    Присоединяйся к нашей команде разработчиков без менеджеров. Попробуй нашу BIM-систему – спроектируй дом своей мечты.

    Анатолий Осокин, ведущий инженер-программист, Renga Software.
    АСКОН
    Крупнейший российский разработчик инженерного ПО

    Комментарии 29

      +4
      Ну так роль менеджера у вас все равно есть, только каждый разработчик взял на себя 1/10 менеджера (условно) и теперь только на 9/10 разработчик
        0
        Прям ответ стандартного менеджера))) Прям как на картинке про непрерывный набор текста…
          +2

          Всмысле? Тут же прямо написано, что каждый разработчик должен ещё помнить о том, что кому-то надо таки организовать встречу и в свободное время сначала выполняет у себя в голове скрипт "а не пора ли запустить митинг".

            +2
            … каждый разработчик должен ещё помнить о том, что кому-то надо таки организовать встречу ...

            Интересная подмена понятий. Я работал в трех IT-компаниях в CAD индустрии. Ни в одной я не сталкивался с тем, что разработчики «должны» помнить. Каждый почему-то понимал и ценил каждую активность, которая у нас проводилась и сам напоминал, если кто-то в потоке забывал о времени. Бывало, что из-за потока забывали о совещаниях, но было это редко и проблем не доставляло.

            И да, разработчикам, с которыми я работаю и работал, в радость созывать народ для обсуждения какой-то фичи или архитектуры. Ведь каждый профессионал понимает, что, как правило!, только в разговоре и споре рождается лучший вариант решения.
            +1
            То есть если аргумент звучит, как что-то, что мог бы сказать сторонник точки зрения, отличной от вашей, то это автоматически не верно?
            Но я, например, разработчик, и я хочу писать код и продумывать архитектуру приложения, а не заниматься организационными вопросами. Так что пусть лучше менеджеры остаются.
            У вас, видимо, просто не было опыта работы с нормальным менеджером.
              +1

              Если возник вопрос по работе, Вы


              • идёте к коллеге и говорите с ним?
              • или Вы просите менеджера организовать официальный митинг?
                0
                А зачем ради такого менеджера привлекать? Пусть он своей работой занимается, а такие вещи быстрее напрямую решить.
          0

          Черт, сколько бы я отдал, лишь бы посмотреть, что получится, если применить данный подход к разработке программного обеспечения, например, для системы управления ракеты Falcon 9. Например как бы планировалась и реализовалась в спринтах фича "автоматического возвращения первой ступени на платформу в океане". Включая демо и ретро.
          Реально вопрос — что получилось бы в итоге — базы на Марсе к 2025 или полный факап?
          Вроде ж ракеты у SpaceX имеют версии — 1.0, 1.1 и т.д. Значит возможен софтовый подход?

            0

            Скорее всего mission critical software так разрабатывать не стоит. Цена ошибки в бизнесе измеряется деньгами, а если накосячить в по для самолета, могут погибнуть люди.

              +1
              Вспоминается «Бойцовский клуб» с историей героя (вроде бы основанной на реальных событиях) об автомобильной компании, которая подсчитала что ей выгоднее ежегодно выплачивать компенсации за несколько жертв ДТП, произошедших по вине неудачной тормозной системы, чем отзывать и модернизировать десятки тысяч автомобилей.
                +1

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


                Но методология к которой в итоге пришли Ай-Тишники — требования — разработка — тестирование — все-же сходна с V-моделью разработки, применяемой для ответственного ПО для авиа и автомобильной отрасли. Поэтому, по идее, количество ошибок и качество ПО можно держать под контролем и в Agile. Вопрос в основном в том, что будет с планированием и ресурсами.

                0
                Ничего не получится при таком подходе, т.к. слишком большое кол-во влияющих ЗЛ. А в статье мы видим, что все диктует PO, что и как он сказал — так и запилят…
                  +2
                  Сомневаюсь, что внедрение lean и agile связано именно с количеством стейкхолдеров.
                  Как правило, критерием становится именно цена ошибки. Самая простая ошибка — потеря $. Самые сложные — смерть людей, вред экологии, уничтожение других материальных ценностей (памятники культуры, например). Поэтому самолеты, атомные электростанции и дома не производят по agile…
                  0
                  Ну такое, всё же нужна твёрдая рука, ибо ладно программа по проектированию, но жизни людей. Это довольно ответственно.
                    0

                    Есть отличный пример компании, которая работает без менеджеров в железной отрасли: http://www.favi.com/en/about-favi/


                    Подробно она описана, как и другие такие компании, в книге Лалу «Открывая организации будущего» (Reinventing organizations)


                    Основной ответ: нет, факапа не будет. Все люди взрослые и прекрасно понимают свою ответственность. Более того, в таких командах брак намного ниже.


                    Сбер, Альфа, ВкусВилл экспериментируют с безменеджерским подходом в России и получается неплохо.

                    0

                    Круто иметь два дополнительных выходных между спринтами.

                      0

                      Два выходных между спринтами и 5 "боевых" рабочих часов в день. Т.е. где-то 46 часов в месяц из 176 каждый разработчик не разрабатывает, а занимается оргвопросами. Страшно умножать это на количество разработчиков, но по-моему секрет вашего успеха не в эффективности распределения рабочего времени.

                        0
                        Это правильно считать, что эффективное время будет 5 часов в день. 8 часов в день — это пришел и не отвлекаясь занимаешься задачей, обед и снова занимаешься задачей уже до конца рабочего дня. Ни каких телефонных разговоров или чатов. Ни каких взаимодействий между коллегами. Так редко когда получается. Или кто-нибудь позвонит, или кто-то что-то спросит. Спросить может и по рабочим вопросам, например, по ранее реализованной фичи, является ли странное поведение багом или фичей. А может кто-то из коллег попросит помощи. Так что если человек не проводит на работе 10 — 12 часов, то 8 часов тратить на задачу постоянно — не получится. В конце концов, человек может себя в какой-нибудь день плохо чувствовать и работать менее эффективно. Так что и без орг вопросов не получится тратить по 8 часов в день.

                        P.S.
                        Я к автору статьи не имею никакого отношения, исключительно мой личный опыт и опыт коллег.
                          0
                          Я согласен с вашим комментарием, но он лежит в другой плоскости.
                          Я намекал, что 1702 часа оргвопросов в месяц (размер команды х 46 — примерно как 9,5 человек фулл-тайм) это повод задуматься об эффективности данной модели. Например что-то придумать, чтобы не всю команду вовлекать в эти процессы.
                            0
                            Так два дня тратятся на демо и ретро, и если на демо еще можно не привлекать всех разработчиков, то на ретро и планирование — нужно. Такова идея скрама. Эта та цена которая платится за возможность команды оперативно реагировать на меняющиеся требования к разрабатываемому ПО и предсказуемость сроков завершения (такое мнение у меня сложилось при чтении статей и заметок посвященных скраму). Мне ближе и комфортнее когда есть спецификация, ТЗ, бюджет и сроки. И никаких ретро, демо и ежедневных собраний.
                              0
                              Грубо, эти часы компенсируются взаимозаменяемостью, лучшим переиспользованием кода и более эффективными решениями.
                            +2
                            Если между спринтами есть два дня на ретро, демо и планирование — это не значит, что в эти два дня не пишется код. Это значит, что в эти дни активности — с бОльшим приоритетом, чем написание кода. Эти два дня являются хорошим буфером для амортизации недооценок/переоценок по спринту.

                            По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа в 12 на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.

                            Поделитесь, сколько времени интегрально у Ваших программистов уходит на активности помимо разработки? На мой взгляд, 1 час в день на разговоры — очень небольшая плата за распространение знаний и рефлексию команд.
                          0
                          deleted (промахнулся веткой)
                            +1
                            Извините, что не по теме, но мне показалось, что на скриншоте модель здания Роснефти в Красноярске?
                              +2
                              Это торгово-деловой центр «Первая Башня» в г.Красноярск. Вполне возможно, что имеет отношение к Роснефти)
                              0

                              Зачем вы изобретали велосипед? Описанный подход (за исключением некоторых кривых интерпретаций) называется Скрам и с ним можно познакомиться на любом сертификационном курсе или через книги Сазерленда и Книберга. Если вы знаете про SAFe, то сами должны видеть как решать озвученные проблемы. И да прибудет с вами Lean.

                                0
                                Из-за рекламы, автор все таки немного лукавит. Кто отвечает за доставку фичи, кто решает управленческие вопросы из серии вот вэтом продукте мы приняли такой и такой принцип, подход и практику.
                                Подозревая ответ: команда.
                                А кто тогда следит за соблюдением/применением правил, принципов и подходов? И в том числе, пользуясь авторитетом, может однозначно задать какое-либо направление?
                                  +1
                                  Простите мое лукавство. Конечно, наши Product Owner'ы озабочены тем, что команды не успевают или доставляют баги в продакшн. Они даже часто говорят об этом на синхронизациях и обсуждениях темпов разработки.

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

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

                                  Самое читаемое