Якщо дві команди Scrum використовують один і той же програмний компонент, хто відповідає за забезпечення чіткого архітектурного бачення цього компонента та підтримує / розвиває це бачення у міру розвитку бази коду? У Scrum у вас має бути колективне володіння кодом, тож як переконатися, що розробка, зроблена командою A, не заважає розробці, здійсненій командою B?
Відповіді:
Я не є експертом Scrum, але AFAIK "колективне володіння кодом" мається на увазі для команди та продукту (і, думаю, ваше питання не стосується Scrum, воно може бути застосоване до будь-якого процесу розробки "спільного коду").
Якщо у вас є дві команди A, B, два продукти A, B і спільний компонент C, існують різні можливі сценарії. Можливо, спільний компонент належить насамперед продукту A (і його просто повторно використовують, але не еволюціонують, командою для продукту B). У цій ситуації колектив A явно відповідає за архітектурне бачення. Або навпаки: воно чітко належить до продукту B - тому відповідальність є. Якщо відповідальна команда A, команда B може використовувати вилку компонента, щоб дозволити термінові виправлення (також повинен бути спосіб їх реінтеграції в основний рядок C), але B повинен уникати будь-яких більших еволюцій компонента.
Однак якщо в обох продуктах A і B є багато «вимог до водіння» для C, вам слід керувати C як повністю окремим продуктом, з власним версією, управлінням випуском, управлінням змінами, тестовими одиницями тощо і окремою командою, яка має відповідальність за цей компонент. Ця команда може бути просто "віртуальною командою", що складається з окремих розробників від команди A, B або обох. Ця команда має "спільне володіння кодом" для C та відповідальність за "архітектурне бачення". Подумайте лише про те, як C є компонентом, що постачається стороннім постачальником.
У Scrum чи agile немає поняття "чіткого архітектурного бачення"!
Я давно був архітектором, і мені зрозуміло, що для того, щоб мати архітектурне бачення, потрібно мати чітке уявлення про майбутні вимоги. Оскільки в більшості випадків вимоги зовсім не зрозумілі, не має сенсу мати фіксований зір.
Необхідно мати архітектуру, яка достатньо адаптована до мінливих вимог. Іншими словами, все змінюється, і змінюється архітектура - я не виступаю за "м'яку" архітектуру, яку можна переналаштувати. Я говорю про те, щоб визнати, що архітектура, яка є сьогодні, буде застарілою незабаром і її потрібно буде змінювати, тому ніхто не повинен "одружуватися" з нею.
Колективне володіння кодом означає, що кожен повинен - теоретично - мати можливість що-небудь змінити. Це потрібно розуміти як "протилежність силосу". Іншими словами, на місці може бути бар'єр для навичок, що є нормальним і очікуваним - не кожен є досвідченим DBA, який може точно налаштувати запити SQL, щоб навести приклад - але з цього не випливає, що лише DBA може рука оптимізувати запити. Буде "експерт з доменних функцій", який може допомогти іншим людям стати досвідченими, але завдання все одно повинні покластися на всіх.
Наприклад: якщо я є експертом у галузі доменних функцій "A", я все-таки очікую, що хтось інший буде працювати над функцією "A", але я, мабуть, проконсультуюсь, коли значні зміни повинні відбутися або люди потребують допомоги. Особливість "A", безумовно, не була моєю особливістю. Це буде особливість, яку я добре знаю. Мені буде цікаво дізнатися ще багато особливостей, а інших людей зацікавити цю особливість.
У синтезі: архітектура розробляється та переробляється декілька разів розробниками по мірі появи та зміни вимог. Очікується, що всі мають внести будь-які необхідні зміни відповідно до своїх навичок та знати, коли звернутися за допомогою. Немає довгострокового бачення архітектури, оскільки ми довіряємо людям і не довіряємо вимогам .
Наприклад, для вирішення проблеми spotify використовує роль під назвою "Власник системи" безпосередньо:
Технічно будь-хто може редагувати будь-яку систему. Оскільки команди є ефективно командними командами, їм зазвичай потрібно оновити кілька систем, щоб отримати нову функцію у виробництві. Ризик цієї моделі полягає в тому, що архітектура системи заплутається, якщо ніхто не зосереджується на цілісності системи в цілому.
Для зменшення цього ризику у нас є роль «Власник системи». У всіх системах є власник системи або пара власників системи (ми радимо спарювати). Для експлуатаційно важливих систем Власник системи - це пара Dev-Ops - тобто одна людина з перспективою розробника та одна людина з перспективою операцій.
Власник системи - це особа, яка переходить до будь-яких технічних чи архітектурних питань, пов'язаних із цією системою. Він є координатором і керує людьми, які кодують у цій системі, щоб вони не натикалися один на одного. Він зосереджується на таких речах, як якість, документація, технічна заборгованість, стабільність, масштабованість та процес випуску.
Власник системи - це не вузьке місце або архітектор вежі зі слонової кістки. Він особисто не повинен приймати всі рішення, або писати весь код, або робити всі релізи. Зазвичай він є членом загону або керівником глави, який крім власника системи має інші щоденні обов'язки. Однак час від часу він буде приймати «день власника системи» і робити роботу по догляду за цією системою. Зазвичай ми намагаємось утримувати право власності на цю систему менше ніж на десяту частину часу, але це залежить від систем.
Мені дуже подобається ця ідея, маючи переваги або колективні права власності на рівні компанії (не тільки на рівні команди), але завдяки цьому власники систем намагаються забезпечити певну архітектурну цілісність.
Посилання на повний документ: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , його короткий, але дуже, дуже цікавий документ, заснований на реальному досвіді масштабного масштабування.
Це важко вирішити проблему, і це, звичайно, не вирішується Scrum, який є методологією управління проектами, а не методологією розвитку.
Найефективніше рішення, яке я знайшов, - це гарне управління пакетами (nuget / gem / тощо) та версія. Ніколи не застосовуйте зміни до іншої команди, поки вони не готові споживати її. Нехай вони продовжують використовувати стару збірку, поки ви переходите на нову.
Переконайтеся, що у вас є стратегія версій, яка дає зрозуміти, які зміни порушуються, а які - розширення.
Крім того, коли ви вносите зміни, надішліть огляд коду комусь НА КОЖНІЙ КОМАНДІ. Нехай вони роздивляться, як це може вплинути на них, задовго до того, як їх змусять споживати, щоб вони змогли здійснити свої власні зміни.
І коли речі стають справді безладними; коли одній команді потрібно внести зміни і не може спожити іншу зміну легко (це БУДЬ дійсно рідкісний випадок), роздрібніть код, зробіть це зовсім іншим пакетом, але зробіть пріоритетним повернутися до загального коду, як тільки час дозволяє.
Відповідь, яка не завжди є настільки очевидною, як це могло б, дозволити командам вирішити, як вони поділяться будь-яким компонентом.
Наприклад, нещодавно моя команда почала розробляти нову лінійку продуктів, яка поділяє багато спільного коду з двома іншими командами, які давно розробляють подібні продукти. Наш продукт відрізняється декількома способами, тому нам періодично доводиться розбирати способи додавання точок налаштування до загального коду.
У нас виникли сутички щодо цього коду та спробували декілька різних спеціальних способів вирішити питання спільної власності. Тоді, коли з'явилася нова нова функція, ми вирішили, що нам потрібно зібрати всі команди разом, щоб потрапити на одну і ту ж сторінку, що призвело до меншої групи, що складається з пари членів кожної команди, які розробляють деталі.
Рішення, на яке придумали наші команди, може не спрацювати в іншій ситуації. Можливо, вам знадобиться щось більш просте або щось набагато формальніше. Справа в тому, що ви берете колективну власність і з'ясовуєте, що для вас працює.
Я смію припускати:
Якщо вище припущення є правильними, тоді іноді можуть виникати лише випадки, коли дві команди будуть заважати одна одній. Вони можуть вирішити це за допомогою наступних способів: