У цій статті розглядаються шість способів самооцінки Agile-команд, які допоможуть почати постійне вдосконалення.

Agile команди процвітають завдяки постійному вдосконаленню та адаптивності. Самооцінка — це не просто інструмент аналізу поточного стану, а й компас, який спрямовує команди до їх потенціалу. Це дає змогу командам зрозуміти свої сильні сторони, визначити сфери вдосконалення та глибше заглибитися в динаміку роботи за межі простого результату.

Справжня суть самооцінки в Agile полягає в сприянні прозорості, співпраці та невпинному вдосконаленні. Це не аудит, а дзеркало, що відображає кращу версію вашої Agile команди.

Інструменти самооцінки

Ось колекція відомих інструментів самооцінки здоров’я для натхнення:

1. Перевірка стану команди від Spotify (The Spotify Squad Health Check)

Модель перевірки стану команди від Spotify, представлена Хенріком Кнібергом (Henrik Kniberg), — це інструмент, призначений для оцінки стану команди або «підрозділу» в організації. Модель в основному використовує систему кольорового кодування для вимірювання відповідей. Цей відгук збирається за набором з одинадцяти показників, кожен з яких представляє окремий аспект функції команди:

• Легко реалізувати (Easy to release)
• Відповідний процес (Suitable process)
• Створення цінності (Delivering value)
• Веселощі (Fun)
• Швидкість (Speed)
• Навчання (Learning)
• Місія (Mission)
• Здоров'я кодової бази (Health of Codebase)
• Підтримка (Support)
• Пішаки або гравці (Pawns or Players)
• Командна робота (Teamwork)

2. Індекс щастя від Crisp (Crisp Happiness Index)

Crisp AB:

Наш основний показник — «Nöjd Crispare Index» (англійською мовою: «Happy Crisper Index» або «Crisp Happiness Index»). Це єдине, що ми системно вимірюємо та контролюємо. Шкала 1-5. Дані зберігаються на нашій інформаційній панелі (загальна електронна таблиця Google).

Ось приклад і шаблон, можете копіювати та змінювати.

3. Опитування Scrum команди від Liberators

The Liberators:

Ми створили опитування, щоб підтримати Scrum-команди в їх циклі постійного вдосконалення. Перший крок у цьому циклі — створити прозорість навколо того, де ви зараз перебуваєте, а потім працювати разом як команда, щоб визначити вдосконалення та внести адаптації. Цей документ містить усе, що вам потрібно для початку. Ми також включили посібник для фасилітації, щоб перевірити результати командою і разом визначте покращення.

4. Командний барометр від Джиммі Янлен (Jimmy Janlén)

Джиммі Янлен (Jimmy Janlén) - Agile тренер і вчитель:

Барометр виконаний у вигляді опитування на робочій зустрічі. Опитування складається з 16 командних характеристик, упакованих у вигляді колоди карт. Члени команди голосують зеленим, жовтим або червоним за кожну картку під час зустрічі (або перед зустріччю як анонімне опитування). Після того, як усі картки пройдено, команда обмірковує та обговорює результати. При бажанні можна виконати вправу за тридцять хвилин, але я рекомендую виділити годину.

Характеристики:

1. Довіра
2. Співпраця
3. Зворотній зв'язок
4. Залучення до зустрічі
5. Зобов'язання
6. Поліпшення
7. Взаємна відповідальність
8. Потужність
9. Гордість
10. Стосунки
11. Власність
12. Спільне використання
13. Підсилення один одного
14. Лояльність
15. Пристрасть
16. Цілісність

5. Монітор здоров'я від Atlassian

Монітор здоров'я — це шанс для вашої команди чесно подивитись у дзеркало. Ви оціните свою команду за вісьмома характеристиками, які найчастіше зустрічаються серед здорових команд. Наприкінці сеансу моніторингу стану здоров’я ви визначите сильні сторони, які потрібно використовувати, а також складні напрямки розвитку.

Характеристики:

1. Згуртованість колективу (Team cohesion)
   Взаємна довіру та повага, необхідні для того, щоб бути ефективною командою для здорової співпраці. Сильне відчуття зв’язку між членами команди.

2. Збалансований колектив (Balanced team)
   Є потрібні люди з потрібними навичками, які виконують чітко визначені ролі. Це дозволяє нам успішно забезпечувати цінність, за яку відповідає команда.

3. Заохочувальна відмінність (Encouraging difference)
   Шукаємо та висловлюємо різні точки зору з різних джерел, як внутрішніх, так і зовнішніх, і знаходимо час, щоб з повагою пропрацювати точки розбіжностей.

4. Спільне розуміння (Shared understanding)
   Поділяємо розуміння нашої місії та мети, а також наших ключових етапів для ефективного виконання нашого стратегічного плану як команди.

5. Цінність і показники (Value and metrics)
   Розуміємо цінність, яку надаємо, і цінність для бізнесу, визначення успіху та те, як ця цінність відстежується та вимірюється. Зрештою, використовуємо наші показники, щоб приймати рішення та вживати необхідних заходів.

6. Відповідні способи роботи (Suitable ways of working)
   Способи спільної роботи в команді дозволяють ефективно виконувати свою роботу, незалежно від того, чи розподілені, чи розташовані члени команди в одному місці. Це стосується інструментів, які використовуємо, способів зустрічей і співпраці та прийняття рішень.

7. Залучення та підтримка (Engagement and support)
   Іншим командам зрозуміло, як і коли взаємодіяти, команди роблять це ефективно та постійно отримують підтримку, необхідну для прогресу. Чітко розуміємо, від кого ми залежимо, а хто від нас.

8. Постійне вдосконалення (Continuous improvement)
   Завжди знаходимо час, щоб відзначити успіхи, а також серйозно обміркувати, вжити заходів і реалізувати наші можливості вдосконалення. Є регулярні та цілеспрямовані цикли зворотного зв’язку всередині та поза командою, щоб приймати рішення щодо покращення.

6. Оцінка здоров'я команди від New Relic

Брент Міллер (Brent Miller) головний інженер і архітектор New Relic:

Моя основна команда взяла ці 250 відповідей і скомпонувала їх, поки ми не отримали 22 стандарти здоров’я, які здавалися правдивими та правдоподібними. Ми хотіли, щоб усі в нашій організації вірили в них, і ми хотіли, щоб вони проектували стандарти здорової команди.

Висновок

Самооцінка має вирішальне значення для Agile команд, керуючи постійним вдосконаленням і адаптивністю. Це не просто показник ефективності, він допомагає командам розпізнавати сильні сторони, розкривати сфери зростання та глибше розуміти динаміку роботи. Це інструмент, який сприяє прозорості та невпинному вдосконаленню і ви можите обрати один із вже запропонованих або створити свій під свої потреби.

В Spotify з моменту першої публікації в 2014 році було проведено понад 5000 перевірок працездатності. Принаймні 60% їх команд регулярно проводять перевірки працездатності, використовуючи свої улюблені набори запитаннь, часто з детальним посібником для підтримки осіб, які їх фасилітують. І лідери цих команд регулярно використовують результати як джерело даних для підтримки, а не судження команд.

Незважаючи на весь досвід, Spotify виявили, що завжди існує ризик перетворення процесу перевірки працездатності на ще одну рутинну задачу. Щоб цього уникнути вони пропонують робити оцінку персоналізованою під потреби команди, аналізувати глибше, щоб знаходити приховані проблеми та не зупинятись в проміжках між оцінюваннями.

Існує безліч шаблонів для міжгрупової взаємодії команд платформи та інших команд, і вибір правильних залежить як від фази впровадження платформи, так і від здатності обох команд і кодових баз сприймати зовнішній вплив.

Оригінал: How platform teams get stuff done
Автор: Pete Hodgson

Успіх внутрішньої платформи визначається тим, скільки команд її прийняли. Це означає, що успіх команди платформи залежить від її здатності співпрацювати з іншими командами, зокрема вносити зміни в коди цих команд.

У цій статті розглянемо різні етапи взаємодії, і дослідимо, що команди повинні робити, щоб забезпечити успіх на кожному з цих етапів. Зокрема, три етапи, які ми розглянемо, це міграція на платформу, використання платформи та еволюція платформи. Опишу відмінності кожного з цих етапів, обговоримо деякі операційні моделі, які команди платформи та команди потоків (клієнти платформи) можуть використовувати під час спільної роботи на кожному етапі, і розглянемо, які шаблони взаємодії між командами найкраще працюють на кожному етапі.

Розглядаючи, як співпрацюють команди розробки, основним ресурсом є чудова книга Team Topologies. У розділі 7 автори визначають три режими командної взаємодії: співпраця, X-як-послуга і фасилітація.

Команди доставки платформи і команди доставки продуктів

Перш ніж ми зануримося, давайте з’ясуємо, що відрізняє команду платформи від інших типів команд розробки. У цій дискусії згадуватиму команди доставки продуктів і команди доставки платформи.

Команда з доставки продуктів створює функції для клієнтів компанії – кінцеві користувачі продукту, який вони створюють, є клієнтами компанії. Я також бачив такі типи команд інженерів, які називаються «функціональні команди», «команди продукту» або «вертикальні команди». У цій статті я використовуватиму «команда продукту» як скорочення команди доставки продукту.

На відміну від цього, команда доставки платформи створює продукти для інших команд всередині компанії – кінцевими користувачами продукту команди платформи є інші команди всередині компанії. Я буду використовувати «команда платформи» як скорочення «команди доставки платформи».

Мовою командних топологій команду доставки продукту зазвичай можна охарактеризувати як команду потоку (Stream Aligned). Хоча автори Team Topologies спочатку визначили команду платформи як окрему топологію, згодом вони почали розглядати «платформу» як ширше поняття, а не окремий спосіб роботи – з чим я дуже згоден. З мого досвіду, коли йдеться про термінологію командних топологій, хороша платформа, як правило, функціонує або як команда потоку (їхня платформа є потоком цінностей), або як команда можливостей, допомагаючи іншим командам досягти успіху з їхньою платформою. Фактично, у багатьох моделях співпраці між командами, які ми розглянемо в цій статті, команда платформи діє як команда можливостей.

"Платформа" > Внутрішня платформа розробника

Навколо розробки платформ зараз багато шуму, головним чином зосередженого на Внутрішніх Платформах Розробників (Internal Developer Platforms - IDPs). Хочу пояснити, що розмова про «платформи» тут значно ширша; вона охоплює інші внутрішні продукти, такі як платформа даних, дизайн система для інтерфейсу або експериментальна платформа.

Незважаючи на те, що ми в першу чергу стосуватимемося технічних платформ, багато ідей, представлених тут, також стосуються внутрішніх продуктів, які надають спільні бізнес-можливості – послуга переміщення грошей у фінтех-компанії або послуга каталогу продуктів у компінії електронної комерції. Об’єднуючою характеристикою є те, що платформи це внутрішні продукти, які використовуються іншими командами в організації. Таким чином, команди платформ створюють продукти, клієнтами яких є інші команди в їхній компанії.

команди платформ створюють продукти, клієнтами яких є інші команди в їхній компанії

Етапи прийняття платформи

Повернемося до різних типів міжкомандної роботи. Ми розглянемо три сценарії, які вимагають взаємодії між командами платформи та командами доставки продуктів: міграція на платформу, використання платформи та еволюція платформи.

Коли ми розглядаємо ці три етапи, важливо звернути увагу на дві конкретні характеристики: яка команда керує роботою - є рушійною силою та яка команда володіє кодовою базою, де буде відбуватися робота. Відповіді на ці два запитання значною мірою впливають на те, які моделі взаємодії мають сенс у кожному сценарії.

Міграція на платформу

Почнемо з вивчення міграції на платформу. Міграції передбачають зміни кодових баз команди продукту з метою переходу на деякі нові можливості платформи.

Ми бачимо, що в таких ситуаціях саме команда платформи керує змінами, але право власності на кодову базу, яка потребує змін, належить іншій команді – команді продукту. Звідси виникає потреба у міжкомандній співпраці.

Приклади міграційної роботи

Про які типи змін ми говоримо? Однією відносно простою міграцією може бути оновлення версії — оновлення спільної бібліотеки компонентів або оновлення версії середовища виконання.

Звичайно, більш масштабним переходом буде заміна прямої інтеграції сторонньої системи на якусь внутрішню оболонку – наприклад, переміщення інструментів журналювання, аналітики чи спостереження на використання спільної внутрішньої бібліотеки, яку підтримує команда платформи або заміна прямої інтеграції на платіжний шлюз з інтеграцією через певний внутрішній інтерфейс.

Іншим типом міграції може бути перехід від старої служби користувача до нової служби профілю облікового запису або перенесення використання служби отримання кредитів і кредитних звітів на новий консолідований сервіс кредитних агентств.

Останнім прикладом може бути зміна платформи на рівні інфраструктури — використання Docker контейнерів, що належить команді продукту, впровадження service mash, перехід баз даних з MySQL на Postgres тощо.

Під час міграції на платформу команда продукту часто не має особливої мотивації вносити ці зміни. Іноді вони є, якщо нова платформа збирається надати якісь особливі нові можливості, але часто їх просять здійснити цю зміну як частину ширшої архітектурної ініціативи, фактично не отримуючи величезної вартості для себе.

Шаблони взаємодії

Давайте розглянемо, які шаблони взаємодії між командами підійдуть для роботи при міграції на платформу.

Попросіть виконати роботу

Команда платформи може Подати Заявку в список задач команди продукту, попросивши їх самостійно внести необхідні зміни.

Такий підхід має деякі переваги. Він масштабований – роботу над впровадженням можна доручити всім командам продуктів, чиї кодові бази потребують роботи. Його також можна відстежувати та легко керувати - часто заявку може заповнювати менеджер програми або інші ролі з управління проектом.

Однак є й деякі недоліки. Це дуже повільно – знадобиться тривалий час, перш ніж деякі команди продуктів навіть почнуть роботу. Крім того, це вимагає прикладання сил для визначенням пріоритетів — команди, яким пропонують виконати цю роботу, часто не отримують відчутних переваг, тому природно, що їх залучають, щоб зменшити пріоритетність цієї роботи над іншими завданнями, які є більш терміновими чи впливовими.

Команда платформи виконує роботу

Команда платформи може вирішити самостійно внести зміни в кодові бази команди продукту, використовуючи три схожі, але відмінні шаблони – «Відрядження», «Залучений Експерт» або «Внутрішній Відкритий Код».

У «Відрядженні» інженер із команди платформи «вбудовується» в команду продукту та виконує роботу звідти.

Завдяки Залучений Експерт та Внутрішній Відкритий Код команда продукту приймала б запити на підключення до своєї кодової бази від інженера з команди платформи.

Різниця між цими двома останніми шаблонами полягає в тому, що будь-який інженер може зробити внесок у кодову базу команди продукту, чи лише невелика група довірених зовнішніх учасників. Рідко можна побачити, як команди доставки продукту роблять інвестиції, необхідні для підтримки повного підходу з внутрішнім відкритим вихідним кодом, але це нерідко, коли внески приймаються кількома довіреними інженерами платформи.

