Об Agile по гам­бург­ско­му сче­ту

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

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Бер­тран Мей­ер

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

Клю­че­вые сло­ва: про­грамм­ная ин­же­не­рия, Agile, раз­ра­бот­ка ПО Keywords: Software Engineering, Software Development

Око­ло де­ся­ти лет то­му на­зад воз­ник­ло ощу­ще­ние, что в про­грамм­ной ин­же­не­рии упус­ка­ет­ся нечто важ­ное: о кон­цеп­ции экс­тре­маль­но­го про­грам­ми­ро­ва­ния (Extreme Programming,

XP) речь идет еще с 2000 го­да, но Scrum по боль­шей ча­сти оста­вал­ся в сто­роне. И ко­гда при­шло вре­мя разо­брать­ся, об­на­ру­жи­лись две по­ра­зи­тель­ные неувяз­ки в ми­ре ме­то­дов Agile.

Пер­вая ка­са­лась рас­хож­де­ния меж­ду уни­вер­си­тет­ски­ми кур­са­ми про­грамм­ной ин­же­не­рии, на ко­то­рых в то вре­мя (сей­час си­ту­а­ция из­ме­ни­лась), как пра­ви­ло, во­об­ще не за­тра­ги­ва­лась тема Agile, и мас­шта­ба­ми под­ня­той в от­рас­ли шу­ми­хи во­круг них.

Вто­рое рас­хож­де­ние — неожи­дан­ная ме­ша­ни­на луч­ших и худ­ших идей, а так­же нема­ло­го чис­ла идей неод­но­знач­ных.

В про­грамм­ной ин­же­не­рии че­ло­век, столк­нув­шись с но­вой ме­то­ди­кой, обыч­но при­ме­ня­ет то, что в во­ен­ном де­ле на­зы­ва­ет­ся «си­сте­ма свой-чу­жой», то есть за­да­ет­ся во­про­сом, по­мо­жет нов­ше­ство или на­вре­дит, од­на­ко в слу­чае Agile этот прин­цип не ра­бо­та­ет. Си­ту­а­ция усу­губ­ля­ет­ся тем, что тон боль­шин­ства пуб­ли­ка­ций по Agile весь­ма вос­тор­жен­ный (за немно­ги­ми ис­клю­че­ни­я­ми [1]), хо­тя вос­хи­ще­ние еще не при­чи­на сбра­сы­вать со сче­тов ана­ли­ти­ку и трез­вую оцен­ку. В свое вре­мя спе­ци­а­ли­сты, про­па­ган­ди­ро­вав­шие объ­ект­но-ори­ен­ти­ро­ван­ное про­грам­ми­ро­ва­ние, то­же ча­стень­ко де­мон­стри­ро­ва­ли боль­шой эн­ту­зи­азм, од­на­ко это не ме­ша­ло об­суж­дать не толь­ко «за», но и «про­тив».

ВОСТОРГИ В СТО­РО­НУ

При­ме­ни­тель­но к Agile мо­ей есте­ствен­ной ре­ак­ци­ей бы­ло при­ме­нить ча­сто по­мо­га­ю­щее пра­ви­ло: ес­ли вам что-то ин­те­рес­но, пре­по­дай­те об этом курс, а ес­ли вы чем-то оза­да­че­ны, на­пи­ши­те об этом кни­гу. Так и ро­ди­лась кни­га «Agile! The Good, the Hype and the Ugly» («Ско­рая раз­ра­бот­ка: по­лез­ное, хайп и вред­ное») [2], а так­же он­лайн-курс «Agile Software Development» (до­сту­пен на www.edx.org). Ос­нов­ная цель кни­ги — со­здать са­мо­учи­тель по Agile-ме­то­дам, ко­то­рый дол­жен был стать от­ве­том на мно­го­чис­лен­ные за­про­сы о по­яв­ле­нии ис­чер­пы­ва­ю­ще­го, но без из­ли­шеств сжа­то­го опи­са­ния кон­цеп­ций ско­рой раз­ра­бот­ки. Вто­рая цель — дать ана­лиз и кри­ти­че­скую оцен­ку мас­со­вых вос­хва­ле­ний в ад­рес Agile.

