Как мас­шта­би­ро­вать Agile?

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Алек­сей Ио­нов, Дмит­рий Вол­ков

Се­год­ня ма­ло кто со­мне­ва­ет­ся в эф­фек­тив­но­сти ко­манд, ор­га­ни­зо­ван­ных на прин­ци­пах Agile, од­на­ко при мас­шта­би­ро­ва­нии это­го под­хо­да на уро­вень всей ком­па­нии воз­ни­ка­ет мно­го пре­пят­ствий.

Се­год­ня ма­ло кто со­мне­ва­ет­ся в эф­фек­тив­но­сти ко­манд, ор­га­ни­зо­ван­ных на прин­ци­пах Agile, од­на­ко при мас­шта­би­ро­ва­нии это­го под­хо­да на уро­вень всей ком­па­нии воз­ни­ка­ет мно­го пре­пят­ствий.

Клю­че­вые сло­ва: Keywords: Agile, SAFE

Влю­бой ор­га­ни­за­ции, пред­ла­га­ю­щей рын­ку ка­кой-ли­бо про­дукт, обыч­но ве­дет­ся три ви­да де­я­тель­но­сти: но­ва­ция (раз­ра­бот­ка кон­цеп­ции) про­дук­та, соб­ствен­но раз­ра­бот­ка (из­го­тов­ле­ние), до­став­ка до ко­неч­но­го по­тре­би­те­ля или со­про­вож­де­ние про­дук­та. Как пра­ви­ло, эти ра­бо­ты вы­пол­ня­ют­ся от­дель­ны­ми ко­ман­да­ми со­труд­ни­ков. При по­стро­е­нии эф­фек­тив­ной раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния мно­гие ко­ман­ды се­год­ня ак­тив­но при­дер­жи­ва­ют­ся фи­ло­со­фии Agile, но ком­па­ни­ям од­ной ко­ман­ды раз­ра­бот­чи­ков обыч­но недо­ста­точ­но. Кро­ме то­го, ведь нуж­но не толь­ко раз­ра­ба­ты­вать ПО, но и вы­пол­нять дру­гие ра­бо­ты в рам­ках пе­ре­чис­лен­ных ви­дов де­я­тель­но­сти. По­это­му неиз­беж­но тре­бу­ет­ся про­во­дить мас­шта­би­ро­ва­ние Agile-ко­манд до кор­по­ра­тив­но­го уров­ня. Но тут воз­ни­ка­ют три пре­пят­ствия: бюд­же­ти­ро­ва­ние, ар­хи­тек­ту­ра про­дук­та и ор­га­ни­за­ци­он­ная струк­ту­ра. Из­вест­но несколь­ко под­хо­дов к та­ко­му мас­шта­би­ро­ва­нию : Nexus, RAGE, DAD, LESS, APM, SOS и SAFE (см. врез­ку). Как обой­ти каж­дое из на­зван­ных пре­пят- ствий на этом пу­ти, раз­бе­рем на при­ме­ре SAFE [1–3] — наи­бо­лее по­пу­ляр­но­го се­год­ня фрейм­вор­ка.

БЮД­ЖЕ­ТИ­РО­ВА­НИЕ

Чем бюд­же­ти­ро­ва­ние в гиб­ких ор­га­ни­за­ци­ях от­ли­ча­ет­ся от клас­си­че­ско­го? «Клас­си­че­ское» бюд­же­ти­ро­ва­ние — это все рав­но как за­гру­зить са­мо­свал день­га­ми и по­ста­вить его на сто­ян­ку до то­го мо­мен­та, ко­гда бу­дет при­ня­то ре­ше­ние: от­гру­жать ис­пол­ни­те­лю день­ги или нет. Всем участ­ни­кам про­цес­са невы­год­но из­ме­нять из­на­чаль­но со­гла­со­ван­ные объ­е­мы ра­бот и сро­ки, по­сколь­ку име­ет­ся фик­си­ро­ван­ный бюд­жет, ко­то­рый нуж­но по­тра­тить. Бюд­же­ти­ро­ва­ние же в гиб­ких ор­га­ни­за­ци­ях мож­но срав­нить с вен­ти­лем, ко­то­рым ли­ца, при­ни­ма­ю­щие ре­ше­ния на уровне порт­фе­ля, по­сто­ян­но управ­ля­ют в за­ви­си­мо­сти от те­ку­щих при­о­ри­те­тов биз­не­са в ре­аль­ном вре­ме­ни. Это поз­во­ля­ет уве­ли­чи­вать или умень­шать фи­нан­со­вый по­ток, ко­то­рый на­пря­мую вли­я­ет на про­из­во­ди­тель­ность ко­манд, со­зда­ю­щих цен­ность для ко­неч­но­го поль­зо­ва­те­ля. При этом по­ток фи­нан­си­ро­ва­ния мо­жет пе­ре­на­прав­лять­ся от од­но­го на­прав­ле­ния к дру­го­му, бо­лее при­о­ри­тет­но­му, ока­зы­вая вли­я­ние не толь­ко на про­из­во­ди­тель­ность, но и на со­дер­жа­ние ра­бот.