Так само, як і у випадку з подачою заявки, робота команди платформи має певні плюси та мінуси.

Цей підхід часто скорочує час, необхідний для внесення змін, оскільки команда, яка потребує виконання роботи (команда платформи), також виконує роботу. Узгоджені стимули означають, що команда платформи з більшою ймовірністю визначить пріоритети своєї роботи, ніж команда продукту, яка володіє кодовою базою.

З іншого боку, команда платформи самостійно виконує роботу з міграції лише в тому випадку, якщо команда продукту може це підтримати. Їм повинно бути комфортно, коли до їхньої команди на деякий час приєднається інженер платформи, або вони вже провели достатньо часу з інженером платформи, щоб довіряти йому самостійно вносити зміни до своєї кодової бази, або вони повинні зробити значний інвестиції, необхідні для підтримки внутрішнього підходу з відкритим кодом.

Іншим мінусом є те, що ця стратегія «зроби сам» не масштабується. Інженерний потенціал команди платформи завжди буде меншим порівняно з командами доставки продукту, і якщо не делегувати інженерну роботу командам продукту, весь цей потенціал залишається на столі.

Справді, це трохи складніше

Насправді часто відбувається поєднання цих підходів. Команда платформи, якій доручено виконати міграцію, може запропонувати менеджеру програми надіслати заявки 15 командам із доставки продукту, а потім витратити деякий час, умовляючи їх виконати роботу. Через деякий час деякі команди виконають роботу самостійно, але будуть і інші, які особливо зайняті справами або просто не бажають брати на себе роботу з міграції. Потім команда платформи засукає рукави та використає деякі інші, менш масштабовані підходи, і самостійно внесе зміни.

Використання платформи

Тепер давайте поговоримо про іншу фазу впровадження платформи, яка передбачає співпрацю між командами: використання платформи. Це «стаціонарний стан» для інтеграції платформи, коли команда доставки продуктів використовує можливості платформи як частину своєї повсякденної роботи над функціями.

Одним із прикладів використання платформи може бути команда продукту, яка створює нову послугу за допомогою сервісного шасі, яке підтримується командою інфраструктурної платформи. Або команда продукту може почати використовувати внутрішню платформу аналітики клієнтів або почати зберігати ідентифікаційну інформацію за допомогою спеціальної служби сховища конфіденційних даних.

Ключова відмінність між роботою по використанню платформи та роботою міграції на платформи полягає в тому, що команда продукту одночасно є рушієм роботи та власником бази коду, яка потребує змін. Команда продукту має ширшу власну мету, і вони використовують функції платформи. Це відрізняється від міграції на платформи, коли команда платформи намагається внести зміни в базу коду іншої команди.

З використанням платформи ви можете подумати, що цей сценарій використання платформи не потребує спільної співпраці між командами. Однак, як ми побачимо, команда продукту все ще може потребувати певної підтримки з боку команди платформи.

Шаблони взаємодії

Гідною метою для багатьох команд платформи є створення повністю самообслуговуваної платформи — щось на кшталт Stripe або Auth0, яка настільки добре задокументована та проста у використанні, що розробники продуктів можуть використовувати платформу, не потребуючи прямої підтримки чи співпраці з командою платформи.

Насправді більшість внутрішніх платформ не зовсім такі, особливо на ранніх стадіях. Розробники продуктів, які починають працювати з внутрішньою платформою, часто стикаються з поганою документацією та незрозумілими помилками. Часто ці команди продуктів розводять руками й просять команду платформи допомогти їм почати використовувати функції внутрішньої платформи.

Коли користувач платформи просить власника платформи про практичну підтримку, ми повертаємось до міжкомандної співпраці, і знову в гру вступають різні моделі.

Професійні послуги

Іноді команда продукту може попросити команду платформи написати для них код використання платформи. Це може бути тому, що команда продукту намагається зрозуміти, як використовувати платформу. Або це може бути тому, що цей підхід вимагатиме менше зусиль від команди продукту. Іноді це просто непорозуміння, коли команда продукту не вважає, що вони повинні виконувати роботу самостійно – це може статися, наприклад, під час переходу до моделі DevOps, де команди продукту самообслуговують свої потреби в інфраструктурі.

У цьому сценарії команда платформи начебто стає невеликою групою по наданню професійних послуг в рамках інженерної організації, яка інтегрує свій продукт у системи своїх клієнтів від їх імені.

Ця модель професійних послуг використовує комбінацію шаблонів взаємодії. По-перше, команда продукту зазвичай надсилає запит на послуги команди платформи. Це той самий шаблон, який ми розглядали раніше під час роботи з міграцією на платформу, але інвертований — у цій ситуації команда продукту подає заявку на команду платформи з проханням про допомогу. Потім команда платформи може фактично виконувати роботу, використовуючи шаблони «Залучений Експерт» або «Внутрішній Відкритий Код».

Типовий приклад такої моделі співпраці – коли команді продукту потрібні деякі зміни в інфраструктурі. Вони хочуть запустити нову службу, зареєструвати нову зовнішню кінцеву точку на шлюзі API або оновити деякі значення конфігурації, тому вони подають заявку команді платформи з проханням внести відповідні зміни.

Введення в роботу в білих рукавичках

якщо платформа перебуває на ранніх стадіях і не має належної документації, команда платформи може вибрати підхід до розробки нових продуктів, використовуючи підхід «білих рукавичок», працюючи пліч-о-пліч із цими першими користувачами, щоб розпочати їх роботу. Це може допомогти розпочати впровадження нової платформи, зробивши її менш обтяжливою для перших груп продуктів. Це також може дати команді платформи дійсно цінну інформацію про те, як їхні перші клієнти насправді використовують функції платформи.

Ця модель «білих рукавичок» зазвичай досягається з використанням шаблону співпраці «Відрядження» — один або кілька інженерів платформи витрачатимуть деякий час на команду користувачів, виконуючи необхідну роботу з інтеграції платформи всередині цієї команди.

Спільнота практиків

У міру того, як платформа розвивається та стає легшою у використанні, команда платформи може відійти від виконання практичної роботи з інтеграції та перейти до більш консультативної ролі.

Цей консультативний режим включає в себе такі речі, як розміщення «офісних годин», коли команда споживачів може з’являтися та ставити запитання, або мати представника платформи, який надає цілеспрямовані поради та вказівки на сесіях планування та проектування команди користувачів. На мові командних топологій це буде команда платформи, яка працює в режимі фасилітації.

Для великих, насичених платформ з часом відбувається перехід до моделі підтримки, коли команда платформи інвестує час, щоб створити Спільноту практиків для користувачів своєї платформи. Це може включати такі речі, як канал спільноти або список розсилки, регулярні зустрічі спільноти практиків для пошуку допомоги та демонстрації цікавих ідей, можливо, навіть щорічні виїзні зустрічі практиків.

Практичні заняття не масштабуються

Ми бачимо, що рівень практичної підтримки, яку команда платформи повинна надати користувачам може значно відрізнятися залежно від того, наскільки зрілим є досвід розробника платформи – наскільки добре вона задокументована, наскільки легко її інтегрувати та працювати з нею.

На початку існування платформи було б доцільно, щоб використання платформи вимагало багато енергії від самої команди платформи. Досвід розробників все ще не достатній, можливості платформи ще розробляються, а команди споживачів трохи скептично ставляться до того, щоб вкладати свій власний час як піддослідні кролики. Співпраця з командами продуктів — це чудовий спосіб для команди платформи зрозуміти своїх клієнтів і те, що їм потрібно!

Однак практична підтримка не масштабується, і якщо метою є широке впровадження платформи, команда платформи повинна інвестувати в досвід розробників своєї платформи, щоб не потонути в роботі над підтримкою.

Також важливо чітко повідомити користувачам платформи, яку модель підтримки їм слід очікувати. Команда продукту, яка отримала беззастережну підтримку на перших днях впровадження платформи, з нетерпінням чекатиме можливості насолоджуватися цим досвідом знову в майбутньому, якщо не буде повідомлено інше!

Еволюція платформи

Давайте перейдемо до нашого останнього етапу взаємодії з платформою: еволюції платформи. Це коли команда, яка використовує платформу, потребує змін у самій платформі, щоб заповнити прогалину в можливостях платформи.

Наприклад, команді, яка використовує бібліотеку компонентів інтерфейсу користувача, може знадобитися додати новий тип компонента <Button> або розширити наявний компонент <Button> додатковими параметрами конфігурації. Або команда, яка використовує службове шасі, може захотіти, щоб це шасі надсилало більш детальну інформацію про спостережуваність або, можливо, підтримувало новий формат серіалізації.

Ми бачимо, що на етапі еволюції платформи відповідні ролі команди є протилежними ролям міграції на платформу – тепер роботою керує команда продукту, але зміни мають відбутися в кодовій базі команди платформи.

Давайте розглянемо, які шаблони міжкомандної взаємодії мають сенс у цьому контексті.

Подати заявку

Команда продукту може подати заявку команді платформи з проханням внести необхідні зміни до своєї платформи. Це, як правило, дуже розчаровуючий підхід. Часто команда продукту розуміє, що платформі чогось не вистачає лише в той момент, коли їм це потрібно, і час, необхідний команді платформи для встановлення пріоритетів і виконання роботи, може бути занадто довгим – команди платформи зазвичай перевантажені вхідними запитами. Це призводить до того, що команда платформи стає вузьким місцем і блокує прогрес команди доставки продукту.

Залучайте інженерів до роботи

Після достатнього попередження команди можуть планувати заповнити прогалину в можливостях платформи, тимчасово перепризначивши інженерів для роботи над необхідними вдосконаленнями платформи. Інженери з продуктів можуть працювати в команді платформи, або, як альтернатива, інженер платформи може на деякий час приєднатися до команди з продуктів як вбудований експерт.

Переміщення інженерів між командами неминуче призведе до короткострокового впливу на продуктивність, але наявність вбудованого інженера може підвищити ефективність у довгостроковій перспективі, зменшивши кількість міжкомандних комунікацій, необхідних між продуктом і командами платформи. Вбудований інженер діє як посол, згладжуючи комунікаційні шляхи та зменшуючи телефонні ігри.

Це рівняння фіксованих початкових витрат і поточних вигод означає, що перепризначення інженерів є варіантом, який найкраще зарезервувати для більших удосконалень платформи – переведення інженера в іншу команду на пару тижнів було б швидше руйнівним, ніж корисним.

Ці типи тимчасових призначень також вимагають відносно зрілої структури управління, щоб уникнути відчуття ізоляції вбудованих інженерів. З вбудованим експертом – інженером платформи, перепризначеним для команди продукту – також існує ризик того, що він стане загальним «додатковим працівником», який просто виконує роботу з використання платформи, а не активно працює над удосконаленням платформи, яку виконує команда продукту.

Працюйте на платформі заздалегіть

Якщо команда платформи прийняла підхід внутрішнього відкритого вихідного коду, тоді команда продукту має можливість самостійно впроваджувати необхідні зміни платформи. Роль команди платформи буде здебільшого консультативною, надаючи рекомендації щодо дизайну та переглядаючи PR (pull requests) команди продукту. Після кількох PR інженер продукту може навіть завоювати достатню довіру команди платформи, щоб отримати довіру та стати Залученим Експертом.

Багато команд платформ прагнуть досягти цієї ситуації. Чи не було б чудово, якби ваші користувачі мали змогу впроваджувати власні вдосконалення, а вам не потрібно було виконувати цю роботу! Однак реальність внутрішнього відкритого коду схожа на відкритий вихідний код загалом – для підтримки зовнішніх змін потрібні напрочуд значні інвестиції, і переважна більшість споживачів не стають значущими учасниками.

Команди платформ повинні бути обережними, щоб не відкривати свою кодову базу для зовнішніх змін, не зробивши продуманих інвестицій для підтримки цих змін. У всіх може виникнути глибоке розчарування, якщо команда платформи гордо проголошує, що їх кодова база є спільним ресурсом, але потім неодноразово говорить учасникам з інших команд «ні, ні, не так!».

Висновок

Розглянувши міграцію, використання та еволюцію платформи, стає зрозуміло, що існує велика різноманітність того, як команди взаємодіють навколо платформи.

Також очевидно, що єдиної правильної форми співпраці не існує. Найкращий спосіб спільної роботи залежить не лише від того, на якому етапі впровадження платформи перебуває команда, а й від зрілості інтерфейсів між командами та системами. Очікування можливості інтегрувати нову внутрішню платформу в тому ж самому режимі «як послуга», який ви використовували б із зрілою зовнішньою службою, — це рецепт катастрофи. Подібним чином сподівання на можливість легкого внесення змін до кодової бази команди доставки продукту, коли вони ніколи раніше не приймали зовнішні зміни, є нерозумним припущенням.

Співпрацювати, але лише на деякий час

У Team Topologies зазначають, що найкращий спосіб розробити гарні кордони між двома командами — це спочатку працювати разом у цілеспрямованому, дуже спільному режимі — подумайте про такі шаблони, як «Залучений Експерт» і «Відрядження». Цей період можна використати, щоб дослідити, де найкраще створити межі та інтерфейси між системами та між командами (закон Конвея говорить нам, що ці два аспекти нерозривно переплетені). Однак автори Team Topologies також попереджають, що важливо не залишатися в цьому режимі співпраці надто довго. Команда платформи має наполегливо працювати над визначенням своїх інтерфейсів, намагаючись швидко перейти до режиму «як послуга», використовуючи такі шаблони, як «Подати Заявку» та «Внутрішній Відкритий Код». Як ми обговорювали в розділі «Використання платформи», моделі взаємодії, які дають змогу співпрацювати, просто не будуть масштабовані для команди платформи. Крім того, режими спільної роботи створюють набагато більше когнітивне навантаження на команди користувачів – перехід до стилів взаємодії, що дає більше рук, дозволяє командам доставки продуктів витрачати більше часу, зосереджених на власних результатах. Насправді Team Topologies вважають це зменшення когнітивного навантаження визначальною метою команди платформи.

Одна з найбільших проблем, з якою стикається молода команда платформи, полягає в тому, щоб перейти від активної співпраці до "роботи як послуги". Ваші клієнти почуваються комфортно завдяки досвіду постійного контакту. Складно створити чудову документацію. Складно сказати «ні».

Команди платформ, які працюють у режимі спільної роботи, повинні стежити за зміною викликів масштабування. Як тільки на горизонті з’являється потреба у переході до більш масштабованого підходу без рук, команда платформи повинна почати повідомляти своїм клієнтам про цей перехід. Раннє попередження про те, як зміниться модель взаємодії — і чому — дає командам продуктів шанс підготуватися та почати змінювати свою розумову про модель платформи на щось більш самодостатнє.

Перехід може бути болісним, але коливання погіршує його. Команда з доставки продуктів оцінить чіткі правила взаємодії щодо того, як їхні постачальники платформ підтримуватимуть їх. Крім того, усунення практичної співпраці створює сильну мотивацію вдосконалювати інтерфейси самообслуговування, документацію тощо. Тут діє закон Конвея – перевизначення способу інтеграції команд чинить тиск на те, як інтегруються системи команд.

