Як прийняти спритну методологію розробки прошивки / вбудованих систем-програмного забезпечення?

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

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

Я хотів би почути будь-які поради або вказівки щодо прийняття гнучкої методології для проектів з розробки програмного забезпечення.

Думаю, дві методики є ключовими:

• Розробіть повний тренажер або тестову середовище для обладнання, щоб ви могли розробляти програмне забезпечення так, як якщо б у вас було справжнє обладнання. Не скупіться або приймати ярлики тут: розробка гарного тренажера буде окупатися.

• Напишіть багато одиничних тестів на тренажері.

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

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

Щоб доставити JIT, кожен з постачальників компанії повинен доставити JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

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

Що стосується «поступового» розвитку (він же « Tracer Bullets» 15 років тому), то це означатиме, що «ядро» виходить дуже скоро для хлопця-водія, і що основний драйвер буде доступний інтегратору, і що GUI буде бути розробленим, маючи одну єдину кнопку та поле редагування одночасно.

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

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

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

Не будемо сліпими: Agile теж має справу з важкими процесами! Не потрібно просити команду Agile тепер "рефактор" свою базу коду Java на Python в наступному спринті. Лише тому, що деякі частини справді стабільні, ми можемо танцювати наші рухливі рухи поверх них.

Agile Manifesto: http://agilemanifesto.org/

"Індивіди та взаємодія над процесами та інструментами"

• Зустріньте більше. Менше натискайте на папір.

"Робоче програмне забезпечення над всеосяжною документацією"

• Прототипи та технології побудови шипів рано і часто.

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

"Співпраця з клієнтами щодо переговорів про контракти"

• Гіперскладні процеси контролю змін - це лише способи сказати «ні» клієнту.

• Блокування всіх вимог наперед, а потім накладення контролю змін - це ще один спосіб сказати "ні".

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

"Відповідь на зміни протягом виконання плану"

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

Повністю Agile методологія (тобто scrum) може не мати сенсу для вбудованої системи.

Однак маніфест Agile пропонує способи дозволити можливі зміни, не допускаючи простого хаосу.

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

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

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

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

Ми закінчили писати фрази "Історії користувачів" на кшталт "Як розробник ...", якими я не задоволений, але у використанні цільового процесу (www.targetprocess.com) немає поняття про затримку, яке є завдання чи завдання.

Я хотів би почути, як інші вирішили ці ситуації.