А что же при этом фи­нан­си­ру­ет­ся? При «клас­си­че­ском» под­хо­де обя­за­тель­на про­це­ду­ра за­щи­ты бюд­же­та, по­сле че­го он за­креп­ля­ет­ся «на­все­гда», при гиб­ком управ­ле­нии про­ис­хо­дит фи­нан­си­ро­ва­ние по­то­ков со­зда­ния цен­но­сти для ко­неч­но­го по­тре­би­те­ля. Каж­дый та­кой по­ток — это неко­то­рое чис­ло ко­манд, со­об­ща ра­бо­та­ю­щих над со­зда­ни­ем ка­кой-то си­сте­мы ли­бо про­дук­та, ко­то­рый ком­па­ния вы­во­дит на ры­нок. Та­кое управ­ле­ние со­зда­ни­ем цен­но­сти, оче­вид­но, тре­бу­ет до­пол­ни­тель­ных тру­до­за­трат от тех, кто управ­ля­ет бюд­же­том. Но что про­ис­хо­дит при управ­ле­нии бюд­же­том по про­ек­там? По­сле вы­де­ле­ния средств на про­ект ко­ман­да за­каз­чи­ка пол­но­стью пе­ре­да­ет от­вет­ствен­ность за все ра­бо­ты ко­ман­де ис­пол­ни­те­ля, что су­ще­ствен­но уве­ли­чи­ва­ет рис­ки непо­лу­че­ния ожи­да­е­мо­го за­каз­чи­ком ре­зуль­та­та к кон­цу про­ек­та. Это­го мож­но из­бе­жать толь­ко то­гда, ко­гда управ­ле­ние бюд­же­том и при­о­ри­те­та­ми с уча­сти­ем за­каз­чи­ка про­ис­хо­дит в ре­жи­ме ре­аль­но­го вре­ме­ни.

В клас­си­че­ской ор­га­ни­за­ции обыч­но име­ют­ся под­раз­де­ле­ние, при­ни­ма­ю­щее ре­ше­ния, и ис­пол­ни­тель­ный ап­па­рат, а в гиб­кой для при­ня­тия ре­ше­ний пред­ла­га­ет­ся ис­поль­зо­вать несколь­ко до­ступ­ных всем сущ­но­стей: «стра­те­ги­че­ские те­мы», «меч­та» (или «ви­де­ние») и «клю­че­вые да­ты». Стра­те­ги­че­ские те­мы — это спо­со­бы ве­де­ния биз­не­са, тех­но­ло­гии или ре­ше­ния, на ко­то­рых ком­па­ния кон­цен­три­ру­ет­ся в дан­ный мо­мент вре­ме­ни. Меч­та — кар­тин­ка «иде­аль­но­го» для вы­пус­ка­е­мо­го про­дук­та ми­ра, в ко­то­рый ком­па­ния во­вле­ка­ет сво­е­го кли­ен­та. Клю­че­вые да­ты — со­бы­тия на рын­ке, внут­ри ком­па­нии ли­бо до­го­во­рен­но­сти с парт­не­ра­ми, к мо­мен­ту на­ступ­ле­ния ко­то­рых нуж­но со­здать мак­си­маль­ную (на­сколь­ко это воз­мож­но) до­пол­ни­тель­ную биз­нес-цен­ность. Вся эта ин­фор­ма­ция до­ступ­на на всех уров­нях гиб­кой ор­га­ни­за­ции: на уровне порт­фе­ля, где при­ни­ма­ют­ся ре­ше­ния о цен­но­сти тех или иных круп­ных ини­ци­а­тив; на уровне

про­грам­мы, где при­ни­ма­ют­ся ре­ше­ния о том, ка­кая функ­ци­о­наль­ность си­стем или про­дук­тов со­зда­ет­ся в первую оче­редь; на уровне ко­манд, где при­ни­ма­ют­ся ре­ше­ния о том, ка­кой кон­крет­ный функ­ци­о­нал сле­ду­ет раз­ра­бо­тать в со­от­вет­ствии с наи­бо­лее важ­ны­ми по­треб­но­стя­ми биз­не­са. Важ­но, что на каж­дом из уров­ней ре­ше­ния при­ни­ма­ют­ся неза­ви­си­мо и один уро­вень не мо­жет дик­то­вать при­о­ри­те­ты дру­го­му. В тер­ми­нах Scrum [4, 5] на каж­дом уровне су­ще­ству­ет свой спи­сок за­дач (backlog), ко­то­рый об­ра­ба­ты­ва­ет­ся сво­им вла­дель­цем про­дук­та (product owner, PO) и сво­ей ко­ман­дой раз­ра­бот­ки.

