English for Developer Experience Engineers: DX, SPACE Framework, and Platform Metrics (англійською)
Вивчіть словниковий запас, який використовують інженери DX у презентаціях і презентаціях лідерів — SPACE framework, DX Core 4, журнали тертя, когнітивне навантаження, стан потоку і NPS розробника.
Досвід розробника (DX) інженерія є практикою поліпшення того, як працюють розробники програмного забезпечення - зменшення тертя, збільшення потоку і вимірювання впливу платформи і інструментальних інвестицій. Це відносно нова назва, але швидко зростаюча дисципліна в таких компаніях, як Spotify, Shopify, GitHub і Stripe. Якщо ви працюєте над внутрішніми платформами, інструментами розробників або інженерною продуктивністю, цей словник є необхідним для передачі цінності вашої роботи як колегам, так і керівництву.
Що таке досвід розробника?
** Досвід розробника (DX) ** відноситься до суми всіх взаємодій, інструментів, процесів і середовищ, з якими розробник стикається під час виконання своєї роботи. Для інженерів це те, що досвід користувача (UX) є для кінцевих користувачів — цілісна якість робочого середовища.
Погана DX виглядає як повільні CI-конвейери, заплутана документація з впровадження, неякісні тести і пошкоджені локальні середовища розробки. Хороший DX виглядає як п’ятихвилинні петлі зворотнього зв’язку, чіткі API, надійні інструменти і безшумне розгортання. Інженери DX кажуть: * “Вік першого затвердження для нових найманих працівників в даний час становить 11 днів - наша мета - отримати його нижче 3.” *
Метаболізм і метаболічні процеси
SPACE framework (розроблений дослідниками в GitHub і Університеті Вікторії) є найбільш широко використовуваним framework для вимірювання продуктивності розробників. Акронім означає:
- S — Задоволеність: Наскільки задоволені та зацікавлені розробники своєю роботою та інструментами?
- P — Виконання: Чи розробники створюють код, який досягає бажаних результатів?
- A — Діяльність: Скільки роблять розробники — затвердження, PR, розгортання, перегляд коду?
- C — Комунікація та співпраця: Наскільки ефективно розробники працюють разом?
- E — Ефективність і поток: Наскільки гладко можуть розробники завершити роботу з мінімальними перервами?
Інженери використовують SPACE, щоб стверджувати проти однієї метричної продуктивності: * “Рядки коду на день не є чинною DX-метрикою - це одна мірка діяльності. SPACE каже нам, що нам потрібно дивитися на всі п’ять вимірів.”*
DX Core 4 (від команди DX Research в DX Data) є новітньою, більш гнучкою структурою, яка фокусується на чотирьох високо-сигнальних метриках: швидкість (частота розгортання, час циклу), ефективність (сприйнята інженерна ефективність), якість (рівень дефектів) і вплив (вирівнювання з бізнес-целями).
** Індекс ефективності розробників ** це складний бал, який деякі організації обчислюють з декількох питань опитування DX і метрик платформи.
Фільтрація, очистка, гідроізоляція
** Флоу- стан ** це психологічний стан глибокого, безперервного фокусування, коли розробники дуже продуктивні. Інженери DX прагнуть захистити поток, зменшуючи переключення контексту, переривання зустрічей і помилки інструментів. * “Наша постійна ротаційна робота перериває потік занадто часто - ми в середньому 4 переривання на інженера на день в робочі години.” *
** Когнітивне навантаження ** — це розумові зусилля, необхідні для розуміння системи, вивчення інструменту або виконання завдання. Висока когнітивна навантаження сповільнює розробників і збільшує кількість помилок. Команди DX зменшують когнітивне навантаження, спрощуючи API, покращуючи документацію і автоматизуючи повторювані рішення. “Процес розгортання має занадто багато вручну виконаних кроків - когнітивне навантаження призводить до помилок конфігурації. Нам потрібно автоматизувати вибір середовища.»
** Журнал тривання ** — це щоденник або структурований документ, у якому розробник записує кожну точку заплутаності, затримки або розчарування, з якими він стикається під час виконання завдання. Команди DX використовують журнали тертя для ідентифікації системних проблем. * “Я зробив журнал тертя нового процесу опорних послуг - є сім пунктів, де розробники повинні шукати племінні знання, які ніде не задокументовані.” *
Ключі DX Метрики
- Time-to-first-commit — скільки часу потрібно новопризначеному співробітнику, щоб зробити свій перший значний внесок у код
- ** Час- до- першого- PR ** — скільки часу пройде до того, як новий працівник відкриє свій перший запит на витяг
- ** Частота розгортання на розробника ** — як часто окремі розробники відправляють до виробництва
- ** NPS розробника (чистий бал промоутера) ** — показник, заснований на опитуванні, у якому розробників запитують, наскільки ймовірно, що вони рекомендують свої поточні інструменти і середовище колегам
Відома концепція **“розкладу творця проти розкладу менеджера” ** (від Пола Грема) часто цитується в дискусіях DX: розробники (творці) потребують довгих, неперервних блоків, щоб бути продуктивними; менеджери працюють в одногодинних слотах зустрічей. Інженери DX розробляють процеси, які захищають час виробника.
DX-цінність комунікації до лідерства
Інвестиції DX часто невидимі для керівництва, поки вони не зазнають невдачі. Інженери формулюють DX ROI в конкретних термінах: *“Зменшення середнього часу CI з 18 хвилин до 6 хвилин знижує кожен з наших 80 інженерів приблизно на 20 хвилин на день - це 1600 інженерних годин на місяць відновлено.” *
**Платформа прийняття фуникулер ** відстежує, скільки розробників активно використовують нову внутрішню платформу або інструмент — від обізнаності, до першого використання, до регулярного прийняття. Команди DX використовують це, щоб виміряти, чи їхня робота дійсно покращує поведінку розробників.
Наступні кроки
Запис журналу помилок щодо одного з завдань, яке ви недавно виконали — налаштування нової служби, розгортання можливості або впровадження нового інструменту. Перерахуйте кожен момент затримки або занепокоєння. Потім сформулюйте свої висновки у двохреченнявій англійській резюме, використовуючи словниковий запас з цієї статті: що таке когнітивне навантаження, де знаходиться тертя, і які метричні дані доведуть покращення?
Національні мови: рідна мова для ненаціональних меншин
Зрозуміти англійську мову в технічному середовищі, наприклад, розробці програмного забезпечення, може бути складно навіть для носіїв рідної мови. Тонкі нюанси фразування, специфічний словник, який використовується для опису складних процесів, і очікування навколо комунікації часто є джерелами плутанини. Для розробників, які не повністю володіють англійською, ці виклики можуть значно вплинути на співпрацю, цикли зворотнього зв’язку і, врешті-решт, на якість їх роботи. Це не просто про знання окремих слів; це про розуміння * як * ці слова використовуються для передачі значення в конкретному контексті - часто одним, що керується ефективністю і оптимізацією. Одна з поширених областей для нерозуміння описує проблеми або пропонує рішення. Замість того, щоб просто сказати «Це повільно», інженер DX може пояснити: «Ми спостерігаємо збільшення когнітивного навантаження через поточний робочий процес, особливо при роботі з великими наборами даних. Це, здається, впливає на поточний стан і, можливо, сприяє розчаруванню серед розробників. » Ключова відмінність полягає в рівні деталізації і виправданні, що надається — демонструючи розуміння за межами проблеми поверхневого рівня. Іншою частою перешкодою є прийняття або надання зворотнього зв’язку, особливо навколо переглядів коду. Отримавши коментар на кшталт «Це могло б бути більш читабельним», можна відчувати себе неопределенным. Корисною відповіддю може бути: «Я помітив деякі складні вкладені умови тут; рефакторинг для зменшення когнітивного навантаження за допомогою допоміжної функції покращить читабельність і підтримку»
Крім того, термінологія, що оточує метрики, такі як SPACE (Задоволеність, Виконання, Діяльність, Соціалізація, Залучність) і DX Core 4, може відчуватися абстрактною без чіткого розуміння того, як вони пов’язані з досвідом розробника. Важливо вийти за рамки простого повідомлення цифр і натомість пояснити, що ці цифри * означають * з точки зору настрою розробників, продуктивності або загального здоров’я платформи. Наприклад, повідомлення «NPS не працює» не є дієздатним. Замість цього ви можете сказати: «Наш рейтинг NPS трохи знизився в цьому кварталі, в основному через журнали тертя, що вказують на те, що розробники борються з процесом впровадження нашого нового API. Це свідчить про необхідність переглянути документацію і, можливо, спростити деякі з початкових кроків налаштування. ” Сфокусування на * чому * за метрикою є надзвичайно важливим.
Наконец, помните, что общение не всегда прямое. Розробники часто використовують непрямі формулювання, щоб пом’якшити критику або запропонувати поліпшення - тактика часто корениться в збереженні гармонії команди. Навчання розпізнавати ці тонкі сигнали і відповідно реагувати значно поліпшить ваше розуміння і зможе ефективно сприяти. Не бійтеся просити про пояснення; набагато краще шукати розуміння, ніж робити припущення, засновані на неповній інформації.
# Example: Using `git blame` to investigate a code change - relevant vocabulary around identifying the source of an issue
git blame some_file.js | head -n 10