Хабрахабр

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

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

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

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

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

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

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

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

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.)" A ScrumBut has a particular syntax: (ScrumBut)(Reason)(Workaround).

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

Презентация

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

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

Источник

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

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»