Для га­ран­ти­ро­ван­но­го по­лу­че­ния ре­зуль­та­та при гиб­кой раз­ра­бот­ке обя­за­тель­но ис­поль­зу­ют­ся цик­лы об­рат­ной свя­зи, а са­ма раз­ра­бот­ка ве­дет­ся ин­кре­мен­таль­но, ите­ра­ци­я­ми. По­сколь­ку од­но­вре­мен­но ра­бо­та­ют мно­го ко­манд, уже недо­ста­точ­но ста­вить за­да­чи на од­ну ите­ра­цию (спринт) — нуж­но пла­ни­ро­вать три-че­ты­ре сприн­та впе­ред, для то­го что­бы эф­фек­тив­но син­хро­ни­зи­ро­вать ра­бо­ту ко­манд и оп­ти­маль­но ис­поль­зо­вать вре­мя на ком­му­ни­ка­ции. При раз­ра­бот­ке крайне важ­но ис­поль­зо­вать непре­рыв­ную сбор­ку (continuous integration, CI) и непре­рыв­ную до­став­ку (continuous delivery, CD), по­сколь­ку го­ри­зонт пла­ни­ро­ва­ния мо­жет в точ­но­сти не сов­па­дать с да­та­ми, ко­гда нуж­но до­став­лять но­вую функ­ци­о­наль­ность кли­ен­там. При­ме­не­ние CI/CD обес­пе­чи­ва­ет воз­мож­ность асин­хрон­но­го вы­пус­ка про­дук­тов по от­но­ше­нию к цик­лам пла­ни­ро­ва­ния. Здесь нуж­но за­ме­тить, что под пла­ни­ро­ва­ни­ем по­ни­ма­ет­ся ори­ен­ти­ро­воч­ный спи­сок це­лей, сфор­му­ли­ро­ван­ных в биз­нес-тер­ми­нах, ко­то­рый функ­ци­о­ни­ру­ет по­верх спис­ков за­дач на сприн­ты (sprint backlog), ес­ли ко­ман­да ис­поль­зу­ет ме­то­до­ло­гию Scrum.

Ко­ман­ды каж­до­го уров­ня са­ми ре­ша­ют, сто­ит ли про­ве­рять те или иные биз­нес-ги­по­те­зы и ре­а­ли­зо­вы­вать тот или иной функ­ци­о­нал в про­дук­те. Это осо­бен­но важ­но на уровне круп­ных ини­ци­а­тив, по­сколь­ку вли­я­ет на мно­же­ство лю­дей внут­ри и вне ор­га­ни­за­ции. Круп­ные ини­ци­а­ти­вы в Agile-раз­ра­бот­ке при­ня­то на­зы­вать «эпи­ка­ми» (от ан­гл. epic — «эпи­че­ский», «эпо­халь­ный», «гран­ди­оз­ный»). Все эпи­ки про­хо­дят про­це­ду­ру рас­смот­ре­ния — оцен­ку це­ле­со­об­раз­но­сти и жиз­не­спо­соб­но­сти идеи. По су­ти, про­ект в клас­си­че­ской ор­га­ни­за­ции со­от­вет­ству­ет эпи­ку в гиб­кой, од­на­ко есть су­ще­ствен­ное от­ли­чие: ес­ли про­ект утвер­жден, от­вет­ствен­ный за него уже не мо­жет до­пу­стить невы­пол­не­ние дан­но­го про­ек­та пол­но­стью, от на­ча­ла до кон­ца.

С эпи­ком де­ла об­сто­ят ина­че: каж­дый эпик яв­ля­ет­ся некой биз­нес-ги­по­те­зой, ко­то­рая су­лит ком­па­нии до­пол­ни­тель­ную цен­ность, но при этом все хо­ро­шо по­ни­ма­ют, что на эта­пе на­ча­ла ра­бо­ты над эпи­ком нель­зя точ­но ска­зать, как имен­но бу­дет вы­гля­деть раз­ра­ба­ты­ва­е­мый функ­ци­о­нал. Ес­ли цен­ность биз­нес-ги­по­те­зы до­ста­точ­но вы­со­ка, то раз­ра­бот­ка на­чи­на­ет­ся и при этом не обя­за­тель­но сдать 100% функ­ци­о­на­ла, ко­то­рый был пред­по­ло­жен на эта­пе одоб­ре­ния. Вполне нор­маль­на си­ту­а­ция, ко­гда при­ни­ма­ет­ся ре­ше­ние об оста­нов­ке ра­бот по эпи­ку в се­ре­дине пу­ти, по­сколь­ку ли­бо уже был до­стиг­нут необ­хо­ди­мый уро­вень воз­вра­та ин­ве­сти­ций, ли­бо на прак­ти­ке по­лу­че­но под­твер­жде­ние несо­сто­я­тель­но­сти ги­по­те­зы.

