Чи є найкращі практики щодо передачі даних від архітектури до розвитку?

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

На одному кінці шкали немає архітектурних вказівок, ви ризикуєте отримати хаос, кожен розробник робить все по-своєму.

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

Хтось знайшов оптимальне середнє місце між цими крайнощами? Які артефакти ви доставляєте для розвитку? Наприклад: модулі, структура класу або діаграми послідовностей?

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

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

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

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

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

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

Найкращий спосіб пом'якшити цю проблему - ЗМІНИТЕ групу «Архітектура» та, можливо, поставити їх на лідируючі позиції. Роль групи «Архітектура» повинна бути більш-менш «шквалом технічних провідників», якщо ви хочете. Вони повинні рідко зустрічатися і лише обговорювати питання технічного спрямування найвищого рівня, наприклад. Подумайте, що міграція з Java на Scala, відмова від Oracle для MySQL, можливо, написання загальних бібліотек утиліт, які доручають певному ТИПУ процесу проектування над іншою, переходячи зі StarUML на Altova UML.

Фактична та реальна розробка програмного забезпечення буде спільним процесом, в якому беруть участь ВСІ розробники програмного забезпечення, викладені надзвичайно високим рівнем керівництва групи «Архітектура».

Завжди були проблеми в тому, як інформація надходить від архітектури до тесту на розробку та операції. Спосіб вирішення цих проблем залежить від кількох факторів, таких як:

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

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

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

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

Сподіваюсь, це допомагає.

Я знаю, що це буде не дуже популярним, але коментар, який ви зробили

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

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

Я не повністю згоден з відповіддю maple_shaft, але в коментарі не вистачило місця, щоб сказати весь мій біт! ;-)

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

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

То де ж середина, яку шукала ОП? Відповідь - це все, що стосується відкриття каналів зв'язку. Архітекторам потрібно передати технічні характеристики, які описують їхні проекти досить детально, щоб гарантувати, що команди розробників зрозуміють, де є межі. Історії та сценарії сюжетів у найширшому розумінні, де все вважається чорною скринькою. Тоді архітекторам потрібно забезпечити доступ команд до часу архітектора для підтвердження будь-яких припущень та відповіді на будь-які запитання щодо технічних характеристик, які здаються занадто широкими або незрозумілими. Після цього мова йде саме про те, щоб окремі команди були обізнані над тим, над чим працюють інші команди, і щоб вони знали, з ким слід зв’язатися з іншими командами, щоб кожна частина системи чудово грала з іншими частинами. Ці команди безпосередньо зустрічаються між собою. Після того, як система була розроблена на найширшому рівні, архітектори дійсно повинні бути лише людьми, до яких звертаються команди, коли їм потрібна перевірка обґрунтованості, та забезпечити збереження «бачення» продукту. Вони також повинні брати на борт будь-який необхідний процес інтеграції та забезпечувати необхідний "повітряний прикриття" для команд розробників від менеджерів, клієнтів та будь-яких інших зацікавлених сторін, при цьому все одно забезпечуючи, щоб ці різні люди могли зібратися, щоб працювати між їм, як все має працювати.

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

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

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

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

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

Загалом повинен бути документ про те, що таке проект, технічні характеристики, тестові приклади та діаграми послідовності / класу.

Я б сказав, що представлення діаграм класів, що створюють модель, а також код - це рішення. Діаграма класів представляє статичний вигляд архітектури вашого проекту. Я маю на увазі, що у вас є пакети> класи, інтерфейси, enum> атрибути, mehtods тощо ...> тощо. Якщо ви добре виглядаєте, метамодель UML2 має точно таку ж структуру, як проект java або dotnet.

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

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