11 самых распаўсюджаных прычын выкарыстання маштабаванага Agile Framework (SAFe) і спосабы вырашэння праблемы з нелічыльным Scrum

І таму гэта больш эфектыўна, чым выкарыстанне SAFe

Каб выправіць неэфектыўнасць працы з некалькімі камандамі, часта хтосьці прапануе ўвесці рамкі маштабавання. З вялікай колькасцю каманд, усе віды праблем узнікаюць. Увядзенне рамкі маштабавання гучыць як ідэальнае рашэнне. Так?

Самы вядомы прыклад такіх рамак - Scaled Agile Framework (SAFe). На ўзроўні праграмнага павелічэння SAFe вылучае Scrum як адзін з спосабаў стварэння прырашчэння прадукту. Пры гэтым адаптаваная версія Scrum часта з'яўляецца часткай SAFe.

Калі людзі ўводзяць SAFe, яны ўводзяць дадатковыя падзеі, артэфакты, ролі і правілы. Гэта яшчэ больш павышае складанасць іх асяроддзя, што можа прынесці ўласныя праблемы і праблемы. Часта рызыкі, якія людзі ўводзяць з SAFe, большыя, чым праблемы, якія яны хочуць вырашыць з SAFe.

Аднак самыя распаўсюджаныя прычыны выкарыстання SAFe можна вырашыць, выкарыстоўваючы толькі Scrum, максімальна лёгкі. Я зараз пакажу вам, што вам не трэба SAFe для вырашэння найбольш распаўсюджаных праблем маштабавання.

Паводле cocoparisienne ў Pixabay

1. Упраўленне залежнасцямі каманды, каб забяспечыць павелічэнне

Калі над адным і тым жа прадуктам працуюць некалькі каманд, яны часта залежаць адзін ад аднаго. Каманда A можа запатрабаваць дзеянняў ад каманды B і наадварот. З дапамогай SAFe вы можаце ідэнтыфікаваць такія віды залежнасцей падчас планавання павелічэння Праграмы, як правіла, гледзячы на ​​некалькі спрынтаў.

Scrum мае выдатны спосаб выдаліць гэтую праблему:

"Каманды распрацоўшчыкаў маюць шматфункцыянальную функцыю, валодаючы ўсімі навыкамі, неабходнымі камандзе, каб стварыць павелічэнне прадукту;" - Scrum Guide 2017

Кожная група распрацоўшчыкаў павінна мець магчымасць даставіць працоўную частку прадукту. Калі залежнасці паміж камандамі існуюць, абмяжоўваючы іх у гэтым, то паглядзіце спосабы рэструктурызацыі каманд так, каб залежнасцей больш не было. З гэтай нагоды знікне першая прычына выкарыстання SAFe.

2. Ад бачання да ўзроўню прадукту / выраўноўванне ўзроўню прадпрыемства з узроўнем каманды

Часта прадуктовае бачанне ствараецца далёка ад каманд Scrum, дзе пабудаваны каштоўныя прадукты. З SAFe ёсць дадатковыя пласты (для партфеля і / або вялікіх рашэнняў), прызначаныя для таго, каб дапамагчы сцягнуць зрок на адставанне каманды.

Вось як вы можаце вырашыць гэта з дапамогай Scrum:

"Бэклог прадукту - гэта упарадкаваны спіс усяго, што, як вядома, неабходна ў прадукце. Гэта адзіны крыніца патрабаванняў, якія неабходна ўносіць у прадукт ". - Scrum Guide 2017

Так, Бэклог прадукту - гэта тое, дзе вы прасоўваеце тое, як хочаце перайсці ад бачання да каштоўнасці. Часта вы бачыце, што ўлічваюцца толькі прадметы, якія ўспрымаюцца, неабходныя для наступных некалькіх спрынтаў. У Кіраўніцтве па Scrum цалкам зразумела, што ўсё, што, як вядома, трэба. Гэта не трэба цалкам канкрэтызаваць, вы можаце мець няясныя прадметы, якія ўяўляюць сабой вялікія кавалкі працы.

3. Сумясціце органаў, якія прымаюць рашэнні, і ўладальніка прадукту

Часта рашэнні аб кірунку прадукту знаходзяцца па-за межамі дасяжнасці Уладальніка Прадукту. SAFe забяспечвае гэта з такімі ролямі, як ўладальнік бізнесу і ўладальнік Epic.

Вось як вы можаце вырашыць гэта толькі з Scrum:

"Уладальнік прадукту нясе адказнасць за максімізацыю кошту прадукту, які ўзнікае ў выніку працы групы па распрацоўцы". - Scrum Guide 2017

Калі вы ўключыце ўладальніку прадукту адказнасць за максімальную каштоўнасць прадукту, вам не спатрэбяцца дадатковыя ролі, вызначаныя ў SAFe.

Цяпер вы можаце апынуцца ў іншай сітуацыі, калі адказнасць за прадукт і адказнасць за Бэклог прадукту падзелены. Аднак, каб быць больш эфектыўным у прадуктовым асяроддзі з некалькімі камандамі, падумайце пра змяненне гэтага шляхам пашырэння ролі ўладальніка прадукту.

4. Дайце верхняму ўзроўню арганізацыі механізм кіравання

Людзі, якія знаходзяцца ў верхнім пласце арганізацыі, часта не ведаюць, як менавіта каманды працуюць над стварэннем каштоўных прадуктаў. Яны не адчуваюць, што яны ўдзельнічаюць ці кантралююць. Для гэтага SAFe мае шэраг слаёў і падзей. У няправільных руках, аднак, гэта можа быць выкарыстана няправільна, каб прымусіць кіраваць зверху ўніз.

Scrum прапануе ідэальнае - чыстае і простае - месца, каб ацаніць бягучы статус і абмеркаваць, што рабіць далей:

"Падчас агляду Sprint, Scrum Team і зацікаўленыя бакі супрацоўнічаюць з тым, што зроблена ў Sprint. Зыходзячы з гэтага і любых зменаў у Бэклогу прадукту падчас спрынту, удзельнікі супрацоўнічаюць над наступнымі рэчамі, якія можна зрабіць для аптымізацыі кошту ". - Scrum Guide 2017

Так, агляд Sprint - гэта ваша падзея, калі вы хочаце абмеркаваць бягучы прадукт і рэчы, якія могуць паўплываць на рашэнні, што рабіць далей. Гэта прама і эфектыўна, бо кожны ўдзельнік можа ўдзельнічаць у дыскусіі.

Не мае значэння, якая ваша роля. Калі вы хочаце паўплываць на напрамак прадукту, наведайце агляд спрынту!

5. Сінхранізацыя крокаў дастаўкі / інтэграцыі

У прадуктовай абстаноўцы з некалькімі камандамі цягнікі Agile Release SAFe ёсць для сінхранізацыі дастаўкі да рэлізаў для некалькіх каманд.

З Scrum каманды маюць некалькі спосабаў сінхранізацыі сваёй працы. Галоўнае ў гэтым:

"Некалькі каманд Scrum часта працуюць разам над адным прадуктам. Адзін Бэлог прадукту выкарыстоўваецца для апісання будучай працы над прадуктам. " - Scrum Guide 2017

Гэта азначае наступнае:

1 Бэклог прадукту → 1 Уладальнік прадукту → 1 Павелічэнне прадукту → 1 Спрынтарскі агляд.

Пры гэтым сінхранізацыя ўжо аўтаматычна ўсталёўваецца, таму што ёсць 1 павелічэнне прадукту для праверкі падчас 1 Sprint Review. Эмпірычны падыход да кантролю працэсаў Scrum не павінен быць прызнаны несапраўдным з-за такіх відаў праблем сінхранізацыі выпускаў. Гэта парушыць цыкл зваротнай сувязі.

Замест гэтага калектывы павінны актыўна шукаць шляхі палягчэння інтэграцыі па-сапраўднаму Agile:

"Яны супрацоўнічаюць і ўзаемадзейнічаюць праз складаныя архітэктуры распрацоўкі і асяроддзя мэтавых рэлізаў". - Scrum Guide 2017

6. Павышэнне прадукцыйнасці працы

SAFe часта ўводзіцца для павышэння прадукцыйнасці каманд. Прычынай зніжэння прадукцыйнасці можа быць спалучэнне любога з вышэйзгаданых пытанняў:

  • Упраўленне залежнасцямі каманды, каб забяспечыць павелічэнне;
  • Ад бачання да ўзроўню прадукцыі / узроўню прадпрыемства на ўзроўні каманды;
  • Даць верхняму ўзроўню арганізацыі механізм кіравання;
  • Сінхранізацыя крокаў дастаўкі / інтэграцыі.