АР­ХИ­ТЕК­ТУ­РА

Клю­че­вое от­ли­чие гиб­кой раз­ра­бот­ки круп­ных си­стем за­клю­ча­ет­ся в том, что раз­го­вор идет не об ар­хи­тек­ту­ре про­дук­та или ре­ше­ния, а об ар­хи­тек­тур­ных на­ме­ре­ни­ях, фор­му­ли­ру­е­мых чле­на­ми ко­манд раз­ра­бот­чи­ков. При клас­си­че­ском под­хо­де эти ре­ше­ния при­ни­ма­ют­ся ис­клю­чи­тель­но вы­де­лен­ным ар­хи­тек­то­ром или ко­ман­дой ар­хи­тек­то­ров. В ма­ни­фе­сте гиб­кой раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния Agile Manifesto (agilemanifesto.org/iso/ru/manifesto.html) чет­ко ска­за­но, что луч­шие ар­хи­тек­тур­ные ре­ше­ния соз­да­ют­ся чле­на­ми са­мо­ор­га­ни­зу­ю­щих­ся ко­манд. Этот принцип обя­за­тель­но дол­жен ис­поль­зо­вать­ся и при мас­шта­би­ро­ва­нии Agile-раз­ра­бот­ки. Ар­хи­тек­тор вы­пол­ня­ет

функ­ции «за­да­ю­ще­го на­чаль­ное на­прав­ле­ние» и обес­пе­чи­ва­ет син­хро­ни­за­цию идей, ко­то­рые раз­ра­ба­ты­ва­ют ко­ман­ды (рис. 1). Та­ким об­ра­зом, с од­ной сто­ро­ны, его оцен­ка не до­ми­ни­ру­ет, а с дру­гой, он иг­ра­ет роль фа­си­ли­та­то­ра (то есть ком­му­ни­ка­то­ра), обес­пе­чи­ва­ю­ще­го эф­фек­тив­ное вза­и­мо­дей­ствие ко­манд в ча­сти ар­хи­тек­ту­ры. Еще од­на за­да­ча ар­хи­тек­то­ра — обес­пе­чи­вать со­блю­де­ние ко­ман­да­ми ар­хи­тек­тур­ных на­ме­ре­ний или до­го­во­рен­но­стей, ко­то­рые они уже опре­де­ли­ли.

Ар­хи­тек­тур­ные на­ме­ре­ния пла­ни­ру­ют­ся так на­зы­ва­е­мы­ми го­ри­зон­та­ми: те­ку­щие на­ме­ре­ния, сред­не­сроч­ная пер­спек­ти­ва и бу­ду­щие. При этом чем боль­ше раз­ра­ба­ты­ва­е­мое ре­ше­ние, тем круп­нее бу­дут го­ри­зон­ты. Здесь сто­ит вве­сти еще один тер­мин, по­сколь­ку, кро­ме функ­ци­о­на­ла, раз­ра­ба­ты­ва­е­мо­го для ко­неч­но­го поль­зо­ва­те­ля, обыч­но име­ет­ся еще мно­же­ство тех­ни­че­ских ар­хи­тек­тур­ных за­дач, необ­хо­ди­мых для ра­бо­ты это­го функ­ци­о­на­ла, — так на­зы­ва­е­мые эней­б­ле­ры (enablers — дви­жу­щие, или раз­ре­ша­ю­щие, за­да­чи). При пла­ни­ро­ва­нии ар­хи­тек­тур­ных го­ри­зон­тов эней­б­ле­ры при­мер­но рас­став­ля­ют­ся внут­ри спис­ков за­дач в со­от­вет­ствии с тем, как бу­дет ре­а­ли­зо­вы­вать­ся функ­ци­о­нал для ко­неч­но­го поль­зо­ва­те­ля. А даль­ше, в про­цес­се ра­бо­ты, мож­но от­сле­жи­вать, ка­кое ко­ли­че­ство эней­б­ле­ров бы­ло ис­поль­зо­ва­но для ре­а­ли­за­ции то­го или ино­го функ­ци­о­на­ла. Та­кой ме­ха­низм поз­во­ля­ет из­бе­жать ненуж­ных ин­ве­сти­ций в тех­но­ло­ги­че­скую плат­фор­му. Все это но­сит на­зва­ние «управ­ле­ние ар­хи­тек­тур­ным рус­лом» (managing the architectural runway).

