В качестве предисловия
Ты сидишь перед монитором, разбираешь утреннюю почту, и вдруг воздух вокруг начинает дрожать.
— Что происходит?!
Все резко темнеет, и несколько долгих мгновений ничего не видно и не слышно. Только собственный стук сердца. В следующий миг свет возвращается…
— Где я? Что это за место?
Начав говорить, твое внимание привлекает человек в робе с капюшоном, надвинутым на глаза.
— Приветствую, %UserName%, ты в оплоте магов! Мы знаем, что ты способен пользоваться Источником Силы. Я расскажу тебе о нем. Источник содержит пять Сил — Земля, Воздух, Вода, Огонь и Дух. Земля олицетворяет устойчивость, Воздух — свободу, Вода — изменение, Огонь — мощь, Дух — дисциплину. В большинстве случаев для выполнения необходимого действия вполне достаточно какой-либо одной части из пяти. Так потоки Огня позволяют зажечь свечу и контролировать горение пламени. Но более сложные задачи требуют плетения потоков из большего числа Сил. Для примера, тому, кто захотел бы воздействовать на погоду, потребовалось бы сплести одновременно потоки Воздуха, Воды и Духа. Но для того, чтобы начать обучение, тебе придётся пройти испытание...
Что это было?
Дело в том, что я устал впустую проповедовать в попытке внедрить инженерные agile-практики.
Не знаю как у вас, но среди разработчиков, с которыми мне приходилось сталкиваться, не более 10% реально познали agile-дзэн. Это крайне печальная статистика. И я задумался, можно ли что-то сделать с этим?
При освоении сложных областей всегда так. Сначала все очень сложно и это продолжается какое-то время, потом внезапно становится легко и привычно. Например, с вождением автомобиля такая тема, особенно на механике. Так вот, современные инженерные практики (авто-тесты, CI, CD и прочие DevOps) осваиваются приблизительно так же. Проблема в том, что в глазах большинства процесс освоения выглядит как-то так:
Тем, кто только начинает освоение agile-практик, кажется, что усилий прилагается слишком много, что это никогда не закончится и что так будет всегда. Но те, кто уже освоили эти практики, знают, что в какой то момент происходит переключение в мозге и резко становится проще. Практики становятся родными и после этого уже не представляешь как без них жить.
И как же мотивировать людей дойти до конца в нелегком пути освоения agile-практик?
В момент отчаяния и неверия в свои силы мне чудесным образом попался курс по игрофикации (я уже не один раз замечал, что когда это нужно, в моей жизни что-то внезапно интересное и полезное появляется). Игрофикация — отличный инструмент для обучения и мотивации. Может это то, что нужно?
В качестве цели для своей игрофицированной системы, я определил уменьшение количество ошибок в продуктиве на 20% с одновременным увеличением скорости внесения изменений на 20%.
По моей логике пошаговое освоение новых рабочих навыков участниками игрофицированной системы (далее игроки) приведет к самостоятельному выводу о необходимости применения современных инженерных практик. А освоенные и примененные лучшие современные практики должны привести к достижению обозначенных целей.
Как уже наверное стало понятно, для своей системы я выбрал магическую тематику.
Магия подчиняется особым принципам — это своего рода магическая физика. Заклинания строятся путем сплетения потоков сил разного вида в нужной последовательности и в правильный узор. Потоки силы могут быть 5 видов — огонь, вода, земля, воздух и дух.
Каждая Сила соотнесена с каким-то полезным навыком следующим образом:
- Земля — устойчивость. Качество выпускаемого продукта — авто-тесты + код-ревью;
- Воздух — свобода. Свобода от поддержки/сопровождения, создание документации и передача QA и эксплуатации;
- Вода — изменение. Создание толерантного к изменениям программного кода — минимизация технического долга (рефакторинг + код-ревью);
- Огонь — мощь. Сжигает рутину — внутренняя автоматизация. Использование различных инструментов и утилит, повышающих продуктивность;
- Дух — дисциплина. Декомпозиция своей работы и ежедневное доведение какого-то кусочка работы до состояния «Готово» (Get things done в действии).
Чтобы сплести заклинание, необходимо сначала накопить необходимые для заклинания силы. Накапливаются силы выполнением заданий:
- Декомпозируй и влавствуй — в системе отслеживания задач необходимо довести (под)задачу(и) общей трудоемкостью ~4 часа до состояния “Готово” (+3 Духа);
- Рунопись — необходимо задокументировать выполненную работу на Gherkin (+4 Воздуха);
- Технический долг платежом красен — необходимо уменьшить цикломатическую сложность в программном коде (+5 Воды и +2 Огня);
- Жизнь слишком коротка для ручного тестирования — написать автотест на текущую разработку (+5 Земли и +3 Огня);
- Совместные занятия — написать 3 рецензии на работу коллег (code review) (+2 Духа и +1 Воздуха).
Пример задания:
Технический долг платежом красен.
Необходимо находить запахи кода и избавляться от них.
– Что? Как может пахнуть код?
– Да, пахнуть определенно не может… а вот пованивать — запросто.
Для выполнения задания необходимо:
- Рассчитать цикломатическую сложность до внесения изменений в код;
- Выполнить рефакторинг функционала;
- Рассчитать цикломатическую сложность после внесения изменений в код. Метрика должна снизиться как минимум на 5;
- Оставить комментарий в своем профиле со ссылкой на выполняемое задание, описанием выполненной работы (имя оптимизированного метода и модуль в котором он расположен) и метрикой до и после внесения изменений;
- Договориться с 2 коллегами для проведения кросс-рецензирования. В результате каждый коллега должен оставить ответ на комментарий из п.3 с оценкой выполненной работы и обоснованием поставленной оценки. Период кросс-рецензирования ограничен 3 рабочими днями;
- получить заслуженную Силу исходя из оценок кросс-рецензентов.
В идеале сложность методов не должна превышать значение 15-19.
Кросс-рецензентам при оценке нужно исходить из следующих критериев:
| Оценка | Сила | Комментарий |
|---|---|---|
| 1 | 1 Воды | Цикломатическая сложность снизилась, но обнаружены ошибки при внесении изменений |
| 2 | 2 Воды | Цикломатическая сложность снизилась, ошибок не замечено, но код не стал от этого более понятным |
| 3 | 3 Воды | Цикломатическая сложность снизилась, ошибок не замечено, код стал немного более понятным, но есть существенные замечания к проведенному рефакторингу (например, неверно выбран логический участок кода для выделения метода) |
| 4 | 4 Воды 1 Огня |
Цикломатическая сложность снизилась, ошибок не замечено, код стал более понятным, но есть некоторые замечания (например, к именованию переменных или новых методов) |
| 5 | 5 Воды 2 Огня |
Цикломатическая сложность снизилась, ошибок не замечено, код стал более понятным, никаких замечаний к проведенному рефакторингу нет |
В случае, если автор рефакторинга не согласен с рецензией, то может обратиться к кругу архимагов с целью пересмотра оценки.
Тратить накопленные Силы можно на заклинания. Есть общедоступная книга заклинаний, где содержаться все открытые на текущий момент плетения (список заклинаний открытый, игроки могут предлагать новые заклинания мастеру системы). Каждое плетение имеет стоимость, а также может иметь ряд ограничений, например, текущий уровень игрока (послушник, принятый или маг), время восстановления (как часто заклинание можно сплести) и т.п. Примеры заклинаний:
- Чародейский интеллект — если в течении 5 рабочих дней игрок выполняет не менее 3 ежедневных заданий каждый день, то игрок получает удвоенное количество затраченных на заклинание сил
- Заклинание отгула;
- Прийти на работу позже / уйти раньше;
- Защита от рутинной работы;
- Философский камень — трансформация одной накопленной Силы в другую.
Также за выдающиеся результаты состоявшийся маг имеет возможность войти в высший совет для участия в принятии решений.
Масштабирование системы
Описанную игрофицированную систему можно “прикрутить” практически к любому подразделению. Для этого необходимо выполнить всего несколько шагов:
- Сопоставить Силы и навыки, которые необходимо привить персоналу;
- Составить задания, «прокачивающие» навыки из предыдущего пункта. Причём задание не обязательно должны строго соответствовать какой-то конкретной Силе;
- Придумать плетения для книги заклинаний, чтобы персонал мог куда-то расходовать накопленные ресурсы;
- Сбалансировать количество накапливаемых ресурсов со стоимостью плетений. Я, например, отталкивался от ключевого плетения “Отгул”. По моей задумке его можно сплести приблизительно раз в 18-20 рабочих дней, если ежедневно выполнять все задания. Стоимость остальных плетений уже подгонялась исходя из степени “интересности” относительно “Отгула”.
При этом не обязательно для каждого подразделения использовать свой собственный “инстанс” системы, они могут сосуществовать как различные школы/направления магии (например, маги, жрецы, шаманы, друиды и т.п.). Это открывает широкий простор для дальнейшего развития системы, например, коллективный PvE контент.
В качестве заключения
За 3 месяца работы игрофицированной системы в пилотной команде, я получил просто потрясающий результат:
- Начали покрывать код тестами;
- Переехали в git;
- Индивидуальное владение кодом уже не такое выраженное;
- Участки кода, к которым все боялись прикасаться со словами “работает не трогай”, теперь постепенно приводятся в нормальный вид;
- Члены команды обучаются друг у друга, ведь code-review это не столько инструмент контроля, сколько инструмент взаимного обучения;
- Уменьшилось количество массовых инцидентов (хочется верить, что причина преимущественно в игрофикации и agile-практиках);
- В разы повысилось желание осваивать что-то новое у членов команды;
- На подходе начало использования билд-серверов.
Всего этого я пытался добиться самыми разными способами весь 2016 год.
В качестве следующего шага подумываю использовать цепочки квестов для адаптации новых сотрудников. По задумке, в игровой форме новый человек достаточно быстро должен разобраться, как устроены внутренние процессы и влиться в коллектив.
Тут хочу предложить в комментариях совместно покреативить на тему использования описанной системы в других службах имеющих отношение к ИТ — проектный офис, QA, службы эксплуатации.
Также было бы интересно вместе подумать над интересными идеями для плетений (книгу заклинаний хочется сделать потолще).
И еще, буду признателен за любую обратную связь.
Закончив свое повествование автор делает петлю из Огня, продевает через нее переплетенные Воздух с Духом, следом вплетает поток Воды и закрепляет узор обвязывая вокруг потоком Земли. Узор стабилизируется и на его месте начинает мерцать портал. Он делает шаг в портал и исчезает...
Комментарии (13)
EvilBeaver
25.04.2017 13:50+2Хочется подробностей процесса. Чувак приходит на работу, затем?
Как физически организована ежедневная работа с учетом магических формул и всего вот этого?
emil36
25.04.2017 14:05получает задачи или продолжает выполнять те таски, которые не сделал вчера или ему они были назначены вечером уже, затем после выполнения, отписывается, что вот выполнил такую и такую задачу, при выполнении использовал то-то и то-то, там же есть еще квесты, квест ежедневный, по задачам, затем за то, что применял во время разработки: git или написал автотест, потом чувак идет рецензировать чужую разработку или чужой автотест, за что получает так же nn количество силы. вот как-то так)
wizi4d
25.04.2017 14:22Это надстройка над обычным рабочим процессом, причём вход и выход свободные. Т.о. ежедневная работа выглядит точно также, просто сотрудник может заодно выполнять квесты, зарабатывать ресурсы и использовать их на свое усмотрение.
ShamanR
25.04.2017 15:24+1Это все прекрасно и когда я читаю такие статьи я представляю компанию уровня гугла, где сотрудники сидят в пуфиках, раз в час ходят пить смузи и катаются на кухню на гироскутерах. И тут с неба сходит прожект менеджер, даёт им эту систему, они курят вейп и поддерживают её вредрение, после чего каждый день соревнуются между собой кто больше баллов наберет, и, возможно, ездят на кухню в два раза реже.
Реальность же такова, что у тебя, и у твоей команды, и у соседних команд стоит задач столько, что только успевай делать, и никто тебе не даст рабочих часов чтобы что-то зарефакторить или улучшить. Максимум это покрыть только что написанный код тестами, и то, не под 100%, если начальная проектировка была с отклонениями.
Конечно можно на каждый таск вешать какие-то бонусы и плюшки, но это будет не игрофикация, а просто дополнительная мотивация, потому что ты и так и так сделал бы эту поставленную задачу.
Описанное личный опыт в текущей компании, но думаю такое положение вещей у большинства.emil36
25.04.2017 15:36так авто в статье как раз и написал:
Игрофикация — отличный инструмент для обучения и мотивации.
Так и есть это доп.мотивация.
wizi4d
25.04.2017 15:45Если технический долг только накапливается и никогда не отдается, то очень скоро стоимость внесения изменений начнет зашкаливать. Работа, которую можно было бы сделать за несколько часов, будет выполняться несколько дней.
Кстати, о явном выделении рабочих часов на рефакторинг никто не говорит. Суть в применении правила бойскаута:
Всегда оставляйте код чище, чем он был до вас
hel2gm
25.04.2017 15:57А что мешает сделать пространство вокруг себя как в Гугл? Человек красит место. И дело не в смузи ведь. А в том, что круто работать там, где окунувшись в код, у тебя не остаётся ощущения, что ты хлебнул из тухлого болотца. И если игрофикация помогает достичь этого эффекта, то она полностью оправдывает применение. И это на мой взгляд круто! Лично я бы не отказалась работать в такой атмосфере игры и в окружении единомышленников.
gromozeka07b9
25.04.2017 17:47Отличная статья, спасибо!
Проблемы очень похожие, с тестами так в точку.
Можешь ли пролить свет на такие моменты:
1. Много ли сотрудников, которые НЕ приняли правила игры? И как мотивируете их?
2. Нет ли попыток сломать систему, к примеру, создавая фейковые данные в баг-треккере?
3. Нет ли просадки по выполнению бизнес-задач, учитывая что вы начали тратить время на рефакторинг? Понимаю, что к геймификации это не самое большое отношение имеет, любопытно просто.wizi4d
25.04.2017 18:31- Где-то 20% не стали играть. Пока ничего с ними не делаю, возможно втянутся.
- Начисление Сил происходит в ручном режиме, поэтому кто-то обязательно лично проверяет проделанную работу.
- Хотелось бы ответить, что просадки нет, по факту до 20% времени может уходить на рефакторинг и авто-тесты. Просто мы понимаем, что это инвестиции в будущее. Либо вкладываешься сейчас и потом не теряешь скорость на доработках, либо не вкладываешься, но зато теряешь скорость потом, причем уже с набежавшими процентами.
alexey-lustin
27.04.2017 13:57Где моё любимое? "+800% к морали" — есть Jenkins файл в GIT репозитории
SirEdvin
Существенная проблема в том, что аджайл в чистом виде не нужен практически никому, а мелкие или средние компании часто не могут себе позволить его в том или ином виде.
А оно им нужно? Мне кажется, довольно часто проблемы различных проектов лежат вне плоскости вопроса "девы не понимают аджайл" и большинстов девов это понимают. Какой смысл заставлять девов учить то, что им не поможет?
wizi4d
На самом деле система получилась никак не связанной с аджайлом. Ее предназначение — обучение персонала, а к чему это «приложить» уже дело каждого.
emil36
имхо, в чистом виде аджайл вряд ли вообще кому-то будет полезен, если это не компания софтверная, но вот приведенная в статье система как уже сказал wizi4d больше нацелена на обучение и познание стандартов разработки, во многом она помогает подойти к разработке с другого ракурса, а то что раньше было дремучим лесом, на деле оказалось довольно симпатичной березовой рощей)