Паляпшэнне ў гэтых галінах прывядзе да павышэння прадукцыйнасці працы. Павышэнне прадукцыйнасці працы ў значнай ступені параўноўваецца з традыцыйнымі падыходамі да рэалізацыі праектаў (у раёне вадаспаду).

Я ўжо абмяркоўваў, як эфектыўна зрабіць гэтыя паляпшэнні ў Scrum. У выніку Scrum ужо дапамагае дасягнуць значнага паляпшэння вытворчасці. Для гэтага вам не трэба выкарыстоўваць SAFe.

7. Павелічэнне кошту дастаўкі

SAFe прадстаўлены ў якасці альтэрнатывы традыцыйнаму кіраванню прадуктам. З выкарыстаннем Lean і Agile прынцыпаў і рамак, такіх як Scrum, SAFe засяроджваецца на стварэнні правільнай рэчы. SAFe мае рэгулярныя моманты роздуму, каб забяспечыць гэта.

Аднак большасць гэтых момантаў роздуму ўжо ўкаранілася ў Scrum. Чорт вазьмі, SAFe выкарыстоўвае моманты адлюстравання, вызначаныя ў Scrum (напрыклад, Sprint Review і Sprint Retrospective), патрабуючы толькі дадатковых момантаў адлюстравання з-за дадатковай складанасці.

Што тычыцца Scrum, гэта тое, што гэтыя разважанні - з ключавымі зацікаўленымі бакамі - павінны адбывацца часцей, таму што яны адбываюцца з кожным спрынтам замест кожнай пары спрынтаў (з SAFe). Гэта дазваляе атрымаць больш спрыт, больш магчымасцей прыстасавацца да новых уяўленняў, што ў выніку прыводзіць да больш высокіх шанцаў павялічыць кошт дастаўкі.

8. Павышэнне якасці

SAFe мае "якасць убудаванай якасці". Гэта адзін са спосабаў гарантаваць, што пастаўленая прадукцыя адпавядае стандартам кампаніі. Частка ўбудаванай якасці - гэта вызначэнне каманды "Зроблена".

Аднак Scrum імкнецца зрабіць тое ж самае з азначэннем "Зроблена". Ён ужо павінен утрымліваць стандарты якасці кампаніі. Вызначэнне "зроблена" звычайна вызначаецца на ўзроўні арганізацыі развіцця. Не на ўзроўні каманды.

SAFe падкрэслівае, што якасць убудаванай характарыстыкі пераўзыходзіць азначэнне Scrum "зроблена". Я з гэтым не згодны. Вызначэнне "зроблена" - гэта тое, што з яго складаецца арганізацыя па распрацоўцы. Ён можа ўключаць у сябе тыя ж рэчы, што і якасць убудаванай SAFe.

9. Арганізацыйная схема - што рабіць з усімі людзьмі, якія працуюць над прадуктам?

SAFe мае зручны адказ на пытанне, куды падыходзяць усе людзі з арганізацыі, калі яны працуюць "Agile". З вялікай колькасцю роляў заўсёды знойдзецца месца для ўсіх (кіраванне бізнесам, кіраванне прадуктамі, архітэктары сістэмы, сістэмныя інжынеры, інжынер па выпуску цягнікоў і нават больш для вялікіх рашэнняў).

Наяўнасць усіх гэтых роляў у SAFe дазваляе выказаць здагадку, што яна "лёгка ўпісваецца ў існуючую арганізацыю". Гэта можа выключыць неабходнасць унесці рэальныя - балючыя, але неабходныя - змены ў арганізацыю. З прычыны гэтага арганізацыя выглядае "Agile", але на самой справе не з'яўляецца "Agile", пазбаўляючы ўсіх пераваг працы ў спрытным шляху.

З Scrum, няма такога простага адказу. Scrum ведае толькі тры ролі (уладальнік прадукту, майстар Scrum, член каманды распрацоўшчыкаў) і зацікаўленыя ўдзельнікі. Важна разумець, што гэта ролі Scrum. Гэта не / не павінна супадаць з функцыяй кампаніі.

Scrum - гэта аснова. Ён дае вам палатно, і як вы ствараеце сваю карціну, залежыць толькі ад вас. Вось некалькі прыкладаў, каб вырашыць пытанне, хто куды едзе:

  • Менеджэр па прадуктах можа быць уладальнікам прадукту Scrum або ключавым зацікаўленым бокам;
  • Сістэмны інжынер можа ўваходзіць у склад Распрацоўкі або ключавы ўдзельнік;
  • Сістэмны архітэктар можа ўваходзіць у склад Распрацоўкі або асноўны ўдзельнік;
  • Уладальнік Прадукту, як вызначана SAFe (працуе над Бэк-Бэгам), можа быць часткай групы распрацоўшчыкаў у якасці эксперта па прадуктах альбо быць уладальнікам Прадукту.

