Як архітектори можуть працювати з самоорганізуючими командами Scrum?

Організація з низкою спритних команд Scrum також має невелику групу людей, призначених «архітекторами підприємств». Група EA виконує функції контролю та якості дотримання рішень. Це призводить до перекриттів між командним рішенням та рішенням ЕО.

Наприклад, команда може захотіти використовувати бібліотеку X або використовувати REST замість SOAP, але EA не схвалює цього.

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

Провідники Scrum мають про це сказати:

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

Це розумно? Чи слід розпустити команду ЕА? Чи повинні команди відмовитись або просто виконати їх?

Команду розвитку складають 3–9 людей з крос-функціональними навичками, які виконують фактичну роботу

Scrum Master повинен запропонувати «Enterprise Architect» стати частиною команди проекту. Тоді спілкування між архітектором та програмістами було б чудовим.

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

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

Архітектори не говорять розробникам, як перетворити відставання на прирости (спринти), вони кажуть, які технології можна використовувати, а які не можна використовувати. Ви плутаєте дві різні проблеми.

Рішення - нічого не змінювати. Якщо ваші команди розчаровуються через те, що архітектори занадто обмежуючі або занадто владні, це кадрове питання, яке не має нічого спільного з SCRUM, і його слід вирішувати з бізнес-зацікавленими сторонами як питання задоволення працівників і, якщо можливо, підсумкового рядка ("На x%розробку функцій знадобиться більше часу, yоскільки архітектор zне дозволить нам використовувати Turbo Pascal.")

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

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

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

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

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

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

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

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

З цим пов'язано нещодавню книгу Діна Леффінгвела про Agile Software Requirements , яку я читав сам.

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

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

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

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

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

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

Деякі з цих вимог встановлюються політикою компанії. І вони встановлюють основні правила:

• Команда повинна буде дотримуватися їх, як і будь-які інші вимоги. Оскарження політики після цього просто виходить за межі проекту і має розглядатися окремо.
• Завдання EA - виконувати ці вимоги, а не нав'язувати їх особисті фантазії. Їм не подобається X, то це їхня особиста думка. Нічого більше, нічого менше. Ставтесь до цього, як до будь-якої іншої думки. Однак якщо ЕА може показати, що використання X порушує існуючу вимогу, то вони в межах свого права забороняють використовувати X, і якщо вони знають працездатну альтернативу, а команда цього не робить, то це їхнє право виконувати.

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

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

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

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

Ви цитували Посібник з Scrum: "Ніхто (навіть навіть майстер Scrum) не розповідає команді розробників, як перетворити" Блокування продукту "на збільшення потенційно звільненого функціоналу".

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

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

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

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