Агилна методологија Scrum

У претходним лекцијама видео си да, иако waterfall и V-модел доносе ред и дисциплину у развој софтвера, обе имају заједнички проблем - тешко се прилагођавају променама и корисник производ "уживо" види тек при крају пројекта. Крајем деведесетих и почетком двехиљадитих, група искусних софтверских инжењера дошла је до закључка да је, за велики број пројеката, потребан потпуно другачији приступ - приступ који промене третира као нормалну, очекивану ствар, а не као проблем који треба спречити.

Агилни манифест - у основи свега

Тај нови начин размишљања формализован је 2001. године кроз документ познат као Агилни манифест (енгл. Agile Manifesto), који је поставио темеље за читаву породицу приступа развоју софтвера који се данас називају агилним методологијама.

Које су кључне вредности агилног манифеста?

Агилни манифест истиче четири вредности:

Појединци и интеракција више него процеси и алати.
Софтвер који ради више него исцрпна документација.
Сарадња са клијентом више него преговарање о уговору.
Реаговање на промене више него праћење унапред задатог плана.

Битно је нагласити да ово не значи да су процеси, документација, уговори и планови небитни - него да су вредности са леве стране (људи, радни софтвер, сарадња, прилагодљивост) приоритетније када дође до сукоба.

Из ове филозофије настало је више конкретних методологија - Scrum, Kanban, Extreme Programming (XP) и друге. У овој лекцији фокусираћемо се на најраспрострањенију од свих - Scrum методологију.

Шта је Scrum?

Scrum је агилни оквир (енгл. framework) за развој комплексних производа, у коме тим ради кроз кратке, временски ограничене циклусе званe спринтови (енгл. Sprints), на крају сваког спринта испоручујући употребљиву, тестирану верзију производа, уз редовно прикупљање повратних информација и прилагођавање даљег рада.

Назив "Scrum" потиче из рагбија - тамо scrum означава тренутак када играчи формирају збијену формацију и заједнички, координисано, гурају лопту напред. Аутори методологије (Jeff Sutherland и Ken Schwaber) овим називом желели су да истакну тимски рад, блиску сарадњу и заједничко "гурање пројекта напред".

Scrum почива на такозваној емпиријској контроли процеса (енгл. Empirical Process Control), односно на три стуба:

Транспарентност (енгл. Transparency): Сви важни аспекти процеса (циљеви, напредак, препреке) морају бити видљиви свим учесницима.
Инспекција (енгл. Inspection): Тим редовно проверава напредак и резултате рада, тражећи одступања од циља.
Адаптација (енгл. Adaptation): Уколико се уочи одступање или проблем, тим прилагођава свој даљи рад, уместо да слепо прати првобитни план.

Улоге у Scrum тиму

За разлику од класичних пројектних тимова са пуно различитих титула, Scrum намерно дефинише свега три улоге:

Власник производа (енгл. Product Owner): Особа одговорна за максимизацију вредности производа. Управља и одређује приоритете списка захтева (о коме ће бити речи мало касније), доноси одлуке о томе шта се гради и у ком редоследу, и представља глас корисника/наручиоца унутар тима.
Scrum мастер (енгл. Scrum Master): Особа која служи тиму тако што му помаже да разуме и правилно примени Scrum, отклања препреке (blockers) које успоравају рад тима, и штити тим од спољних ометања. Важно је нагласити да Scrum мастер није класичан менаџер који додељује задатке - он је пре свега "фасилитатор" процеса.
Развојни тим (енгл. Development Team): Стручњаци (програмери, тестери, дизајнери итд.) који заједнички раде на претварању захтева у готов, тестиран производ. Scrum намерно не дефинише посебне подулоге унутар развојног тима - сви чланови су колективно одговорни за резултат.

Зашто Scrum нема улогу 'вође тима' или 'менаџера' у класичном смислу?

Зато што је Scrum замишљен као самоорганизован (енгл. self- organizing) оквир - тим сам одлучује КАКО ће обавити посао, док Product Owner одлучује ШТА треба урадити. Овакав приступ повећава осећај одговорности и мотивацију тима, уместо да чланови тима само извршавају наређења.

Scrum артефакти

Scrum дефинише три главна артефакта - документа/алата који помажу транспарентност рада:

Backlog производа (енгл. Product Backlog): Уређена листа свега што је потенцијално потребно у производу - нових функционалности, побољшања, исправки грешака. Ова листа никада није "завршена" - она се стално мења и допуњује, а њоме управља Product Owner.
Backlog спринта (енгл. Sprint Backlog): Подскуп ставки из backlog-а производа које је тим изабрао да уради током текућег спринта, заједно са планом како ће их урадити.
Инкремент (енгл. Increment): Збир свих завршених ставки из претходних спринтова плус ставки завршених у текућем спринту - другим речима, тренутна, употребљива верзија производа. Свака ставка мора испуњавати договорену дефиницију готовог (енгл. Definition of Done) да би се сматрала делом инкремента.

Шта значи 'Дефиниција готовог' (Definition of Done)?

Дефиниција готовог је списак услова које нека функционалност мора да испуни да би се сматрала заиста завршеном (нпр. код је написан, прегледан од стране колеге, тестиран, документован и спреман за пуштање у продукцију). Ово спречава да се као 'готове' убрајају ставке које су само делимично урађене.

Спринт - срце Scrum-а

Читав Scrum процес одвија се кроз узастопне спринтове (енгл. Sprints) - кратке, фиксне временске оквире (најчешће од једне до четири недеље, при чему су две недеље најчешћи избор) током којих тим ради на претходно договореном скупу задатака.

Битна карактеристика спринта јесте да му се трајање не мења током пројекта (нпр. ако је тим одабрао двонедељне спринтове, сваки наредни спринт траје тачно две недеље), чиме се обезбеђује предвидив ритам рада кроз читав пројекат.

Унутар сваког спринта одвијају се четири формална Scrum догађаја (церемоније):

Планирање спринта (енгл. Sprint Planning): Састанак на почетку спринта на коме тим, заједно са Product Owner-ом, бира ставке из product backlog-а које ће покушати да заврши током спринта, и дефинише циљ спринта (Sprint Goal).
Дневни Scrum састанак (енгл. Daily Scrum или Daily Standup): Кратак (обично до 15 минута) свакодневни састанак развојног тима, на коме сваки члан укратко одговара на три питања: шта сам радио јуче, шта планирам данас, и да ли постоји нешто што ме спречава у раду. Циљ је синхронизација тима, а не детаљно извештавање.
Преглед спринта (енгл. Sprint Review): Састанак на крају спринта на коме тим представља урађени инкремент заинтересованим странама (укључујући, по потреби, и клијента), и прикупља повратне информације које могу утицати на садржај product backlog-а за наредне спринтове.
Ретроспектива спринта (енгл. Sprint Retrospective): Састанак, такође на крају спринта, али усмерен ка самом тиму - тим анализира како је протекао рад (шта је ишло добро, шта није, шта треба променити) и договара конкретна побољшања за наредни спринт.

Графички, један циклус Scrum-а могао би се приказати овако:

[Product Backlog]
    → Планирање спринта
    → СПРИНТ (нпр. 2 недеље, укључује Daily Scrum) 
        ↓
        ↓
        ↓
    → Преглед спринта
    → Ретроспектива
    → нови спринт...

Зашто је Scrum популаран?

Scrum је постао један од најраспрострањенијих начина организације рада у софтверској индустрији (а све чешће и ван ње) из неколико разлога:

Кратки спринтови омогућавају брзо тестирање идеја и рано откривање проблема - без чекања на крај целог пројекта, као код waterfall модела.
Редовна сарадња са Product Owner-ом и, преко Sprint Review-а, са клијентом, смањује ризик да се на крају пројекта испостави да производ не одговара стварним потребама.
Транспарентност кроз дневне састанке и визуелне алате (нпр. Scrum табле) олакшава уочавање проблема пре него што постану озбиљни.
Тим добија аутономију у начину рада, што повећава мотивацију и осећај власништва над резултатима.

Наравно, Scrum није универзално решење за сваки пројекат - захтева дисциплину, стално ангажовање Product Owner-а и тима, а мање је погодан за пројекте са потпуно фиксним, унапред договореним обимом и буџетом (нпр. пројекти по фиксираном уговору, где су класични модели понекад прикладнији).

Задатак

Замисли да си Scrum мастер тима од пет програмера који развија мобилну апликацију за праћење личних финансија, и да је тим управо одабрао двонедељне спринтове.

Опиши шта би се тачно дешавало на састанку за планирање првог спринта - ко учествује, шта се одлучује и шта је резултат тог састанка.
Наведи пример типичног одговора једног програмера на дневном Scrum састанку (шта је радио јуче, шта планира данас, и пример препреке на коју је наишао).
На крају спринта, тим је завршио 6 од 8 планираних ставки. Опиши шта би требало да буде тема Sprint Review-а, а шта теме Sprint Retrospective-а, и зашто је важно да ова два састанка остану одвојена (а не спојена у један).