Команда платформи досягає успіху завдяки співпраці з іншими командами, і ця співпраця може приймати різні форми. Щоб вибрати правильну форму, потрібно враховувати тип роботи на платформі, яку виконує інша команда, і реалістично оцінювати поточний стан обох команд та їхніх систем. Правильний підхід дасть змогу команді платформи розширити адаптацію своєї платформи, але в міру того, як це впровадження зростає, команда також має свідомо переходити до режимів співпраці, які є менш практичними, більш масштабованими та мінімізують когнітивне навантаження для споживачів цієї платформи.

Будь-яка масштабна робота по створенню програмного забезпечення потребує залучення великої кількості людей, а тут одразу постає питання, як розділити їх на ефективні команди. Формування команд, орієнтованих на бізнес-можливості, допомагає в розробці ПО, що буде відповідати потребам клієнтів, але перелік необхідних навичок часто буває завеликий. Командні Топології (Team Topologies) — це модель для опису організації команд розробки ПО, запропонована Метью Скелтоном (Matthew Skelton) і Мануелем Пейсом (Manuel Pais). Вона визначає чотири форми команд і три режими командних взаємодій. Модель заохочує співпрацю, яка дозволяє командам, орієнтованим на бізнес-можливості, процвітати у виконанні своїх цілей із забезпечення постійного потоку цінного програмного забезпечення.

Оригінал: TeamTopologies
Автор: Martin Fowler

Основним типом команди в цій структурі є потокова команда (stream-aligned team), орієнтована на бізнес-можливості, яка відповідає за програмне забезпечення для окремого бізнес напрямку. Це команди, які працюють довго і спрямовують свої зусилля по створенню програмного продукту для збільшення можливостей бізнесу.

Кожна потокова команда має повний стек і повний життєвий цикл: відповідає за інтерфейс, бек-енд, базу даних, бізнес-аналіз, пріоритезацію функцій, UX, тестування, розгортання, моніторинг – увесь комплекс розробки програмного забезпечення. Вони орієнтовані на результат, зосереджені на бізнес-цінності, на відміну від команд, що зосереджені на діяльності і таких функціях, як бізнес-аналіз, тестування або бази даних. Але вони також не повинні бути занадто великими, ідеальний розмір, це команда, яку можна нагодувати двома великими піцами. Велика організація матиме багато таких команд, з різними бізнес-можливостями для підтримки, але спільними потребами, як зберігання даних, мережеві налаштування і можливість моніторингу.

Для невеликої команди важливим є зменшення когнітивного навантаження, щоб вони могли зосередитися на потребах бізнесу, а не на таких питаннях як, наприклад, зберігання даних. Важливою частиною цього процесу є створення платформи для рішення цих нефокусних проблем. Це може бути широко доступна стороння платформа, наприклад Ruby on Rails. Але не для всіх продуктів існує єдина готова до використання платформа, тож команді доведеться знайти та інтегрувати кілька систем. У великій організації також постане питання використання внутрішніх послуг та дотримання корпоративних стандартів.

Цю проблему можна вирішити шляхом створення внутрішньої платформи для організації, яка буде об’єднувати внутрішні та зовнішні служби. Team Topologies називає команду, яка це будує - команда платформи.

Менші організації можуть працювати з єдиної командою платформи, яка створює тонкий шар поверх зовнішнього набору продуктів. Однак для великих платформ потрібно більше людей, ніж можна нагодувати двома піцами. Таким чином, автори переходять до опису групи платформи, що включає декілька команд платформи.

Важливою характеристикою платформи є те, що вона призначена для використання здебільшого в режимі самообслуговування. Потокові команди як і раніше відповідають за роботу свого продукту та керують використанням платформи, не очікуючи детальної співпраці з командою платформи. У структурі командних топологій цей режим взаємодії називається режимом X-як-послуга, при цьому платформа діє як сервіс для потокових команд.

Однак команди платформ повинні самі будувати свої послуги як продукти, глибоко розуміючи потреби своїх клієнтів. Це часто вимагає, щоб вони використовували інший режим взаємодії - режим співпраці. Режим співпраці є більш інтенсивною партнерською формою взаємодії, і його слід розглядати як тимчасовий підхід, доки платформа не стане достатньо зрілою, щоб перейти до режиму X-як-послуга.

Поки що нічого особливо винахідливого модель не представляє. Поділ організацій на команди, орієнтовані на бізнес, і команди технологічної підтримки — це підхід, такий же старий, як корпоративне програмне забезпечення. Останніми роками багато авторів висловлювали важливість того, щоб ці бізнес-команди відповідали за повний стек і повний життєвий цикл. Для мене яскраве розуміння командних топологій зосереджено на проблемі: наявність повноцінних бізнес-команд із повним життєвим циклом означає, що вони часто стикаються з надмірним когнітивним навантаженням, яке суперечить бажанню невеликих команд. Ключовою перевагою платформи є те, що вона зменшує це когнітивне навантаження.

Головний інсайт Командних топологій це зменшення когнітивного навантаженні на потокові команди завдяки використанню платформи.

Це розуміння має глибокі наслідки. Для початку це змінює те, як команди платформ мають думати про платформу. Зменшення когнітивного навантаження клієнтських команд призводить до різних дизайнерських рішень і планів продуктів для платформ, призначених головним чином для стандартизації або скорочення витрат. За межами платформи це розуміння спонукає командні топології до подальшого розвитку своєї моделі, визначивши ще два типи команд.

Деякі потреби вимагають спеціалістів, які можуть витратити багато часу та енергії на опанування теми, важливої для багатьох команд, що вирівнюють потоки. Спеціаліст із безпеки може витрачати більше часу на вивчення питань безпеки та взаємодію із напрямком безпеки, ніж це було б можливо як член команди, що працює в потоку. Такі люди об’єднуються в команди можливостей, роль яких полягає в розвитку відповідних навичок в інших командах, щоб ці команди могли залишатися незалежними та краще володіти та розвивати свої послуги. Щоб досягти цього, робочі групи використовують третій режим взаємодії в командних топологіях. Режим фасилітації включає в себе роль тренера, де команда не існує для написання та забезпечення відповідності стандартам, а натомість для навчання своїх колег, щоб потокові команди стали більш автономними.

Потокові команди несуть відповідальність за весь потік цінностей для своїх клієнтів, але час від часу ми знаходимо технічну спеціалізацію потокової команди, яка є достатньо специфічною, щоб зосередитися на ній окремо. Це веде до четвертого й останнього типу команди: команда складної підсистеми. Метою команди зі складною підсистемою є зменшення когнітивного навантаження потокових команд, які використовують цю складну підсистему. Це вартий розподіл, навіть якщо для цієї підсистеми є лише одна команда клієнтів. Переважно команди зі складними підсистемами прагнуть взаємодіяти зі своїми клієнтами, використовуючи режим X-як-послуга, але їм доведеться використовувати режим співпраці протягом коротких періодів часу.

Командні топології містять набір графічних символів для ілюстрації команд та їхніх взаємовідносин. Наведені тут стандарти відповідають чинним стандартам, які відрізняються від тих, що використовуються в книзі. Недавня стаття детально описує, як використовувати ці діаграми.

Командні топології розроблено з явним визнанням впливу закону Конвея (Conways Law). Прихильники командної топології мають на меті, щоб структура команди сформувала майбутній розвиток архітектури програмного забезпечення у відокремлені компоненти, узгоджені з потребами бізнесу.

Джордж Бокс (George Box) акуратно пожартував: «усі моделі неправильні, деякі корисні». Отже, топології команд неідеальні: складні організації не можна просто розбити на чотири види команд і три види взаємодії. Але такі обмеження роблять модель корисною. Командні Топології — це інструмент, який спонукає людей розвивати свою організацію до більш ефективного способу роботи, який дозволяє потоково вирівняним командам максимізувати свій потік, зменшивши когнітивне навантаження.

Технології постійно стають розумнішими та потужнішими. Але часто в міру їхнього впровадження продуктивність організації замість поліпшення знижується. До цього призводить збільшення складності та когнітивні навантаження розробників. У цій статті наведено фреймворк для максимізації ефективності розробника. Завдяки дослідженням визначено ключові цикли зворотного зв'язку, у тому числі цикли мікрозворотного зв'язку, які розробники виконують 200 разів на день. Їх слід оптимізувати, щоб вони були швидкими, простими та ефективними.

Автор досліджує, як деякі організації використовували ці цикли зворотного зв'язку для підвищення загальної ефективності і продуктивності.

Оригінал: Maximizing Developer Effectiveness
Автор: Tim Cochran

Коли інженерні організації проходять трансформацію, то це і технологічна і культурна трансформація. Наприклад, ці організації можуть намагатися розбити основну монолітну систему на мікросервіси, щоб мати незалежні команди та застосовувати підхід DevOps. Вони також можуть захотіти покращити свої гнучкі та продуктові методи, щоб швидше реагувати на сигнали ринку.

Знову і знову ці зусилля зазнавали невдачі на якомусь етапі шляху трансформації. Менеджери незадоволені затримками та перевитратою бюджету, тоді як технарі намагаються усунути перешкоди з усіх боків. Продуктивність надто низька. Команди паралізовані безліччю залежностей, когнітивним перевантаженням та недоліком знань про нові інструменти / процеси. Обіцянки, надані вищому керівництву щодо нових технологій, не виконуються так швидко, як очікувалось.

Основна причина проблем полягає в тому, що інженерна організація не подбала про надання розробникам ефективного робочого середовища. У ході перетворень вони впровадили надто багато нових процесів, надто багато нових інструментів та нових технологій, що призвело до ускладнення їхніх повсякденних завдань та збільшення супротиву.

Підходи компаній із високою та низькою ефективністю розробки сильно відрізняються.

Найпростіший спосіб пояснити - на прикладі 1 дня з життя розробника:

День із життя у високоефективному середовищі

Розробник:

• перевіряє інструмент керування завданнями, а потім йде на стендап, де чітко розуміє, над чим потрібно працювати.
• зазначає, що середовище розробки було автоматично оновлено, а конвеєри CI/CD мають зелений колір.
• отримує останній код, вносить інкрементну зміну коду, яка швидко перевіряється шляхом розгортання в локальному середовищі та запуском модульних тестів.
• залежить від можливостей іншої команди реалізації своїх завдань. Може знайти документацію та специфікації API через портал для розробників. Все ще є питання, тому йде до чату команди і швидко отримує допомогу від іншого розробника, який надає підтримку.
• зосереджується на своїй задачі протягом кількох годин без перерв.
• робить перерву, п'є каву, гуляє, грає у пінг-понг із колегами.
• фіксує зміну коду, яка потім проходить ряд автоматичних перевірок перед розгортанням у виробничому середовищі. Поступово випускає зміну для користувачів у виробничому середовищі, відстежуючи при цьому бізнес-показники та операційні показники.

Розробник може досягти поступового прогресу за день і щасливим піти додому.

День із життя у малоефективному середовищі

Розробник:

• починає свій день, маючи потребу негайно розібратися з низкою повідомлень про проблеми на продуктивному середовищі.
• перевіряє низку систем журналювання та моніторингу, щоб знайти звіт про помилку, оскільки немає агрегованих журналів по системах.
• працює з операціями на телефоні та визначає, що попередження є хибними спрацьовуваннями.
• очікує відповіді від груп архітектури, безпеки та управління для попереднього завдання, яке завершив.
• день розбитий на безліч зустрічей, багато з яких є статусними.
• відзначає, що попереднє завдання було схвалено, переміщує його в іншу гілку, яка запускає довгий нічний набір тестів E2E, які майже завжди червоні.
• залежить від API іншої команди, але не може знайти поточну документацію. Натомість розмовляє з менеджером проекту в іншій команді, намагаючись отримати запит. Запит на відповідь триватиме кілька днів, тому це блокує поточне завдання.

Можна й надалі продовжувати, але зрештою розробник мало чого досягає, залишається розчарованим та невмотивованим.

Ефективність розробника

Що означає бути ефективним? Як розробник він приносить максимальну користь вашим клієнтам. Це здатність якнайкраще спрямувати свою енергію та інновації на досягнення цілей компанії. Ефективне середовище дозволяє легко впровадити корисне високоякісне програмне забезпечення у продуктивне використання і керувати ним так, щоб розробникам не доводилося стикатися з непотрібними складнощами, що дозволяє зосередитися на завданнях, пов'язаних з додаванням цінності.

У прикладі, який показує малоефективне середовище, все займає занадто багато часу. День розробника складається з нескінченних блокувань та бюрократії. Це схоже на смерть від 1000 порізів. Поступово продуктивність знижується через невелику неефективність, яка має комплексний ефект. Відчуття неефективності поширюється на всю організацію. Інженери зрештою почуваються безпорадними - вони непродуктивні. І, що ще гірше, вони приймають це, спосіб роботи стає загальноприйнятою рутиною, що визначає, як здійснюється розробка. Розробники переживають за безпорадність.

З огляду на те, що у організації, яка забезпечує високоефективне середовище, є почуття миттєвості, все просто та ефективно, і розробники не стикаються з труднощами. Вони витрачають більше часу створення цінності. Саме створення цього середовища без опору та культуру, яка підтримує його, заохочуючи бажання та здатність постійно вдосконалюватися, є найскладнішим для компаній, які проводять цифрову трансформацію.

Організації шукають способи виміряти продуктивність розробників. Звичайний анти-шаблон – дивитися на рядки коду, вихідні дані функції або приділяти занадто багато уваги спробам визначити недостатньо ефективних розробників. Але краще зосередитися на тому, як організація забезпечує ефективне середовище розробки. Продуктивність мотивує розробників. Без тертя вони мають час творчо мислити і виявляти себе. Якщо організації цього не зроблять, то найкращі інженери підуть. Розробник не має причин працювати в неефективному середовищі, коли безліч великих інноваційних цифрових компаній прагнуть найняти сильних технічних фахівців.

Давайте подивимося на приклад компанії, що оптимізувала ефективність розробників.

Приклад: Spotify

Spotify провела дослідження серед своїх інженерів, щоб краще зрозуміти ефективність розробників. У ході цього дослідження вони виявили два ключові висновки:

1. Фрагментація внутрішнього інструментарію. Внутрішня інфраструктура та інструменти Spotify були побудовані як невеликі ізольовані «острови», що призвело до переключення контексту та когнітивного навантаження на інженерів.
2. У Spotify не було централізованого місця для пошуку технічної інформації. Оскільки інформація поширювалася всюди, інженери навіть не знали, де шукати інформацію.

Команда розробників Spotify описує ці проблеми як негативний маховик; порочне коло, коли розробникам надається занадто багато невідомих, змушуючи їх приймати багато рішень ізольовано, що, у свою чергу, посилює фрагментацію та дублювання зусиль і, зрештою, скорочує час безперервного постачання продуктів.

Негативний маховик Spotify

Щоб пом'якшити ці складності, вони розробили Backstage, портал для розробників з відкритим вихідним кодом з архітектурою плагінів, щоб допомогти уявити всі продукти інфраструктури в одному місці, пропонуючи узгоджений досвід розробника та відправну точку для інженерів, щоб знайти необхідну їм інформацію.

