Виробництво проти розробки програмного забезпечення [закрито]

Часто говорять про те, що галузь програмного забезпечення незріла в порівнянні з виробництвом. Зокрема щодо процесу, що керується процесом.

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

Моя думка : у виробництві створення продукту ведеться в значній мірі. У вас може бути фабрика, де кожна людина має певний набір завдань, яких вона виконує. Працівник (або робот) може затягувати гвинт цілий день. Потім чергове завдання в процесі виконує наступний фахівець. Робітники (і роботи) не стримуються від процесу і не складають щось «на льоту». Частини відбиваються наскрізним процесом, а вихід - готовим продуктом. Це добре працює, і компанії досягають 99,99966% безкоштовних продуктів. Компанії з часом вигадують неефективність. Це вражає, і це дуже добре може бути ознакою зрілої галузі.

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

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

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

Всі, з ким я спілкуюся, схоже, згодні з виробничим складом. Я один у своїх думках?

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

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

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

Якщо ми розглянемо процеси дизайну виробів, то найкращі галузі, які ми повинні розглядати, поділяються на дві категорії:

• ті, де виробництво може бути реалізовано за товарними ставками; наприклад, звукозаписна галузь (1% або менше ціни на компакт-диск - це випічка та друк), графічний носій тощо.
• ті, де кількість настільки низька, що фаза проектування є найвизначнішим фактором витрат (розкішні вироби, високомобільна продукція, ринки ніш ...)

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

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

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

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

На жаль, відповідь на це незрозуміла, оскільки сама галузь програмного забезпечення ще не знає відповіді. Щоб відповісти на це, індустрії програмного забезпечення потрібно провести дослідження того, що працює і чому? Наприклад, були проведені дослідження, які показують, що дизайн тестового приводу (TDD) призводить до поліпшення якості. Хоча питання продуктивності все ще видається без відповіді або, принаймні, ще не повністю зрозумілим. Що стосується того, що свідчать досі:

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

Є людина на ім’я Грег Вілсон, який кілька років тому розповів про це щось чудово. Ось посилання на бесіду: Розмова про Грега Вілсона

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

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

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

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

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

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

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

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

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

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

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

• огляди коду: Чи корисний би перегляд коду, якщо процес огляду та критерії кодування змінилися для кожного огляду? Звичайно, ні.

• Життєвий цикл розробки програмного забезпечення: Весь аналіз -> дизайн -> реалізація -> тест -> цикл обслуговування - це процес, який слід чітко визначити.

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

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

Розробка програмного забезпечення вже прийняла багато виробничих концепцій:

• Важко не побачити вплив взаємозамінних частин Елі Вітні як на ООП, так і на основі компонентів .

• Методи управління проектами, що застосовуються при розробці програмного забезпечення, не сильно відрізняються від технологій, розроблених для виробництва. Як лише два приклади, світ програмного забезпечення лише нещодавно прийняв концепцію Kanban, розроблену десятиліттями тому в Toyota, і діаграми Ганта використовувались у виробництві задовго до того, як був побудований перший електронний комп'ютер.

• Методології управління якістю, такі як Six Sigma, розроблені для виготовлення, були адаптовані до розробки програмного забезпечення.

Незважаючи на важкі умови, керовані процесами, розробник повинен брати участь у створенні речей "на льоту".

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

Робити речі на льоту - це проти духу виготовлення.

Знову ж таки, якщо "на льоту" означає "поза процесом", ви маєте рацію. Але якщо ви думаєте, що виготовлення не вимагає швидкого мислення та розвитку творчих рішень проблем, ви помиляєтесь. У процесі виготовлення виникають усілякі проблеми - кекси не мають достатнього наповнення кремом, пофарбовані поверхні раптом перестають проходити тест на подряпину QA, у 20% готових деталей відсутнє важливе фіксуюче кільце, система замішування тіста зламала критична частина ...