Есть еще од­но важ­ное от­ли­чие про­цес­са со­зда­ния ар­хи­тек­ту­ры в гиб­ких ком­па­ни­ях. При клас­си­че­ском под­хо­де каж­дое ре­ше­ние рас­смат­ри­ва­ет­ся как за­кон­чен­ный про­ект, и, та­ким об­ра­зом, оно долж­но быть иде­аль­но са­мо по се­бе, а зна­чит, ар­хи­тек­ту­ра долж­на быть, на­при­мер, са- мой де­ше­вой, са­мой «пра­виль­ной», са­мой ин­те­гри­ро­ван­ной ли­бо са­мой «кра­си­вой». При гиб­ком под­хо­де рас­смат­ри­ва­ет­ся ре­ше­ние, обес­пе­чи­ва­ю­щее гиб­кость с точ­ки зре­ния раз­ви­тия, по­это­му при­ве­ден­ные кри­те­рии не под­хо­дят. При гиб­кой раз­ра­бот­ке си­стем в первую оче­редь ис­поль­зу­ют­ся са­мые про­стые и наи­бо­лее лег­ко из­ме­ня­е­мые ре­ше­ния.

Мо­но­по­лия на ин­но­ва­ции в тра­ди­ци­он­ных ор­га­ни­за­ци­ях, при ко­то­рой воз­мож­ность со­зда­вать ин­но­ва­ции за­креп­ле­на за кон­крет­ным че­ло­ве­ком или груп­пой лю­дей, иг­ра­ет про­тив ком­па­нии. В гиб­кой ор­га­ни­за­ции обес­пе­чи­ва­ют­ся усло­вия, при ко­то­рых каж­дый член ко­ман­ды мо­жет пред­ло­жить но­вые под­хо­ды, но­вые ре­ше­ния ли­бо из­ме­не­ния су­ще­ству­ю­щих про­цес­сов. Для это­го в гра­фи­ке ра­бо­ты ко­манд за­кла­ды­ва­ет­ся вре­мя на со­зда­ние ин­но­ва­ций. На­при­мер, по­сле то­го как ко­ман­да от­ра­бо­та­ет три или че­ты­ре ите­ра­ции над про­дук­том, она по­лу­ча­ет це­лую ите­ра­цию на то, что­бы ста­би­ли­зи­ро­вать раз­ра­бо­тан­ный функ­ци­о­нал и по­ра­бо­тать над ин­но­ва­ци­я­ми. С точ­ки зре­ния управ­ле­ния про­цес­сом раз­ра­бот­ки по­след­няя ите­ра­ция так­же ис­поль­зу­ет­ся для про­ве­де­ния пла­ни­ро­ва­ния, ко­гда про­хо­дит «кон­фе­рен­ция раз­ра­бот­чи­ков», на­прав­лен­ная на пла­ни­ро­ва­ние ин­кре­мен­та про­дук­та (PI Planning) или си­сте­мы.

Ра­бо­ту над ар­хи­тек­ту­рой нель­зя рас­смат­ри­вать как еди­но­вре­мен­ную за­да­чу — ар­хи­тек­тур­ная раз­ра­бот­ка долж­на пред­став­лять со­бой по­сто­ян­ный по­ток ра­бот, для управ­ле­ния ко­то­рым в Agile обыч­но ис­поль­зу­ет­ся ме­то­до­ло­гия Кан­бан [5].

ОР­ГА­НИ­ЗА­ЦИ­ОН­НАЯ СТРУК­ТУ­РА

Эф­фек­тив­ное управ­ле­ние тре­бо­ва­ни­я­ми — ос­нов­ная за­да­ча, ко­гда речь идет о раз­ра­бот­ке про­дук­та или ре­ше­ния. Преж­де чем опи­сы­вать струк­ту­ру управ- ле­ния в гиб­ких ор­га­ни­за­ци­ях, по­смот­рим на две ча­сто встре­ча­ю­щи­е­ся прак­ти­ки пе­ре­ко­сов в управ­ле­нии тре­бо­ва­ни­я­ми. Пер­вая за­клю­ча­ет­ся в том, что все ре­ше­ния при­ни­ма­ют­ся ру­ко­вод­ством цен­тра­ли­зо­ван­но, при этом ко­ман­ды яв­ля­ют­ся ис­клю­чи­тель­но ис­пол­ни­те­ля­ми во­ли вы­ше­сто­я­щих; та­кая струк­ту­ра по­лу­чи­ла на­зва­ние «дик­та­то­ры и бур­ла­ки». Вто­рая за­клю­ча­ет­ся в из­лиш­ней гиб­ко­сти, гра­ни­ча­щей с ха­о­сом. Вы­ше­сто­я­щим ру­ко­вод­ством озву­чи­ва­ют­ся некие «меч­ты», ко­то­рые долж­ны быть ре­а­ли­зо­ва­ны ко­ман­да­ми без уча­стия са­мих «меч­та­те­лей»; та­кая струк­ту­ра на­зы­ва­ет­ся «меч­та­те­ли и ви­но­ва­тые», по­сколь­ку в ней «ви­но­ва­тые» не мо­гут удо­вле­тво­рить «меч­ты» ру­ко­во­ди­те­лей.