З чого почати?

Компанії з високоефективним середовищем повністю прийняли культуру DevOps, безперервне постачання та продуктове мислення. Цілком розумно, що більшість компаній знаходяться на шляху до досягнення цього середовища. Вони прочитали звіт Accelerate та State of DevOps. Вони знають, який тип організації хочуть побудувати. Чотири ключові показники (час виконання, частота розгортання, середній час відновлення та відсоток збоїв змін) є відмінними показниками продуктивності DevOps.

Один із способів поглянути на показники DevOps - це індикатори. Це корисні виміри, що дозволяють зрозуміти, де ви знаходитесь, і вказати, коли потрібно зробити роботу, щоб з'ясувати, які речі слід зробити компанії, щоб стати кращими. В ідеалі хотілося б визначити показники ефективності нижчого рівня, які є більш дієвими. Є кореляція із показниками вищого рівня. Це також слід поєднувати з іншими джерелами досліджень, такими як опитування задоволеності розробників.

Існує безліч хороших порад, практик, інструментів і процесів, які можна використовувати для поліпшення. Дуже важко зрозуміти, що робити. Але існує низка ключових циклів зворотного зв'язку з розробниками. Виміряйте довжину циклу зворотного зв'язку, обмеження та кінцевий результат. Коли вводяться нові інструменти та методи, ці метрики можуть ясно показати, якою мірою ефективність розробника підвищується або, принаймні, не гірша.

Цикли зворотнього зв'язку

Ключові цикли зворотного зв'язку наступні:

Не кожній компанії потрібно, щоб всі цикли зворотного зв'язку були із високою ефективністю, але вони встановлюють конкретні цілі прийняття рішень. Інженерні організації повинні проводити дослідження у своєму конкретному контексті, щоб з'ясувати, які цикли та показники є важливою технологічною стратегією.

Корисно подивитися, які методи були використані для оптимізації циклів зворотного зв'язку та який шлях компанії пройшли для цього. Ці тематичні дослідження можуть дати безліч ідей для застосування у вашій організації.

Цикли зворотного зв'язку під час розробки нової функціональності

На схемі вище показано спрощене уявлення про те, як розробники використовують цикли зворотнього зв'язку під час розробки. Ви можете бачити, що розробник перевіряє відповідність своєї роботи специфікаціям та очікуваним стандартам на кількох етапах шляху. Слід зазначити такі ключові спостереження:

• Розробники запускатимуть цикли зворотного зв'язку частіше, якщо вони коротші.
• Розробники будуть видавати більший результат, якщо вони бачитимуть реальну цінність у своїх діях, а не суто бюрократичні накладні витрати.
• Більш ранні та частіші перевірки скорочують доопрацювання надалі.
• Цикли зворотного зв'язку, які легко інтерпретувати у результати, скорочують обмін даними та когнітивні витрати.

Коли організаціям не вдається досягти цих результатів, проблеми швидко посилюються. Розробники витрачають багато зусиль та часу на очікування, пошук чи спроби зрозуміти результати. Це призводить до значних затримок у розробці продукту, що проявляється у нижчих індекаторів за чотирма ключовими показниками (зокрема, частотою розгортання та часом виконання).

Представляємо цикли мікро зворотного зв'язку

Потрібно закріпити основи того, що розробники роблять 10, 100 чи 200 разів на день. Їх називають цикли мікрозворотного зв'язку. Це може бути запуск модульного тесту під час виправлення помилки або зміна коду, перевірка у локальному середовищі чи середовищах розробки. Це також може бути оновлення даних у середовищі. Розробники, якщо вони наділені повноваженнями, природно оптимізуються, але часто циклами мікрозворотного зв'язку нехтують. Ці цикли навмисно короткі, тому доводиться мати справу з дуже короткими проміжками часу.

Цикли мікро-зворотного зв'язку об'єднуються, щоб впливати на більші цикли зворотного зв'язку.

Керівництву складно пояснити, чому потрібно зосередитись на таких дрібних проблемах. Чому потрібно витрачати час на оптимізацію етапу компіляції з двохвилинним часом виконання, щоб натомість він займав лише 15 секунд? Набагато простіше зрозуміти, навіщо оптимізувати те, на що йде два дні. Адже для цього необхідно виконати обсяг робіт, можливо розділити систему на незалежні компоненти.

Але ці дві хвилини можуть швидко накопичуватися та перевищувати 100 хвилин на день. Ці невеликі паузи – можливість втратити контекст та зосередитися. Їх достатньо, щоб розробник відволікся, вирішив відкрити електронний лист або піти випити кави, так що тепер він відволікається і не в стані потоку. Існують дослідження, які показують, що може знадобитися до 23 хвилин, щоб повернутися в стан потоку і повернутися до високої продуктивності.

Насправді, розробники компенсують це тим, що заповнюють ці моменти бездіяльності корисними речами. Вони можуть виконувати два завдання, і вони можуть перемикатися між ними. Вони можуть знизити частоту компіляції за рахунок пакетування змін. Але обидва ці фактори призведуть до затримки інтеграції коду та часу розробки.

Як далеко слід заходити до оптимізації? Коли вистачить? Уявіть, що тепер є ця зміна до 15 секунд, але ми вважаємо, що можемо скоротити її до трьох секунд. Чи варто починати? Це залежить від того, наскільки складно внести цю зміну і який вплив вона принесе. Якщо ви можете розробити інструмент або можливість, які прискорять роботу 10 команд, це того варте. Тут у гру вступає платформне мислення, а не оптимізація для окремих команд.

Розподілені системи є особливою проблемою. Існує безліч вагомих причин для поділу систем на різні одиниці, що розгортаються (зазвичай мікросервіси). Однак розподілені системи також ускладнюють багато речей, включаючи ефективність для розробників. Іноді команди можуть оптимізуватись для командної автономії або продуктивності під час виконання, але вони приносять у жертву ефективність розробника, тому що вони не вкладаються у підтримку швидких циклів зворотного зв'язку. Це дуже поширена ситуація, з якою стикаються компанії.

Організаційна ефективність

Високоефективні компанії спроектували свою інженерну організацію так, щоб оптимізувати ефективність та забезпечити зворотний зв'язок. Лідерство з часом створює культуру, яка дає розробникам можливість поступово покращувати ці цикли зворотного зв'язку.

Все починається з визнання керівництвом того, що технології – та усунення тертя між командами розробників – життєво важливі для бізнесу. Це проявляється по-різному.

Технічні керівники постійно вимірюють та переглядають ефективність. Високоефективні організації створили основу для прийняття рішень на основі даних шляхом відстеження чотирьох ключових показників та інших точок даних, важливих для їхнього контексту. Ця культура починається на виконавчому рівні і доводиться до решти організації.

На додаток до показників, вони створюють відкритий форум, щоб слухати окремих учасників, які щодня працюють у середовищі. Розробники знатимуть проблеми, з якими стикаються, і вони мають багато ідей, як їх вирішити.

На основі цієї інформації інженерні менеджери можуть визначити пріоритети для інвестицій. Великі проблеми можуть вимагати, відповідно, великих програм модернізації для вирішення проблеми поганого досвіду розробників. Але часто річ у тому, щоб дати командам можливість постійно вдосконалюватись.

Ключовий принцип - використовувати досвід розробника. Досвід розробників означає, що технічні можливості повинні створюватися з використанням тих самих підходів, які використовуються для розробки продукту кінцевим користувачам, із застосуванням тих же досліджень, визначення пріоритетів, мислення, орієнтованого на результат, та механізмів зворотного зв'язку зі споживачами.

У високоефективних організаціях є політики, згідно з якими команди мають вносити додаткові технічні покращення та керувати технічним боргом. Між розробниками та менеджментом продукту має бути здорове обговорення на основі даних. Високоефективні організації також надають можливість розробникам вводити нововведення; коли їхні команди мають чіткі цілі і чітке уявлення про вузькі місця, розробники можуть творчо підходити до вирішення проблем. Ці організації також створюють способи, що дозволяють кращим ідеям «випливати нагору», а потім подвоювати їх, використовуючи дані для оцінки того, що є найкращим.

Після зобов'язань, вимірювань та розширення можливостей настає масштабування.

За певного розміру організації необхідно підвищити ефективність за рахунок економії на масштабі. Організації роблять це, застосовуючи платформне мислення - створюючи внутрішню платформу, спеціально орієнтовану на підвищення ефективності. Вони інвестують в інженерні команди, які створюють технічні можливості підвищення ефективності розробників. Вони розглядають інші команди розробників як своїх споживачів, а послуги, що надаються ними, розглядаються як продукти. У команд є технічні менеджери з продукту та показники успіху, пов'язані з тим, як вони впливають на команди-споживачі. Наприклад, група розробників платформи, сфокусована на спостереженні, створює можливості моніторингу, реєстрації, оповіщення та відстеження, щоб групи могли легко відслідковувати стан своїх сервісів та налагоджувати проблеми у своєму продукті.

Потреба в управлінні, як і раніше, залишається пріоритетом. Однак це не слід сприймати негативно, оскільки її застосування у високоефективних організаціях сильно відрізняється. Вони переходять від централізованих процесів до спрощеного підходу. Йдеться швидше про вибудовування "перил", для підштовхування команд у правильному напрямку, а не про тривалі підходи до процесу затвердження. Управління може грати вирішальну роль ефективності, якщо воно реалізується у вигляді:

• Постановки чітких інженерних цілей
• Визначення способів взаємодії команд та служб один з одним
• Заохочення корисної експертної оцінки
• Впровадження найкращих практик у можливості платформи
• Автоматизація управління за допомогою функцій архітектурної придатності

Власне, ефективні організації скорочують цикли зворотного зв'язку з управління.

Приклад: Etsy

Etsy була одним із піонерів руху DevOps. Її керівники працювали над впровадженням ефективності розробників у свою культуру, вірячи в те, що швидке просування є одночасно технічною та бізнес-стратегією. Вони активно оцінюють свою здатність швидко та безпечно вводити у виробництво цінні продукти та коригують свої технічні вкладення, щоб виправити будь-які перешкоди чи затримки.

Одним із ключових показників Etsy є час виконання замовлення, яке вимірюється, відстежується та відображається в реальному часі у всіх офісах компанії. Коли виконання замовлення перевищить певний ключовий поріг, група розробки релізів постарається знизити його до розумного рівня. Їхній технічний директор Майк Фішер говорить про те, що інженери Etsy «безстрашні», щоб швидко рухатися вперед, але мають сітку страхування, щоб пробувати нові речі.

Швидке розгортання програмного забезпечення – це лише половина справи. Щоб програмне забезпечення було справді ефективним, воно має бути цінним для споживачів. Etsy робить це, використовуючи підхід, що базується на даних, де кожна функція має вимірні KPI.

Зміни коду проходять ряд перевірок, щоб розробники були впевнені, що зміна відповідає SLA Etsy щодо продуктивності, доступності, частоти відмов тощо. Після того, як зміна знаходиться у продуктивному використанні, платформа Etsy для експериментів може збирати показники поведінки користувачів. Команди використовують метрики для ітерації продуктів, оптимізуючи пов'язані з ними ключові показники ефективності та задоволеність користувачів. Якщо зрештою виявиться, що зміна не становить цінності, вона буде усунена, що дозволить уникнути технічного боргу.

У Etsy є поточна ініціатива, яка ставить на чільне місце досвід розробників. Він складається з чотирьох основних стовпів:

4 стовпи досвіду розробників

Допоможіть мені створити продукти гарантує, що ми маємо необхідні абстракції, бібліотеки та будівельні блоки, щоб інженери по продукту могли виконувати свою роботу.

Допоможіть мені розробляти, тестувати та розгортати, орієнтовані на інженерів по продуктах, зокрема, на самі середовища розробки (IDE, лінтери), модульне / інтеграційне тестування, шаблони, а також на інструменти та процеси розгортання.

Допоможіть мені працювати з даними орієнтована на фахівців з даних та інженерів з машинного навчання, забезпечуючи інтуїтивно зрозуміле налаштування всієї екосистеми інженерії даних, простоту тестування та розгортання.

Допоможіть мені зменшити важку працю орієнтована на чергових інженерів, щоб переконатися, що ми створюємо виробничі системи з належним рівнем автоматизації, у нас є Runbook і документація, які легко доступні та актуальні, а також ми відстежуємо та розставляємо пріоритети зі скорочення трудомістких дій.

Ця політика є справжньою відданістю керівництва Etsy своїм розробникам. Вони постійно перевіряють свою ефективність, відстежуючи метрики, включаючи 4 ключові індикатори, і проводять щомісячні опитування з розробниками, щоб отримати Індекс Споживчої Лояльності (NPS).

Ми в ITsmartfelx захоплені технологіями. Ми їх створюємо, вивчаємо, тестуємо та постійно прагнемо покращувати.
У ITsmartfelx R'n'D група технологічних експертів розвиває Радар Технологій. Вони відстежують та обговорюють глобальні технологічні тенденції, які суттєво впливають на нашу галузь. Радар фіксує результати обговорень та поточного стану у форматі, який становить цінність для широкого кола зацікавлених сторін, від розробників до ІТ-директора.

Про Радар Технологій

Радар Технологій має графічне подання, елементи розділені на 4 сегменти:

• техніки та принципи
• мови та фреймворки
• платформи та інфраструктура
• інструменти

Залежно від нашого поточного ставлення елемент потрапляє в одне з 4-х кілець:

Використовуємо (Adopt)

Використовуємо при необхідності і вже застосовуємо в кількох проектах у продуктиві.

Тестуємо (Trial)

Одна з команд вже використовує цю технологію на практиці та інші можуть використовуватись для нових проектів.

Дивимось (Assess)

Детально вивчаємо, щоб оцінити, як застосування елемента чи технології вплине на наші проекти. На практиці поки що не використовуємо.

Уникаємо (Hold)

При необхідності продовжуємо використовувати, але з обережністю та намагаємось замінити на альтернативні технології. Не використовуємо в нових проектах.

ITsmartfelx Радар Технологій 2023-05

Техніки та Принципи (Techniques and Principles)

Використовуємо:

1. Agile practices
2. API-first approach
3. Business Process Model and Notation (BPMN)
4. Continuous Delivery
5. Continuous Integration
6. DevOps practices
7. Diagrams as code
8. Documentation as code
9. GoF patterns
10. KISS
11. Lean development
12. Microservices architecture
13. Microservices patterns
14. oAuth 2.0
15. SOLID
16. TMForum Open API
17. TMForum Open Digital Architecture (ODA)
18. Unified Modeling Language (UML)
19. Use cases
20. User stories
21. Zero deployment downtime

Тестуємо

22. Distroless Docker images
23. GitOps practices
24. Kanban method

Дивимось

25. Micro frontends
26. Zero trust architecture

Уникаємо

27. Micro frontend anarchy

Мови та Фреймворки (Languages and Frameworks)

Використовуємо:

28. Angular
29. Camunda platform
30. Groovy
31. Hibernate
32. Java 17 LTS
33. Liquibase
34. Node.js
35. REST assured
36. SASS
37. Selenide
38. Spring
39. Spring Boot
40. TypeScript

