scrum доска что это
Доска с задачами: онлайн и офлайн. Способ, который пригодится всем
Что такое SCRUM?
Метод SCRUM пришел в офисный и школьный мир из спорта. Так называется прием в регби, означающий борьбу между командами: игроки сбиваются в несколько рядов, обхватив друг друга руками. Scrum в переводе с английского означает «схватка». Но если в регби этот прием травмоопасен и со стороны смотрится очень агрессивно и хаотично, то в работе и учебе он, наоборот, призван расчистить рабочее пространство и голову от суеты, а еще — выстроить структуру работы и стать надежным и прозрачным инструментом для повседневных дел.
Суть метода SCRUM — в создании доски задач. Шапка таблицы делится на 5 ячеек:
Замыслы / Планы на неделю / В работе / Проверка / Выполнено
Идеи, замыслы
Этот столбик могут пополнять все: и дети, и педагог. Его можно не делить на строчки, так как в него попадают задачи, которые пока не в плане, а в статусе пассивного ожидания. Наклеивайте сюда все, что было бы интересно выполнить: уборка пришкольной территории в начале мая, экологическая инициатива класса, командная игра по субботам, новый формат проведения урока.
Так вы, во-первых, не забудете интересный замысел, а во-вторых, о нем узнают и другие участники, что может способствовать рождению новой идеи по реализации задумки у членов команд.
Планы, дела на неделю
В работе
Проверка
Выполнено
Чем удобен Trello?
Онлайн-сервисов для управления проектами существует немало. Чаще всего, правда, их используют не школьники, а разработчики в сфере ИТ. Пожалуй, самый известный из них в среде, далекой от программирования, — Trello. Его может использовать учитель для планирования своих задач на день, неделю, месяц. Или им может пользоваться весь класс. Каждому участнику необходим аккаунт, который привязан к адресу электронной почты.
Для онлайн-взаимодействия, особенно на дистанционном обучении, этот инструмент очень удобен. Можно создать несколько досок по предметам, и тогда планировать занятия будет еще удобнее!
Сервис Trello очень простой. В интернете много инструкций, которые объясняют, как работать на начальном этапе и рассказывают о каких-то интересных фишках, которые пригодятся продвинутым пользователям.
Если полностью копировать тот формат, который мы предложили для обычной доски, то на доске в Trello существенно ничего не изменится. Создаете непосредственно доску, а в ней — 5 колонок с теми заголовками, которые мы уже приводили. Готово! Теперь в каждую колонку нужно добавить карточку — аналог обычного стикера.
Добавляйте развернутые описания, картинки, прикрепляйте ссылки и документы. И, если на обычной доске со стикерами вы только увидите статус задачи, то в Trello сможете проверить выполненное задание на месте — перейдя по ссылке или открыв приложенный файл.
Оставляйте комментарии! Дети могут задавать вопросы, а учитель — объяснять, почему, например, не перенес карточку в колонку «Выполнено».
У Trello, помимо очевидных функций, красивый и понятный интерфейс. Вы можете изменить фоновую картинку, определить цвета для разных меток, добавить в карточки участников и присоединиться самостоятельно к карточкам других, чтобы следить за статусом выполнения.
Совет: когда вы перенесете выполненную задачу в колонку «Готово», храните там карточку еще хотя бы неделю, прежде чем отправить ее в архив. А еще лучше — создайте шестой столбик под названием «Архив выполненных задач» (имя колонки не так уж и важно, главное — суть). «Сбрасывайте» сюда все, что было выполнено на прошлой неделе, чтобы очистить место для текущих дел. Так вы сможете вернуться к старым задачам, еще раз посмотреть прикрепленные документы или картинки, узнать точную дату, исполнителей и другие важные моменты. Храните архивы, если это важно, за месяц и даже за год. Или перенесите их на другую доску, чтобы не создавать хаос на рабочей.
Бесплатного доступа для выполнения задач на школьном уровне будет вполне достаточно. Даже многие небольшие стартапы и компании используют сервис бесплатно, не задействуя «золотой» уровень.
Недавно у Trello появились шаблоны. Можете использовать их, если умеете переводить с английского. А учителю английского языка, возможно, даже больше понравится формат ведения доски не на русском.
Если нашей статьи недостаточно, почитайте инструкцию, чтобы понять, как работать в сервисе Trello.
Почему SCRUM — это удобно?
Методом уже пользуются многие школьные учителя и педагоги вузов. Можно сразу видеть и контролировать выполнение задач, ученикам проще ориентироваться в собственной деятельности.
Большущий плюс еще и в том, что дети учатся брать на себя ответственность. Они и сами не заметят, насколько интересным станет для них процесс генерации новых задач, выполнения запланированных и переноса готовых в другую колонку.
Разбираемся в Scrum и Kanban
Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, о которых я писал в предыдущей статье.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Обе технологии близки, потому их инструменты можно комбинировать.
Команды в Kanban и Scrum
Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Поскольку команда автономная и самоорганизующаяся, за успех или неудачу она отвечает как единое целое. Провал не свалить на ленивого разработчика или невнимательного тестировщика.
Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.
А вот дальше в Kanban и Scrum начинаются различия.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
Как составляют список задач
Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.
Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».
Каждая задача имеет вес — обычно это время, которое нужно на решение. Команда сама оценивает вес всех задач, поэтому если проект не закончен в срок, виновата команда.
Также у каждой задачи есть приоритет. В Kanban приоритеты расставляет команда, в Scrum — владелец продукта. Приоритеты можно и даже нужно пересматривать по ходу проекта — это один из столпов гибких методологий.
Как работают над проектом
Когда начинается работа, Scrum становится понятно, почему его называют намного более директивной методологией.
Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.
Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.
Спринт состоит из четырех последовательных этапов.
В Scrum категорически нельзя добавлять задачи в текущий спринт, поэтому Scrum менее гибок. Даже если появилась срочная и важная задача, она пойдет в работу только со следующего спринта.
В конце спринта недоделанные задачи уходят обратно в бэклог. Нужно ли их доделывать и когда, определяют на этапе планирования следующего спринта.
По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.
Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.
Вспомним этапы scrum-спринта:
В Kanban один этапы не завязаны на другие. Наступают они, когда решит команда. К примеру, релиз — по вторникам, планирование — когда закончились задачи, ретроспективы — каждый последний четверг месяца, а на фоне всего этого непрерывно идет разработка.
Поскольку выраженных спринтов нет, появляются особенности:
Что за доски используют Scrum и Kanban
Доска — это сердце kanban- и scrum-разработки, единственный визуальный атрибут методологий. Доски первым делом вешают на стену, когда хотят показать, что работают по Kanban или Scrum.
Доску используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.
Доску расчерчивают на столбцы. Каждый столбец — это состояние задачи («Разработка», «Тестирование», «Релиз»). Количество столбцов зависит от проекта, но чем их меньше, тем лучше.
Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.
Доски бывают физические и электронные.
Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.
Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.
Электронная доска. Электронная доска под рукой на пляже, на даче, в машине и в метро. Если у вас есть сотрудники, которые работают удаленно, электронная доска — единственный выход.
Я люблю настоящие доски, но без электронных иногда не обойтись.
Что такое SCRUM-доска и как она учит ребёнка управлять своими делами
Чтобы научить своего 12-летнего сына Никиту навыкам самоорганизации, мы стали использовать дома своеобразную версию методологии управления проектами SCRUM. Спустя полгода могу с уверенностью сказать, что это работает. Рассказываю о самой системе и её базовых принципах.
Сразу оговорюсь, я не фанат тайм-менеджмента и планирования, в моей жизни инструменты управления делами появились в глубоко взрослом возрасте как вынужденное зло. Можете представить себе, каким стрессом для меня было попасть в ситуацию, когда несколько лет назад мне стало нужно не только свои дела организовывать, но и координировать работу целой команды «Банды умников»?
Я искренне восхищаюсь своими коллегами, которые легко и эффективно планируют своё время, концентрируются на важных вещах, ведут карточки в Trello, записывают дела и задачи не на случайных бумажках, а в специальном блокноте, и он не теряется у них через неделю.
Так вот, ближе к «детскому» вопросу: в работе «Банды» уже полтора года мы используем методологию (идеологию, фреймворк… да неважно!) SCRUM. Вот так в самом начале внедрения выглядели наши SCRUM-доски (сейчас они переехали в электронный вид).
Сказать, что навыки самоорганизации стали камнем преткновения для Никиты и наших отношений с ним — ничего не сказать. Он не только гениально ленив, инертен, «забывчив», изобретателен в отговорках, склонен к прокрастинации, но ещё и абсолютно устойчив к уговорам, подкупу, шантажу, санкциям, социальному давлению, похвалам и всем остальным попыткам заставить его делать что-то, чего ему прямо сейчас почему-то не хочется. Я бы давно отчаялся, если бы не рассказы мамы о моём поведении в детстве, из которых становится понятно, от кого Никите достались эти таланты.
В общем, внедрение Baby-SCRUM было для нас, мягко говоря, серьёзным вызовом, и по итогам полугода можно точно сказать, что это работает. Расскажу вкратце о самой системе и её базовых принципах.
Стикеры с задачами
Начну с этой простой вещи, которая кажется избитой и очевидной, но на самом деле замечательно отражает саму суть Agile-подхода к управлению делами.
Так вот, стикеры с задачами — просто гениальная вещь при умелом использовании. Перечень или список задач — жёсткая, непластичная вещь. Написав перечень задач в блокноте или на доске, уже сложно поменять задачи местами, дописать что-то, разбить какую-то из задач на части, убрать потерявшие актуальность.
Но стоит переписать задачи на клейкие стикеры — и всё приходит в движение! Например, их можно сначала наделать сколько угодно, а потом подумать, в каком порядке их выполнять — и без проблем переклеить. Или часть отложить на будущее. Или переклеить в перечень дел другому человеку. Красота!
Стикеры можно использовать не только на доске, но и в папке или даже в блокноте.
SCRUM-доска
Это командная рубка всей системы, тут наглядно видны все текущие задачи и задачи на ближайшее будущее. В нашем случае доска на холодильнике — это стратегический узел домашней логистики на входе в кухню: хочешь не хочешь, а сталкиваешься с ней десятки раз в день.
SCRUM-доска состоит из колонок, стикеры с задачами продвигаются по ним по мере приближения к состоянию «сделано». Прелесть этих простых действий с переклеиванием стикеров туда-сюда заключается в том, что в повседневных заботах можно оставить в поле зрения только те дела, на которых нужно сфокусироваться, не забивая голову тем, что ещё только предстоит или тем, что уже сделано.
Вот как устроены колонки:
«Бэклог»
Сюда попадают задачи с пока неопределённым сроком выполнения, вроде «надо не забыть когда-то потом при случае сделать». В общем, они на виду, и когда придёт их черёд — про них не забудут.
Например, пришла вам идея, что неплохо бы как-нибудь в выходные сходить в зоопарк. Но, как всегда, когда эти самые выходные наступят, это как-то забудется, и пройдут выходные буднично и бездарно… А вечером воскресенья — бац! Точно, в зоопарк же хотели! Вот если в бэклог писать все идеи на выходные, то прямо вечером пятницы будет просто спланировать выходные.
Это уже не просто идеи, а конкретные задачи, которые нужно сделать на этой неделе. Они туда попадают и из бэклога, и напрямую (например, в школе что-то задали). Часть стикеров тут появляется вечером воскресенья, а часть добавляются в течение недели.
«Делать»
Это задачи на день. Часть задач здесь оказывается вечером накануне, из колонки «надо» или напрямую. Собственно, вечер — это единственное время, когда я вижу Никиту в будни, утром он уезжает в школу намного раньше меня. А часть оперативных задач сюда поступает от Юли (моей жены), это хозяйственные дела по дому, помощь с Алисой (нашей младшей) и всё в этом духе.
«Проверка»
Промежуточная колонка, куда Никита перемещает сделанные (по его мнению) дела. Оттуда они попадают (или не попадают) в «Готово» или в течение дня, после проверки мной или Юлей, или только вечером, когда мы с ним делаем обзор дня.
«Готово»
Сюда задачи попадают из «Проверки», но не всегда. Дело в том, что наше с Никитой мнение относительно «сделанности» дел иногда очень сильно расходится. Например, он считает, что прибрался на кухне, а я вижу оставшуюся на плите грязную сковороду и крошки на столе, и стикер возвращается в «Делать».
Лайфхак: вместо стикеров для стандартных повторяющихся задач (вынести мусор, купить воду и прочее) удобно использовать магнитные стикеры.
SCRUM-доска настолько классный и удобный инструмент, что постепенно там появились и мои собственные хозяйственные дела, а потом появился и отдельный цвет стикеров для Юли.
Ежедневное и еженедельное планирование
Как известно, в квартире вещи могут быть всегда на местах, только если этот порядок постоянно поддерживается — все кладут вещи на место, а не оставляют, где придётся. Точно так же и в организации дел: SCRUM-доска не только должна быть на виду, с ней нужно работать с установленной регулярностью и по чётким правилам. Иначе рано или поздно какие-то задачи окажутся не записанными, какие-то стикеры — не переклеенными, а контроль над состоянием дел утрачен. В общем, её постигнет судьба моих многочисленных блокнотов и ежедневников.
У нас две обязательные процедуры: ежедневный обзор дел и еженедельный обзор.
Ежедневный обзор
Каждый вечер мы с Никитой и Юлей смотрим на доску и оцениваем, что из сегодняшних дел сделано, а что нет. Естественно, Никита очень гордится, если продуктивно провёл день, ну а я, как любой родитель, горжусь не меньше. Если что-то не сделано — обсуждаем причины или возникшие сложности.
Сначала мы смотрим колонку «Проверка». Например, Никита должен был сделать задания в тетради по английскому — тут же её смотрим, даём обратную связь, стикер двигается либо в «Готово», либо, если задания нужно ещё доработать — возвращаем в «Делать».
Потом смотрим колонку «Делать» — что не сделано, что помешало, как это сделать завтра.
Потом колонку «Надо» — дела, которые стоит взять в работу на завтра. Кроме этого, конечно же, можно посмотреть в расписание уроков, график занятий, в календарь, чтобы понять, какие ещё дела на завтра ещё актуальны. Например, если вечером пойдём в гости, то после школы нужно сбегать в магазин за тортом.
Получилось аж несколько абзацев, но на практике такой вечерний обзор занимает пять-десять минут, потому что в обычный будний день обсуждения заслуживает одно-два дела.
Еженедельный обзор
Тоже довольно быстрое дело, минут на 10—15:
• Делаем обзор колонки «Готово». Резюмируем успехи и выводы, после этого освобождаем её от всех стикеров (теоретически можно сохранить для истории и статистики, но мы просто выбрасываем).
• Наполняем колонку «Надо» новыми задачами. Задачи сюда вносятся из «Бэклога», календарей, расписания и просто из головы.
Хотя, как я уже написал, очень важна обязательность и регулярность. У нас, к сожалению, пропускается как минимум 20—30% вечерних обзоров — или я поздно прихожу с работы, или дома обстоятельства совсем не позволяют найти удачный момент. В субботу вечерний обзор не особо нужен, в воскресенье делаем обзор недели и планирование следующей (иногда это сползает на вечер понедельника).
Действия с колонками по времени:
Ещё в процессе обзора и планирования стараюсь больше задавать вопросы, чем указывать, что делать — мы ведь хотим научить Никиту самого контролировать свои дела, распределять приоритеты, выстраивать график.
Обязательные правила
Есть несколько обязательных правил, о которых мы поэтапно договорились с Никитой, чтобы всё это работало. Их немного, часть из них, как мне кажется, универсальны, а часть нужны именно исходя из нашей жизненной ситуации, уклада.
1. Любая задача сразу фиксируется на стикере
Вы сами, наверное, знаете, сколько раз ребёнку нужно сказать «убери вещи в шкаф», чтобы вещи в конце концов там оказались. Одна из целей обучения управлению делами — чтобы человек был сам в состоянии удерживать свои задачи под контролем.
В практическом плане это правило введено для того, чтобы дела Никиты не нужно было отслеживать и напоминать. Иначе зачастую проще сделать что-то самому, чем пять раз напоминать (ведь у ребёнка всегда найдётся какое-то текущее дело поинтереснее) и постоянно следить, выполнено или нет.
Если Никита получает какое-то задание (а это далеко не всегда происходит на планировании), оно сразу же пишется на доску (в «Бэклог», «Надо» или «Делать — смотря что за дело).
Исключение — только дела, которые нужно «всё бросить и сделать» прямо сейчас, вроде «быстро разобрать сумки из магазина». Ну и ещё есть дела, которые выполнить быстрее, чем написать, например, «убрать обувь с прохода на полочку».
2. Есть перечень постоянных обязанностей, которые Никита контролирует сам каждый день
Этих задач не так много, но перечень, конечно же, расширяется со временем. Сейчас это утренний разбор посудомоечной машины, покупка питьевой бутилированной воды, вынос мусора.
А ещё обязательно нужно после школы выполнять хотя бы три хозяйственных поручения, полученных от Юли (я в это время на работе). То есть, придя домой, Никита должен сам в инициативном порядке спросить, что ему нужно сделать, чем помочь, записать это на стикеры и взять в работу.
3. Видео и компьютер — после всех остальных дел
Ну тут всё просто: у Никиты есть ежедневный лимит по времени, которое он может пользоваться компьютером и планшетом. Это дело даже вынесено на отдельный стикер и стоит в «надо» каждый день, но в самом конце перечня дел.
Наша общая цель — чтобы на это дело тоже хватало времени, и мы в этом заинтересованы не меньше его. Наша позиция: «Никита, от жизни нужно получать удовольствие, тебе нравится играть в компьютерные игры — давай стараться, чтобы у тебя на это хватало времени!»
Очень важный, на мой взгляд, момент, заключается в том, чтобы не превращать систему управления делами в «тоталитарную машину». Мы с Никитой обсуждаем планы и дела, но не мы с Юлей указываем каждый день, что и как должно происходить в жизни Никиты. Здесь, как мне кажется, стоит перекладывать на ребёнка ответственность за планирование дел, ответственность за выбор, за принятие многих решений.
Есть область взаимных обязанностей, ведь мы одна семья и совместно ведём домашнее хозяйство, и тут родители как бы являются «начальством». Но обязательно должны быть и задачи, появление и выполнение которых исходит от ребёнка, в выполнении которых заинтересован он сам.
По затратам времени: ведение дел в таком виде требует определённой организованности, но во много раз экономичнее по времени, чем постоянно контролировать дела ребёнка и напоминать по десять раз о том, что ему нужно сделать прямо сейчас.
Гибкая методология разработки Scrum, или как быть в потоке всем участникам проекта
Поток, что это? Это быть в моменте, здесь и сейчас, каждому участника проекта. Есть ты, рабочее пространство и 100% фокус. Рабочее пространство — это стены офиса или уголка в доме, если ты на удалёнке, твои коллеги очно, либо в мессенджерах, задачи, безумные идеи и яркие цели.
Мы в IT часто сталкиваемся или столкнёмся с тем, что надо запилить нечто такое, в короткие сроки, с учётом таких-то деталей и интеграции новшеств, не потеряв в скорости. В общем сделать так, чтобы всё было хорошо :). Вполне обычная задача, приступая к которой, засучиваешь рукава, хватаешь маркер, карандаши с ручками, собираешь или входишь в команду, проектируешь, визуализируешь, генерируешь идеи, варишь, варишь, варишь и идёшь стучать по клавишам, реализуя крутые вещи.
Scrum методология позволяет погрузить каждого, хоть немного ответственного, даже заинтересованного на малую долю участника, в процесс с головой. Каждый участник берёт на себя ответственность за задачу, невыполнение которой, подведёт в первую очередь всю команду и конечно самого себя. А это обидно, очень обидно.
Не будем сейчас расписывать мотивационную составляющую, в каждой компании свои методы, условия и плюшки. Мне больше импонирует человеческий фактор, прям от самой сути слова — человеческий. Это и компетенция, и опыт, и настроение, и желание, и общение и ещё десятки качеств, которые формируют человека, стоящего перед тобой.
В первую очередь, всегда говорил и говорю команде — мы делаем общее дело, все вместе. Так было 12 лет назад, когда занимался сопровождением продуктов, так было 9 лет назад, когда занимался системным и бизнес анализом и 7 лет назад, руководя производством, и вот уже на протяжении 4-х лет, руководя проектами. Лично для меня, нет должностных вертикалей, есть команда, которая на равных в своей компетенции, делает продукт. Такой подход стирает границы формальностей, бюрократии и самое главное, временных ожиданий. Любой участник имеет право голоса тогда, когда он считает нужным. И кстати, под словом команда, я имею в виду и заказчика, который является полноправным участником и входит в состав наших Scrum-команд.
Что такое гибкая методология разработки?
Гибкость в IT сейчас повсюду и философия Agile с набором ценностей, сформулированных в манифесте из 4-х ключевых идей и 12 принципов также, у всех на слуху, на виду и возможно в обойме вашего проекта, в котором вы участвуете. Мы полностью поддерживаем Agile в части взаимодействия людей внутри команд, топим за работающий продукт вместе с заказчиком, который как указал ранее, является частью команды и конечно же, мы 24/7 готовы к любым изменениям, абсолютно любым.
С философией определились, а за методологией или как правильно называют книги — фреймворком, далеко ходить не пришлось. Scrum почти идеально вписывался в наш проект. Почему почти, да потому что мы же говорим о гибкости и внедрять гибкую методологию, как оказалось, можно тоже гибко. Например, мы грешим взятием задач в уже запущенный спринт, да, ещё мы можем переносить не закрытые задачи в следующий спринт. Но это не мешает работать по Scrum методологии и успешно сдавать продукт.
Расскажу про адаптацию методологии в реалии разрабатываемого продукта. Да, возможно приверженцы и адепты Scrum до самых корней, будут немного удивлены описанному далее подходу, но ребят, мы же IT, а значит, нужно пробовать варианты, адаптировать под свои процессы и достигать успеха! Ведь конечная цель — это качественный и в срок, рабочий продукт! Что мы с командой и делаем.
Итак, Scrum методология/фреймворк, что мы взяли и как у нас есть
1. Product owner (PO) — Заказчик
В нашем случае это внешний заказчик, IT-технологи (в каждой команде 1-2 технолога), которые полностью участвуют в наших процессах разработки выставляя и транслируя требования/задачи своего бизнес-заказчика. Бизнес-заказчик, кстати, временами участвует в показах и грумингах команд, что очень полезно на стадии сбора первичных требований глобальных задач, фиксации промежуточных и конечных результатах.
2. Scrum master (SM) — Lead в команде + фасилитатор
3. Команда
Рекомендуемое методологией количество участников одной команды 5-9 человек. Состав наших команд от 6 до 12 человек. В сравнении с командой из 6 человек, проблем с увеличением времени митингов или каких-либо коммуникаций, в команде из 12 человек, не наблюдаем.
Команды делятся по функциональности продукта. В общей сложности у нас 7 команд, суммарной численностью 50+ человек в компетенциях: Аналитики, Разработчики разных направлений (Front, Back, Integration), Архитекторы, Тестировщики, Системные администраторы и Сопровожденцы.
Практически в каждой команде 100% автономность, покрывающая функциональность продукта. Но и тут есть адаптация Scrum методологии. Например, архитекторы участвуют во всех командах и точечно подключаются, когда зовут, для участия в митингах, грумингах и решении каких-либо задач. Точечное подключение касается команд администрирования и сопровождения. Также, участник команды в любой компетенции, может привлекаться к другим командам для решения задач, например, доработки модуля, который срочно нужно внедрить в предстоящий релиз. Такие привлечения согласовываются между SM команд, которые анализируют задачи спринтов и возможность отдачи компетенции, на срок, позволяющий максимально сохранить покрытие запланированного объёма задач, в рамках текущего спринта. Финальное решение переключения зависит от исполнителя компетенции, т. к. он берёт на себя ответственность, помимо закрытия задач своего спринта, закрыть дополнительно задачу спринта другой команды. Бывают ситуации, когда сами заказчики в командах, понимая важность рабочего модуля для проекта в целом, жертвуют компетенцией исполнителя/ей, перенося свои незавершённые задачи на следующий спринт. Но как показывает практика, все «жертвы» не напрасны. Мы получаем рабочий продукт в установленный релиз, клиенты довольны, мы довольны что клиенты довольны, ну, а взаимопомощь всегда хорошо, и кто знает, когда какой-то из функциональных команд, потребуется доп. помощь компетенции другой функциональной команды?
С ролями, надеюсь, всё понятно. Давайте рассмотрим предметно, что к чему.
Организация процесса
1. Boards — доски
Какое-то первичное понимание ведения досок у нас было. Мы знали, что можно брать стикеры, писать на них задачи и двигать бумажки по ячейкам, ровно так, как мы делали на Kanban доске. Kanban доска была классной, такой красивой, огромной и пробковой. У задач был свой жизненный цикл (ЖЦ) и до какого-то момента, стикеры помещались все. Но с наращиванием команды, оптимизации процессов разработки, прокачке компетенций, задач стали брать больше и больше. Как итог, десятки стикеров с задачами, которые попросту перестали умещаться на доске. И это глобальные задачи, детализация которых велась в Jira.
Scrum-методология тоже рекомендует стикеры, доску на которую их можно лепить, маркеры и стоящую вокруг доски, активно обсуждающую задачи, команду. Окай, сформировали пилотную команду и начали проводить данный обряд в митингах, грумингах и ретроспективах. Практически на каждом обряде очно присутствовал заказчик. Опыт неоценимый и очень результативный. Благодаря чему, команда сплотилась, выстроила чёткий вектор развития, прозрачно, объективно и с понятным (в Story Pointʼах) сроками.
ЖЦ скрам доски стандартный:
Параллельно физической доске, мы продолжали вести задачи в Jira, для удобства обмена информацией, историчности, оперативного поиска, обращения к вложениям и прочим благам цифровизации, а также заделом на будущее, для региональных и работающих удалённо участников будущих команд. Спустя какое-то время, стикеры, маркеры, флипчарты стали доставлять неудобства из-за объёма информации. Было принято решение, в той же Jira, сформировать Scrum доску. Это очень правильно решение, с него и надо начинать.
Позитивный и результативный успех пилотной команды, заложил фундамент на будущее. Разрабатываемый продукт у нас уже был разделён на функциональные блоки, которые вперемешку делали все участники команды в рамках своей компетенции и направлении задач.
Начали формировать команды, децентрализация по России сотрудников которых, составляет 45%. У каждой функциональной команды появилась своя доска в Jira, со своим SM, списком задач и сроками.
2. Коммуникации
Децентрализация команды, временами, ограничение возможности присутствия заказчика, а также необходимость в бизнес-заказчике, потребовало наладки VoIP коммуникации. Начали со Skype, но результат не отвечал нашим требованиям в части видеопотока, да и звука. Думаю, вы понимаете, о чём я, видя, как шевелят губами, роботом говорящие ребята. Это была проблема, т. к. большинство сотрудников заказчика, подключаются с мобильных устройств с плохим интернет-каналом.
В поисках решений, кто-то предложил Zoom клиент. Попробовали. Зашло. Аудио и видео потоки не прерывались, даже со слабым интернетом-каналом. Каждый участник команды, подключаясь на встречу, обязательно включает камеру, тем самым, частично компенсируя своё физическое отсутствие. Да и продуктивнее общаться online, видя собеседника и всю команду в целом.
SM команды, на каждом митинге шарит доску, вводя команду в единое инфополе.
Также, мы запустили Confluence, что позволило избавиться от тонны пересылаемых документов, с кучей разных версий, ожиданием пока кто-то почистит ящик, чтобы принять документ и прочими неудобствами. Confluence вывешен во вне и в моменте, все могут видеть единую версию документа, либо осуществлять правки в online, прям по ходу груминга например. Подключили плагин версионности публикуемых документов, с ним куда проще работать, особенно имея релизность продукта. Прям советую.
3. Backlog — список задач
Сформировать первичный бэклог труда нам не составило. После создания Scrum-доски в Jira, все незакрытые задачи публикуются в бэклоге. За несколько лет накопилось неплохое количество незакрытых задач, которые как ни кстати требовалось проштудировать и в целом понять, что актуально, что нет.
Оставив «жмых» из более чем сотни задач, стали распределять по командам, там-же, в бэклогe, путём создания новых спринтов с припиской «Backlog». Данные спринты никогда не берутся в работу, а служат только для хранения историй/задач для последующего взятия в спринт. Такой подход очень удобен тем, что все задачи на виду у всех участников множества команд. Бывают случаи, что кто-то цепляет взглядом какую-то интересную, по его мнению, задачу из другой команды, лезет чуть глубже и понимает, что она плотно коррелирует с тем, над чем он сейчас работает. Такие задачи переходят в команду интересующегося участника и как правило оперативно закрываются. Также, полная картинка бэклога мне даёт оперативный срез по объёмам производства и понимание динамики задач.
В основном задачи в бэклог добавляет SM, но каждый участник проекта может докидывать задачи в ходе рабочего процесса, уведомив SM. Например фичу надо допилить, для улучшения скорости загрузки, или не забыть поправить что-то не критичное, но мешающее внутреннему миру разработчика жить мягко и пушисто.
Как наполняется Backlog:
Выше упоминал о релизности продукта. Всю историю и будущее планирование выпуска релизов мы также, ведём в Jira. Количество и частота релизов с каждым годом увеличивается примерно в два раза. Все связи задач, историй, epicʼов и версий релизов, ведётся в бэклоге.
Релиз в Jirʼe декомпозируем следующим образом:
4. Оценка задач (подзадач)
Само собой, у всех нас была в голове одна оценка (ну ладно, две, вторая: сложно, не сложно) задач, в днях и в часах (для самых мелких задач). Тут снова приходит Agile и говорит, возьми не временную оценку, а оценку усилий, заложи туда всё, что может произойти с задачей и назови Story Point (SP). Было не просто уйти от привычного мерила, но шаг за шагом мы двигались, формировали в головах новые нейронные связи и пришли к градации 3, 6, 9, 12. Где 3 самая простая задача, 12 самая сложная. Кто-то использует шаг в 2 SP, кто-то ряды Фибоначчи или размеры одежды и даже размеры животных, мы же остановились на шаге в 3 SP, как самым оптимальным.
Для оценки задачи, субъективно, самой распространённой или скорее более точной техникой является Planning Poker. Тут вновь отходим от правильной методики оценки SP. В каждой нашей команде как минимум, есть 2 сотрудника одной компетенции, например аналитик. Да, они могут быть с разными скиллами, но это не мешает выходить на диалог при оценке задач. SM называет задачу, участник из команды, в рамках своей компетенции, откликается в качестве исполнителя, погружается (хотя в большинстве своём, команда предметно знает свои задачи бэклога из грумингов и рабочего процесса) детально в задачу и оглашает свою оценку в SP. Если SM или сотрудник в схожей компетенции, имеют вопросы или предположение своей оценки, отличной от озвученной, начинается дискуссия и раскладка задачи по полочкам, для более детальной и объективности оценки. Когда все вопросы дискуссии проработаны, фиксируется проговоренная между участниками команды SP задачи. Исполнитель финально подписывается под оценкой.
Задача = подзадача истории. Для удобства контроля выполнения подзадач и историй в целом, мы немного доработали Jira, включив суммарное отображение SP открытых подзадач в истории. Если подзадача закрывается, SP подзадачи вычисляется из общего SP истории. Оценки видны в бэклоге, что позволяет оперативно реагировать на «застрявшие» задачи. К примеру, если история взята в 2-х недельный спринт с оценкой 150 SP, то в соответствии с диаграммой погашения задач, в середине спринта, остаток открытых задач должен составлять примерно 75 SP ±. Видя сильное отклонение от цифры, на командном митинге, можно более детально углубиться в причины и скорректировать действия для успеха исполнения истории в текущий спринт.
Вся оценка историй и Epicʼов строится из оценки подзадач. Со временем, ты понимаешь продуктивность своей команды в SP. Даже при планировании спринта, накидывая историй с подзадачами, ориентируешься на средний показатель спринта. Продуктивность каждого участника команды также видно в SP. Это дополнительный инструмент SM, которым аккуратно можно балансировать нагрузку.
5. Sprint
Временной отрезок, включающий в себя полный цикл разработки продукта, с готовым функционалом на выходе. Спринт состоит из:
Временной отрезок, как правило, задаётся длинной в 1 — 2 недели или месяц. Этого более чем достаточно для потребностей большинства команд. Мы взяли 2-х недельный отрезок, как самый оптимальный и вот почему:
Как упоминал ранее, у нас 7 команд. Каждая команда использует компоненты спринта в удобные для себя дни и время. У кого-то спринт может стартовать/завершаться в середине недели, у кого-то со вторника. Время на груминги и ретроспективы, команда тоже определяет сама. Далее буду описывать работу на примере команды архитекторов.
Новый спринт у нас формируется каждый второй понедельник, после отчётного митинга за минувший рабочий день.
Отличие отчётного митинга от ежедневного митинга только в одном — участник команды не говорит о том, что будет делать сегодня.
В ежедневном митинге, каждый участник команды отвечает на 3 вопроса:
Ловить проблемы разного уровня, в ходе исполнения задач, это нормально. Если решение доступно в моменте, команда молниеносно прорабатывает варианты и принимает к исполнению (например композит выдаёт ошибку из-за некорректно указанной ссылки. Обновили ссылку, всё заработало). Если есть понимание, что требуется потратить приличное количество времени на решение проблемы, идём по сценариям:
Митинг проходит каждый рабочий день, в одно и то же время. У каждой команды своё время с разницей проведения в 30 минут. Это сделано для того, чтобы участники команд, при необходимости, могли подключаться с максимальным погружением к нескольким созвонам (например потребность в архитекторах может быть в нескольких командах сразу).
Груминг (Grooming) проводим каждую неделю, иногда чаще, в зависимости от потребности обсуждения/проработки задач. Стандартная встреча раз в неделю в запланированное время (например, каждый вторник в 16:00). На грумингах мы обсуждаем:
Продолжительность проведения груминга от 30 минут до нескольких часов.
Демонстрация функциональности (Demo/Показ) — проводится каждую вторую пятницу, в день завершения спринта. Demo это всегда волнующий и эмоциональный момент, ведь это двухнедельный результат работы всей команды и каждый участник с трепетом относится к своему детищу.
Demo зачастую проводит тестировщик, он как никто, знает, что показывать и как показывать. Знает, что работает, что нет, знает где есть костыль и как обойти багу. Шучу. Показ нацелен на результат команды, а вы помните, что заказчик является частью команды и прекрасно знает, если что где-то не так, знает, что не успели сделать и знает почему. Все успехи и неудачи делятся поровну, на всех участников команды. Методология скрама этим и хороша — все процессы настолько прозрачны, что в голове и мысли нет, чтобы тратить время на какие-то костыли и варианты демонстрации «красивой картинки». Мы оперируем фактами в текущем моменте, открыто принимаем ситуацию как есть и вместе ищем пути решения.
Ретроспектива спринта — проводится в день показа, ближе к концу рабочего дня. Ретроспектива помогает навести фокус на упущенные вещи, ввести корректировки в процессы команды, поставить новые цели и определить пути достижения. Каждый участник высказывается, делясь своим мнением и мыслями по ходу прошедшего спринта (что настораживает, что радует), озвучивает свои предложения, а также, предлагает идеи и способы реализации.
Поначалу, команде было не очень комфортно высказываться. Вроде всё нормально, спринт закрыли, всё показали, да и пятница, выходные уже вот-вот, что ты от меня хочешь? В какой-то степени это нормально, когда привык делать своё дело и делать его хорошо, да даже отлично. Но сейчас всё иначе. Сформировавшаяся сплочённость, персональная ответственность, открытость в процессах, меняет мышление. Это должно было произойти. Даже интроверты выходят за привычные им рамки и начинают «бомбить» идеями, предложениями, адресованными отзывами, проявляя открытость. Если вначале, мы могли слышать фразы — Вась, твой скрипт навернул мне процесс, что привело к нескольким часам поиска проблемы и как результат, я чуть не зафакапил свои задачи. И Вася начинает ещё больше напрягаться, ведь уже в ходе спринта всё проговорили, поправили, а сейчас опять тему поднимаем. То сейчас, мы говорим так — Вась, твой скрипт навернул мне процесс, мы с тобой потратили много времени на поиск и исправление, я тут прикинул, как в будущем уберечь нас от таких проблем, слушай.
В команде выстраивается открытый диалог, который нацелен на решение проблемы на уровне проекта, а не на уровне личных задач.
Пожалуй, это все процессы, которые мы ежедневно используем в рамках Agile философии и Scrum методологии. Возможно есть ещё какие-то вещи, но они кажутся настолько очевидными за 3 года применения и использования, что я попросту мог их не упомянуть выше.
Теоретическая применимость фреймворка ясна. В следующей статье рассмотрим практическое применение.
Автор: Константин Гусев
Руководитель проектов
Компания ОТР