В гиб­кой ор­га­ни­за­ции на каж­дом уровне ре­ше­ния при­ни­ма­ют­ся мак­си­маль­но неза­ви­си­мо, та­кие уров­ни мож­но на­звать «уров­ня­ми кас­ка­ди­ро­ва­ния», по­сколь­ку они не яв­ля­ют­ся, стро­го го­во­ря, вер­ти­каль­ной иерар­хи­ей. Са­мый гло­баль­ный уро­вень при­ня­тия ре­ше­ний на­зы­ва­ет­ся «Порт­фель», за ним сле­ду­ют уров­ни «Про­грамм» и «Ко­манд». Тре­бо­ва­ния, ко­то­ры­ми управ­ля­ют на каж­дом из этих уров­ней, со­от­вет­ствен­но на­зы­ва­ют­ся «Эпи­ки» (под­ра­зу­ме­ва­ю­щие под со­бой круп­ные ини­ци­а­ти­вы), «Фи­чи» (ино­гда «Те­мы», под ко­то­ры­ми ча­сто по­ни­ма­ет­ся при­ня­тие ре­ше­ний на уровне от­дель­ных си­стем или про­дук­тов) и «Поль­зо­ва­тель­ские ис­то­рии» (или «Ис­то­рии», где рас­смат­ри­ва­ют­ся кон­крет­ный функ­ци­о­нал или свой­ства про­дук­тов).

Пред­ста­ви­те­ли ка­ких ро­лей нуж­ны на каж­дом из этих уров­ней? В Scrum тре­бу­ет­ся на­ли­чие трех ро­лей: Scrum­ма­стер, вла­де­лец про­дук­та и раз­ра­бот­чик. Ко­гда несколь­ко ко­манд объ­еди­ня­ют­ся в «Про­грам­му» (при раз­ра­бот­ке, на­при­мер, од­ной биз­нес-си­сте­мы), то на этом уровне «ко­ман­ды ко­манд» долж­ны при­сут­ство­вать вла­де­лец про­дук­та и Scrum­ма­стер, но по­яв­ля­ет­ся так­же ар­хи­тек­тор — ком­му­ни­ка­тор, по­мо­га­ю­щий ко­ман­дам сов­мест­но ра­бо­тать в ча­сти ар­хи­тек­ту­ры (рис. 2). Нель­зя за­бы­вать об об­щих сер­ви­сах, ко­то­рые все­гда при­сут­ству­ют в круп­ной ор­га­ни­за­ции и ко­то­рые, к со­жа­ле­нию, нере­аль­но вклю­чить в со­став кросс-функ­ци­о­наль­ных ко­манд раз­ра­бот­ки. Это, на­при­мер, ди­зай­не­ры, спе­ци­а­ли­сты, обес­пе­чи­ва­ю­щие сбор­ку си­сте­мы и ее ин­те­гра­цию, а так­же спе­ци­фи­че­ское те­сти­ро­ва­ние. В за­ви­си­мо­сти от ти­па раз­ра­ба­ты­ва­е­мо­го про­дук­та эти сер­ви­сы мо­гут от­ли­чать­ся. Са­мый гло­баль­ный уро­вень «Порт­фель», ана­ло­гич­но «Про­грам­ме»,

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