Тестуємо

41. Clojure
42. Kotlin
43. Spring WebFlux
44. storybook.js
45. Vue.js

Дивимось

46. Camel
47. Go
48. LLaMA

Уникаємо

49. AngularJS
50. Java 11 LTS
51. Java 8
52. jQuery
53. Kotlin Multiplatform Mobile (KMM)
54. Lua
55. PHP
56. Scala
57. Swift

Платформи та Інфраструктура (Platforms and Infrastructure)

Використовуємо:

58. Docker
59. ElasticSearch
60. Fluent Bit
61. Fluentd
62. Grafana
63. Kafka
64. Kibana
65. Kubernetes
66. Longhorn
67. Minio
68. Nginx
69. Oracle RDBMS
70. Prometheus
71. Rancher
72. Redis
73. Vector
74. XM^online

Тестуємо

75. PostgreSQL
76. Vodafone IaaS

Дивимось

77. Apache Flink
78. Apache Ignite
79. Apiman
80. Cassandra
81. Cilium service mesh
82. Free5GC
83. Gravity API gateway
84. Istio
85. Kong API gateway
86. Open5GS
87. srsRAN
88. Vault
89. WSO2 API Manager

Уникаємо

90. Consul
91. Docker Swarm
92. Loki
93. MongoDB
94. Zabbix

Інструменти (Tools)

Використовуємо:

95. Ansible
96. Atlassian Confluence
97. Atlassian Jira
98. Figma
99. GitLab
100. GitLab CI
101. Gradle
102. Helm
103. JHipster
104. JMeter
105. Microsoft Office 365
106. Microsoft Teams
107. Mockserver
108. Nomnoml
109. PlantUML
110. Selenoid
111. Sentry
112. sequencediagrams.org
113. SonarQube
114. Swagger
115. Terraform

Тестуємо

116. Artillery
117. Gatling

Дивимось

118. Argo CD
119. Flux CD
120. k6
121. OpenTelemetry

Уникаємо

122. Jenkins
123. Maven
124. Rocket.chat
125. Slack

Наприклад розповім застосування Діаграм як кода:

Використовуємо - Діаграми як код (Diagrams as code)

Ми бачимо все більше інструментів, які дозволяють створювати програмну архітектуру та інші діаграми у вигляді коду. Використання цих інструментів має ряд переваг перед іншими підходами, включаючи простий контроль версій та можливість генерувати DSL із багатьох джерел. Інструменти в цій галузі, які нам подобаються:

• nomnoml
• sequencediagram.org
• PlantUML

Висновок

Проста ідея Радара від ThoughtWorks дозволила синхронізувати команди по поточному стеку технологій, а також відкриває напрямки для розвитку.

Ось ще посилання на Радари Технологій з цікавою візуалізацією від інших компаній:

• Zalando Tech Radar
• AOE
• World Government Summit
• The Software House
• Get Your Guide

Посібник Чемпіонів Безпеки - це проект, започаткований Олександром Антухом (Alexander Antukh) у рамках підготовки до презентації "Security Champions 2.0" на конференції OWA Bucharest AppSec Conference 2017. У ньому описуються основні кроки для швидкого створення програми Чемпіонів Безпеки незалежно від розміру компанії та зрілості існуючих безпекових процесів.

Хто такі Чемпіони Безпеки?

Згідно з визначенням OWASP, Чемпіони Безпеки – це «активні члени команди, які можуть допомогти прийняти рішення про те, коли задіяти групу безпеки». Вони виступають як основний елемент процесу забезпечення безпеки в рамках продукту або послуги та виконують роль єдиної точки контакту (SPOC) у команді.

Які перваги Чемпіони приносять компанії?

Основні переваги наявності команди Чемпіонів Безпеки:

• Маштабування безпеки за допомогою кількох команд
• Залучення людей, не пов'язаних з безпекою
• Створення культури безпеки

Чемпіони Безпеки - посібник

Шість простих кроків із поясненнями для кожного кроку. Кожен крок включає загальні рекомендації, посилання на джерела та особистий досвід.

1. Визначте команди

Першим кроком у запуску вашої власної програми «Чемпіони Безпеки» є визначення масштабу проблеми, з якою доведеться працювати. Оскільки ми прагнемо більшого охоплення та поширення безпеки, надзвичайно важливо записати це і зберігати в загальновідомому та доступному місці. Хорошим початком будуть індивідуальні співбесіди з власниками продуктів та провідними розробниками.

Типові питання, які ви можете поставити:

• скільки команд працюють над продуктом
• які технології (мови програмування, фреймворки) вони використовують
• де зберігається код та документація
• які автоматизовані інструменти та зовнішні / внутрішні сервіси використовуються для розробки та тестування
• який зараз процес перевірки коду (включаючи перевірку коду безпеки), і хто в ньому бере участь
• чи є інші дії, пов'язані з безпекою продукту, крім перевірки коду
• який календар випуску / цикл / поточний етап продукту
• які найчастіше використовувані канали зв'язку до роботи над продуктом
• як зазвичай повідомляють про проблему / помилку безпеки продукту, і хто про це піклується

Результатом цієї вправи має бути сторінка внутрішньої вікі з таблицею, наприклад:

2. Визначте роль

Суть цього кроку – сформулювати реальні цілі та підготувати чіткий опис ролей для майбутніх Чемпіонів Безпеки. Хоча вимір поточного стану безпеки в групах частково виконано на попередньому кроці, докладний опис побудови глобальної стратегії безпеки AppSec виходить за рамки цієї інструкції - зверніться до існуючих фреймворків, таких як OWASP SAMM, який забезпечує простий та зрозумілий спосіб досягнення цієї мети.

Після визначення програми AppSec та глобальних цілей дуже важливо розрізняти дії, що найбільш підходять для Чемпіонів Безпеки, та співвідносити їх з цією метою. Залежно від поточного стану безпеки у вашій організації, це може включати деякі або всі з наведених нижче:

• проводити та/або організовувати перевірки безпеки в команді
• просувати передовий досвід
• піднімати питання про ризики у існуючому та новому коді
• створювати моделі загроз для нових функціональностей
• проводити та/або організовувати автоматичне сканування
• дослідити звіти про помилки
• брати участь у дослідницьких активностях

Більш детально дії перераховані в результатах сесії Чемпіонів Безпеки на саміті OWASP 2017. Пам'ятайте, що дії можуть поступово розвиватися, пристосовуючись до середньострокової стратегії безпеки!

3. Призначте Чемпіонів

Отже, ролі визначені, тепер настав час призначати Чемпіонів. Для того, щоб цей крок пройшов гладко, спочатку необхідно отримати схвалення керівництва на всіх рівнях – від вищого керівництва та власників продукту до безпосередніх менеджерів команди. Незважаючи на те, що це класичний підхід «згори донизу», це надзвичайно важлива частина, оскільки вона гарантує, що найгірший аргумент, який ви можете почути: «Я не мав часу на безпеку», буде виправлений. Зробіть презентацію певних ролей, переваг для команди та зразкового часу, який Чемпіони витратить на завдання безпеки – 20% має бути достатньо для початку.

Після схвалення наступним кроком буде визначення потенційних Чемпіонів. Сядьте разом із менеджером команди, виберіть кандидатів та проведіть міні-інтерв'ю з кожним із них. Пам'ятайте – справа не у призначенні, а у висуванні! Опишіть роль, очікування та стратегію та покажіть їм особисті переваги від статусу Чемпіона:

• саморозвиток та вміння по-іншому дивитися на речі
• підвищення вартості на ринку
• поліпшення якості продукту
• відвідування конференцій з безпеки
• стати важливою частиною мета-команди безпеки
• веселитися :)

У гіршому випадку попросіть менеджера команди допомогти знайти його – хоча, сподіваюся, ви отримаєте Чемпіонів одразу після першої презентації.

Останнім кроком на цьому етапі буде офіційне призначення - додайте його на сторінку мета-групи безпеки, замінивши тимчасовий «контакт служби безпеки» на «Чемпіон безпеки», придумайте якусь «відзнаку», наприклад [кружки](https://raw .githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/bb919b1d48243743bb94e2a6708dba8ad4f3e249/content/2.Risk-workflow/Security-champions/If-you-doimage ampion-mug.jpg ), і познайомте новачка з іншими.

4. Налаштуйте канали зв'язку

Призначені Чемпіони не можуть діяти власними силами, і найкраще це працює, коли вони дійсно відчувають командний дух, тому наступним кроком буде налаштування каналів зв'язку. Залежно від корпоративної культури це може бути:

• приватні канали Slack/IRC
• команди Keybase
• групові чати Skype
• групи Yammer
• Списки поштових розсилок

Насправді чим більше, тим краще - просто переконайтеся, що є простий спосіб поширити важливу інформацію і отримати відгуки. Крім того, налаштуйте періодичну синхронізацію, щоб бачити, як ідуть справи, і разом коригувати короткострокові цілі. Для початку підійдуть зустрічі раз на два тижні.

5. Створіть міцну базу знань

Основна ідея – внутрішня база знань має бути основним джерелом відповідей на питання, пов'язані з безпекою. Крім сторінки мета-команди, яка дозволяє будь-кому швидко знайти потрібний контакт, наступні сторінки виявляться дуже корисними:

• Глобальна стратегія безпеки
• Чітко визначені ролі та процедури безпеки
• Найкращі практики безпечної розробки
• Рекомендовані криптоалгоритми
• Опис загальних ризиків та вразливостей
• Політика паролів

Особливу увагу слід приділяти простим і зрозумілим контрольним спискам, оскільки це найпростіший спосіб розпочати роботу. Приклади контрольних списків:

• Контрольні списки безпеки для веб та мобільних пристроїв
• Контрольний список безпеки сторонніх бібліотек та систем
• Контрольний список безпеки інтерфейсу користувача
• Контрольний список конфіденційності

Хоча створення всього з нуля може виявитися стомливим завданням, існує низка проектів з відкритим вихідним кодом, які можуть значно полегшити ваше життя. Проекти OWASP, такі як Security Knowledge Framework, ASVS та MASVS, а також найкращі галузеві практики (наприклад, стандарти безпечного кодування CERT CERT+Coding+Standards)) стануть чудовою відправною точкою для підвищення вашої бази знань та основою для кількох перших внутрішніх семінарів.

6. Зберігайте зацікавленість

Для створення безперервної та успішної екосистеми Чемпіонів Безпеки дуже важливо постійно підтримувати їх та надавати навчальні матеріали. Нижче ви можете знайти кілька способів підтримати інтерес Чемпіонів та допомогти їм розвиватися як професіонали в галузі безпеки.

Майстер-класи та тренінги

Проводьте періодичні семінари для команд, пояснюйте стратегію, просувайте передовий досвід або просто діліться останніми новинами зі світу безпеки. Організуйте інтерактивну вікторину, оголосіть «Хакерський четвер» або почніть «Місяць помилок». Поговоріть з Чемпіонами та разом вирішите, який формат вам найбільше підходить. Незалежно від того, який формат ви виберете, це, ймовірно, найважливіший момент у всьому посібнику. Підтримуйте їхню мотивацію, і ви дуже скоро будете приємно здивовані!

Регулярні інформаційні бюлетені

Ділиться останніми новинами в галузі безпеки через встановлені канали зв'язку (наприклад, [тижневі збірки з проблем безпеки Ezine] (https://github.com/Simpsonpt/AppSecEzine)). Крім того, почніть щомісячні інформаційні бюлетені з безпеки з оновленнями команд, планами, зізнаннями за хорошу роботу та будь-якою іншою актуальною та цікавою інформацією – це не лише привабить ще більше Чемпіонів, а й стане гарною контрольною точкою для вашої програми безпеки.

Простір Чемпіонів безпеки

Створіть окремий простір у внутрішній wiki та додайте туди спеціальні сторінки, такі як:

• Календар конференції (почніть з цього)
• бібліотека хороших книг та статей з безпеки (почніть з цього)
• слайди з відвіданих конференцій (або почніть з цього)
• «кімнати для ідей та покращень»

Місцеві збори OWASP

Почніть місцеві збори або приєднайтесь до існуючих та запросіть Чемпіонів навчатися та ділитися! Це ще один чудовий спосіб поспілкуватися, зустрітися та обговорити актуальні проблеми, новини та ідеї.

Висновок

Якщо ви виконали всі кроки, тепер у вас має бути працююча програма Чемпіонів Безпеки.

Найкраще в екосистемі Чемпіонів – це не лише масштабованість, а й «побічні вигоди», які отримує ваша організація, головною з яких є розвиток культури безпеки. Згодом вони почнуть пропонувати свої власні ініціативи, брати участь у дослідженнях та розробках та проводити семінари з конкретних продуктів, залучаючи все більше і більше людей і роблячи безпеку «справою кожного», як і має бути.

У єгипетських готелях хороший інтернет традиційно тільки в зоні ресепшн, тому постало питання придбання місцевої сім-карти.

В аеропорту Хургади пропонують карту на 30Гб інтернету за 35$ та на 10Гб - за 17$ з тарифним планом Tourist line. Придбати можна на стійці на виході з аеропорту. При собі обов'язково мати паспорт.

Готельний гід запропонував картку на 36Гб за 32$. Тарифний план Flex 25 та трьома пакетами по 12Гб.

Не забувайте - у більшості телефонів, щоб витягнути сім-карту, потрібен ключ із комплекту або тонкий гострий предмет, наприклад скріпка.

Вставляємо карту, отримуємо вхідні SMS з налаштуваннями та інформацією про тариф. На сайті можна переглянути деталі тарифного плану.

У Play Market є 8 мобільних застосунків, мене в першу чергу цікавило програми самообслуговування Ava Vodafone і його функціональність.

Швидкість завантаження майже 13Мб/с. Інтернет готелю видавав не більше 2Мб/с.

Після запуску застосунка Ava Vodafone пропонується автентифікація на основі мережі. Достатньо просто вимкнути WiFi та використовувати передачу даних через мережу оператора. На жаль не вдалося перевірити як це працює у них (HTTP або HTTPS).

Головний екран містить нижнє меню та набір карток з основними віджетами та переходами на категорії.

Відразу запропонували отримати ще 400Мб, чим я і скористався.

Поточний баланс, можливість поповнити кредитною карткою. Інтернет пакети можна перевірити окремо та замовити додатково. Також можна настроїти дію для завершення пакетів, наприклад автоматичне продовження.

Flex - тарифний пакет зі своєю "валютою", яку можна витрачати на базові та додаткові сервіси.

Є також можливість об'єднуватись у команди, але для туриста ця функціональність буде некорисною.

Можливість настроїти пакети під свої потреби. Вибираємо тип, кількість, бачимо вартість та замовляємо.

Додаткові пропозиції вийшли недоступними.

Профіль: ім'я вже заповнено, номер телефону, вибір мови інтерфейсу, кредитні картки. Історія та поштова скринька виявилися порожніми.

Vodafone Cash – фінансові послуги. Саму функціональність скріншотити не вдалося, оскільки стоїть захист. Як на мене – правильно.

