Agile vs Waterfall

Agile vs Waterfall

User stories and estimation
Agile-ում User story-ն ամենափոքր միավորն է, որի վրա աշխատում են: Այն end user-ի կամ customer-ի տեսանկյունից software-ի հատկությունների մասին գրավոր ընդհանուր բացատրությունն է: Գլխավոր նպատակն է պարզաբանել, թե ծրագրի փոքր կտորն ինչ արդյունք պիտի տա customer-ին: Դրանք գրվում են հասկանալի լեզվով եւ ընդգծում են ցանկալի արդյունքը՝ առանց մանրամասների: Պահանջներն ավելացվում են հետագայում թիմի համաձայնեցումից հետո: User story-ներից յուրաքանչյուրն ունենում է սահմանված point-եր՝ 1 pnt –small-ջանքեր չի պահանջում, 3 pnt – medium – անհաղթահարելի բան չկա, 5pnt – large – պահանջում է որոշակի ջանք, եւ իրենցից ներկայացնում են 1-2օրվա աշխատանք: Դրանք գրվում են հաճախորդների հետ մանրամասն քննարկումներ անելով: Scrum-ում user story-ներն ավելացվում են sprint-ներին,իսկ Kanban-ում դրանք հավաքվում են backlog-ի մեջ:

Iterations
Իտերացիան միավոր development cycle-ն է, որը տեւում է 1-2 շաբաթ: Այսինքն յուրաքանչյուր story անցնում է development cycle-ի փուլերով, որից հետո տվյալ պատրաստի մասը ցուցադրվում է պատվիրատուին եւ feedback արվում: Հենց այդ պրոցեսը կոչվում է իտերացիա:

Planning and Refactoring
Master Story – Բոլոր story-ների ցուցակն է:
Refactoring-ը կոդը բարելավելու գոծընթացն է՝ պահպանելով առկա ֆունկցիոնալությունը: Նպատակը անարդյունավետ եւ բարդ կոդը արդյունավետ եւ հեշտ դարձնելն է: Եթե կոդը չունի լավ կառուցվածք եւ հեշտ պահպանվող չէ, ամեն իտերացիայից հետո կոդն ընդլայնել հնարավոր չի լինի: Իսկ եթե կոդը փոփոխվում է առանց պատշաճ Refactoring-ի, ապա դա կարող է նպաստել cod smell-ի եւ technical debt-ի առաջացմանը: Թեստավորողի գործն է Refactoring-ից հետո ստուգել bug-երի առկայությունը, ստուգել ֆունկցիոնալությունը պահպանվել է, թե ոչ եւ այլն:
Team Velocity – Թիմի՝ user story-ն աշխատող ծրագիր դարձնելու, արագությունն է:
Planning – Գնահատում է աշխատանքը, ջանքը՝ օգտագործելով իտերացիաները:
iterations = total effort / estimated team velocity
Agile planning-ը տարբերվում է նրանով, որ ոչ թե ամբողջական պլանավորում է, այլ՝

- բաժանված է սպրինտների,
- հիմնված է User story-ների վրա,
- քայլ առ քայլ է,
- գնահատումը կատարվում է թիմի անդամների կողմից:

Agile	Waterfall
Այն բաժանում է նախագծի lifecycle-ը սպրինտների:	Ծրագրային ապահովման մշակման գործընթացը բաժանված է առանձին փուլերի.
Այն հետևում է աստիճանական մոտեցմանը:	Waterfall մեթոդաբանությունը հաջորդական նախագծման գործընթաց է:
Agile մեթոդոլոգիան հայտնի է իր ճկունությամբ:	Waterfall-ը ծրագրային ապահովման մշակման կառուցվածքային մեթոդաբանություն է, ուստի շատ դեպքերում այն կարող է բավականին կոշտ լինել:
Agile-ը կարելի է դիտարկել որպես բազմաթիվ տարբեր նախագծերի հավաքածու:	Ծրագրային ապահովման մշակումը կավարտվի որպես մեկ միասնական նախագիծ:
Agile-ը բավականին ճկուն մեթոդ է, որը թույլ է տալիս փոփոխություններ կատարել նախագծի մշակման պահանջներում, նույնիսկ եթե նախնական պլանավորումն ավարտված է:	Ծրագրի մշակումը սկսելուց հետո պահանջները փոխելու հնարավորություն չկա:
Agile մեթոդաբանություն, հետևեք կրկնվող զարգացման մոտեցմանը, քանի որ պլանավորման, մշակման, նախատիպի ձևավորման և ծրագրաշարի մշակման այլ փուլերը կարող են հայտնվել մեկից ավելի անգամ:	Ծրագրի զարգացման բոլոր փուլերը, ինչպիսիք են նախագծումը, մշակումը, փորձարկումը և այլն, ավարտվում են մեկ անգամ ջրվեժի մոդելում:
Փորձարկման պլանը վերանայվում է յուրաքանչյուր սպրինտից հետո:	Թեստի պլանը հազվադեպ է քննարկվում թեստային փուլում:
Agile development-ը գործընթաց է, որի ժամանակ ակնկալվում է, որ պահանջները փոխվեն և զարգանան:	Մեթոդը իդեալական է այնպիսի նախագծերի համար, որոնք ունեն որոշակի պահանջներ և փոփոխություններ, որոնք բոլորովին չեն սպասվում:
Agile մեթոդաբանության մեջ թեստավորումն իրականացվում է ծրագրային ապահովման մշակման հետ միաժամանակ:	Այս մեթոդաբանության մեջ «testing» փուլը գալիս է «build» փուլից հետո
Agile-ը ներկայացնում է արտադրանքի մտածելակերպ, որտեղ ծրագրային արտադրանքը բավարարում է իր վերջնական հաճախորդների կարիքները և փոխվում է ըստ հաճախորդի պահանջների:	Այս մոդելը ցույց է տալիս նախագծային մտածելակերպը և ամբողջովին կենտրոնանում է նախագծի իրականացման վրա:
Agile մեթոդաբանությունը բացառիկ լավ է աշխատում Time & Materials-ի կամ ոչ ֆիքսված ֆինանսավորման հետ: Դա կարող է մեծացնել սթրեսը ֆիքսված գնով սցենարներում:	Նվազեցնում է ռիսկը ընկերության ֆիքսված գնով պայմանագրերում` գործընթացի սկզբում ռիսկի համաձայնագիր ստանալով:
Նախընտրում է փոքր, բայց նվիրված թիմեր՝ համակարգման և համաժամացման բարձր աստիճանով:	Թիմի համակարգումը/համաժամեցումը շատ սահմանափակ է:
Ապրանքների սեփականատերը թիմի հետ պատրաստում է պահանջները գրեթե ամեն օր նախագծի ընթացքում:	Բիզնեսի վերլուծությունը նախապատրաստում է պահանջները նախքան նախագծի սկիզբը:
Թեստային թիմը կարող է առանց խնդիրների մասնակցել պահանջների փոփոխությանը:	Թեստի համար դժվար է նախաձեռնել պահանջների որևէ փոփոխություն:
Ծրագրի մանրամասների նկարագրությունը կարող է փոփոխվել ցանկացած պահի SDLC գործընթացի ընթացքում:	Մանրամասն նկարագրությունը պետք է իրականացնի Waterfall ծրագրային ապահովման մշակման մոտեցումը:
Agile Team-ի անդամները փոխարինելի են, արդյունքում նրանք ավելի արագ են աշխատում: Ծրագրի ղեկավարների կարիք նույնպես չկա, քանի որ նախագծերը ղեկավարվում են ամբողջ թիմի կողմից	Waterfall մեթոդով գործընթացը միշտ պարզ է, ուստի ծրագրի ղեկավարը կարևոր դեր է խաղում SDLC-ի յուրաքանչյուր փուլում:

o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

Օգտակար հղումներ՝

Agile vs Waterfall article/rus
Agile vs Waterfall video tutorial/eng
Agile vs Waterfall article/eng