Те­перь по­про­бу­ем со­брать эту струк­ту­ру во­еди­но (рис. 3). На уровне эпи­ков су­ще­ству­ет ко­ман­да управ­ля­ю­щих порт­фе­лем — обыч­но это пред­ста­ви­те­ли биз­не­са и экс­пер­ты, ра­бо­та­ю­щие на дру­гих уров­нях и от­ве­ча­ю­щие за про­дукт уров­ня всей ком­па­нии. Имен­но они при­ни­ма­ют ре­ше­ние о том, сто­ит ли за­пус­кать в ра­бо­ту тот или иной эпик. Здесь нуж­но на­пом­нить, что су­ще­ству­ет уро­вень «Фич», на ко­то­ром так­же при­сут­ству­ют лю­ди, участ­ву­ю­щие в оцен­ке цен­но­сти тех или иных ини­ци­а­тив. Та­ким об­ра­зом, управ­ля­ю­щие порт­фе­лем и вла­дель­цы биз­не­са обес­пе­чи­ва­ют из­на­чаль­ное ре­ше­ние о цен­но­сти ини­ци­а­тив. Даль­ше су­ще­ству­ет ар­хи­тек­тур­ный кас­кад, ко­гда на уровне всей ком­па­нии ко­ман­да ар­хи­тек­то­ров об­суж­да­ет вме­сте с управ­ля­ю­щи­ми порт­фе­лем пред­ва­ри­тель­ные ар­хи­тек­тур­ные ре­ше­ния, но даль­ше их за­да­ча за­клю­ча­ет­ся в фа­си­ли­та­ции ар­хи­тек­тур­ных ре­ше­ний, ис­хо­дя­щих от ко­манд раз­ра­бот­ки. Сле­ду­ю­щий кас­кад — про­дук­то­вый. На уровне эпи­ков он за­мы­ка­ет­ся на вла­дель­цев эпи­ков, ко­то­рые по­мо­га­ют как с точ­ки зре­ния тре­бо­ва­ний к са­мо­му про­дук­ту, так и с точ­ки зре­ния ор­га­ни­за­ции эф­фек­тив­ной ра­бо­ты ко­манд. Даль­ше име­ют­ся управ­ля­ю­щие про­дук­та­ми на уровне си­стем и вла­дель­цы про­дук­тов на уровне ко­манд, а так­же ма­сте­ра про­из­вод­ства на уровне си­стем (в SAFE — это RTE, Release Train Engineers) и Scrum­ма­сте­ра ко­манд.

Та­ким об­ра­зом, по­лу­ча­ет­ся от­но­си­тель­но про­стая струк­ту­ра, поз­во­ля­ю­щая мас­шта­би­ро­вать про­цесс раз­ра­бот­ки на боль­шое ко­ли­че­ство ко­манд, со­хра­няя гиб­кость и прин­ци­пы де­цен­тра­ли­за­ции при­ня­тия ре­ше­ний. Для очень круп­ных ор­га­ни­за­ций мо­жет быть недо­ста­точ­но трех уров­ней, в этом слу­чае мо­жет быть вве­ден чет­вер­тый уро­вень кас­ка­ди­ро­ва­ния.

УПРАВ­ЛЕ­НИЕ

SAFE пред­ла­га­ет мно­же­ство идей для ор­га­ни­за­ции про­цес­са управ­ле­ния, но все они ос­но­ва­ны на че­ты­рех прин­ци­пах.

• Мак­си­ми­за­ция цен­но­сти в каж­дый мо­мент вре­ме­ни в про­цес­се раз­ра­бот­ки. Под цен­но­стью по­ни­ма­ет­ся цен­ность для ко­неч­но­го по­тре­би­те­ля или цен­ность раз­ра­ба­ты­ва­е­мо­го ре­ше­ния для биз­не­са.

• Вза­и­мо­дей­ствие на всех уров­нях в сти­ле парт­нер­ства. Ко­гда ко­ман­ды ори­ен­ти­ро­ва­ны на до­сти­же­ние об­щей це­ли при от­сут­ствии кон­ку­рен­ции меж­ду ни­ми, дру­ги­ми ор­га­ни­за­ци­он­ны­ми еди­ни­ца­ми и меж­ду уров­ня­ми управ­ле­ния ор­га­ни­за­ции.

• Пря­мое об­ще­ние. Об­ще­ние « ли­цом к ли­цу» поз­во­ля­ет су­ще­ствен­но со­кра­тить из­держ­ки, неиз­беж­но воз­ни­ка­ю­щие при фор­ма­ли­за­ции про­цес­сов управ­ле­ния.

• Де­цен­тра­ли­за­ция при­ня­тия ре­ше­ний. Ко­ман­ды, рав­но как и участ­ни­ки всех уров­ней кас­ка­ди­ро­ва­ния си­сте­мы, при­ни­ма­ют ре­ше­ния неза­ви­си­мо, а при­ня­тие ре­ше­ния на бо­лее вы­со­ком уровне обыч­но за­пус­ка­ет про­цесс при­ня­тия ре­ше­ний на преды­ду­щем, бо­лее низ­ком уровне.