Інформація про роумінг у додатку та на сайті з можливістю дозамовити спеціальні пропозиції.

З додаткової функціональності є ще чат бот, але насправді виявилося, що це вибір пунктів з меню. Та й щоб замовити/змінити/відмовитися потрібно потім окремо посилати USSD команди.

Традиційний контент послуги на основі нотифікацій. Але деталей щодо них немає.

Тільки перша SMS прийшла англійською, всі інші, на жаль, були арабською. Хоча в додатку була обрана англійська.

Висновок

Купівля місцевої карти себе цілком виправдала. Звичайний готельний інтернет не витяг би повноцінний робочий процес з відеодзвінками та роботою через VPN.

Крім того, у поїздці на південь країни я не лише користувався інтернетом сам, а й організував роздачу на 5 пристроїв.

Майже у всіх населених пунктах покриття 4G (карта на базі інформації GSMA).

Щоб досягти успіху в DevOps, команди використовують багато різних інструментів. Ось чому різні DevOps метрики є важливими для різних команд розробників. Наводимо список часто використовуваних.

Оригінал: 13 DevOps Metrics for Increased Productivity
Автор: Sara Miteva

DevOps підвищує швидкість та якість доставки програмного забезпечення за рахунок низки практик, заснованих на гнучкому мисленні. Коли ви згадуєте DevOps, на думку спадають терміни: безперервна інтеграція, безперервна доставка та розгортання, автоматизація та моніторинг.

DevOps означає різні речі для різних команд. Деякі команди займаються автоматизацією, тоді як інші роблять щось вручну і вважають, що вони займаються DevOps. Деякі сприймають його як культуру та спосіб мислення.

Оскільки в основі DevOps лежить безперервна і швидка доставка коду, дуже важливо діяти також швидко, без серйозних помилок. Тому так важливо відстежувати DevOps метрики, які можуть допомогти вам у цьому.

Щоб досягти успіху в DevOps,команди використовують безліч різних інструментів. Саме тому різні показники DevOps є важливими для різних команд розробників.

Отже, перш ніж розпочати роботу з DevOps, ваша команда має визначити, що для неї означатиме DevOps. Більше того, команди також повинні визначати свої найбільші DevOps проблеми. Тоді їм буде легше вирішити, які метрики їм потрібно відстежувати активніше, щоб покращити та створити якісніший процес доставки програмного забезпечення.

Ось критичні метрики DevOps, які вважаються важливими для більшості команд:

Частота розгортання (Deployment Frequency)

Важливо розвивати та підтримувати конкурентну перевагу, щоб пропонувати оновлення, нові функції та технічні покращення з вищим рівнем якості та точності. Збільшення інтенсивності доставки сприяє більшій гнучкості та відповідності мінливим вимогам споживачів.

Метою має бути якнайчастіше розгортання невеликих систем. Дрібні зміни набагато зручніші для тестування та розгортання програмного забезпечення.

Регулярне вимірювання частоти розгортання дозволить відразу зрозуміти, які поліпшення успішніші і які сегменти вимагають змін. Швидке падіння частоти може вказувати на те, що інші завдання або дії, які виконуються вручну, порушують робочий процес. Для стійкого зростання та розвитку оптимальні індикатори частоти розгортання, що передбачають незначні, але постійні зміни.

Зробивши тестування більш керованим, можна виміряти як виробничі, так і невиробничі розгортання. Таким чином, ви зможете визначити частоту розгортань для контролю якості та оптимізувати їх для ранніх та невеликих розгортань.

Час розгортання (Deployment Time)

Цей показник вимірює, скільки часу потрібно для розгортання. Хоча спочатку це може здатися недоречним, час розгортання є одним з показників DevOps, який може вказувати на потенційні проблеми. Наприклад, якщо розгортання займає годину, щось негаразд. Ось чому краще зосередитися на невеликих, але частіших розгортаннях.

Відсоток успішно пройдених автоматичних тестів (Percentage of Automated Tests Pass)

Рекомендується, щоб команда ефективно використовувала модульне та end-to-end тестування для максимального збільшення швидкості. Оскільки DevOps залежить від автоматизації, корисна метрика DevOps - це вимір того, наскільки добре працюють автоматизовані тести. Корисно знати, скільки коригування коду призводить до збою тестів.

Коміти коду (Code Commits)

Ця метрика підраховує кількість коммітів, зроблених командою щодо програмного забезпечення до його впровадження у продуктивне використання. Це є мірою як швидкості розробки, і точності коду. Команда повинна вигадати стандартний набір кодових коммітів, яким повинен слідувати кожен член команди.

Велика кількість комітів може означати погану якість коду або відсутність чітких цілей розробки. З іншого боку, коли число нижче стандартного діапазону, команді може невистачати продуктивності чи хорошої організації. Необхідно з'ясувати причину падіння чи збільшення кількості коммітів, щоб зберегти ефективність та темп проекту, зберігаючи при цьому максимальне задоволення серед членів команди.

Швидкість усунення дефектів (Defect Escape Rate)

Незалежно від того, наскільки ви досвідчені в DevOps, трапляються помилки, особливо коли ви часто вносите зміни. Розробка програмного забезпечення передбачає експериментування, і в рамках цього процесу завжди слід передбачати помилки.

Метрика швидкості усунення дефектів показує вашу здатність виявляти дефекти програмного забезпечення, перш ніж вони надійдуть на продуктивне оточення. Це особливо важливо, якщо ви хочете швидко доставити код. Щоб досягти цієї мети, необхідно ефективно виявляти дефекти.

Вартість (Costs)

Хоча хмарні рішення чудово підходять для скорочення витрат на інфраструктуру, деякі незаплановані помилки та події можуть призвести до дуже високих витрат. Ось чому слід зосередитись на визначенні зайвих витрат та їх скороченні. Візуалізація джерел ваших витрат може відіграти велику роль у розумінні того, за які дії ви платите найдорожче.

Невдалі розгортання та здоров'я оточень (Failed Deployments and Environment Health)

Розгортання часто викликають проблеми у ваших користувачів, а іноді нам доводиться скасовувати невдалі розгортання. Ми цього не плануємо, але маємо бути готовими до такої ситуації. Часто невдалі розгортання є індикаторами стану оточення, що дозволяє нам перейти до наступного показника.

Час до виявлення проблем (Time to Detection)

Хоча скорочення чи навіть усунення невдалих змін є оптимальним підходом, важливо швидко виявляти помилки, якщо вони виникають. Час, необхідний для виявлення проблем, вказує на адекватність поточних заходів реагування. Тривалий час виявлення може спричинити обмеження, які порушують весь робочий процес.

Незапланована робота (Unplanned Work)

Кількість часу, який ви витратили на завдання, яких не було в початковому плані. У стандартних проектах коефіцієнт незапланованих робіт (UWR) не повинен перевищувати 25%. Високе значення UWR може виявити витрачені зусилля на непередбачені помилки, які, очевидно, не були помічені на початку робочого процесу. Разом із частотою переробок (RWR), яка стосується спроби виправити проблеми, викладені в заявках, UWR також є важливим показником.

Середній час до відмови (Mean Time to Failure - MTTF)

MTTF - це середній час, протягом якого несправна система зможе працювати до виходу з ладу. Тривалість вважається від моменту початку роботи програми або виправлення останньої критичної проблеми до моменту появи нової критичної проблеми.

MTTF використовується для відстеження стану компонентів системи, що не підлягають ремонту, і оцінки того, як довго вони можуть працювати до виходу з ладу. Цей показник також дозволяє команді DevOps підтримувати стан компонентів, що використовуються в критично важливих системах при виявленні збоїв.

Продуктивність застосунків (Application Performance)

Перед виконанням розгортання необхідно перевірити межі продуктивності. Після релізу було б добре відстежувати значні зміни у використанні певних запитів SQL, викликів веб-сервісів та інших нефункціональних вимог до рішення. Щоб виявити їх, можна використовувати інструменти моніторингу, які точно покажуть вам зміни.

Середній час до виявлення (Mean Time to Detection - MTTD)

Коли проблеми все ж таки виникають, важливо, щоб ви легко їх ідентифікували. Ви не хочете мати серйозні часткові або повні перебої у роботі обладнання та не знати про це. Налаштування надійного моніторингу програм може допомогти вам легко виявляти помилки.

Середній час відновлення (Mean Time to Recovery - MTTR)

MTTR – це показник успіху, який перевіряє ефективність команд у вирішенні проблем. Здатність аналізувати вплив клієнтського досвіду створює перспективу, необхідну для ретельного розуміння проблем та визначення їхньої пріоритетності.

MTTR розраховує загальний час від збою до рішення та пропонує інформацію про те, чи втратили клієнти функціональність, чи зіткнулися із затримками чи вийшли із системи. Поліпшення MTTR знижує вплив цих проблем, зберігаючи задоволеність користувачів.

Вкрай важливо скоротити MTTR за рахунок наявності практичних інструментів керування програмами, що дозволяють швидко виявляти проблеми та безболісно виправити.

Час на реалізацію (Lead Time)

Важливим показником для вимірювання робочого процесу та ефективності є оцінка середнього часу, який потрібний проекту, щоб перейти від концепції до реалізації. Найменший час виконання означає, що команда є гнучкою і може швидко відповідати на нові потреби.

Agile-методології, пов'язані з DevOps, можуть забезпечити швидкий період обробки покращень інфраструктури, дозволяючи бізнесу задовольняти потреби споживачів та зосередитись на зміні тенденцій. Ви можете використовувати такі інструменти, як Jira та Trello, щоб ефективно відстежувати час виконання завдань.

Обсяг змін (Change Volume)

Оскільки DevOps - це часті зміни, необхідно виміряти рівень змін між розгортаннями. Кінцева мета повинна полягати в тому, щоб сконцентруватися на значних поліпшеннях, які завдають менше незручностей і призводять до більш плавної взаємодії. Для кожного розгортання моніторинг обсягу змін дозволяє більш точно описати розвиток. Ви можете отримати цю інформацію з таких інструментів, як GitHub, Bitbucket та Jira.

Клієнтські запити (Customer Tickets)

Позитивний досвід клієнтів має вирішальне значення виживання продукту. Задоволені клієнти та гарне обслуговування призводять до збільшення обсягів продажу. Ось чому запити клієнтів вказують на рівень їхньої задоволеності, відображаючи якість ваших процесів DevOps. Чим менша цифра, тим краще сервіс.

Висновок

Метою DevOps є сприяння координації та співпраці між розробниками та операційними групами таким чином, щоб підтримувати швидку роботу програм, зводячи до мінімуму простої, затримки та проблеми, які негативно позначаються на досвіді кінцевого користувача.

Це залежить від конкретних проблем вашого ринку та необхідності вибору конкретних метрик DevOps для відстеження. Вибір правильних індикаторів успіху для моніторингу допоможе приймати стратегічні рішення, пов'язані з розробкою та технологіями, одночасно підтримуючи виконання поточної діяльності DevOps.

Шукаєте інструменти керування журналами у Kubernetes? Подивіться на ці 7 відмінних інструментів для більш простого та ефективного ведення журналів!

Оригінал: 7 Best Log Management Tools for Kubernetes 2020
Автор: Max Shash

Kubernetes домінує на ринку менеджменту контейнерів та часто використовується для розміщення мікросервісів. Кожен екземпляр мікросервісу генерує велику кількість подій журналу, керування якими може швидко стати скрутним. Але що ще гірше, коли щось йде не так – знайти першопричину може бути складно через взаємодію між сервісами та майже нескінченну кількість можливих режимів відмови. Саме можливість виникнення проблем призвела до зростання популярності інструментів управління журналами для Kubernetes.

Але чому на ринку так багато інструментів? Чи є один ідеальний інструмент, який задовольнить усі потреби та зробить моніторинг, ведення журналу та аналіз причин максимально ефективним та швидким? Як ви вже здогадалися, ні.

Більшість інструментів управління журналами Kubernetes є варіаціями ELK, що роблять аналогічні речі та мають аналогічні обмеження. Ці інструменти допоможуть вам отримати доступ до журналів і знайти інформацію, але проблема в тому, що вам потрібно знати, що шукати. Більшість цих інструментів для правильної роботи також потребує правил синтаксичного аналізу та правил попередження. Але я зіткнувся з одним винятком, для якого не потрібно створювати правила автоматичного виявлення проблем.

Читайте мій список найкращих інструментів управління журналами для Kubernetes у 2020 році.

1. Zebrium

Ви очікували, що спочатку з'явиться інший інструмент? Може, Prometheus чи ELK? Ні, я поставив Zebrium на перше місце, тому що бачу, що цей інструмент може стати наступним великим кроком у керуванні журналами Kubernetes.

Цей новий стартап нещодавно був включений до рейтингів Gartner «25 найкращих стартапів у галузі корпоративного програмного забезпечення, за якими варто стежити у 2020 році» і Forbes “Найбільш перспективні компанії Америки в галузі штучного інтелекту”.

Говорячи про успіх, Zebrium також нещодавно допоміг Sweetwater скоротити час відстеження інцидентів з 3 годин до кількох хвилин. Zebrium може навіть виявити приховані проблеми, на які раніше не звертали уваги. Це відмінна функція, оскільки вона допомагає виявити проблеми, перш ніж вони вплинуть на клієнтів.

То що відрізняє підхід Zebrium від конкурентів? Вони використовують штучний інтелект (ШІ), щоб знаходити проблеми, а також автоматично виявляти основну причину, в той час, як всі інші інструменти покладаються на додавання правил користувачами вручну. Zebrium можна також використовувати як окрему платформу управління журналами або інтегрувати зі стеком ELK (вони називають його стеком ZELK :-) або іншими менеджерами журналів.

Схоже, мрія збулася, тож я протестував її на дуже простому проекті.У цьому тесті Zebrium автоматично виявив проблему, пов'язану з тайм-аутом мережного виклику. Я не створював жодних правил та не контролював систему вручну. Zebrium визначив проблему за допомогою своїх алгоритмів на основі машинного навчання та негайно видав повідомлення.

Також важливо відзначити, що я не професійний DevOps інженер і ще не тестував Zebrium на великих проектах.

Плюси:

1. Легко розпочати; просто скопіюйте / вставте команду helm або kubectl.
2. Автоматичне виявлення проблем та причин без застосування ручних правил.
3. Може використовуватися як автономний інструмент керування журналами або як надбудова машинного навчання до існуючого інструменту керування журналами, наприклад, стеку ELK.

Мінуси:

1. Не такий відомий, як його конкуренти.
2. Безкоштовний план обмежений 500 МБ на день із 3-денним зберіганням.
3. Підтримує Kubernetes, Docker та найпоширеніші платформи, але поки що не підтримує Windows.

2. Sematext

Це рішення для управління журналами та моніторингу продуктивності програм. Sematex забезпечує повну видимість стану системи.

Sematext не обмежується журналами K8s, але також виконує моніторинг та оповіщення за метриками та журналами. Зібрані журнали аналізуються / структуруються автоматично для декількох відомих форматів журналів. Можна налаштувати шаблони і для журналів користувача.

