Привет, Хабр! Меня зовут Женя. Я системный аналитик компании «НОРБИТ» и начинающий Scrum-мастер. Я давно присматривалась к Scrum с целью изучить, попробовать и оценить его возможности в нашей команде аналитиков. И вот, после легкого пинка воодушевляющего разговора с РП я поняла: хватит думать, пора делать.
В этой статье я расскажу о нашем опыте подготовки к использованию ограниченного Scrum от лица Scrum-мастера: что мы сделали, чтобы запуститься. На момент написания статьи завершен 15-й спринт. Полет нормальный!
Я часто слышала о применении фреймворка Scrum в командах, участники которой — не разработчики. Команды разной экспертизы активно вливаются в Agile. Я думала о том, что изначально Scrum был создан для команд разработки полного цикла, и поэтому есть ряд сложностей или интересных моментов, на которые стоит обратить внимание, если команда отличается от эталонной, той, о которой думали создатели. Я выделяю команды по направлению экспертизы и степени участия в цикле развития продукта. Направление экспертизы, на мой взгляд, не ограничивает в использовании Scrum. А вот степень участия в развитии продукта может ограничивать. Одни могут выполнять полный цикл работ по продукту, отвечая за конечный, доступный заказчику результат — и на мой взгляд, в таких командах можно использовать полноценный Scrum. А другие — выполняют только часть полного цикла, являясь частью рабочей цепочки. В этом случае могут быть вопросы и сложности с полноценным Scrum. Такая проектная ситуация может потребовать компромиссного подхода.
В этой статье речь пойдет про команду, отвечающую за часть цикла развития продукта и подготовку к запуску в ней ScrumBut.
Наш план действий для запуска был таков:
Сначала я загуглила и получила:
Т.е. ScrumBut — это ограниченный Scrum. Эта вариация фреймворка позволяет взять из Scrum все необходимое и не брать то, что, на наш взгляд, не требуется. Безусловно, это скользкая дорожка, т.к. для понимания, что является необходимым и что не требуется, важно иметь представление о классическом Scrum, мне было важно осознать, зачем это включено в полную версию.
Полезным для меня в матчасти оказались:
Для начала я воспользовалась своим видением и вынесла несколько пунктов для оценки со стороны руководителей.
Собрала мнения участников команды и зафиксировала их.
У нас вышло два списка: что имеем на входе и что хотим получить.
Сюда вынесу консолидированные и обобщенные списки.
На этапе моделирования мы распределили командные роли: определили владельцев продукта, участников команд и меня как скрам-мастера, длительность спринта, процесс наполнения и приоритизации беклога.
Были определены обязательные атрибуты задач, ворк-флоу для трекинга, средство для трекинга, присвоение оценки в человекочасах для каждого типа задачи и общее количество часов в неделю на каждого аналитика с учетом выполнения командного плана на спринт, время и регулярность daily-митингов и ретроспектив.
Владельцем продукта и человеком, задающим беклог, стал руководитель группы аналитиков. Команды было решено сделать по 2-7 человек, удовлетворяя требованию количества 7±2. Это были две команды, условно поделенные по функциональному признаку решаемых задач, что было ближе изначальной модели, но дальше от намеченной цели – кросс-функциональности.
Для трекинга мы решили использовать имеющийся TFS, в котором удобно выводить задачи по статусам «Новое», «В работе», «Завершено» на доску и есть возможность собирать небольшую статистику по результатам для обсуждения на встрече-ретроспективе в конце спринта. Доска TFS имитирует физическую Scrum-доску, но физическая у нас тоже была.
Этап планирования завершился демонстрацией команде презентации по результатам моделирования «Начинаем работать по-новому вместе», обсуждения и коррекцией того, что не нашло отклика у ребят.
Scrum и ScrumBut в частности — это командная работа, согласованность, прозрачность и общее принятие. Это был важный момент, с которого мы вдохновенно стартовали.
Источник
Когда работаешь на большом проекте, нет возможности идти в омут с головой, поэтому без планирования не обойтись. Важно понимать, как это будет и какие результаты это принесет, но мы встретились с необходимостью быть готовым к тому, что план в каких-то аспектах так и останется планом. При планировании мы рисовали крупными мазками, а уже на этапе реализации мы смогли добавить детали, которые привнесла команда и проектная ситуация.
Наша команда отвечает только за часть цикла разработки ПО, поэтому были трудности с тем, что назвать продуктом и что получать как прирост. Мы знали, что он должен быть целостным и завершенным. Мы договорились, что мы со стороны команды аналитиков готовим несколько видов документов для взаимодействия с заказчиком и создаем задачи разработчикам для их бэклога. Таким образом, задачи попадают в спринты к разработчикам. На мой взгляд, такой компромиссный путь может подойти как для проектов, в которых отдельные команды аналитиков, разработчиков, тестировщиков, поддержки, так и для проектов, где количество людей требует разделения на несколько команд. В таком решении есть и минус — участники нашей команды не могут влиять на сроки готовности прироста функциональности продукта, мы можем влиять только на выполнение своей части работы. Есть и плюсы — преемственность задач аналитиков для разработчиков. Это решение позволило избежать попыток стать одной кроссфункциональной командой (аналитики = разработчики = тестировщики и т.д), что в нашем случае на данном этапе было бы невозможным, сохранив при этом цикл развития продукта с компромиссным преломлением на стыке взаимодействия команд.
На этапе презентации наши ребята из «НОРБИТ» отреагировали достаточно вовлеченно и с интересом. Но предполагаю, что положительный эмоциональный отклик команды — это заслуга проработки целей и их связанности с актуальными и очевидными проблемами.
Описанные выше шаги (изучение теории, моделирование и презентация), сделали свое дело: мы успешно запустились.
Но запуститься — это только первый шаг. О том, что было после запуска и каких удалось добиться результатов, я расскажу в своей следующей статье.
В этой статье я расскажу о нашем опыте подготовки к использованию ограниченного 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-команд» (Лисса Адкинс);
- ряд длительных и интересных консультаций с действующим сертифицированным скрам-мастером, практикующим классику.
Как я оценивала текущую ситуацию
Для начала я воспользовалась своим видением и вынесла несколько пунктов для оценки со стороны руководителей.
Собрала мнения участников команды и зафиксировала их.
У нас вышло два списка: что имеем на входе и что хотим получить.
Сюда вынесу консолидированные и обобщенные списки.
Что имели на входе
- Крупный проект по развитию интерпрайз-системы.
- Отдельные команды разработчиков, поддержки и аналитиков.
- Крутая команда аналитиков (около 14 чел.).
- Возможность действовать только в рамках команды аналитиков.
- Релизный выход версий системы.
- Водопадная модель управления жизненным циклом ПО.
- Невозможность жесткого планирования, так как задачи от заказчика приходят в любое время.
- Неравномерность загруженности аналитиков.
- Функциональная распределенность зон экспертизы аналитиков.
Что хотим получить
- Уметь быстро реагировать на изменения бизнеса.
- Учитывать и назначать приоритетность задач в работу
- Иметь выполнимые прогнозы прироста продукта.
- Короткие спринты могут позволить отслеживать, фиксировать и выполнять задачи и точнее прогнозировать попадание задач в релиз.
- Создавать беклог задач аналитикам.
- В любой момент времени аналитик знает, чем ему заняться.
- Обмениваться опытом в решении сложных задач.
- Наладить командную работу таким образом, чтобы делиться знаниями было приятно, комфортно и взаимополезно.
- Организовать свой Scrum c Блек Джеком и т.д. :)
- Попробовать новое, повысить командный дух. Ребята классные. Почему бы и нет?
Моделирование
На этапе моделирования мы распределили командные роли: определили владельцев продукта, участников команд и меня как скрам-мастера, длительность спринта, процесс наполнения и приоритизации беклога.
Были определены обязательные атрибуты задач, ворк-флоу для трекинга, средство для трекинга, присвоение оценки в человекочасах для каждого типа задачи и общее количество часов в неделю на каждого аналитика с учетом выполнения командного плана на спринт, время и регулярность daily-митингов и ретроспектив.
Владельцем продукта и человеком, задающим беклог, стал руководитель группы аналитиков. Команды было решено сделать по 2-7 человек, удовлетворяя требованию количества 7±2. Это были две команды, условно поделенные по функциональному признаку решаемых задач, что было ближе изначальной модели, но дальше от намеченной цели – кросс-функциональности.
Для трекинга мы решили использовать имеющийся TFS, в котором удобно выводить задачи по статусам «Новое», «В работе», «Завершено» на доску и есть возможность собирать небольшую статистику по результатам для обсуждения на встрече-ретроспективе в конце спринта. Доска TFS имитирует физическую Scrum-доску, но физическая у нас тоже была.
Презентация
Этап планирования завершился демонстрацией команде презентации по результатам моделирования «Начинаем работать по-новому вместе», обсуждения и коррекцией того, что не нашло отклика у ребят.
Scrum и ScrumBut в частности — это командная работа, согласованность, прозрачность и общее принятие. Это был важный момент, с которого мы вдохновенно стартовали.
Выводы по результатам подготовки к запуску
Когда работаешь на большом проекте, нет возможности идти в омут с головой, поэтому без планирования не обойтись. Важно понимать, как это будет и какие результаты это принесет, но мы встретились с необходимостью быть готовым к тому, что план в каких-то аспектах так и останется планом. При планировании мы рисовали крупными мазками, а уже на этапе реализации мы смогли добавить детали, которые привнесла команда и проектная ситуация.
Наша команда отвечает только за часть цикла разработки ПО, поэтому были трудности с тем, что назвать продуктом и что получать как прирост. Мы знали, что он должен быть целостным и завершенным. Мы договорились, что мы со стороны команды аналитиков готовим несколько видов документов для взаимодействия с заказчиком и создаем задачи разработчикам для их бэклога. Таким образом, задачи попадают в спринты к разработчикам. На мой взгляд, такой компромиссный путь может подойти как для проектов, в которых отдельные команды аналитиков, разработчиков, тестировщиков, поддержки, так и для проектов, где количество людей требует разделения на несколько команд. В таком решении есть и минус — участники нашей команды не могут влиять на сроки готовности прироста функциональности продукта, мы можем влиять только на выполнение своей части работы. Есть и плюсы — преемственность задач аналитиков для разработчиков. Это решение позволило избежать попыток стать одной кроссфункциональной командой (аналитики = разработчики = тестировщики и т.д), что в нашем случае на данном этапе было бы невозможным, сохранив при этом цикл развития продукта с компромиссным преломлением на стыке взаимодействия команд.
На этапе презентации наши ребята из «НОРБИТ» отреагировали достаточно вовлеченно и с интересом. Но предполагаю, что положительный эмоциональный отклик команды — это заслуга проработки целей и их связанности с актуальными и очевидными проблемами.
Описанные выше шаги (изучение теории, моделирование и презентация), сделали свое дело: мы успешно запустились.
Но запуститься — это только первый шаг. О том, что было после запуска и каких удалось добиться результатов, я расскажу в своей следующей статье.