По­след­ние про­сто по­ра­жа­ют. Взять хо­тя бы кни­гу од­но­го из ав­то­ров кон­цеп­ции Scrum, ко­то­рая обе­ща­ет «вдвое боль­ше ра­бо­ты за по­ло­ви­ну вре­ме­ни» [3]. Ни­че­го се­бе! Вряд ли кто-то от­ка­зал­ся бы от воз­мож­но­сти че­ты­рех­крат­но­го по­вы­ше­ния про­из­во­ди­тель­но­сти. В дру­гой кни­ге [4], так­же от со­зда­те­лей Scrum, со­об­ща­етcя: «Ин­ду­стрия про­грамм­но­го обес­пе­че­ния 40 лет ва­ми пре­не­бре­га­ла — не пред­на­ме­рен­но, но из-за сво­ей су­ти. Мы хо­тим вос­ста­но­вить парт­нер­ские от­но­ше­ния». Ни боль­ше ни мень­ше. Ин­те­рес­но, а при со­став­ле­нии по­доб­но­го за­яв­ле­ния, слу­чай­но, не ис­поль­зо­ва­лась са­ма про­грамм­ная си­сте­ма?

В це­лом пуб­ли­ка­ци­ям об Agile при­сущ ка­кой-то под­рост­ко­вый мак­си­ма­лист­ский дух («Толь­ко мы зна­ем ис­ти­ну!»). Од­на­ко

идеи не рож­да­ют­ся в ва­ку­у­ме — раз­ви­тие Agile сто­ит рас­смат­ри­вать как эво­лю­цию, а не ре­во­лю­цию. Ес­ли су­дить толь­ко по «агит­кам» ско­рой раз­ра­бот­ки, это неоче­вид­но, но со­об­ще­ство про­грамм­ной ин­же­не­рии не до­жи­да­лось по­яв­ле­ния «Ма­ни­фе­ста Agile» для при­зна­ния необ­хо­ди­мо­сти пе­ре­мен. На­при­мер, еще в 1995 го­ду в кни­ге «Object Successs: A Manager's Guide to Object Orientation, Its Impact on the Corporation and Its Use for Reengineering the Software Process» для биз­нес-ру­ко­во­ди­те­лей ре­ко­мен­до­ва­лось про­ек­ти­ро­вать ПО с рас­че­том на из­ме­не­ние и под­чер­ки­ва­лась важ­ность при­о­ри­те­та ко­да над диа­грам­ма­ми и до­ку­мен­та­ци­ей. Поль­за Agile со­сто­я­ла не в раз­ра­бот­ке но­вых идей, а в том, что­бы на­ко­нец-то убе­дить от­расль при­нять уже су­ще­ству­ю­щие, дав­но из­вест­ные, а так­же дру­гие — на­при­мер, о цен­но­сти те­стов и необ­хо­ди­мо­сти ите­ра­тив­но­го про­цес­са — раз­ра­бот­ки.

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

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

СОРТИРУЕМ ИДЕИ AGILE

Итак, рас­пре­де­лим ос­нов­ные по­зи­ции Agile по ка­те­го­ри­ям «по­лез­ное», «пре­уве­ли­чен­ное», «вред­ное» и «пре­крас­ное».

Пре­уве­ли­чен­ное

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

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

Вред­ное

Боль­ше бес­по­кой­ства вы­зы­ва­ют ре­ко­мен­да­ции, ко­то­рые мож­но от­не­сти к ка­те­го­рии вред­ных. По­жа­луй, са­мое вре­до­нос­ное — по­все­мест­ный от­каз от мас­штаб­ной под­го­то­ви­тель­ной ра­бо­ты: пред­ва­ри­тель­но­го пла­ни­ро­ва­ния, со­став­ле­ния тре­бо­ва­ний, про­ек­ти­ро­ва­ния и т. п. Обос­но­ва­ние по

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

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