Sematext також надає API-інтерфейс Elasticsearch. Тому можна використовувати будь-який інструмент, який працює з Elasticsearch. Наприклад Filebeat і Logstash. Ви можете використовувати його як варіант ELK або з власною екосистемою Sematext. Інструмент допомагає створювати певні правила для відстеження конкретних випадків та виявлення аномалій. Клієнти можуть контролювати та відстежувати всі сервіси завдяки комплексній панелі управління Sematex в режимі реального часу.

Плюси:

1. Інтеграція з іншими інструментами Sematext Cloud, такими як Experience та Infrastructure Monitoring.
2. Можна налаштовувати обмеження вартості, припиняючи прийом журналів.
3. Гнучкість як у ELK.

Мінуси:

1. Віджети Sematext та Kibana не можна змішувати на одній панелі.
2. Користувальницький синтаксичний аналіз повинен виконуватися у відправнику журналів, Sematext аналізує лише Syslog та JSON на стороні сервера.
3. Слабка функція трасування, хоча вони планують її покращити.

3. Loki от Grafana

Третє місце у моєму списку інструментів моніторингу журналів K8s займає не ELK, а Loki. Loki - це розрахований на багато користувачів і високодоступний інструмент агрегування журналів, створений на основі Prometheus. Цей інструмент допомагає збирати журнали, але користувачам потрібно буде вручну створювати для нього правила. Loki працює з Grafana, Prometheus та Kubernetes і досягає великої ефективності, оскільки індексує не вміст ваших журналів, а лише набір позначок для кожного потоку подій.

Плюси:

1. Велика екосистема.
2. Широкі можливості візуалізації.
3. Ефективність через відсутність індексації вмісту журналу.

Мінуси:

1. Не оптимізован для керування журналами Kubernetes.
2. Багато ручної роботи зі створення правил.
3. Відсутність індексації контенту потенційно знижує продуктивність пошуку.

4. ELK Stack - Elastic Stack

Нарешті, ELK посідає четверте місце у списку. ELK, мабуть, найвідоміший інструмент із відкритим вихідним кодом для управління журналами загалом. ELK - це абревіатура від Elasticsearch, Logstash та Kibana; кожен компонент піклується про різні частини процесу журналювання.

Elasticsearch - це потужна та масштабована пошукова система, Logstash збирає та обробляє журнали, а Kibana надає інтерфейс для аналізу та візуалізації, який допомагає користувачам аналізувати дані. Разом вони забезпечують комплексне рішення для журналу даних для K8s. Зверніть увагу, що існує безліч інших варіантів стеку ELK (наприклад, EFK Stack - Elasticsearch, Fluentd та Kibana).

ELK використовується багатьма великими компаніями, такими як Adobe, T-Mobile та Walmart, тому ви можете бути впевнені у його надійності. В цілому це надійний інструмент, що добре зарекомендував себе. Я не поставив його на третє місце через його складність та значні ресурси, необхідні для роботи.

Плюси:

1. Інструмент добре відомий і має величезну спільноту.
2. Дуже широка підтримка платформи.
3. Багаті можливості аналізу та візуалізації в Kibana.
4. Потрібен складний аналіз журналів та ручне визначення правил.

Мінуси:

1. Важко підтримувати під час масштабування.
2. Багато налаштувань, особливо для великих оточеннь.
3. Велике споживання ресурсів.
4. Для деяких функцій потрібна платна ліцензія.

5. Google Operations - Stackdriver

Google Operations, який ви, можливо, знаєте як Stackdriver, - це вбудований інструмент для моніторингу, усунення несправностей та підвищення продуктивності програм у середовищі технологічного гіганта Google. Він збирає показники, журнали та трасування в Google Cloud та ваших додатках. Google Operations є еквівалентом CloudWatch на AWS і, як і CloudWatch, має рішення для ведення журналів та моніторингу.

Cloud Logging глибоко інтегрований з GKE і за умовчанням додається до кожного створеного вами кластера GKE. Ваші журнали зберігаються у сховищі даних та індексуються як для пошуку, так і для візуалізації. Cloud Logging підтримує гнучкі запити (які можна зберігати), прості польові дослідження та візуалізації гістограм та може бути легко інтегрований з іншими інструментами з інфраструктури Google.

Плюси:

1. Управління та аналіз журналів у реальному часі.
2. Вбудоване відстеження показників під час масштабування.
3. Безліч інтеграцій.

Мінуси:

1. Важко відстежити реальну затримку, тому що запит проходить через різні рівні Google Cloud Platform (GCP).
2. Підходить лише для середовищ GCP.
3. Система ціноутворення - складно заздалегідь оцінити, скільки щось коштуватиме.

6. CloudWatch

CloudWatch - це рішення для Amazon Web Services. Воно збирає моніторингові та операційні дані з AWS і візуалізує їх на єдиній автоматизованій панелі управління. Це дозволяє вам переглядати та складати журнали та показники, щоб знайти основну причину проблеми. Журнали можна аналізувати за допомогою спеціальної мови запитів CloudWatch, яка підтримує агрегування, фільтри та регулярні вирази. Ви також можете надсилати журнали в Elasticsearch через Lambda.

В цілому CloudWatch - відмінний вибір, якщо ви вже працюєте з сервісами Amazon. Його також можна використовувати в гібридних хмарних архітектурах і використовувати агент або API для моніторингу локальних ресурсів. CloudWatch використовує безліч великих компанія, таких як Airbnb, Deliveroo, 9GAG та інші. Він також може економити компаніям мільйони щорічно завдяки DynamoDB TTL.

Плюси:

1. Створений спеціально для моніторингу ресурсів AWS.
2. Має метрики стрибкоподібних екземплярів.
3. Детальний моніторинг та автоматичне масштабування груп.

Мінуси:

1. Його можна використовувати лише для сервісів AWS.
2. Небагато варіантів налаштування дашбордів.
3. Не підтримує трасировку транзакцій.

7. Fluentd

Fluentd - це кроссплатформенний колектор даних з відкритим вихідним кодом, що пропонує уніфікований рівень ведення журналу (але це не автономний менеджер журналів). Це досить популярний інструмент, яким користуються понад 5000 компаній, включаючи Atlassian, Microsoft та Amazon. Дивлячись на клієнтів, можна зробити висновок про високий рівень надійності та продуктивності. Крім того, Fluentd створює єдиний рівень ведення журналу, який допомагає більш ефективно використовувати дані та швидко виконувати їхню обробку у вашому програмному забезпеченні. Із цим інструментом можна обробляти до 120 000 записів за секунд.

Плюси:

1. Велика спільнота та екосистема плагінів.
2. Єдиний рівень ведення журналу.
3. Перевірена надійність та продуктивність.
4. Простий старт: можна встановити менш ніж за 10 хвилин.

Мінуси:

1. Важко налаштувати.
2. Обмежена підтримка перетворення даних.
3. Не повне рішення для ведення журналу.

Висновок: Як правильно вибрати інструмент?

По-перше, я повинен пояснити, чому не включив до списку Prometheus, який, впевнений, ви очікували побачити. Причина в тому, що ця стаття присвячена інструментам моніторингу журналів, а Prometheus займається метриками і не підтримує журнали.

Отже, якщо вам набридло вручну шукати в журналах першопричину або створювати правила оповіщеннь та керувати ними, спробуйте Zebrium з алгоритмами на основі AI та ML. Це, ймовірно, заощадить багато часу і позбавить вас від трудомісткого завдання створення безлічі правил.

Але якщо ви шукаєте щось масове і знаєте, які правила оповіщеннь створювати - або ви не довіряєте ШІ - спробуйте Loki або Sematext. Це ефективні інструменти, які підійдуть, навіть якщо ви раніше не використовували інструменти моніторингу журналів. Вони будуть особливо корисними, якщо ви користуєтеся продуктами Grafana або Sematext Cloud/Enterprise.

Якщо ви використовуєте Google GCP для свого проекту, хорошим і цілком очевидним варіантом може бути Google Operations.

Якщо ж у вас різноманітні чи нестандартні джерела журналів, спробуйте Fluentd з його універсальним підходом, але при цьому все одно знадобиться інструмент управління журналами.

І, звичайно ж, якщо ви користувач AWS, CloudWatch стане вашим очевидним вибором.

Для нової команди створення канви Робочої Угоди про спільну роботу - відмінна вправа, що допомагає сформувати командну ідентичність, та має вирішальне значення для успіху.

Оригінал: Kick-Off Your Agile Team With A Working Agreement Workshop
Автор: Ayman Idris

Канва, створена Аві Шнайєром (Avi Schneier) і командою Scrum Inc, спонукає команду ставити питання, які торкаються суті командної динаміки, від норм і керівних принципів, яких вони погоджуються дотримуватися, до навичок, якими вони хочуть навчитися один в одного, як вони відзначають успіх і навчаються на невдачах. У цій статті я розповім, як я адаптував канву Аві до потреб команд, яких тренував, детально зупинюся на різних елементах робочої угоди та поділюся з вами покроковим керівництвом щодо полегшення розробки угоди про спільну роботу.

Короткий огляд 8 блоків канви

Назва та девіз команди

Наявність назви команди, з якою можуть ідентифікуватись всі члени команди, є одним із аспектів створення унікальної ідентичності команди. Назва команди має бути створена (і узгоджена) командою самостійно. Є багато анекдотичних розповідей про те, як об'єднання під загальною назвою команди допомагає команді працювати набагато гладкіше та ефективно (плюс, водночас цікаво придумати відмінну назву команди!). На недавньому семінарі з робочої угоди в групі було так багато шанувальників Гаррі Поттера, що вони вирішили називатися Командою Слізерина. Ви б чули сміх, коли вони намагалися придумати цю назву!

Девіз – це крилата фраза команди. Деякі команди обирають щось, що у кількох словах передає те, що вони вважають суттю гарної командної роботи, тоді як інші вважають за краще щось глузливіше. Мені подобається спостерігати за динамікою команди і за тим, як вони дізнаються більше про один одного, намагаючись придумати девіз.

Місія команди

Канва робочої угоди дозволяє команді однією пропозицією оголосити світу, чому ця команда існує. Це дозволяє членам команди глибоко вивчити свої (і чужі) погляди на те, чому ми тут розпочинаємо цю велику справу.

Спільна розробка командної місії дає чудове уявлення про те, як кожен член команди засвоїв усі розмови та інформацію, представлену та обговорювану в рамках ініціації/початку/нульового спринту тощо.

Сильні сторони та навички

Широке розуміння наборів навичок (бізнес, технології, інструменти, міжособистісні навички тощо), доступних у команді, дає безліч переваг, у тому числі:

• Це дозволяє команді використовувати унікальні навички своїх членів, що виходять за рамки їх посад (back-end розробник може не тільки займатися back-end розробкою - він також може мати пристойний досвід автоматизації тестування, наприклад, отриманий від попередніх проектів або з минулої кар'єри). Уявіть, наскільки корисно дізнатися про це на початку проекту.
• Знання про поточні навички показує команді, чи є недолік у певних сферах, дозволяючи команді (і керівництву) швидко вирішити цю проблему.
• Бачення широти знань та навичок, доступних у команді, спонукає членів команди розвивати широкі Т-подібні навички, навчаючись у своїх колег. Ви завжди хотіли вивчити певний інструмент чи технологію, наприклад, але чи завжди відчували, що у вас немає часу? Яке щастя, що один із ваших нових членів команди є експертом у цій технології!
• Крім того, я незмінно знаходжу нові команди здивованими широтою та глибиною знань та досвіду всередині групи. Це багато в чому допомагає членам нової команди розвинути почуття пошани та вдячності один одному, а також прищепити почуття гордості за те, що вони є частиною команди.

Пробіли та можливості зростання

Як ми зможемо стати більш універсальними як команда та більш Т-подібними як індивідууми? Попередній блок надав нам важливу інформацію про знання та досвід усередині команди, а наступним кроком потрібно буде з'ясувати, що робити з цією інформацією. Наприклад, чи є якісь конкретні навички, які нам потрібні, яких немає в команді? Що ми збираємось із цим робити? Якими є наші індивідуальні цілі щодо формування більш Т-подібного набору навичок?

Святкуйте та покращуйте

У цьому блоці є дві основні теми: як ми відзначаємо успіх і як ми навчаємось на невдачах. І те, й інше важливо для створення високопродуктивної команди. Люди майже інтуїтивно розуміють, як важливо вчитися на невдачах / помилках, але переваги святкування успіху часто не беруться до уваги. Ніщо так не сприяє спільній роботі, як святкування перемог у команді та обмін успіхами один одного.

У цьому блоці канви робочої угоди команда обговорює і погоджується з тим, як вони планують отримувати уроки з невдач і святкувати успіх (наприклад, як і коли вони будуть розмірковувати над помилками, як вони збираються отримувати уроки з минулих невдач і перетворювати на дії, що успіх означає для цієї команди – як окремих осіб, так і колективу – і як вони планують відзначити його тощо).

Норми та рекомендації

Тут ми обговорюємо та колективно узгоджуємо наші основні правила: кодекс поведінки, який описує ту культуру роботи, яку ми хочемо для нашої команди. Ми підходимо до цього, описуючи, як ми повинні (і не повинні) поводитися, беручи участь у різних аспектах спільної роботи: від того, як ми проводимо зустрічі та заходи, до того, як ми вирішуємо конфлікти, розподіляємо робоче навантаження, співпрацюємо, спілкуємось, надаємо зворотний зв'язок, і т. д. Мета полягає в тому, щоб створити середовище, в якому всім буде комфортно висловлювати свою думку без страху.

Події

Як довго мають бути наші спринти? У який день і час ми повинні проводити зустрічі з планування спринту, уточнення беклогу, огляду спринту, ретроспективи спринту та щоденного скраму? Де мають проводитися ці зустрічі? Хто має бути присутнім на яких зустрічах/церемоніях? І т.п.

Висновок

Не надто намагайтеся вигадати ідеальну канву для угоди про спільну роботу. Канва робочої угоди, як і решта в контексті Agile-команди, розвивається в міру того, як ми дізнаємося більше. Чим довше ми працюємо разом, тим більше ми дізнаємося один про одного та про те, що покращує (або заважає) нашу робочу динаміку в команді. Дещо з того, що ми зараз вкладаємо в робочу основу угоди, буде страшенно неактуальним через кілька тижнів або місяців, тоді як нові речі, що з'являються (наприклад, нові доповнення до норм і керівних принципів) вимагатимуть уваги і, природно, опиняться у робочій угоді. Це показує, що ми дійсно вчимося, розвиваємось і постійно стаємо кращими.

Семінар з робочої угоди - Посібник з фасилітації (1-годинний семінар)

Ця діяльність призначена тільки для основних членів команди, тому інші зацікавлені сторони не грають у ній ролі. Під «основною командою» тут розуміються люди, які справді створюють продукт: розробники, тестувальники, аналітики, Scrum Master, Product Owner тощо.

Попросіть команду сформувати групи по 2 особи. Кожна група спочатку спробує створити основу для робочих угод самостійно, перш ніж намагатися поєднати всі різні версії в одну основу, яка представляє думки та погляди всієї команди.

Крок 1: пари, що працюють незалежно один від одного, щоб заповнити канву (20 хвилин):

• Назва: пара проводить мозковий штурм за назвою команди і домовляється про одне.
• Девіз: пара вигадує девіз / слоган для команди. Слоган може бути будь-яким, але лише коротким та яскравим. Пара повинна узгодити один девіз, щоб нанести на канву.
• Місія: парний мозковий штурм відповідає питанням: «Чому існує ця команда?». Знову ж таки, двоє обговорюють свої точки зору та погоджують місію для команди, яку вони додають на канву в блоці «Місія».
• Сильні сторони та навички
  • Спочатку пара проводить мозковий штурм всіх навичок, які вони мають на різних рівнях майстерності (від новачка до експерта), включаючи технології, бізнес, інструменти, м'які навички і т.д. Думайте широко і не обмежуйте себе лише навичками / областями, які ви знаєте.
  • Потім пара працює над тим, щоб оцінити свій рівень майстерності в кожній виявленій навичці. Одна шкала, яку вони можуть використовувати - це проста п'ятиступінчаста шкала: немає навичок - базові знання - виконує основні завдання - виконує всі завдання - навчає всім завданням.
  • Щоб візуалізувати рівень володіння людиною певною навичкою, мені подобається використовувати візуалізацію, яка відповідає 5-ступінчастій шкалі.
  • Візуалізація парою своїх навичок та відповідних рівнів майстерності виглядатиме приблизно так.
• Навички, які ми хочемо вивчити: у яких навичках хочемо підвищити свій рівень майстерності? Пара вивчає матрицю навичок, яку вони створили на попередньому кроці, а потім визначають будь-які потенційні набори навичок, які вони хочуть покращити (або вивчити з нуля), та записують на замітку навички та рівень, яких вони хочуть досягти (наприклад, вони вже на рівні 1 і хочете бути на рівні 3) – разом зі своїми ініціалами. Одна замітка на кожну навичку, яку потрібно вивчити.
• Святкуйте успіхи та невдачі: як і коли ми розмірковуватимемо над помилками? Як ми збираємося втілити в життя те, чого навчилися з минулих невдач? Що означає успіх для цієї команди – як окремих осіб, так і колективу – і як ми збираємось його відзначати? Проведіть мозковий штурм і запишіть на стікерах відповіді на ці запитання та інші, які пара може вигадати в рамках теми святкування успіху та невдачі та помістіть листок на канву для подальшого обговорення з іншою командою.
• Норми та рекомендації: пара проводить мозковий штурм за правилами, які, на думку, повинні визначати, як члени команди працюють разом. Деяким командам подобається оформлювати це як список речей, які ми маємо і не повинні робити. Один із способів, яким я допомагаю командам продумати цю частину, - це просити їх озирнутися на найкращі та найгірші команди, в яких вони колись були. Намагайтеся подумати про те, що виділялося і продовжило цей досвід (позитивний чи негативний). Яка поведінка чи стосунки характеризували це командне середовище і чого ми можемо навчитися у них, щоб сформувати ту культуру, яку ми хочемо для нашої команди?
• Події: Мета цієї частини – забезпечити, щоб регулярні зустрічі /церемонії щодо проекту були заплановані на час, зрозумілий для всіх членів команди. Якщо ви не можете прийти на роботу до 9:30, наприклад, через те, що вам потрібно залишити дітей у школі, тоді команді важливо знати про це, щоб стендап був призначений на більш вдалий час. Пара обговорює дати та час регулярних церемоній на проекті (наприклад, планування спринту по понеділках, огляди та ретроспективи по п'ятницях до 15:00, стендапи щоранку о 10:00 тощо). Їх пропозиції будуть обговорені з іншими групами та дати, час та вибрані місця повинні задовольняти потреби та обмеження всіх членів команди. Щоб розпочати розмову, ставте такі питання, як «Як довго мають тривати наші спринти?» У який день і час ми повинні проводити зустрічі з планування спринту, уточнення беклогу, огляду спринту, ретроспективи спринту та щоденного скраму? Де мають проводитися ці зустрічі? Які відвідувачі мають бути присутніми на яких зустрічах/церемоніях?

Крок 2: Сформуйте пари (тобто групи з 4 осіб), що працюють разом, щоб об'єднати свої канви (20 хвилин):

• Попросіть команду сформувати пари (4 особи)
• Мета полягає в тому, щоб дві пари, що складають кожну групу з 4 осіб, обговорили подібності та відмінності між їхніми двома робочими угодами, зрештою створивши одну канву робочої угоди, яка відображає ідеї обох пар.
• Візьміть блоки один за одним і обговоріть для кожного блоку, як ці дві пари вирішили проблему (наприклад, назва команди, мета, навички і т.д.). Пари по черзі представляють те, що вони розробили, та своє обґрунтування. Дві пари беруть участь у розмові, обговорюють області згоди та розбіжності, різні варіанти об'єднання двох версій в одну і зрештою приходять до єдиної відповіді для кожного блоку.

Крок 3: Вся команда займається створенням однієї робочої угоди (20 хвилин):

• Повторіть крок (2), але на цей раз усі пари збираються разом як одна команда, щоб порівняти свої варіанти і, в кінцевому підсумку, створити 1 остаточну канву робочої угоди команди.
• Проведіть швидке голосування методом Кулак п'яти голосів, щоб оцінити рівень прихильності / віри в канву угоди про спільну роботу.
• Якщо ви отримали 1 або 2: залучіть членів команди, які поставили ці бали, щоб спробувати зрозуміти їхню точку зору – запитайте, що потрібно зробити, щоб наблизитись до 5? Працюйте в команді, щоб включити будь-які зміни або уроки, що були зроблені з цієї діяльності, в оновлення та покращення канви робочих угод.

Прогресивні веб-застосунки (PWA) в даний час гаряче обговорюються. Що ж таке PWA та в чому їх переваги перед традиційними застосунками?

Оригінал: The Rising Era of Web Application Development With PWAs
Автор: Marie Weaver

Що таке прогресивний веб-застосунок?

Прогресивні веб-застосунки поєднують у собі властивості веб-сайтів і традиційних застосунків. Вони поступово адаптуються до відповідного пристрою, та використовують і викликають браузер як веб-сайт шляхом введення URL-адреси.

Доступ до веб-застосунків здійснюється через URL-адресу. ЇХ перевага перед традиційними полягає в тому, що вам більше не потрібно переглядати магазини програм. Ви викликаєте веб-застосунок у браузері і додаєте його на свій «домашній екран». Завантаження з магазину програм більше не потрібне. Оновлення через магазин програм, як ми звикли з традиційними застосунками, також виконуються автоматично.

Додайте прогресивний веб-застосунок на головний екран. Перевага цієї функції в тому, що ви та ваші клієнти заощаджуєте багато місця для зберігання порівняно з традиційними застосунками. Дні, коли ви не могли завантажити застосунок з магазину програм через переповнення місця в сховище, пішли в минуле.

Навіщо розробляти PWA замість звичайних застосунків?

PWA має код, який працює незалежно від різних мобільних платформ. Обслуговування менш затратне, ніж у традиційних застосунків.

• Традиційний застосунок спочатку необхідно завантажити та встановити з магазину програм. PWA працює без встановлення та може бути переданий іншим через URL.
• PWA вимагають менше місця на пристрої та краще сумісні зі старими операційними системами смартфонів.
• Розробка та обслуговування традиційних застосунків зазвичай обходяться дорожче, тому що розробникам доводиться розробляти версії для різних платформ.
• Традиційні застосунки спочатку перевіряються і затверджуються магазином програм. PWA готовий до негайного використання.
• Вони називаються PWA, щоб гарантувати, що кожен користувач використовує останню версію. За допомогою застосунка користувачі можуть відкласти оновлення.
• Наприклад, згідно з інформації Google, Alibaba.com зміг збільшити конверсію в мобільній сфері на 76 відсотків за допомогою PWA, тому що не було потреби завантажувати застосунок.

Недоліки прогресивних веб-застосунків

У порівнянні з традиційними застосунками, PWA також мають недоліки:

• Обмежений доступ до функцій кінцевого пристрою.
• Якщо PWA підтримуватиме кілька мобільних браузерів, витрати на розробку та обслуговування різко зростуть.
• Користувачі можуть вважати прогресивний веб-застосунок гірше, тому що його не потрібно вказувати в магазинах програм.

Односторінкові застосунки як точка старту

Хоча передові веб-застосунки вважаються гарячою темою в технічній спільноті, вони все ще не набули широкого поширення. Вже їх визначення часто спричиняє плутанину. Деякі компанії не розділяють прогресивні веб-застосунки та односторінкові застосунки (SPA).

Односторінковий застосунок це сайт, який швидко реагує завдяки децентралізації. Це означає, що сервер лише надає дані користувача та надсилає їх браузеру. Веб-клієнт керує сеансом і може реагувати незалежно на дії користувача. Під час використання веб-сайту оновлюється лише інформація, потрібна для динамічного відображення.

SPA – це лише перший крок у розробці PWA, але не є прогресивним веб-застосунком. Хоча часто вони не диференціюються. Навіть якщо компанії пропонують своїм клієнтам досвід роботи зі SPA, подібним до PWA, але їм не місце в такому веб-застосунку без автономної (offline) роботи.

Які додаткові функції пропонують прогресивні веб-застосунки?

На додаток до типових функцій адаптивного веб-сайту, розробники можуть використовувати безліч додаткових функцій за допомогою PWA.

Вони включають в себе:

Push-повідомлення, також доступні в традиційних застосунках. Підвищують швидкість взаємодії. Push-повідомлення - це повідомлення, які відображаються прямо на вашому смартфоні, незалежно від того, відкритий застосунок чи ні.

Ви можете використовувати push-повідомлення, щоб інформувати клієнтів про акції, знижки та заходи. Ваші клієнти одержують повідомлення прямо на свої смартфони. Тут потрібна згода на отримання push-повідомлень. Як і у випадку з традиційними застосунками, push-сповіщення також можливі у прогресивних веб-застосунках.

У PWA більш швидкий час завантаження, ніж у традиційних застосунків. Прогресивні веб-застосунки призначені для швидкого завантаження. Зазвичай кажуть, що користувачі йдуть з мобільних сайтів, якщо сайт не завантажується протягом 3 секунд. Якщо PWA викликається вдруге, він відкривається менш як за 3 секунди завдяки Service Worker, навіть коли відповідний користувач не в мережі.

Функція додати на головний екран дозволяє додати PWA на головний екран смартфона. Користувачі можуть запустити PWA як програму, клацнувши значок, навіть в автономному режимі. Таким чином забезпечується високий рівень лояльності клієнтів, без зусиль по встановленню та без необхідності займати багато місця для зберігання.

Автономні функції доступні для працівників сервісу завдяки функції кешування. Після отримання інформація стає доступною в автономному режимі. Використання можливе без встановлення та є багато місця для зберігання.

На жаль, в даний час Apple не повністю підтримує веб-застосунки. У серпні цього року було оновлення статусу, з якого видно, що Apple розпочала реалізацію.

Може також використовуватися в автономному режимі або під час повільного підключення до Інтернету

Ще одна перевага прогресивних веб-застосунків у порівнянні з традиційними застосунками: вони також працюють в автономному режимі або при повільному або поганому підключенні до Інтернету. Після завантаження вмісту веб-програми можна знову викликати його в будь-який час в автономному режимі. Хто з вас цього не знає: ви сидите у трамваї (метро) або у поїзді і у вас погана чи повна відсутність інтернет-з'єднання. Використання традиційних застосунків зараз досить складне і втомлює.

Прогресивні веб-застосунки дають змогу почати працювати тут і зараз. Вони також працюють у ті моменти, коли традиційні застосунки «зазнають невдачі». Тут у гру вступає так званий Service Worker. Що таке Service Worker найкраще пояснити словами Вікіпедії: “Service Worker – це сучасна браузерна технологія, яка використовує JavaScript для забезпечення проксі-сервера між веб-браузером та сервером, який може використовуватись у різний спосіб. Найбільш відоме використання, щоб зробити певні сторінки доступними офлайн".

За допомогою Service Worker веб-застосунок також можна використовувати в автономному режимі. PWA використовує вміст та функції з кеша. Підключення до Інтернету більше не потрібне.

Цілі та необхідні кроки для прогресивного веб-додатку

Застосунок повинен виконувати такі функції:

• Значок застосунку для швидкого доступу з головного екрана.
• Відображення початкового екрана під час завантаження функцій у фоновому режимі.
• Безперебійне використання - онлайн та офлайн.
• Веб-push-повідомлення для збільшення взаємодії.

Функції тільки для смартфонів та планшетів

Незважаючи на те, що вони працюють лише в браузері, прогресивні веб-застосунки можуть отримувати доступ до обладнання, додатків та даних на смартфонах або планшетах за допомогою веб-технологій. Підтримка окремих функцій сильно залежить від браузера, що розглядається. Safari, зокрема, ще треба надолужити втрачене, але інші браузери на платформі Apple також пропонують обмежені можливості. Прогресивний веб-застосунок працює для кожного користувача та адаптується до технічних можливостей пристрою.

Список варіантів доступу та функцій, які прогресивний веб-застосунок вже може використовувати на смартфоні або планшеті, вражає.

Функції PWA (підбір):

• Робота з камерою, мікрофоном та голосове управління
• Робота з USB
• Доступ до файлів, доступ до пам'яті
• Доступ до контактів, SMS, буфер обміну
• Збережені способи оплати
• Радіотехнології (наприклад, Bluetooth, NFC)
• Функції трансляції для презентацій
• Робота з GPS
• Датчики (зовнішнього освітлення, датчика прискорення та положення пристрою в приміщенні)
• Запит статусу пристрою (рівень заряду батареї, онлайн-з'єднання)
• Вібрація, повідомлення (push та локальні повідомлення)
• Значок на головному екрані
• Повноекранний режим браузера
• Автономний режим, фонова синхронізація

Висновок

Щоб оцінити, як має виглядати наступний веб-застосунок або програма для електронної комерції, необхідні вимоги клієнта, перш ніж проконсультуватися з компанією з розробки веб-застосунків. Які елементи процесу покупки в Інтернеті є найбільш важливими для вас? Чи це безперебійна робота з кількома каналами, надання останньої інформації про продукти чи доступність в автономному режимі? Хоча PWA забезпечують більш легкий доступ і більш узгоджений інтерфейс користувача, ніж мобільні застосунки, технологія все ще розвивається. На даний момент вона ще не готова до випуску на ринок, і це займе деякий час.

Тим не менш, стає зрозуміло: класичні веб-застосунки, що складаються з декількох пов'язаних HTML-документів, в найближчому майбутньому будуть замінені застосунками, які більше не роблять відмінностей між настільними та мобільними пристроями. Тому компаніям рекомендується уважно спостерігати за цим розвитком та враховувати його при плануванні майбутньої модернізації своєї присутності в електронній комерції – це стосується як вибору технологічної платформи, так і концепції дизайну, яка має відповідати новим вимогам до технологій, такі як PWA.