Кро­ме прин­ци­пов, мож­но от­ме­тить важ­ные управ­лен­че­ские прак­ти­ки. Ре­ше­ния о бюд­же­ти­ро­ва­нии при­ни­ма­ют­ся не на ос­но­ве ре­зуль­та­тов за­щи­ты про­ек­тов, а на ос­но­ве «стра­те­ги­че­ских на­прав­ле­ний раз­ви­тия» ор­га­ни­за­ции, с уче­том «меч­ты» и «клю­че­вых дат», при­чем в ре­жи­ме ре­аль­но­го вре­ме­ни и че­рез управ­ле­ние «по­то­ка­ми со­зда­ния цен­но­сти». Дол­жен быть преду­смот­рен про­цесс одоб­ре­ния ини­ци­а­тив, при ко­то­ром каж­дая ини­ци­а­ти­ва (эпик) рас­смат­ри­ва­ет­ся как ги­по­те­за, ко­то­рую на­до про­ве­рить на прак­ти­ке и ко­то­рая бу­дет вы­пол­не­на в объ­е­ме, опре­де­ля­е­мом в про­цес­се ее ре­а­ли­за­ции. Управ­ле­ние ра­бо­той ко­манд осу­ществ­ля­ет­ся по Scrum и Кан­бан, оцен­ка объ­е­мов про­из­во­дит­ся в услов­ных еди­ни­цах (storypoints), а управ­ле­ние за­да­ча­ми осу­ществ­ля­ет­ся че­рез бэк­ло­ги, об­ра­ба­ты­ва­е­мые са­мо­ор­га­ни­зу­ю­щи­ми­ся ко­ман­да­ми. Пред­ста­ви­те­ли биз­не­са не име­ют пра­ва ре­дак­ти­ро­вать сфор­му­ли­ро­ван­ные це­ли, но мо­гут су­дить о биз­нес-цен­но­сти каж­дой из них, влияя на при­о­ри­те­ты за­дач ко­манд, что по за­вер­ше­нии ин­кре­мен­та про­грам­мы (три-че­ты­ре сприн­та) поз­во­ля­ет оце­нить раз­мер со­здан­ной биз­нес­цен­но­сти.

***

Мас­шта­би­ро­ва­ние Agile-раз­ра­бот­ки — до­ста­точ­но слож­ная за­да­ча, осо­бен­но ес­ли речь идет об ор­га­ни­за­ции с уже сло­жив­ши­ми­ся струк­ту­рой и про­цес­са­ми, од­на­ко се­год­ня это неиз­беж­ный путь, ко­то­рый долж­на прой­ти лю­бая ком­па­ния циф­ро­вой эко­но­ми­ки. В ар­се­на­ле Agile уже име­ют­ся глу­бо­ко про­ра­бо­тан­ные под­хо­ды, ко­то­рые по­мо­гут ре­шить за­да­чу мас­шта­би­ро­ва­ния, и во­прос лишь в том, на­сколь­ко ор­га­ни­за­ции и их ру­ко­во­ди­те­ли го­то­вы к ис­поль­зо­ва­нию прин­ци­пи­аль­но иных ме­то­дов управ­ле­ния.

ЛИТЕРАТУРА

1. 11th annual State-of-agile report, 17 p. Versionone. URL: https://explore.versionone.com/state-of-agile/versionone-11th-annualstate-of-agile-report-2 (да­та об­ра­ще­ния: 05.12.2017).

2. Ан­дрей Ко­сы­гин. Agile и Devops на служ­бе круп­но­го биз­не­са // От­кры­тые си­сте­мы.субд. — 2016. — № 2. — С. 28–29. URL: www.osp.ru/os/2016/02/13049287 (да­та об­ра­ще­ния: 05.12.2017).

3. Scaled Agile Framework. URL: http://www.scaledagileframework.com (да­та об­ра­ще­ния: 05.12.2017).

4. Майк Кон. Scrum: гиб­кая раз­ра­бот­ка ПО/ Пер. с ан­гл. — М.: ООО «И.Д. Ви­льямс», 2011. — 576 с.: ил.

5. Май­кл Ку­зу­ма­но, Мэ­ри Поп­пен­дик. Бе­реж­ли­вая раз­ра­бот­ка про­грамм // От­кры­тые си­сте­мы.субд. — 2012. — № 8. — С. 32–37. URL: https://www.osp.ru/os/2012/08/13019237/ (да­та об­ра­ще­ния: 05.12.2017).

Алек­сей Ио­нов (alexey@ionovpartners.com) — управ­ля­ю­щий парт­нер, ком­па­ния «Ио­нов и Парт­не­ры», Дмит­рий Вол­ков (vlk@keldysh.ru) — со­труд­ник ИПМ им. М.В. Кел­ды­ша РАН, (Москва).

Рис. 2. Принцип мас­шта­би­ро­ва­ния с ис­поль­зо­ва­ни­ем ро­лей Scrum

Рис. 1. Ос­нов­ные прин­ци­пы по­стро­е­ния ар­хи­тек­ту­ры при ис­поль­зо­ва­нии SAFE

Рис. 3. Упро­щен­ное пред­став­ле­ние кас­ка­ди­ро­ва­ния ро­лей в SAFE

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.