Цю саму картинку наш технічний директор підкладав в кожну презентацію з коментарем: «Я хочу, щоб ви були як вони».
Вітаю, дорогий читач.
В атмосфері взаємодії гнучкості і тісної взаємодії (на буржуйському - Agile і DevOps) присутнє таке поняття, як Continuous Learning. По суті загальна ідея полягає в тому, щоб визнавати простий факт: як би старанно ти не працював, яким би професіоналом би ти не був - ти завжди можеш бути і робити краще.
Щоб не викликати комплекс неповноцінності, я взяв за правило, що мій ККД - 95%.
Ця цифри взята зі стелі, але вона дає мені право усвідомлювати, що я досить залучений в процес, я намагаюся вичавити максимум зі своїх можливостей, але завжди є 5% яких мені не вистачає до ідеалу. Набравшись нових знань, я пробую знову - але цифри завжди залишаються колишніми - 95% і ні відсотка більше.
Однак, кожен раз я задаюся одним і тим же питанням - чи стаю я краще?
У Scrum є такий цікавий процес як refinement (він же estimation). Кожен член команди тримає в руці колоду карт Scrum покеру і готується показати карту з кількість очок на кожну історію. Історія обговорюється, декомпозується, розжовується до дрібниць поки абсолютно всі члени команди не зрозуміють, конкретно що і як необхідно зробити. У момент, коли консенсус досягнутий власник продукту говорить сакральну фразу: «Оцінимо?». На раз-два-три гравці показують карту, дивлячись оцінки один одного, і, якщо вони різняться, обговорюють знову поки всі не прийдуть до однієї оцінки.
Є безліч способів визначення оцінки, але ми в нашій команді (враховуючи, що ми не розробники, а інженери) взяли за основу оцінки такі критерії: тривалість, складність, ризик, невідомість і взаємодія з третіми особами (читай - сусідніми командами).
Наприклад з'являється завдання - інвентаризувати всі підмережі, якими ми користуємося. Це не складне завдання, в принципі достатньо залізти на core маршрутизатори, подивитися віртуальні свичі в Vmware, на крайній випадок - поспілкуватися з іншими інженерами або поскрести по сусеках у пошуках старої документації. Однак можна витратити цілий тиждень, а то й два вишукуючи кожен іпшник. І як оцінити це завдання?
А ось є завдання інше - наприклад освоїти динамічні інвентарі Ansible, в приватному випадку - той же Vmware. Теж нескладне завдання на перший погляд, але якщо залізти поглибче, постане інше питання - як групувати? За тегами, ресурс пулам або мережам? Або побудувати великі групи на основі датацентрів і дочірні групи в кластерах? Чи треба додавати ESX хости або тільки гостьові віртуалки? У цього завдання в добавок до «складності» з'являється критерій невідомості.
Ну і сама м'яка. Візьмемо за основу, що «найбільше завдання», яке займе одного інженера на цілих 2 тижні, дорівнює 5 очкам. Звідси виливається наступний негативний момент:
- Послідовність Фібоначчі не має в собі цифр 10 або 15 - як оцінити якщо завдання займе 2 інженерів на весь спринт?
- У такому випадку швидкість команди залишається фіксованою Х * 5, де Х - кількість очок. Як тоді об'єктивно оцінити можливості команди до зростання?
Позначаємо стандартне завдання
Вище вже зрозуміло, що ставити оцінку, базуючись на термінах, не найправильніше рішення.
Тоді візьмемо якесь стандартне завдання - наприклад приготувати для команди розробників 1 сервер. Сервер може бути залізним або віртуальним, він повинен бути встановлений/створений, на ньому повинна бути встановлена ОС, призначений іпшник, доданий в домен, налаштовані бекапи і моніторинг, записана документація, сервер переданий в експлуатацію stakeholder'y. Історія стандартна, з нею впорається кожен член команди, нікому нічого пояснювати/навчати не треба - 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'a, але набагато краще сказати «Наша команда за цей спринт змигрувала всі сервери на новий домен, старий можна анігілювати», ніж «Наша команда за цей спринт закрила завдань на 50 очок». 50 очок, вау круто, а що ви зробили?
Але знову ж візьмемо за правило, що більше deliverables - краще працює команда, що може піти не так?
Ось ще кейс - підготовка до різдва. Для нашої ecommerce платформи це особливий час, і все-все-всі розробники, інженери та аналітики кидають все нові фічі і готуються відповісти на наступні питання:
- Чи зможе фронтенд витримати 1 мільйон запитів на хвилину?
- Чи зможе поштовик обробити 1 мільйон листів на день?
- Чи зможе платформа обробляти більше 9000 замовлень на годину?
- А що в WMS?
- А чи впорається сітка?
Пізніше ми відзвітуємо про те, як ми зміцнили милиці нашу інфраструктуру, але це не можна приймати за deliverables - наступного року це питання стане знову і колесо Сансари дасть черговий обіг.
Чи вважається що команда працювала погано? Ні.
Так як же зрозуміти, чи стаю я кращим чи ні?!
Робота.
Я обійшов всіх наших Agile Coach'ей, сподіваючись отримати особливу стандартну відповідь на це питання. Відповідь була отримана - особливої стандартної відповіді немає. Але була одна гарна здогадка, і ім'я їй - Робота.
Під роботою розуміється кількість витраченого часу на один deliverable. Час розраховується емпіричним шляхом зі стори пойнтів - на виході можна отримати співвідношення результат до витрачених зусиль.
У підсумку я і як інженер, і член команди розумію, що якщо я доставив 4 deliverables'a на 20 очок, то середня температура по лікарні - 5 очок на один deliverable. У наступному спринті буде 10 на 30, а потім - 15 на 40.
Таким чином я зрозумію, чи стала моя команда швидшою, розумнішою, вищою, сильнішою, ефективнішою, і чи став я як інженер сильнішим за вчорашнє себе.
