Метью Флаутт — CTO, Джефф Дей — старший технічний радник, та деякі єдинороги
Одна з причин, чому я почав цей блог, — це поділитися уроками, які я засвоїв, переходячи від квартальної до щоденної доставки програмного забезпечення та допомагати іншим командам в інших контекстах навчатися цьому самому. Не кожна команда досягла цієї мети, але кожна, яка спробувала, мала менше болю, вищу мораль і кращі результати для бізнесу. Покращення результатів і якості життя — ось чому я так часто висловлююся з цих питань.
Протягом років я бачив багато людей, які стверджували, що вони «працюють з CD», але ігнорували основні практики, що приносять переваги CD.
- Автоматизація зборки/розгортання з GitFlow, кілька юніт-тестів і ручне тестування прийняття — це не CD.
- Перехід через пайплайн для гарячої виправлення — це не CD.
- Доставка раз на місяць «тому що саме так часто хочуть клієнти» — це не CD.
Оскільки я бачив значно більше фальшивого CD, ніж реального, моя стандартна реакція — скептицизм, коли я чую, що хтось заявляє, що це робить. Я очікую, що будуть значні прогалини або навіть автоматизація зборки, і мене рідко це дивує.
Армія США здивувала мене.
Мені випала нагода відвідати Програмне забезпечення Армії США в Остіні, Техас, частина Command Army Futures. Мене запросили, щоб подивитися, що вони роблять, порівняти зауваження з командами та дізнатися, що ми можемо навчити один одного. Армійська програмна фабрика має програму курсу для навчання солдатів, як професійно розробляти програмне забезпечення, щоб вони могли повернутися до своїх підрозділів і постачати можливості на полі бою на постійній основі.
Проблема, яку потрібно вирішити
Протягом десятиліть Міністерство оборони покладалося на підрядників для поставки затвердженого програмного забезпечення. Це зазвичай слідує класичному процесу водоспаду розробки, після чого отримується Authority to Operate. Весь процес може зайняти місяці або роки, щоб потрапити до тих, кому це потрібно. Результатом часто є програмне забезпечення, яке менш ніж «підходить для мети», з високими витратами на оновлення або виправлення. Це призводить до того, що солдати на полі бою з самостійно здобутими знаннями з розробки пишуть програмне забезпечення, яке задовольняє негайні тактичні потреби їхніх підрозділів. Це відбувається з тієї ж причини, чому існує тіньова ІТ в багатьох великих підприємствах: «Нам потрібні рішення зараз, і ми не можемо чекати, поки ІТ їх доставить!»
Солдати, що постачають програмне забезпечення для інших солдатів, можуть забезпечити швидшу доставку рішень, які краще відповідають їхнім потребам. Люди, які найбільше розуміють проблему, є тими, хто може найкраще доставити правильні рішення. Але це має свою ціну: розробники без належної підготовки не мають досвіду для створення сталих рішень. Це може призвести до розгортання критичних можливостей, які є крихкими і важкими для підтримки, покращення та забезпечення безпеки.
Перетворення бійців на програмістів
Щоб вирішити ці проблеми, Армійська програмна фабрика розробила спеціалізовану навчальну програму, щоб навчити солдатів навичкам екстремального програмування (Extreme Programming), безперервної інтеграції (continuous integration) та безперервної доставки (continuous delivery) в командному середовищі. Їхня мета — створити прототип майбутнього військового дизайну. Вони хочуть показати Армії, як використовувати розробників як стратегічний актив через Доктрини. Солдати, які проходять навчання, мають підтримувати це зусилля і допомогти поширювати знання про сучасну розробку програмного забезпечення в своїх майбутніх призначеннях. Щоб потрапити до програми, солдати повинні мати звання від E-5 (сержант) до O-3 (капітан). Після того, як вони прийняті на одну з відкритих посад, вони проводять кілька місяців, вивчаючи основні навички розробки, перш ніж приєднатися до платформи або продуктової команди. Солдати приходять з мінімальним або взагалі без досвіду в розробці. Їх навчають основним мовним навичкам і тому, як працювати в сучасній команді розробників, використовуючи такі техніки, як TDD (Test-Driven Development), розробка на основі основної гілки (trunk-based development), безперервна інтеграція (continuous integration) та безперервна доставка (continuous delivery).
З того часу вони проводять решту свого дво-річного циклу навчання, постачаючи реальне програмне забезпечення, вдосконалюючи свої навички.
Кожна команда володіє конкретною продуктовою доменною областю та відповідає за свої результати. Оскільки це Міністерство оборони США, безпека та відповідність стандартам є критично важливими. З цією метою команди з безпеки та відповідності працюють із командами розробників, допомагаючи їм досягти цих цілей якості. Вони забезпечують безпеку та відповідність, а не виконують роль наглядачів.
Після першого року солдати проходять технічну атестацію, маючи дві спроби для успішного проходження. Якщо вони не здадуть атестацію двічі, їх виключать з програми. Наприкінці програми успішні випускники переходять до наступного призначення. Деякі з них приєднаються до розробки програмного забезпечення в своєму наступному підрозділі. Деякі офіцери стануть лідерами існуючих або нових команд розробників, а деякі повернуться до своїх попередніх підрозділів. Останні не будуть займатися розробкою, але вони стануть краще поінформованими користувачами систем, якими вони користуються, і зможуть надавати кращі відгуки людям, які їх створюють.
Маркетинг чи реальність?
Я відвідав програму на два дні та взяв інтерв'ю у кількох солдатів з продуктових і платформених команд, а також у лідерів команд безпеки та відповідності. Я занурився в деталі, щоб перевірити наявність прогалин у їхніх процесах. У більшості команд, з якими я спілкувався раніше, не важко знайти загальні проблеми. Це не означає, що ті команди були погані, але важко бути «добрим», якщо ти ніколи не бачив «добре». У цьому випадку я з труднощами знаходив легкі рішення для виправлення. Я мав деякі пропозиції щодо покращення робочого процесу навколо перегляду коду та уточнення завдань, але це більше оптимізація, ніж критичні зміни.
Розробники повідомили, що інтегрують код у основну гілку кілька разів на день. Більшість команд отримують часті та швидкі відгуки від поля. Деякі команди працюють над рішеннями, які потребують розповсюдження через магазини додатків, і мають повільніший зворотний зв'язок, але вони намагаються залучати людей з експертизою в доменній області, щоб використовувати його на стадійному сервері для отримання найкращих відгуків. Це вражає, і я з радістю приєднався б до будь-якої з їхніх команд, щоб підтримувати низькодрамну атмосферу доставки, яку я віддаю перевагу.
Виклики
Нічого не буває ідеальним, і оскільки Програмна фабрика армії є частиною Армії США, утопія ніколи не була варіантом.
- У 2024 році командування Армійських майбутніх можливостей прийняло рішення скоротити термін програми з трьох до двох років через високий попит по всій армії на можливості, які вони надають. Це означає, що солдат проведе 18 місяців в команді після закінчення кодувального табору замість 30 місяців. Втрата одного року практичного досвіду є значною, але, сподіваємось, дисциплінований навчальний процес, який вони застосовують, все ж надасть їм необхідний досвід, щоб допомогти здійснити зміни.
- Вони навчають нових розробників, як робити це правильно. Проблема в тому, що більшість інших організацій не знають, як робити це правильно, не кажучи вже про стимулювання команд працювати так. Сподівання полягає в тому, що випускники зможуть впливати на зміни. Для цього їм необхідно побачити, як може виглядати «погане», і навчитися пояснювати, чому «цей спосіб працює краще». Я переживаю, що деякі з них можуть бути розчаровані, якщо їм доведеться працювати так, як це роблять багато команд (навіть у приватному секторі).
- Офіцери, які закінчують курс, повинні розуміти, як донести цей спосіб роботи до своїх керівників для впливу на зміни.
Я поговорив з капітаном, якого наступне призначення полягало у керівництві зусиллями з модернізації програмного забезпечення. Він запитав, чи слід йому обговорювати «агіл» або «модель Pivotal» зі своїм новим керівництвом. Я відповів йому, що за жодних обставин він не повинен це обговорювати. Керівництво не буде зацікавлене і навіть може бути ворожим до модних слів. Слід зрозуміти проблеми, які намагаються вирішити ваші керівники, і бути здатним пояснити, як покращення логістики розробки програмного забезпечення може допомогти вирішити ці проблеми.
Створення майбутнього програмного забезпечення Армії
Програма, яку побудувала Армія, дійсно вражає. Вона працює як експеримент вже кілька років, але цінність була визнана.
Станом на січень 2025 року, Секретар армії США ухвалив рішення про створення нової кар'єрної сфери «Операції з програмним забезпеченням» на основі моделі ASWF. Це важка, але заслужена перемога, яка свідчить про цінність, яку армія надає контролю над результатами свого програмного забезпечення та використанню сучасних методів інженерії програмного забезпечення для його доставки. Сподіваюся, що інші підрозділи Міністерства оборони США визнать цю цінність і підуть шляхом армії.
Армія США обігнала вас
У вашій організації, ймовірно, менше бюрократії та інерції, ніж у Армії США. Що заважає вам модернізувати вашу інженерію програмного забезпечення? Все, що потрібно, це знайти хорошу інформацію, готовність змінюватися та замінити страх і стагнацію на цікавість.
Ресурси:
ASWF не використовує фреймворк, тому що фреймворки вирішують чужі проблеми. Вони використовують ті самі методи, які ви можете знайти в цих книгах.
- Modern Software Engineering — Dave Farley
- Accelerate — Nicole Forsgren, Jez Humble, & Gene Kim
- Engineering the Digital Transformation — Gary Gruver
- Continuous Delivery — Dave Farley & Jez Humble
Оригінально опубліковано на блоці Defense Unicorns
Перекладено з: 5-Minute DevOps: How The US Army Does it Better Than You