Бизнис

Architecting for Sustainable Delivery: Beyond Feature Velocity

Архитектура за одржлива испорака: Надвор од брзината на развој на функционалности

Брзината на испорака на функционалности лесно се слави затоа што е видлива. Се објавува издание, ставка од патоказот ја менува бојата и тимот може да посочи нешто ново што клиентите можат да го користат. Тие моменти се важни. Но, продуктна организација изградена само околу брзината на своето следно издание на крајот ја плаќа таа брзина со побавни одлуки, кревки системи, нејасна одговорност и исцрпени луѓе.

Одржливата испорака не е спротивност на брзото движење. Таа е способност постојано да се прават корисни промени без непрекинато да се зголемуваат трошокот, ризикот и координацијата потребни за следната. За тоа е потребна архитектура, но не само софтверска архитектура. Потребни се и јасни продуктни граници, здрави тимски навики и заедничка дефиниција за тоа што значи работата да биде завршена.

Брзината е резултат, а не стратегија

Тимот може да изгледа брз, додека акумулира сериозни ограничувања. Можеби испорачува заобиколно решение затоа што основниот модел е нејасен. Можеби секоја промена бара неколку луѓе да се усогласат низ повеќе услуги. Можеби проблемите со поддршката се решаваат херојски, но никогаш не се претвораат во продуктни или инженерски подобрувања.

Ниту еден од овие проблеми нужно не спречува издание оваа недела. Тие го отежнуваат следниот квартал.

Затоа, техничките лидери треба да гледаат подалеку од прашањето: „Колку функционалности испорачавме?“ Корисни придружни прашања се:

  • Со колкава сигурност можеме да ја измениме оваа област од продуктот?
  • Кој може да донесе и потврди одлука кога вообичаениот експерт не е достапен?
  • Кој проблем на клиентот го решава оваа работа и како ќе знаеме?
  • Кои кратенки се намерни, документирани и достапни за повторно разгледување?
  • Дали ова издание ја поедностави идната работа или ја направи поповрзана?

Овие прашања не ги заменуваат метриките за испорака. Тие им даваат контекст. Тим што испорачува помалку ставки за краток период додека отстранува тесно грло можеби го зголемува својот вистински капацитет. Тим што испорачува долг список мали дополнувања, додека секој работен тек го прави позаплеткан, можеби го намалува.

Дизајнирајте за промени на продуктната граница

Разговорите за архитектура често почнуваат со бази на податоци, услуги, рамки или cloud инфраструктура. Тие избори се важни, но најскапите неуспеси често започнуваат порано: тимот не ја направил продуктната граница доволно јасна.

Разгледајте барање да се „додаде одобрување на сметка“. Таа фраза може да крие неколку различни потреби: спречување неовластен пристап, воведување работен тек за преглед, собирање информации за усогласеност или едноставно овозможување администраторот да ги контролира поканите. Секое толкување подразбира различни податоци, дозволи, кориснички патувања, оперативни одговорности и начини на откажување.

Одржливиот тим накратко забавува на оваа граница. Ги идентификува актерот, одлуката, промените на состојба и неприфатливите исходи. Потоа го избира најмалиот дизајн што може да ги изрази тие потреби без да се преправа дека решава неповрзани идни проблеми.

Користете точки на раздвојување, а не шпекулативна механизација

Добрата архитектура создава точки на раздвојување каде што промените се веројатни. Таква точка може да биде добро дефиниран модул, стабилен интерфејс, посебен работен тек или јасно поседуван модел на податоци. Таа не е автоматски нов микросервис, слој на апстракција или систем за конфигурација.

На пример, ако правилата за одобрување може да се развиваат, изолирајте ја одлуката зад фокусирана компонента наместо да расфрлате проверки низ контролери, позадински задачи и код за корисничкиот интерфејс. Првата имплементација може да остане едноставна. Важно е остатокот од продуктот да поставува едно јасно прашање, наместо да вградува сопствена верзија на правилото.

Разликата е важна. Точка на раздвојување ги зачувува опциите. Шпекулативната механизација создава обврски за одржување пред да постојат докази дека е потребна.

Направете ја одговорноста конкретна

Одговорноста често се опишува како начин на размислување. Во пракса, таа мора да биде воочлива. Некој треба да знае за кои исходи е одговорна одредена продуктна област, што значат нејзините оперативни сигнали, каде се наоѓаат нејзините важни одлуки и како работата влегува во нејзината редица.

Тоа не значи дека едно лице станува постојан чувар на влезот. Всушност, систем што зависи од еден експерт има слаба, а не силна одговорност. Трајната одговорност го распределува контекстот, а одговорноста ја задржува јасна.

Корисен тимски договор наведува:

  • која продуктна или системска област е во сопственост;
  • кои исходи за клиентите и бизнисот се важни;
  • кој тим е одговорен за секојдневните одлуки и одржување;
  • кои интерфејси и зависности бараат координација;
  • каков се очекува одговор кога нешто ќе откаже или повратните информации од клиентите ќе откријат празнина.

