У спритному середовищі, який відповідає за архітектуру програмного забезпечення

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

Можливо, власник продукту, майстер scrum, команда scrum чи хтось інший?

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

• Джерело: http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

Архітектори, звичайно, але, можливо, не традиційні види архітекторів.

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

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

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

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

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

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

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

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

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

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

Я знаю, що було багато.

Список літератури

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

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

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

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

- Проворний маніфест

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

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

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

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

На їхньому сайті є кілька чудових ресурсів команди Scaled Agile Framework (SAFe).

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

Редагуйте для наочності, щоб вирішити це питання безпосередньо:

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

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

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

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

За інформацією TOGAF, відділ архітектури підприємства розробляє плани на високому рівні для та з бізнесом щодо створення та заміни ІТ-середовища. Enterprise Architect матиме визначені архітектурні принципи та підписувати їх на найвищих рівнях організації та допоможе створити архітектуру високого рівня та вимоги до кожного проекту. Кожен проект ініційований для створення архітектурного будівельного блоку в цій архітектурі високого рівня.

Отже, на рівні проекту архітектор Solution створить архітектуру проекту (можливо, повторно) та отримає вихід із Enterprise Architect.

Тепер, щоб зосередитися на спритному проекті. Швидкий проект має вимоги. Вони не у формі масового «Документу про вимоги», а натомість епопеї та історії. Ці епоси ще потребують планування. Ви не відправляєте команду розробників на кілька спринтів у невідоме. Ви знаєте на високому рівні, що потрібно робити системі, з якими іншими системами вона потребує взаємодії та з якими апаратними / операційними системами / мовами обмежує організацію, і це керує та обмежує архітектурний вибір, відкритий архітектору рішення. Наприклад, якщо ви прихильні до .NET і SQL-сервера, вам доведеться зробити надзвичайно багатопереконливий випадок впровадження сайту електронної комерції на базі Magento з використанням PHP та MySQL через витрати, пов'язані з підтримкою двох БД, двох мов, двох веб-серверів тощо. Крім того, один проект міг би використовувати зовсім іншу бібліотеку або інший вигляд і відчуваю, і це може мати наслідки для всіх інших польотних проектів. Для запобігання подібного "архітектурного боргу" важливо мати нагляд за корпоративним архітектором.

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

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

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

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

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

Те, що вони не торкаються, - це ще один спритний принцип:

Простота - мистецтво максимізувати обсяг незаробленої роботи - є суттєвим.

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

Подумайте "садівництво" над "архітектурою" - створіть культуру життя, зростаючий дизайн

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

Інші прочитані:

• https://less.works/less/technical-excellence/architecture-design.html