В ра­бо­те [2] при­во­дит­ся ци­та­та Па­ме­лы Зейв из AT&T, ко­то­рая де­сят­ки лет изу­ча­ла про­ек­ти­ро­ва­ние на ос­но­ве функ­ций—ме­то­дом, при­ме­ня­е­мым в те­ле­ком­му­ни­ка­ци­он­ной ин­ду­стрии. Слож­ность с ин­ди­ви­ду­аль­ны­ми функ­ци­я­ми в том, что они вза­и­мо­дей­ству­ют друг с дру­гом, и та­кие вза­и­мо­дей­ствия, неред­ко неяв­ные, об­ре­ка­ют на неуда­чу лю­бой ме­тод, пред­пи­сы­ва­ю­щий со­зда­ние си­стем пу­тем ре­а­ли­за­ции функ­ции за функ­ци­ей. Все бу­дет ка­зать­ся класс­ным, по­ка вне­зап­но не вы­яс­нит­ся, что оче­ред­ная поль­зо­ва­тель­ская ис­то­рия кон­флик­ту­ет с уже ре­а­ли­зо­ван­ны­ми ра­нее, из-за че­го при­дет­ся вер­нуть­ся к на­ча­лу и все пе­ре­де­лать. Об­ще­при­ня­то­го стан­дар­та со­став­ле­ния тре­бо­ва­ний нет, но непло­хим на­ча­лом бу­дет объ­ект но ори­ен­ти­ро­ван­ный ана­лиз, при ко­то­ром вы­яв­ля­ют­ся низ­ко­уров­не­вые аб­страк­ции дан­ных, а ин­ди­ви­ду­аль­ные сце­на­рии не име­ют зна­че­ния.

По­лез­ное

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

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

У Agile-ме­то­дов есть пре­иму­ще­ства, оче­вид­ные се­год­ня мно­гим с уче­том то­го, нас­коль­ко силь­ное вли­я­ние на раз­ра­бот­ку ПО они ока­за­ли. Са­мое за­мет­ное то, что про­ек­ты уже не осу­ществ­ля­ют­ся по схе­ме раз­де­ле­ния за­да­чи на круп­ные фраг­мен­ты, са­мо­сто­я­тель­ные под­про­ек­ты, ко­то­рые спу­стя ме­ся­цы пы­та­ют­ся со­еди­нить друг с дру­гом. Та­кой под­ход сей­час

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

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

Пре­крас­ное

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

Пер­вая идея заслу­жи­ва­ет ос­но­ва­тель­но­го об­суж­де­ния, но здесь огра­ни­чим­ся лишь ее упо­ми­на­ни­ем: ни­ка­ко­го ветв­ле­ния про­ек­та (branching). Ветв­ле­ние — зло.

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

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

Что­бы ис­поль­зо­вать пре­иму­ще­ства Agile, нуж­но за­ме­чать и от­вер­гать вред­ное, иг­но­ри­ро­вать пре­уве­ли­чен­ное и брать на во­ору­же­ние по­лез­ное и пре­крас­ное. Участ­ни­ки рын­ка на­учи­лись это­му до­ста­точ­но быст­ро. Не­смот­ря на угро­жа­ю­щие за­яв­ле­ния неко­то­рых апо­ло­ге­тов Agile («сле­дуй­те толь­ко мо­им за­по­ве­дям, а не то…»), в рам­ках всех про­ек­тов, с ко­то­ры­ми я имел де­ло, на во­ору­же­ние бе­рет­ся лишь часть идей вы­бран­ной ме­то­до­ло­гии, а те, что не впи­сы­ва­ют­ся в куль­ту­ру или не со­от­вет­ству­ют по­треб­но­стям ком­па­нии, от­вер­га­ют­ся.

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

ЛИ­ТЕ­РА­ТУ­РА

1.

B. Boehm, R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-wesley, 2003. 2.

B. Meyer. Agile! The Good, the Hype and the Ugly. Springer, 2014. 3.

J. Sutherland. Scrum: The Art of Doing Twice the Work in Half the Time. Random House, 2015. 4.

K. Schwaber, J. Sutherland. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust. John Wiley & Sons, 2012.

Бер­тран Мей­ер (bertrand.meyer@inf.ethz.ch) — про­фес­сор про­грамм­ной ин­же­не­рии Ми­лан­ско­го уни­вер­си­те­та и Уни­вер­си­те­та Ин­но­по­лис.

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.