Scrum дае вам свабоду рэалізаваць гэта, як вы лічыце, найбольш выгадна. Для гэтага вам не спатрэбяцца дадатковыя ролі ці падзеі. Кожны можа мець месца ў вашым падыходзе да выкарыстання рам Scrum.

10. Кіруйце праграмай з некалькімі прадуктамі

Яшчэ адна прычына ўвядзення SAFe - кіраванне праграмай з некалькімі прадуктамі з вялікай колькасцю залежнасцей.

Вы можаце сцвярджаць, што я ўжо абмяркоўваў залежнасці (тэмы 1 і 5 прыходзяць на розум). Аднак я хачу канкрэтна прапанаваць гэты прыклад некалькіх прадуктаў.

Першае: гэта не змешванне кіравання праектамі і кіраваннем прадуктам?

SAFe і Scrum - гэта рашэнне для дастаўкі каштоўных прадуктаў. Абодва не з'яўляюцца рамкамі кіравання праектамі.

Калі ў вас ёсць розныя прадукты са шматлікімі залежнасцямі, вам варта перагледзець тое, што вы вызначаеце як свой прадукт. Паўторная ацэнка вашага вызначэння прадукту і, як вынік, паўторная ацэнка вашага партфеля можа быць у парадку. Гэта, хутчэй за ўсё, павялічыць празрыстасць (напрыклад, хто нясе адказнасць за ўладальніка прадукту) і пазбавіць відавочнай неабходнасці выкарыстання SAFe.

11. Каб выраўнаваць некалькі ўладальнікаў прадуктаў па кірунку да прадукту

SAFe часта таксама разглядаецца як рашэнне для выраўноўвання некалькіх уладальнікаў прадуктаў, адказных за прадукт. Затым праца можа скончыцца з праграмы, альбо адставання партфеля да адставання ў камандзе, падзеленага на ўладальніка прадукту.

Праблема заключаецца ў тым, што прадукт павінен мець толькі ўладальніка прадукту (1 Бэклог тавараў → 1 Уладальнік прадукту). Такім чынам, наяўнасць некалькіх уладальнікаў прадуктаў для прадукту з'яўляецца анты-узор. Калі вы здымаеце гэтую праблему, вы таксама пазбаўляеце неабходнасці вырабляць гэты тып выраўноўвання, што з'яўляецца прычынай выкарыстання SAFe.

Ніжняя лінія

Маштабная Agile Framework (SAFe) пастаўляецца з рашэннем многіх распаўсюджаных праблем, калі вы хочаце перайсці да спосабу працы з больш спрытам. Аднак для вырашэння вашых праблем вам не спатрэбяцца ўсе звоны SAFe. Вы можаце вырашыць тыя ж праблемы з Scrum, які з'яўляецца сапраўды лёгкім. Выкарыстоўваючы Scrum самастойна, вы пазбягаеце непатрэбных складанасцей і накладных выдаткаў.

Мая парада заўсёды будзе вызначыць, што вашыя сапраўдныя патрэбы, і пачаць з малых.

Лягчэй дадаць складанасць, чым выдаліць яе. Таму заўсёды будзьце асцярожныя, дадаючы адначасова шмат складанасці. Паспрабуйце дадаваць яго паступова і высвятліце, ці сапраўды вам гэта трэба і ці сапраўды ён вырашае вашу праблему. Патрапіўшы туды, гэта цяжка зняць.

Scrum - адзін са спосабаў пачаць з малога. Калі вы недастаткова асвоілі Scrum і ўсё яшчэ адчуваеце, што чагосьці не хапае, вы заўсёды можаце шукаць спосабы маштабавання. Тут SAFe - адзін з варыянтаў, але ёсць і LeSS, Nexus, Scrum @ Scale і іншыя.

Вы будзеце прыемна здзіўлены моцай Scrum. Проста маштабуйце толькі з Scrum.

Маштабаваны Scrum па-ранейшаму Scrum. Просты і магутны.
Вы хочаце напісаць сур'ёзны Scrum ці сур'ёзна абмеркаваць Scrum?