Сама методология довольно неплохо (но для тех кто первый раз пытается погрузиться, возможно это описание будет выглядеть перегруженным) описана на Вики https://ru.m.wikipedia.org/wiki/SCRUM. Для тех кто не хочет читать, или предпочитает более легкую и наглядную демонстрацию, я предлагаю посмотреть вот такой короткий ролик на Ютубе:
Вот ещё небольшая юмористическая зарисовка на тему скрам из сериала «Кремниевая долина»:
— «Ну scrum, так скрам» скажете вы. — » Зачем нам это, это же девелоперские фишки, код там писать, тестить. Это нам не поможет, мыж сервера поднимаем, сетку настраиваем, юзеры вечно что то хотят.» Не применимо это короче — а вот и нет!!! Очень даже применимо. Ибо это организация работы над проектом и задачами. Просто для OPS команды (сисадмины, сетевики и пр), его надо немного доработать.
После доработки он становится вполне применим и позволяет делать следующие вещи:
1. приводить в порядок список ваших проектов и долгоиграющих задач ( ведь у вас на это появляются силы и возможности)2. спокойно поставить задачи и двигаться к намеченным целям всем сотрудникам отдела / членам команды3. регулярно пересматривать ваш список задач и проектов, выявлять не актуальные и тем самым не держать за спиной груз бесполезных задач4. гибко и быстро реагировать на поступающие запросы
и многое другое что дает SCRUM
Сейчас я расскажу о нашем опыте. Мы не переизбирали эту методологию. И в первую очередь, вам нужно познакомиться с ней, с ее идеями, с ее артефактами и тп. Иначе все сказанное ниже будет казаться для вас если не ахинеей то как минимум слабо связанным с тз идей текстом.
Далее я привожу список наших доработок или “патчей”, чтобы scrum мог работать для Ops команд:
1. Заведите backlog (хранилище задач) под все ваши задачи, проекты, тикеты и ТД. Это обязательное требование Scrum в принципе, но для OPS команд это означает — заведите единое хранилище. То есть не должно быть такого что заявки от пользователей Вам приходят в хелпдеск / тикет систему, указания от руководства (не IT отдел) не покидают Ваш телефон или почту и хранятся только там, а все внутренние задачи и проекты записаны только в блокноты сотрудников. У вас должно быть централизованное унифицированное хранилище “истины”. Увидел кто-то что была найдена уязвимость в ядре и вышло обновление — поставь сам задачу на отдел — “протестить и обновить сервера” (это кстати не очень хорошая формулировка, но об этом чуть позже), вместо того, чтобы пометить в блокноте и забыть на месяц. Или того хуже — сказать коллегам за кофе, чтобы они “угукнули” и забыли все вместе- коллективно и навсегда.
2. Начинаем использовать спринты. Берем максимально короткий для SCRUM интервал — 1 рабочая неделя. В начале недели, в понедельник с утра — собираем команду на 1 час, планируем спринт. То есть берем готовый к работе бэклог, набираем из него задач на неделю, что-то распределим, что-то оставляем в свободном виде (тот кто освободился- подхватил), а вечером пятницы, незадолго до конца рабочего дня, тоже собираемся на час и смотрим что получилось. Ведем разбор полетов- что успели, а что нет. Почему, как в следующий раз не допустить, какие были проблемы и ошибки, чему научились. Это все кстати лучше фиксировать.
3. Помимо планирования спринтов в начале недели и разбора полетов в конце, проводите ежеутренние “стендапы” (летучки) всей командой. 15-20 минут с утра, у маркерной доски, в строго определенное время и стоя! Строго определенное время нужно для приучения всех к дисциплине, 15-20 минут — этого хватает чтобы каждый рассказал чем занимался вчера, чего достиг, что планирует сейчас, что было интересного и в чем ему нужна помощь коллег. Эдакая синхронизация команды. А стоя — так по нашему опыту не возникает желания растягивать это надолго, естественным образом пресекаются долгие дискуссии и холивары. Каждый по очереди пишет на доске напротив своего имени что будет делать сегодня, зачеркивает/стирает что делал вчера и делает другие пометки. Да, это необычно для скрам, тк там должна быть только скрам доска со стикерами или их аналогом ( у нас она заменена веб приложением), но скрам доска нужна для поддержания сквозного скрам процесса, спринта и тд а это чисто утренний синк команды.
4. Разбейте все ваши проекты и долгоиграющие задачи на подзадачи, которые могут быть выполнены за 1-3 дня. Не больше. Если задача тяготеет к 5 дням работы, она рискует быть не выполненной за спринт (отвлеклись и оп), а значит ее надо разбить на подзадачи. Более того, выше я приводил пример как человек заводит внутреннюю задачу “протестить и обновить сервера” — это плохая задача. Хорошая задача формулируется так, что для ее выполнения не надо думать “что надо сделать и с чего начать” — не тратятся мозговые ресурсы. Она должна быть сформулирована так, чтобы вы могли за нее взяться даже если Вас разбудят в 3 ночи. Например — “развернуть тестовый сервер на виртуальной машине с текущей версией ядра, потом обновить его до версии с патчем, протестировать (напишите как — например развернуть копию рабочей базы данных и прогнать пару тестов на производительность), а потом пачками по Х штук обновить сервера 1,2,3,4 и тд в продакшене ( список серверов и порядок обновления)”.
5. Начните оценивать задачи которые вы ставите сами себе или которые ставят вам с точки зрения — «сколько человеко часов на это уйдет». Это будут наши story points или очки задач. Во первых, это поможет вам с предыдущим пунктом, а во вторых приучит к оценке и планированию. Не бойтесь брать небольшой запас и не бойтесь ошибаться, со временем вы и ваша команда научитесь это делать это четко и точно.
6. Посчитайте число участников вашей команды. Их не должно быть больше 10. для таких команд скрам не работает. Если вас меньше, скажем 7-8, вычтите 1 (потом увидите зачем) и получившееся число умножьте на число человеко часов вашей рабочей недели ( например у нас стандартная 5-ти дневка, мы работаем 8 часов из которых час на обед и прочие надобности — покурить, туалет и ТП). Итого 5*7= 35 часов. на 7 человек (8-1) имеем 245 свободных поинтов. Теперь на этот размер можно набирать задач из бэклога, только так чтобы 1 задача не превышала за раз 3 поинтов как вы поняли.
Итак, у нас есть хранилище куда попадают все задачи которые мы должны сделать, задачи перевариваются — разбиваются если надо и оцениваются, у нас есть своя оценка поинтов (именно описанная выше оценка лучше всего подходит для ОПС команд) и есть понимание сколько всего очков у нас в запасе на спринт. Пока все более менее стандартно, ничего нового.
Помните вы вычитали одного члена команды ( кстати он может быть и не один но это надо подбирать на практике, мы справляемся с одним)? Это дежурный инженер или on-call. Его время не учитывается в работе, оценке, исполнении спринта — его задача быть буфером между командой и задачами «срочно, сломалось, надо было вчера сделать».
Все входящие задачи, помимо оценки времени должны разделятся по одному принципу — “это задача или инцидент?”. Как это сделать:
- Если чего то не было и это хотят (новый принтер в бухгалтерию ) — это задача. - Если вам надо развернуть новую серверную ферму под кластер виртуализации — этот проект который надо разбить на задачи. - А вот если что то работало и потом сломалось, например: в офисе пропал интернет, почтовый сервер все пихает в спам, 1С не грузится, у пользователя не включается компьютер, сайт отдает 503 — это инцидент.
Дежурный инженер должен принять их на вход и обработать. Например оценит что это срочно и важно и ринуться грудью на амбразуру, прикрывая товарищей от отвлекающей рутины. Или поняв что это нечто, требующее долгой работы отдела (тот же пресловутый кластер виртуализации рассыпался и теперь надо в несколько пар рук заниматься им полное время) — собирает всю информацию, составляет диагноз, нарезает первые задачи с чего начать и, уведомив руководство, первым кидается тушить пожар. А уже IT менеджер / старший админ / начальник отдела оценивает масштаб происшествия и принимает решение кого и как прислать на подмогу.
Так же, дежурный инженер должен заниматься ежедневными рутинными задачами — «разгребать» их, снимая эту нагрузку с команды — отключения учетных записей, проверки бекапов, наблюдение за мониторингом и тп.
Таким образом нейтрализуется ежедневный отвлекающий фактор, создающий прерывания и приносящий “рабочий шум”. Команда же может спокойно планировать задачи и выполнять их.
На этом все! Применение этих простых “патчей” позволит Вам использовать SCRUM методологию в Вашей Ops команде!
П.С. Тэг "мое", тк перенесено сюда из статьи моего блога: https://kazarin.online/index.php/2019/06/06/how-to-patch-scr...
