ScrumBut в команде аналитиков: перед взлётом

    Привет, Хабр! Меня зовут Женя. Я системный аналитик компании «НОРБИТ» и начинающий Scrum-мастер. Я давно присматривалась к Scrum с целью изучить, попробовать и оценить его возможности в нашей команде аналитиков. И вот, после легкого пинка воодушевляющего разговора с РП я поняла: хватит думать, пора делать.

    В этой статье я расскажу о нашем опыте подготовки к использованию ограниченного Scrum от лица Scrum-мастера: что мы сделали, чтобы запуститься. На момент написания статьи завершен 15-й спринт. Полет нормальный!


    Я часто слышала о применении фреймворка Scrum в командах, участники которой — не разработчики. Команды разной экспертизы активно вливаются в Agile. Я думала о том, что изначально Scrum был создан для команд разработки полного цикла, и поэтому есть ряд сложностей или интересных моментов, на которые стоит обратить внимание, если команда отличается от эталонной, той, о которой думали создатели. Я выделяю команды по направлению экспертизы и степени участия в цикле развития продукта. Направление экспертизы, на мой взгляд, не ограничивает в использовании Scrum. А вот степень участия в развитии продукта может ограничивать. Одни могут выполнять полный цикл работ по продукту, отвечая за конечный, доступный заказчику результат — и на мой взгляд, в таких командах можно использовать полноценный Scrum. А другие — выполняют только часть полного цикла, являясь частью рабочей цепочки. В этом случае могут быть вопросы и сложности с полноценным Scrum. Такая проектная ситуация может потребовать компромиссного подхода.
    В этой статье речь пойдет про команду, отвечающую за часть цикла развития продукта и подготовку к запуску в ней ScrumBut.

    Наш план действий для запуска был таков:

    • изучить и оценить текущую ситуацию и желаемую,
    • построить модель as is и to be в терминологии ScrumBut,
    • презентовать и воодушевить команду

    Как я изучала, что такое ScrumBut


    Сначала я загуглила и получила:

    A ScrumBut has a particular syntax: (ScrumBut)(Reason)(Workaround). ScrumBut Examples: "(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have one per week.)" "(We use Scrum, but) (Retrospectives are a waste of time,) (so we don't do them.)"

    Т.е. ScrumBut — это ограниченный Scrum. Эта вариация фреймворка позволяет взять из Scrum все необходимое и не брать то, что, на наш взгляд, не требуется. Безусловно, это скользкая дорожка, т.к. для понимания, что является необходимым и что не требуется, важно иметь представление о классическом Scrum, мне было важно осознать, зачем это включено в полную версию.

    Полезным для меня в матчасти оказались:

    • изучение литературы: Agile-манифеста разработки программного обеспечения, «SCRUM революционный метод управления проектами» (Джозеф Сазерленд), «Коучинг Agile-команд» (Лисса Адкинс);
    • ряд длительных и интересных консультаций с действующим сертифицированным скрам-мастером, практикующим классику.

    Как я оценивала текущую ситуацию


    Для начала я воспользовалась своим видением и вынесла несколько пунктов для оценки со стороны руководителей.

    Собрала мнения участников команды и зафиксировала их.

    У нас вышло два списка: что имеем на входе и что хотим получить.

    Сюда вынесу консолидированные и обобщенные списки.

    Что имели на входе

    1. Крупный проект по развитию интерпрайз-системы.
    2. Отдельные команды разработчиков, поддержки и аналитиков.
    3. Крутая команда аналитиков (около 14 чел.).
    4. Возможность действовать только в рамках команды аналитиков.
    5. Релизный выход версий системы.
    6. Водопадная модель управления жизненным циклом ПО.
    7. Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
    8. Неравномерность загруженности аналитиков.
    9. Функциональная распределенность зон экспертизы аналитиков.

    Что хотим получить

    1. Уметь быстро реагировать на изменения бизнеса.
    2. Учитывать и назначать приоритетность задач в работу
    3. Иметь выполнимые прогнозы прироста продукта.
    4. Короткие спринты могут позволить отслеживать, фиксировать и выполнять задачи и точнее прогнозировать попадание задач в релиз.
    5. Создавать беклог задач аналитикам.
    6. В любой момент времени аналитик знает, чем ему заняться.
    7. Обмениваться опытом в решении сложных задач.
    8. Наладить командную работу таким образом, чтобы делиться знаниями было приятно, комфортно и взаимополезно.
    9. Организовать свой Scrum c Блек Джеком и т.д. :)
    10. Попробовать новое, повысить командный дух. Ребята классные. Почему бы и нет?

    Моделирование


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

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

    Владельцем продукта и человеком, задающим беклог, стал руководитель группы аналитиков. Команды было решено сделать по 2-7 человек, удовлетворяя требованию количества 7±2. Это были две команды, условно поделенные по функциональному признаку решаемых задач, что было ближе изначальной модели, но дальше от намеченной цели – кросс-функциональности.

    Для трекинга мы решили использовать имеющийся TFS, в котором удобно выводить задачи по статусам «Новое», «В работе», «Завершено» на доску и есть возможность собирать небольшую статистику по результатам для обсуждения на встрече-ретроспективе в конце спринта. Доска TFS имитирует физическую Scrum-доску, но физическая у нас тоже была.

    Презентация


    Этап планирования завершился демонстрацией команде презентации по результатам моделирования «Начинаем работать по-новому вместе», обсуждения и коррекцией того, что не нашло отклика у ребят.

    Scrum и ScrumBut в частности — это командная работа, согласованность, прозрачность и общее принятие. Это был важный момент, с которого мы вдохновенно стартовали.

    Источник

    Выводы по результатам подготовки к запуску


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

    Наша команда отвечает только за часть цикла разработки ПО, поэтому были трудности с тем, что назвать продуктом и что получать как прирост. Мы знали, что он должен быть целостным и завершенным. Мы договорились, что мы со стороны команды аналитиков готовим несколько видов документов для взаимодействия с заказчиком и создаем задачи разработчикам для их бэклога. Таким образом, задачи попадают в спринты к разработчикам. На мой взгляд, такой компромиссный путь может подойти как для проектов, в которых отдельные команды аналитиков, разработчиков, тестировщиков, поддержки, так и для проектов, где количество людей требует разделения на несколько команд. В таком решении есть и минус — участники нашей команды не могут влиять на сроки готовности прироста функциональности продукта, мы можем влиять только на выполнение своей части работы. Есть и плюсы — преемственность задач аналитиков для разработчиков. Это решение позволило избежать попыток стать одной кроссфункциональной командой (аналитики = разработчики = тестировщики и т.д), что в нашем случае на данном этапе было бы невозможным, сохранив при этом цикл развития продукта с компромиссным преломлением на стыке взаимодействия команд.

    На этапе презентации наши ребята из «НОРБИТ» отреагировали достаточно вовлеченно и с интересом. Но предполагаю, что положительный эмоциональный отклик команды — это заслуга проработки целей и их связанности с актуальными и очевидными проблемами.

    Описанные выше шаги (изучение теории, моделирование и презентация), сделали свое дело: мы успешно запустились.

    Но запуститься — это только первый шаг. О том, что было после запуска и каких удалось добиться результатов, я расскажу в своей следующей статье.
    • +47
    • 3,3k
    • 7
    ГК ЛАНИТ
    498,00
    Ведущая многопрофильная группа ИТ-компаний в РФ
    Поделиться публикацией

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

      +2
      >Релизный выход версий системы.
      Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.

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

      > Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
      Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.

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

      >Функциональная распределенность зон экспертизы аналитиков.
      Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)

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

      >Учитывать и назначать приоритетность задач в работу
      Работа лида команды и менеджера

      >Короткие спринты могут позволить отслеживать, фиксировать и выполнять задачи и точнее прогнозировать попадание задач в релиз.
      Почему ваше руководство не может договориться с заказчиком что и когда релизят: фиксированные сроки — плавающий scope или наоборот, плавающие сроки, фиксированный scope, при чем каждый релиз может релизиться по своей схеме.

      >Создавать беклог задач аналитикам.
      А что backlog без скрама уже отменили?

      >Попробовать новое, повысить командный дух.
      Это явно не скрам, есть более интересные способы :)

      А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
      Такое чувство что вы пытаетесь «натянуть» сову на глобус.

      Если ситуация выше истинная, то надо сменить руководителя над аналитиками или вообще руководителя департамента. Классическая попытка слабого и неопытного руководства прикрытся процессом.
        –1

        Она же все расписала в заголовке. Просто опечаталась. Получился типичный scrumbutt

        +2
        >>Релизный выход версий системы.
        >Чем отсуствие scrum'а мешает настроить релиз процесс именно под ваши условия? Найдите тех, кто готов взять на себя работу релиз инженера.
        В данном случае это константа, от которой мы отталкиваемся, как и большинство пунктов из списка «что на входе».

        >>Водопадная модель управления жизненным циклом ПО.
        >Даже в водопаде была итеративность, водопад это была первая попытка формализаци процесса разработки, в котором просто были выделены этапы разработки, на сегоднячний день кардинально ничего не поменялось, только циклы стали быстрее и многое автоматизировано.
        Интересно. В нашем случае, итеративность тоже была на стыке команд. Но с помощью ScrumBut мы формализуем внутреннюю работу команды, создав итеративность внутри команды и сохранив при этом межкомандное взаимодействие по передаче отработанных рабочих элементов.
        >> Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
        >Это задача PM, Product Owner или любого другого, который умеет общаться с заказчиком на его языке, а главное у заказчика есть доверие к нему.
        А зачем нам влиять на заказчика? Мы с радостью готовы делать все задачи в любое время, надо только организовать процесс внутри. Чем скорее начнем, тем скорее закончим и наш продукт будет прокачан. Все счастливы.

        >>Вход>Неравномерность загруженности аналитиков.
        получить>В любой момент времени аналитик знает, чем ему заняться.
        >>Учитывать и назначать приоритетность задач в работу
        >Проблема руководителя аналитиков, скрам не поможет.
        >Работа лида команды и менеджера
        Руководитель тут не при чем. Scrum как раз ее и отвечает на этот вопрос. Есть такой принцип, что команда сама решает, чем заняться каждому в каждый момент времени из бэклога, который готовит и приоритезирует product owner. Как раз метод кнута или еще какие-то методы силового воздействия тут совсем вне концепции. Благодаря прозрачности процесса в целом и каждого участника между собой, каждый активно стремиться включаться в рабочий процесс. Нагрузка фактически закладывается путем подготовки и приоритизации бэклога.

        >>Функциональная распределенность зон экспертизы аналитиков.
        >Тут вообще непонятно то ли это плохо то ли хорошо. Экспертиза нужна с каким-то разумным перекрытием (bus factor)
        Я бы не стала говорить в градациях хорошо/плохо. Это не всегда удобно. Так как создает неравномерность нагрузки в том числе. Бывают проектные ситуации, когда по одному направлению сразу много задач, а по другим мало или нет совсем. В таком случае, одни могут зашиваться, а других будет тяжело подключать, т.к. пользы от них немного. Кроме того, взаимное обогащение экспертизой в последствии полезно для командной работы — всяких brain storm'ов, например, в рамках какой-нибудь большой интересной амбициозной задачки.

        >>Возможность действовать только в рамках команды аналитиков.
        >Почему аналитик не может дойти до тестировщика, разработчика, бизнеса, почему есть эти ограничения?
        Аналитик может и с радостью это делает. Я тут про реорганзиацию процесса работы над задачами — реорганизовывать мы могли только свой участок работы.

        >А где тут про скрам собственно? Где факты того, что текущая модель плоха или не оптимальна, где аргументы что надо менять процесс, а не людей, например?
        я скрам-мастер :) у меня есть команда и я не меняю людей :)
        Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.
          +1
          Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.

          Большего заблуждения о Скраме сложно и придумать.

          Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большенству старых методологий или самоклёпок.

          Увеличение продуктивности достигается за счет насыщения команды информацией. То есть, улучшается коммуникация которая приводит к:
          • Уменьшению потерь на переделки, благодаря частым сессиям по выявлению ожиданий (Планинги, Демо);
          • Уменьшение потерь на стыковку и синхронизацию команды за счет регулярного выявления зависимостей и планированию на местах (Дейлики, Планинги);
          • Сокращение ошибок, и увеличение производительности труда за счет регулярной рефлексии и анализа проделанной работы (Ретроспектива, Демо)


          В принципе, это всё про скрам. И этого достаточно что бы он работал и делал свою работу прекрасно. Главная беда это тренеры которые интерпретируют скрам не так, и применяют его не туда.
            0
            >Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большинству старых методологий или самоклёпок.
            Согласна и еще расскажу об этом на нашем примере.
            Здесь речь об этом и идет:
            >быть действительно командой и выдавать результат.
            и выше указала про управление загруженностью и подготовку и приоретизацию бэклога.
              –1

              Вы и вправду верите, что скрап может увеличить производительность в 3-8 раз? Мне искренне жаль людей, которые работают под таким руководством.
              С заказчиком надо взаимодействовать. Заказчик и исполнитель это одна команда, идущая к одной цели, а не так, что заказчик там что-то сказал и вы бросились делать. Ему плевать что у вас там, скрам, срам или трам. Ему надо чтобы его задачи были решены вчера и полностью.
              Задача руководителя выбрать те задачи, которые наиболее дёшевы в реализации и приносят максимальный эффект для бизнеса.

            0
            Я рассказываю о внутренней командной работе аналитиков и применении в ней фреймворка. О нашем опыте запуска.
            Совершенно не о взаимодействии заказчика и исполнителя.

            >Вы и вправду верите, что скрап может увеличить производительность в 3-8 раз?
            Тут не в вере дело, а планировании. Было бы странно запускать что-либо не просчитав план реализации и последствий.

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

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