Одговорноста исто така го менува начинот на кој тимовите го третираат одржувањето. Дефектите, збунувачките работни текови, бавните пребарувања, недостапните интеракции, ненадежните распоредувања и нејасната документација не се прекини на „вистинската“ продуктна работа. Тие се докази за продуктот што клиентите навистина го доживуваат.

На оддалечените тимови им се потребни намерно осмислени оперативни системи

Работата од далечина ги прави скриените претпоставки поскапи. Во канцеларија, нејасна одлука може да се поправи во разговор во ходник. Низ временски зони, двосмисленоста може да остане недопрена еден ден, а потоа повторно да се појави како преработка во pull request или доцнење на изданието.

Одговорот не е повеќе состаноци. Тој е лесен оперативен систем за одлуки.

Запишете го проблемот пред да дебатирате за решението. Запишувајте ги одлуките таму каде што луѓето што се засегнати можат да ги најдат. Нека асинхроните ажурирања одговараат на прашањата што колега инаку би требало да ги постави. Користете ги состаноците за несогласувања, компромиси и градење односи; користете пишани артефакти за траен контекст.

Заменете го статусниот театар со корисни сигнали

Доброто ажурирање не е список на активности. „Работевме на миграцијата“ му остава на читателот повеќе прашања отколку одговори. Посилно ажурирање кажува што се променило, што останува неизвесно, која одлука е потребна и кој ризик може да влијае на испораката.

На пример: „Миграцијата сега ги обработува постојните сметки и новите пријавувања при тестирање. Преостанатата одлука е дали одобренијата што чекаат треба да истечат. Без таа одлука, опсегот на изданието сè уште е стабилен, но работниот тек на поддршката не е.“

Овој стил го почитува вниманието и ја олеснува соработката. Исто така, ги учи тимовите рано да ја изложуваат неизвесноста, кога е најевтино да се реши.

Вградете квалитет во патот до продукција

Квалитетот не треба да биде церемонијална фаза на крајот од развојот. Тој е збир од повратни јамки вградени во начинот на кој работата се движи од идеја до продукција.

За значајна промена, тоа може да вклучува јасен пат за прифаќање, преглед на код, автоматизирани проверки соодветни на ризикот, начин да се набљудува резултатот по изданието и план за враќање назад или ограничување на штетата. Точниот процес ќе варира. Промена на текст и работен тек поврзан со плаќања не треба да носат ист товар.

Важниот принцип е пропорционалноста. Тимовите губат доверба кога секоја промена бара тежок процес. Тие исто така губат доверба кога важните промени се потпираат на оптимизам. Зрелата испорака го приспособува нивото на грижа кон потенцијалната последица од тоа да се биде во грешка.

Кога распоредувањата се рутински, тимовите можат безбедно да се подобруваат во помали чекори. Помалите чекори ги скратуваат циклусите на повратни информации, го намалуваат опсегот на враќањето назад и го олеснуваат учењето која промена го произвела кој исход. Тоа не е само инженерска предност; тоа е продуктно учење со поздраво темпо.

Развивајте кариери со зголемување на влијанието

За развивачите, одржливата испорака е и кариерна вештина. Силните придонесувачи прават повеќе од завршување на доделените тикети. Тие ја прават следната корисна акција појасна за луѓето околу нив.

Тоа може да значи разјаснување на барање пред да започне имплементацијата, документирање неочигледна одлука, подобрување на тест околу повторлив дефект или забележување дека зависност создава избегливо доцнење. Може да значи и спротивставување на нагонот секој проблем да се реши самостојно. Барањето ран преглед често е знак на расудување, а не на слабост.

Техничкото лидерство е видливо во квалитетот на одлуките што тимот може да ги донесе откако сте споделиле контекст, а не во бројот на одлуки што мора да поминат низ вас.

Трајната предност

Корисните дигитални продукти ретко се резултат на едно драматично издание. Тие произлегуваат од многу одговорни одлуки: избор на јасна граница, правење на компромисите експлицитни, третирање на одржувањето како продуктна работа и помагање на луѓето да соработуваат без да се потпираат на постојана достапност.

Брзината на испорака на функционалности сè уште е важна. Клиентите заслужуваат напредок. Но, најотпорните тимови го мерат напредокот според подлабок стандард: дали стануваат поспособни да ја испорачаат следната вредна промена. Градете за таа способност, и брзината станува помалку спринт што треба да се одржува, а повеќе својство на организацијата.

Портрет на автор на блогот

Mihajlo

Јас сум Михајло - развивач поттикнат од љубопитност, дисциплина и постојаната желба да создадам нешто значајно. Споделувам увиди, упатства и бесплатни услуги за да им помогнам на другите да ја поедностават својата работа и да растат во постојано развивачкиот свет на софтверот и вештачката интелигенција.