Эту самую картинку наш технический директор подкладывал в каждую презентацию с комментарием: «Я хочу, чтобы вы были как они.»

Приветствую, дорогой читатель.

В атмосфере взаимодействия гибкости и тесного взаимодействия (на буржуйском — Agile и DevOps) присутствует такое понятие, как Continuous Learning. По сути общая идея заключается в том, чтобы признавать простой факт: как бы усердно ты ни работал, каким бы профессионалом бы ты ни был — ты всегда можешь быть и делать лучше.

Дабы не вызывать комплекс неполноценности, я взял за правило, что мой КПД — 95%.
Эта цифры взята из потолка, но она дает мне право осознавать, что я достаточно вовлечен в процесс, я пытаюсь выжать максимум из своих возможностей, но всегда есть 5% которых мне не хватает до идеала. Набравшись новых знаний, я пробую снова — но цифры всегда остаются прежними — 95% и ни процента больше.

Однако, каждый раз я задаюсь одним и тем же вопросом — становлюсь ли я лучше?

В Scrum есть такой интересный процесс как refinement (он же estimation). Каждый член команды держит в руке колоду карт Scrum покера и готовится показать карту с количество очков на каждую историю. История обсуждается, декомпозируется, разжевывается до мелочей пока абсолютно все члены команды не поймут, конкретно что и как необходимо сделать. В момент, когда консенсус достигнут владелец продукта говорит сакральную фразу: «Оценим?». На раз-два-три игроки показывают карту, смотря оценки друг друга, и, если они разнятся, обсуждают снова пока все не придут к одной оценке.

Есть множество способов определения оценки, но мы в нашей команде (учитывая, что мы не разработчики, а инженеры) взяли за основу оценки следующие критерии: длительность, сложность, риск, неизвестность и взаимодействие с третьими лицами (читай — соседними командами).
К примеру появляется задача — инвентаризировать все подсети, которыми мы пользуемся. Это не сложная задача, в принципе достаточно залезть на core маршрутизаторы, посмотреть виртуальные свичи в Vmware, на крайний случай — пообщаться с другими инженерами или поскрести по сусекам в поисках старой документации. Однако можно потратить целую неделю, а то и две выискивая каждый ипшник. И как оценить эту задачу?

А вот есть задача иная — например освоить динамические инвентари Ansible, в частном случае — тот же Vmware. Тоже несложная задача на первый взгляд, но если залезть поглубже, встанет другой вопрос — как группировать? По тегам, ресурс пулам или сетям? Или построить большие группы на основе датацентров и дочерние группы в кластерах? Надо ли добавлять ESX хосты или только гостевые виртуалки? У этой задачи в добавок к «сложности» появляется критерий неизвестности.

Ну и самая мякотка. Возьмем за основу, что самая «большая задача», которая займет одного инженера на целых 2 недели, равна 5 очкам. Отсюда выливается следующий негативный момент:

• Последовательность Фибоначчи не имеет в себе цифр 10 или 15 — как оценить если задача займет 2 инженеров на весь спринт?
• В таком случае скорость команды остается фиксированной Х*5, где Х — количество очков. Как тогда объективно оценить возможности команды к росту?

Обозначаем стандартную задачу

Выше уже понятно, что ставить оценку, базируясь на сроках, не самое правильное решение.
Тогда возьмем какую-нибудь стандартную задачу — например приготовить для команды разработчиков 1 сервер. Сервер может быть железным или виртуальным, он должен быть установлен/создан, на нем должна быть установлена ОС, назначен ипшник, добавлен в домен, настроены бекапы и мониторинг, записана документация, сервер передан в эксплуатацию stakeholder'у. История стандартная, с ней справится каждый член команды, никому ничего объяснять/обучать не надо — 1 очко.

Базируясь на определенном стандарте человек понимает: «Час на это, полчаса на это, еще имейл накатать, ну за день справлюсь.» Имея стандарт можно подобным образом оценивать другие задачи, даже с большим объемом неизвестности.

Вот например Puppet — соседние ребята, сопровождающие фронт на нем уже собаку съели, а мы его особо не используем (ну только ноды и роли прописать, много ума не надо). И вот тут ситуация — надо написать свой модуль для amavis, чтобы сканеры почты можно было деплоить за 5 минут, вместо часа. Выгода очевидна, преимуществ немеряно, Infrastructure-as-Code тот же. Но писать модули никто не умеет. И тут уже другая цепочка — покурить мануалы, сходить к ребятам за лучшими практиками, разработать, прописать тестовое окружение, простестировать, пофиксить, протестировать, пофиксить, добавить модуль в Puppetfile и т.д. — много всего. Вот тут уже инженер может дать слабину — испугавшись многих «если» он может переоценить задачу или, что еще хуже, недооценить. Но если вспомнить про «скелет» задачи, можно хотя бы приблизительно понять сколько усилий, крови, пота и боли будет стоить эта задача.

Количество стандартов может быть разным:

• Новая роль Ansible — 2 очка
• Продиагностировать из-за чего упал сервер — 0.5 очка
• Срелизить новую версию продукта — 1 очко (CI/CD то налажен!)
• Исследовать новый продукт — от 2 до 5 очков
• Ну и так далее

Таким образом формируется определенная производительность, ставится планка, которую надо потом увеличивать. Но изначальная проблема «становлюсь ли я лучше» остается.

Как же ее решить?

На основе velocity

Дополнительным преимуществом оценивания является возможность измерить результаты и сравнить с предыдущими спринтами. Вот на этом спринте было 10 очков, я только пришел в контору, и коллеги потратили много времени, чтобы ввести меня в курс дела. Вот тут уже вышли на 15, мало, но 2 инженеров были в отпуске. Вот уже 20 очков, круто, но это базовая планка. От терний к звездам можно двигаться до бесконечности. Velocity — одна из базовых метрик измерения потенциала команды, но если брать ее за единственный объективный критерий, то, Scrum Master/PO, жди что твои коллеги начнут оценивать задачи вдвое-втрое больше. :)

Иным является ситуация со скелетом задачи — доставка сервера. Когда задача «весит» 1 очко, мы понимаем, что сервер надо руками создать в vmware, поставить ОС из шаблона, прописать руками ипшник, установить NRPE и настроить Veeam бекапить эту машинку — а что если все автоматизирировать? Вот у нас конфигурация машины в Terraform, в CI стриггерится билд, сервер будет добавлен в нужную группу в динамическом инвентаре на основе тэга, стриггерится другой билд — ВЖУХ и накатится роль с агентом для Nagios, и запустится скрипт, чтобы добавить сервер в расписание бекапов. Означает ли это, что усилия по задаче снижены? Безусловно.

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

Deliverables

Важно не только количество съеденных стори поинтов, но и практическая польза от произведенного труда. Измеряется она очень абстрактно — в нашем случае так вообще на размере улыбки stakeholder'а, но гораздо лучше сказать «Наша команда за этот спринт смигрировала все серверы на новый домен, старый можно аннигилировать», чем «Наша команда за этот спринт закрыла задач на 50 очков». 50 очков, вау круто, а что вы сделали-то?

Но опять же возьмем за правило, что больше deliverables — лучше работает команда, что может пойти не так?

Вот еще кейс — подготовка к рождеству. Для нашей ecommerce платформы это особое время, и все-все-все разработчики, инженеры и аналитики бросают все новые фичи и готовятся ответить на следующие вопросы:

• Сможет ли фронтенд выдержать 1 миллион запросов в минуту?
• Сможет ли почтовик обработать 1 миллион писем в день?
• Сможет ли платформа обрабатывать больше 9000 заказов в час?
• А что в WMS?
• А справится ли сетка?

Позже мы отчитаемся о том, как мы упрочнили костыли нашу инфраструктуру, но это нельзя принимать за deliverables — в следующем году этот вопрос станет снова и колесо Сансары даст очередной оборот.

Считается ли что команда работала плохо? Нет.

Так как же понять, становлюсь ли я лучше или нет?!

Работа.

Я обошел всех наших Agile Coach'ей, надеясь получить особый стандартный ответ на этот вопрос. Ответ был получен — особого стандартного ответа нет. Но была одна хорошая догадка, и имя ей — Работа.

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

В итоге я и как инженер, и член команды понимаю, что если я доставил 4 deliverables'а на 20 очков, то средняя температура по больнице — 5 очков на один deliverable. В следующем спринте будет 10 на 30, а затем — 15 на 40.

Таким образом я пойму, стала ли моя команда быстрее, умнее, выше, сильнее, эффективней, и стал ли я как инженер сильнее вчерашнего себя.