Senior Project Manager в Dev-Pro.net
  • Как мы масштабировали команду и выжили

    На подготовку времени отдельно практически не было.

  • Как мы масштабировали команду и выжили

    Спасибо, Богдан.
    1 — около года, чуть больше
    2 — ресторанный бизнес

  • Как мы масштабировали команду и выжили

    Инна,

    Мы рассматривали ряд практик: SAFe, Nexus Framework, отчасти даже Spotify Tribe approach. Выбирали подходящее, но так и не выбрали. Поскольку мы аутсорс компания, возможности имплементации тех или иных процессов ограничены спецификой устоявшихся бизнес-процессов заказчика. Не то чтобы их нельзя изменить — скорее вопрос целесообразности и затрат на имплементацию против ожидаемого эффекта.

    Проект начинался с Kanban-based фреймворка и продолжает свою дорогу тем же путем. В процессе описанных в статье изменений, фреймворк собрал лучшие, на наш взгляд, и подходящие практики scaled подходов.

    Если кратко, то наш изначальный фреймворк набрал «„жирка“» в виде дополнительных процедур и артефактов, но ни одним из популярных scaled фреймворков не стал, на данный момент в этом нет нужды.

  • Как мы масштабировали команду и выжили

    Роман,
    Тут двумя словами не обойтись и комментарий может получиться больше самой статьи :)

    Учитывая нашу ко-локацию, Харьков, предлагаю обсудить на кофе-брейке какой-нибудь из следующих локальных конференций. На PMCon я часто Вас видел, так что, как вариант — на следующем.

    Вы не против?

  • Как мы масштабировали команду и выжили

    Андрей,
    Не могу не согласиться.

    Именно поэтому, мы стараемся выдерживать баланс seniority как 50% Intermediate, и по 25% Junior и Senior — как среди разработчиков, так и среди не-деливери специалистов.

    Практика показывает, что при такой композиции команд объем коммуникации позволяет поддерживать ее же качество на стабильном и приемлемом уровне.

    Поддержал: Kseniia Ryabova
  • Как мы масштабировали команду и выжили

    Анна,
    Вы правы касательно сути system stability testing.

    Стоит отметить, что мы сфокусировались именно на объеме assurance работ, то есть помимо testing, как финального этапа проверки уже работающей системы, мы инвестировали еще и в сам процесс обеспечения и повышения качества продукта: как с точки зрения функциональных, так и нефункциональных требований.

    В качестве примера, могу привести вектор SSA для обеспечения стабильности приложения, а именно — его бесперебойной работы в течение N бизнес-дней.
    С точки зрения «testing» — мы внедрили авто-тест, который симулировал работу продукта в максимально-приближенных к regular business operation условиях. То есть, фактически констатировал, может ли приложение покрыть то самое значение N.

    А вот с точки зрения assurance мы внедрили инструмент по обнаружению и репортингу утечек памяти в приложении, который тестирует код на наличие потенциальных и реальных утечек и предоставляет информацию для анализа, которая процессится командой реактивно, если утечки были обнаружены.

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

    Поддержал: Ann Ivanicheva