agile methodology beginner s guide agile method
Комплетан водич за агилну методологију: (20+ детаљних водича за агилну Сцрум методологију)
Ово је водич за програмере и тестере софтвера да разумеју и започну рад на врло познатом Агиле СЦРУМ методологија за развој и тестирање софтвера . Научите основне, али важне терминологије које се користе у процесу Агиле Сцрум, заједно са стварним примером целокупног процеса.
За вашу удобност навели смо све Агиле туторијале у овој серији. Надам се да ће вам бити од огромне помоћи.
Теме које се обрађују: Шта је Агиле, Шта је Сцрум, Агиле методологија у развоју и тестирању софтвера, Агиле тестирање, Агиле Сцрум процес, Сцрум методологија са Сцрум тимом и Сцрум Мастер-ом.
Шта ћете научити:
Листа туторијала за агилну методологију
Туториал # 1: Агиле Сцрум методологије (Овај водич)
Туториал # 2: Агиле Манифесто
Туториал # 3: Сцрум тим и њихове улоге и одговорности
Туториал # 4: Сцрум Артефацтс
Водич бр. 5: Сцрум Евентс
Лекција # 6: Триагинг дефекта у скруму
Туториал # 7: Самодовољни Сцрум тимови
Туториал # 8: Три принципа Амиго
Туториал # 9: САФе - Скалирани агилни оквир
Водич бр. 10: Агиле Сцрум Куиз
ЈОШ препоручених Агиле Сцрум водича:
Туториал # 11: Врхунске агилне технике процене
Водич бр. 12: Агиле Хибрид Модел водопада
Водич бр. 13: Канбан вс Сцрум вс Агиле
Водич # 14: ЈИРА Агиле Туториал
Водич бр. 15: Агиле Ретроспецтиве Меетингс
Туториал # 16: Улога пословних аналитичара у СЦРУМ-у
Водич # 17: КА’с Роле ин Сцрум
Алати и питања за интервју:
Туториал # 18: Агиле Тест Тоолс
Водич бр. 19: Најбољи агилни алати за управљање пројектима
Водич бр. 20: Најпопуларнија питања о агилном интервјуу
Туториал # 21: Топ Сцрум Интервју питања
Почнимо са првим упутством у серији - Агиле Сцрум Интродуцтион.
Увод у агилни развој
Окретан у развоју софтвера:
Агиле је један од најчешће коришћених и најпризнатијих оквира за развој софтвера на свету.
Већина организација прихватила га је у неком или другом облику, али још увек је дуг пут до зрелости њихових програма усвајања. Једини циљ ове серије туторијала је укрцавање технолошких и нетехнолошких професионалаца у Агиле Ворлд.
Провешћемо вас кроз агилно путовање корак по корак док не разумете филозофију употребе Агиле-а, његове предности и како то вежбати. Ова серија има за циљ да оспособи и омогући читаоцима да примене Агиле и Сцрум учење у свом раду.
Овај водич је посвећен томе да вам објасни зашто је постојала потреба за Агилеом и како је створен. Овде је основно разумевање концепта агилног усвајања у индустрији софтверског развоја.
Историја агилности
Агиле се родио када се једног лепог дана када се 17 људи са различитим позадинским методологијама развоја окупило како би размислили постоји ли могуће алтернативно решење за развој софтвера које би могло довести до бржег развоја и мање документације.
У то време развој софтвера се догађао толико дуго да је посао, док су пројекти били спремни за испоруку, напредовао и захтеви се променили. Дакле, пројекат није био у стању да задовољи пословне потребе, чак иако је могао да испуни своје дефинисане циљеве.
Тако су се ови прваци различитих техника софтверског инжењерства окупили и крајњи резултат њиховог састанка био је оно што су назвали „агилни манифест“, о чему ћемо детаљно разговарати у следећем водичу ове серије.
Али агилни који се родио тог дана није оно што данас видимо у организацијама. Методологија око које су се стручњаци сложили описана је као „лагана“ и брза. Али главна победа на овом састанку била је мисао да су бржа испорука производа и сталне повратне информације кључ за постизање успеха у развоју софтвера.
Постојеће технике слапова биле су превише гломазне и нису имале могућност повратних информација док коначни производ није био спреман за испоруку. То је значило да није било могућности за корекцију курса и да купац није имао поглед на напредак док цео производ није био спреман. И то је оно што су ови стручњаци желели да избегну.
Желели су решење које ће имати простор за сталне повратне информације како би се избегли трошкови прераде у каснијој фази.
Агиле Цхалленгес
Постојеће технике слапова у то време биле су превише гломазне и нису имале могућност повратних информација док коначни производ није био спреман за испоруку. Назван је водопадним моделом развоја, јер су тимови прво завршили један корак у потпуности, а тек након тога прешли су на следећи корак.
То је значило да није било могућности за корекцију курса и да купац није имао поглед на напредак док цео производ није био спреман. И то је оно што су ови стручњаци желели да избегну. Желели су решење које ће имати простор за сталне повратне информације како би се избегли трошкови прераде у каснијој фази.
И зато је агиле и прилагодљиво и континуирано усавршавање, колико и сталне повратне информације и брзина испоруке.
Шта су Агиле Промисес?
Агиле није само примена постављених пракси у развоју софтвера. Такође доноси промену у начину размишљања Тима која их води ка изградњи бољег софтвера, заједничком раду и на крају им доноси срећног купца.
Агилне вредности и принципи омогућавају тиму да преусмери фокус и промени свој мисаони процес изградње бољег софтвера.
Шта је тачно агилно?
Агиле није скуп правила. Агиле није скуп смерница. Агиле није чак ни методологија. Уместо тога, Агиле је скуп принципа који подстичу флексибилност, прилагодљивост, комуникацију и радни софтвер у односу на планове и процесе. Веома је језгровито обухваћен оним што се назива агилним манифестом.
Агилан развој софтвера омогућава тиму да ефикасније и ефикасније раде заједно у развоју сложених пројеката. Састоји се од пракси које користе итеративне и инкременталне технике које се лако усвајају и дају одличне резултате.
Да бисмо применили Агиле у акцију, имамо различите методе и методологије засноване на Агиле-у. Ове методе и методологије задовољавају све потребе индустрије за развој софтвера, почев од дизајна и архитектуре софтвера, развоја и тестирања до управљања пројектима и испорука.
И не само то, агилне методе и методологије такође отварају простор за побољшање процеса као саставни део сваке испоруке.
Агиле је приступ развоју софтвера где самодостатан и вишефункционалан тим ради на континуираним испорукама кроз итерације и развија се током процеса прикупљањем повратних информација од крајњих корисника.
Како вежбати агилно?
Постоје разне агилне методологије које су у пракси у различитим диверзификованим индустријама.
Међутим, најпопуларније методологије међу свима њима су:
- Сцрум
- Канбан
- Екстремно програмирање
Све ове методологије усредсређене су на леан развој софтвера и помажу у стварању бољег софтвера ефикасно и ефикасно.
То је све уз Агиле Интродуцтион. Део је структуриран тако да вам помогне да разумете основне вредности и принципе који ће бити усвојени да би тим радио у агилном начину и начину размишљања.
Окретан Методологија
Увод у агилне моделе:
грешке у животном циклусу у тестирању софтвера
Као што сви знамо, Агиле је методологија развоја софтвера.
Такође смо сазнали о вредностима и принципима које су оснивачи агилног споменули у агилном манифесту. У нашим почетним дискусијама такође смо се заокупили на разликама између агилних и традиционалних модела водопада.
У овом упутству ћемо се упознати са предностима и недостацима агилне методологије.
Видећемо шта је сцрум? и по чему се разликује од окретног. Тада ћемо разумети разне агилне методологије које користе различите организације и како можемо применити агилне користећи их.
Такође ћете моћи да цените разлику, као и предности / недостатке ових методологија.
Предности агилне методологије
Доље су дате разне предности агилне методологије:
- Купци непрестано добијају поглед и осећај напретка пројекта на крају сваке итерације / спринта.
- Сваки спринт пружа купцу радни софтвер који испуњава њихова очекивања у складу са дефиницијом урађеног од њих.
- Развојни тимови прилично реагују на променљиве захтеве и могу прилагодити промене чак и у напредним фазама развоја.
- Постоји стална двосмерна комуникација која одржава купце укљученима, тако да сви актери - пословни и технички - имају јасну видљивост напретка пројекта.
- Дизајн производа је ефикасан и испуњава пословне захтеве.
Мане агилне методологије
Иако постоји неколико предности Агиле методологије, постоје и одређени недостаци.
Су:
# 1) Није пожељна свеобухватна документација која може довести до тога да агилни тимови погрешно протумаче ово јер агилној документацији није потребна. Тако се строгост губи на документацији. То треба избегавати непрекидним запиткивањем да ли су ово довољне информације за наставак или не.
#два) Понекад, на почетку пројеката, захтеви нису кристално јасни. Тимови би могли да наставе и утврде да се визија купаца преобликовала и у таквим ситуацијама тимови морају да унесу многе промене, а тешко је измерити и крајњи резултат.
Врсте агилних методологија
У пракси постоји неколико агилних методологија у свету. Сазнаћемо детаљније о четири најпопуларнија.
# 1) Сцрум
Сцрум се лако може сматрати најпопуларнијим агилним оквиром. Већина практичара израз „окршај“ сматра синонимом за „окретан“. Али то је заблуда. Сцрум је само један од оквира помоћу којих можете применити агилно.
Реч сцрум потиче од спортског рагбија. Тамо где се играчи скупљају у међусобно повезаном положају гурајући против противника. Сваки играч има дефинисану улогу у својој позицији и може играти и офанзиву и дефанзиву према захтеву ситуације.
Слично томе, препирка у ИТ-у верује у оснажене самоуправне развојне тимове са три специфичне и јасно дефинисане улоге. Те улоге укључују - Власник производа (ПО), Сцрум Мастер (СМ) и развојни тим који се састоји од програмера и тестера . Они раде заједно у итеративним временским оквирима који се називају спринти.
Први корак је стварање заосталих производа од стране ОП. То је списак обавеза које треба да уради сцрум тим. Тада сцрум тим бира ставке са највишим приоритетом и покушава да их заврши у року који се назива спринт.
Једноставнији начин памћења свега овога је памћење оквира 3-3-5. То значи да сцрум пројекат има 3 улоге, 3 артефакта и 5 догађаја.
Су -
Улоге: ПО, Сцрум мајстор и развојни тим.
Артефакти: Заостатак производа, Спринт заостатакиПрираст производа.
Догађаји: Спринт, планирање спринта, дневни скрум, преглед спринта и ретроспектива спринта.
О сваком од њих детаљније ћемо се упознати у нашим наредним водичима.
# 2) Канбан
Канбан је јапански израз који значи карта. Ове картице садрже детаље о раду на софтверу. Сврха је визуелизација. Сваки члан тима је свестан посла који треба обавити путем ових визуелних помагала.
Тимови користе ове Канбан картице за континуирану испоруку. Баш као и Сцрум, Канбан такође помаже тимовима да ефикасно раде и промовише самоуправне и сарадничке тимове.
Али постоје разлике и између ове две - као током спринт спринта, предмети на којима ради тим су фиксни и не можемо да додајемо ставке у спринт, док у Канбану можемо да додајемо ставке ако има слободних капацитета. Ово је посебно корисно када се захтеви често мењају.
Слично томе, друга разлика је у томе што иако сцрум има дефинисане улоге ПО-а, мастер сцрум-а и развојних тимова, у Канбану нема таквих унапред дефинисаних улога.
Друга разлика је у томе што иако сцрум сугерише приоритет заосталих производа, Канбан нема такав захтев и он је потпуно необавезан. Стога Канбан захтева мање организације и избегава активности које не додају вредност и погодан је за процесе који захтевају реакцију на промене.
# 3) мршав
Леан је филозофија која се фокусира на смањење отпада. Како се то ради?
У мршављењу, процес делите на активности додавања вредности, активности без додавања вредности и основне активности без додавања вредности. Свака активност која се може класификовати као активност без додавања вредности је отпад и требало би да покушамо да уклонимо тај отпад у процесу како бисмо га учинили виткијим.
Лаганији процес значи бржу испоруку и мање напора који се троши на задатке који не помажу у постизању циљева тима. Ово помаже у оптимизацији сваког корака у циклусу развоја софтвера. Због тога су принципи виткости прилагођени од витке производње ка развоју софтвера.
Леан развој софтвера може се користити у било ком ИТ пројекту применом седам леан принципа који су приказани у наставку:
То су сасвим објашњено како њихова имена сугеришу. Елиминисање расипања је прво и најважније витко начело и видели смо како то да урадимо, само класификујемо активности као додатак вредности и вредности без вредности.
Активност која не доноси вредност може бити било који део кода који је може учинити мање робусном, повећати напор и одузети пуно времена, а не додати оправдану пословну вредност. То такође могу бити нејасне корисничке приче или лоше тестирање или додавање функција које нису потребне у широкој слици.
Други принцип који појачава учење је поново лако разумети, јер тиму требају разне вештине за испоруку производа у окружењу које се брзо мења, уз нове технологије које се брзо појављују.
Доношење касних одлука може бити корисно у околностима у којима се смањује прерада, на пример ако се очекују неке промене, онда је боље одложити тако да тим не мора да понавља посао јер се посао мења.
Али овде увек постоји компромис јер тимови то морају уравнотежити са четвртим принципом брже испоруке. Одлагање одлука не би требало да утиче на целокупну испоруку и не сме да смањи темпо рада. Једно око увек треба да гледа на целовиту слику.
Имати оснажене тимове такође је врло често у данашње време и то је нешто што чак и спретни сугеришу. Оснажени тимови су одговорнији и могу брже доносити одлуке. Осјећај власништва у оснаженом тиму доводи до бољих резултата. Да би оснажили тим, треба им омогућити да се сами организују и доносе одлуке.
Стога видимо да витки и окретни имају много тога заједничког са једном оштром разликом - док мршави тимови могу помоћи у усавршавању производа, окретни тимови су ти који заправо производе производ.
# 4) Екстремно програмирање (КСП)
Екстремно програмирање је још једна од најпопуларнијих агилних техника. Као и према ектремепрограмминг.орг, први КСП пројекат покренут је 6. марта 1996. Они такође помињу да КСП утиче на развој софтверских пројеката на 5 различитих начина - комуникацијом, једноставношћу, повратним информацијама, поштовањем и храброшћу. То се називају вредности КСП.
Од тога, све почиње комуникацијом. КСП тимови редовно сарађују са пословним тимовима и колегама програмерима и започињу са изградњом кода од првог дана. Овде је фокус на комуникацији лицем у лице што је више могуће уз помоћ других визуелних помагала.
Екстремни програмери такође граде једноставан код и почињу да добијају повратне информације о њему од првог дана. Фокус је на не претјеривању или предвиђању захтјева који нису подијељени. Ово олакшава дизајн и производи само минимални производ који ће задовољити захтеве.
Повратне информације помажу тиму да побољша и произведе бољи квалитет рада. То им помаже да изграде поштовање једни према другима док уче једни од других и науче како да деле своје ставове.
Ово им такође даје храброст јер знају да су прикупили свачије најбоље идеје и произвели добар производ уз повратне информације од других. Стога се такође не плаше да укључе промене или добију даље повратне информације о свом раду.
Ово је посебно корисно у пројектима где ће се захтеви често мењати. Сталне повратне информације помоћи ће тимовима да храбро укључе ове промене.
Тако смо видели различите агилне методологије као што су Сцрум, КСП, Канбан и Леан, заједно са њиховим предностима и недостацима.
Сада их можемо лако разликовати и такође уважити суптилније разлике међу њима. Такође смо научили основе сваке од ових методологија и видели како да их применимо у нашим пројектима када и када је то потребно.
У следећем делу, хајде да разумемо све о Сцрум-у.
Сцрум методологија
СЦРУМ је процес у агилној методологији који је комбинација итеративног модела и инкременталног модела.
Један од главних недостатака традиционалног Модел водопада је то било - све док прва фаза не буде завршена, апликација се не пребацује у другу фазу. И случајно, ако дође до неких промена у каснијој фази циклуса, постаје врло изазовно применити те промене, јер би то подразумевало поновни преглед ранијих фаза и понављање промена.
Неке од кључних карактеристика СЦРУМ-а укључују:
- Самоорганизовани и фокусирани тим.
- Нема огромних докумената, већ имају врло прецизне и тачне приче.
- Вишефункционални тимови раде заједно као једна целина.
- Блиска комуникација са представником корисника ради разумевања карактеристика.
- Има одређени временски оквир од највише месец дана.
- Уместо да ради целу „ствар“ одједном, Сцрум ради помало од свега у датом интервалу.
- Способност ресурса и доступност узимају се у обзир пре него што почините било шта.
Да бисте добро разумели ову методологију, важно је разумети кључне терминологије у СЦРУМ-у.
Такође прочитајте => Како испоручити софтверске функције високе вредности у кратком временском периоду помоћу Агиле Сцрум процеса
Важне СЦРУМ терминологије
1) Сцрум тим
Сцрум тим је тим који се састоји од 7 чланова са + или - два члана. Ови чланови су мешавина компетенција и састоје се од програмера, тестера, људи из базе података, људи који подржавају итд., Заједно са власником производа и сцрум мајстором.
Сви ови чланови раде у тесној сарадњи у рекурзивном и одређеном интервалу како би развили и применили поменуте карактеристике. Распоред седења екипе СЦРУМ игра веома важну улогу у њиховој интеракцији, они никада не седе у кабинама или кабинама, већ на огромном столу.
2) Спринт
Спринт је унапред дефинисани интервал или временски оквир у којем посао мора бити завршен и припремљен за преглед или спреман за примену у производњи. Овај временски оквир обично лежи између 2 недеље и 1 месеца.
најбољи шпијунски програми за мобилне телефоне
У нашем свакодневном животу када кажемо да следимо једномесечни Спринт циклус, то једноставно значи да радимо месец дана на задацима и спремимо га за преглед до краја тог месеца.
3) Власник производа
Власник производа је кључна заинтересована страна или водећи корисник апликације коју треба развити. Власник производа је особа која представља страну купца. Он / она има коначни ауторитет и увек треба да буде доступан тиму.
Требало би да буде доступан / а када неко сумња у потребно разјашњење. Власник производа је важно да разуме и да не поставља нове захтеве усред спринта или када је спринт већ почео.
4) Сцрум Мастер
Сцрум Мастер је фацилитатор сцрум тима. Он / она осигурава да сцрум тим буде продуктиван и напредан. У случају било каквих препрека, мастер надметања прати и решава их за тим. СЦРУМ Мастер је посредник између ОП-а и тима.
Он / она обавештава ПО о напретку спринта. Ако постоје препреке на путу или недоумице за тим, разговара са ПО и решава их. Као и свакодневни стандуп тима, и СЦРУМ Мастер са ПО се дешава сваког дана.
Препоручено читање => Како бити добар ментор, тренер и истински тим-бранилац у агилном свету тестирања?
5) Пословни аналитичар (БА)
Пословни аналитичар игра веома важну улогу у СЦРУМ-у. Ова особа је одговорна за финализирање и израду захтева у документима о захтевима (на основу којих се креирају корисничке приче).
Ако постоје нејасноће у корисничким причама / критеријумима за прихватање, он / она је тај коме се обраћа технички (СЦРУМ) тим и он га затим пребацује у ПО или, ако је могуће, сам решава. У великим пројектима може бити више од 1 БА, али у малим пројектима СЦРУМ Мастер може деловати и као БА.
Увек је добра пракса имати БА када започне пројекат.
6) Прича о кориснику
Приче корисника нису ништа друго до захтеви или особине које се морају применити.
У досадашњој расправи немамо те огромне документе са захтевима, већ су захтеви дефинисани у једном пасусу, обично у формату:
Као
Желим да
Постигнути, постићи
На пример :
Као администратор желим да закључам лозинком у случају да корисник три пута узастопно унесе нетачну лозинку како би ограничио неовлашћени приступ.
Постоје неке карактеристике корисничких прича којих се треба придржавати. Корисничке приче би требале бити кратке, реалне, могле би се процијенити, цјеловите, преговарати и провјерити. Корисничка прича се никада не мења или мења усред Спринта.
Одговорност СЦРУМ Мастер-а и БА-а (ако је применљиво) је да осигурају да је наручилац налога правилно саставио корисничке приче уз одговарајући скуп критеријума за прихватање “. Ако треба извршити било какве промене које ће утицати на издање спринта, тада се такве приче извлаче из спринта или се раде према расположивим сатима.
Свака корисничка прича има критеријум прихватања који би тим требао добро дефинисати и разумети.
Критеријуми за прихватање детаљно описују корисничку причу која пружа пратећу документацију. Помаже у даљем усавршавању корисничке приче. Свако из тима може да запише критеријуме прихватања. Тест тим заснива своје тест случајеве / услове на овим критеријумима прихватања.
7) Епови
Епови су недвосмислене корисничке приче или можемо рећи да су то корисничке приче које нису дефинисане и чувају се за будуће спринтеве.
Покушајте то повезати са животом, замислите да идете на одмор. Како идете следеће недеље, на располагању вам је све, на пример резервације хотела, разгледање града, путнички чек итд. Али шта је са вашим планом одмора за следећу годину? Имате само нејасну идеју да можете да одете до места КСИЗ, али немате детаљан план.
Епиц је попут вашег плана за одмор за следећу годину, где једноставно знате да бисте можда желели да идете, али где, када, с ким, све ове детаље у овом тренутку немате појма.
На сличан начин постоје и функције које је потребно применити у будућности чији детаљи још увек нису познати. Углавном нека карактеристика започиње епском верзијом, а затим се дели на приче које би могле бити примењене.
8) Заостатак производа
Заостатак производа је врста сегмента или извора у којем се чувају све корисничке приче. Ово одржава власник производа. Заостатак производа може се замислити као листа жеља власника производа који му даје приоритет према пословним потребама.
Током састанка о планирању (види следећи одељак), једна корисничка прича је преузета из заосталих производа, а затим тим врши мозгалицу, разуме је и дорађује и колективно одлучује које ће корисничке приче узети, уз интервенцију власника производа.
9) Спринт Бацклог
На основу приоритета, корисничке приче узимају се из заосталих производа као једна по једна. Сцрум тим тим мозгом утврђује изводљивост и одлучује о причама које ће радити на одређеном спринту. Скупни списак свих корисничких прича које сцрум тим ради на одређеном спринту познат је као Спринт заостатак.
10) Стори Поинтс
Поента приче су квантитативни показатељ сложености корисничке приче. На основу приче, одређују се процена и напори за причу.
Поента приче је релативна и није апсолутна. Да бисмо били сигурни да су наша процена и напори тачни, важно је проверити да корисничке приче нису велике. Што је корисничка прича прецизнија и мања, то ће процена бити тачнија.
Свака корисничка прича додељена је тачки приче заснованој на Фибоначијевој серији (1, 2, 3, 5, 8, 13 и 21). Што је већи број, комплекс је прича.
Да будемо прецизни
- Ако наведете 1/2/3 приче, значи да је прича мала и да има малу сложеност.
- Ако дате бодове као 5/8, то је средње сложено и
- 13 и 21 су веома сложени.
Овде се сложеност састоји и од развоја и од напора за тестирање.
Да би се одлучило о причи, мождано олуја се дешава унутар сцрум тима и тим колективно одлучује о причи.
Може се догодити да развојни тим даје тачку приче 3 одређеној причи, јер за њих то могу бити 3 линије промене кода, али тим за тестирање даје 8 прича, јер сматрају да ће ова промена кода утицати на веће модуле, тако да напор би био већи. Коју год причу да дате, морате је оправдати.
Дакле, у овој ситуацији се дешава мождана олуја и тим се колективно слаже у једној причи.
Кад год се одлучите за причу, имајте на уму следеће факторе:
- Зависност приче са другом апликацијом / модулом.
- Скуп вештина ресурса.
- Сложеност приче.
- Историјско учење.
- Критеријуми прихватања корисничке приче.
Ако нисте свесни одређене приче, немојте је увећавати.
Кад год је прича = или> 8 поена, она се дели на 2 или више прича.
11) Табела сагоревања
Графикон сагоревања је граф који приказује процењени в / с стварни напор скрум задатака.
То је механизам праћења помоћу којег се за одређени спринт прате свакодневни задаци како би се проверило напредују ли приче ка завршетку преданих тачака приче или не.
Пример : Да бисте ово разумели, погледајте доњу слику:
Претпоставио сам:
- 2 недеље Спринт (10 дана)
- 2 ресурса који стварно раде на спринту.
„Прича“ -> Ова колона приказује корисничке приче узете за спринт.
'Задатак' -> Ова колона приказује листу задатака повезаних са корисничком причом.
'Напор' -> Ова колона приказује напор. Сада је ова мера укупан напор да се задатак изврши. Не приказује напор који улаже било која одређена особа.
„1. дан - 10. дан“ -> Ове колоне показују сате који су преостали за довршавање приче. Молимо вас да видите да сат НИЈЕ сат који је већ урађен, већ сати који су још преостали.
„Процењени напор“ -> Да ли је укупан напор. За „Старт“ то је једноставно збир целокупног појединачног задатка: СУМ (Ц5: Ц15)
Укупан број напора који треба обавити за један дан је 70/10 = 7. Дакле, на крају дана 1, напор треба да се смањи на 70 - 7 = 63. На сличан начин, израчунава се за све дана до 10. дана, када би процењени напор требао бити 0 (ред 16)
„Стварни напор лево“ -> Као што и само име говори, да ли је заправо уложен напор да се прича заврши. Такође се може догодити да се стварни напори повећају или смање од процењеног.
Можете да користите уграђене функције и Графикон у програму Екцел да бисте креирали овај сажети графикон.
Кораци сагоревања графикона би били:
- Унесите све приче (колона А5 - А15).
- Унесите све задатке (колона Б5 - Б15).
- Унесите дане (1. дан - 10. дан).
- Унесите почетне напоре (Збројите задатке Ц5 - Ц15).
- Примените формулу за израчунавање „Процењених напора“ за сваки дан (1. до 10. дан). Унесите формулу на Д15 (Ц16 - 16 Ц $ / 10) и превуците је свих дана.
- За сваки дан унесите стварне напоре. Унесите формулу на Д17 (СУМ (Д5: Д15)) за сумирање стварних преосталих напора и превуците је за све остале дане.
- Изаберите га и креирајте графикон на следећи начин:
12) брзина
Укупан број тачака приче које сцрум тим архивира у спринту назива се брзина. Сцрум тим се процењује или се на њега односи његова брзина. Имајући то у виду, треба имати на уму да овде циљ НИЈЕ постизање максималних бодова из приче, већ квалитетна испорука, поштујући ниво комфора сцрум тима.
На пример : За одређени спринт: укупан број корисничких прича је 8 са причама као што је приказано у наставку.
Дакле, овде ће брзина бити збир бодова приче = 30
Дефиниција готовог:
Спринт је означен као Готов када су све приче завршене, сви програми, задаци за развој, КА су означени као 'Довршени', све грешке су фиксно затворене, а оне које се могу касније урадити (попут нису у потпуности повезане или су мање важне) се извлаче и додају у заостатак, преглед кода и јединствено тестирање су завршени, процењени сати су испунили стварне сате предвиђене задацима и што је најважније успешан демо приказан је ПО и заинтересованим странама.
Активности урађене у СЦРУМ методологији
# 1) Састанак за планирање
Састанак за планирање је полазна тачка Спринта. То је састанак на којем се окупља цео сцрум тим, СЦРУМ Мастер бира корисничку причу на основу приоритета из заосталих производа и тимског мозга на њој.
На основу дискусије, сцрум тим одлучује о сложености приче и одређује је према Фибоначијевој серији. Тим идентификује задатке заједно са напорима (у сатима) који би се учинили да се доврши примена корисничке приче.
Често састанку за планирање претходи „састанак пре планирања“. То је исто као домаћи задатак који сцрум тим уради пре него што седне на формални састанак за планирање. Тим покушава да запише зависности или друге факторе о којима би желео да разговара на састанку о планирању.
# 2) Извршење спринт задатака
Као што и само име говори, ово је стварни посао који је сцрум тим обавио да би извршио свој задатак и одвео корисничку причу у стање „Готово“.
# 3) Дневни стандуп
Током спринт циклуса, сваки дан сцрум тим састаје се, не више од 15 минута (може бити усправни позив, препоручује се током дана) и наводи 3 бода:
- Шта је члан тима урадио јуче?
- Шта је члан тима планирао да уради данас?
- Има ли препрека (блокада путева)?
Сцрум мајстор је тај који води овај састанак. У случају да се било који члан тима суочава са било каквим потешкоћама, мастер надметања следи да би се решио. У Станд уп-има, одбор се такође прегледава и сам по себи показује напредак тима.
# 4) Преглед састанка
На крају сваког спринт циклуса, СЦРУМ тим се поново састаје и демонстрира имплементиране корисничке приче власнику производа. Власник производа може унакрсно верификовати приче према његовим критеријумима за прихватање. Поново је одговорност господара Сцрум-а да председава овим састанком.
Такође у алату СЦРУМ, Спринт је затворен и задаци су означени као готови.
# 5) Ретроспективни састанак
Ретроспективни састанак се дешава након састанка за ревизију.
СЦРУМ тим се састаје, расправља и документује следеће тачке:
- Шта је прошло добро током Спринта (најбоље праксе)?
- Шта није добро прошло у Спринту?
- Научене лекције
- Предмети акције.
Сцрум тим би требало да настави да следи најбољу праксу, да игнорише „не најбоље праксе“ и да примени лекције научене током следећих спринтова. Ретроспективни састанак помаже у спровођењу континуираног побољшања СЦРУМ процеса.
Како се ради процес? Пример!
Прочитавши техничке жаргоне СЦРУМ-а. покушаћу да демонстрирам цео процес на примеру.
Пример:
Корак 1 : Хајде да имамо СЦРУМ тим од 9 људи који се састоји од 1 власника производа, 1 Сцрум мастер, 2 тестера, 4 програмера и 1 ДБА.
Корак 2 : За Спринт је одлучено да следи 4-недељни циклус. Тако имамо 1-месечни Спринт почев од 5. јуна до 4. мартатхјула.
Корак # 3 : Власник производа има приоритетну листу корисничких прича у заостатку производа.
Корак # 4: Тим одлучује да се састане 4тхЈуна за састанак „Предпланирање“.
- Власник производа узима 1 причу из заосталих производа, описује је и препушта тиму да о њој размишља.
- Читав тим разговара и директно комуницира са власником производа да би јасно разумео корисничку причу.
- На сличан начин се узимају и разне друге корисничке приче. Ако је могуће, тим може да настави и да увећа и приче.
После свих дискусија, поједини чланови тима се враћају на своје радне станице и
- Идентификујте њихове појединачне задатке за сваку причу.
- Израчунајте тачан број сати на којима ће радити. Проверимо како члан закључује ове сате.
Укупан број радних сати = 9
Минус 1 сат за паузу, минус 1 сат за састанке, минус 1 сат за е-пошту, дискусије, решавање проблема итд.
Дакле, стварно радно време = 6.
Укупан број радних дана током Спринта = 21 дан.
Укупан број сати на располагању = 21 * 6 = 126.
Члан је на одсуству 2 дана = 12 сати (Ово се разликује за сваког члана, неки могу узети одсуство, а неки не.)
Број стварних сати = 126 - 12 = 114 сати.
То значи да ће члан заиста бити доступан 114 сати за овај спринт. Тако ће разбити свој индивидуални спринт задатак на такав начин да се постигне укупно 114 сати.
Корак # 5 : Дана 5тхјуна цео Сцрум тим састаје се на „састанку планирања“.
- Коначна пресуда о корисничкој причи из заосталих производа је готова и прича је премештена у Спринт Бацклог.
- За сваку причу, сваки члан тима изјављује своје идентификоване задатке, ако је потребно, може водити дискусију о тим задацима, може их увећати или променити величину (сетите се Фибоначијеве серије !!).
- Сцрум мајстор или тим уносе своје појединачне задатке заједно са својим сатима за сваку причу у алат.
- Након што су све приче завршене, Сцрум мајстор бележи почетну брзину и формално покреће Спринт.
Корак # 6 : Једном када је Спринт покренут, на основу додељених задатака, сваки члан тима почиње да ради на тим задацима.
Корак # 7 : Тим се састаје свакодневно по 15 минута и разговара о 3 ствари:
- Шта су радили јуче?
- Шта планирају да ураде данас?
- Има ли препрека (блокада путева)?
Корак # 8 : Сцрум мастер свакодневно прати напредак уз помоћ „Бурн довн цхарт“.
Корак # 9 : У случају било каквих сметњи, Сцрум мастер следи да их реши.
Корак # 10 : Дана 4тхЈула, тим се поново састаје на састанку за ревизију. Члан демонстрира имплементирану корисничку причу власнику производа.
Корак # 11 : Дана 5тхЈула, Тим се поново састаје на Ретроспективи, где разговарају
- Шта је прошло добро?
- Шта није добро прошло?
- Предмети акције.
Корак # 12 : Дана 6тхЈула, тим се поново састаје на састанку пре планирања за следећи спринт и циклус се наставља.
СЦРУМ Алат за активности
Постоји неколико алата који се могу широко користити за праћење скрум активности.
Неки од њих укључују:
У предстојећем упутству бацићемо светло на Агиле манифест који је појам који покреће ефикасне Агиле тимове.
О ауторима: Ову серију написали су следећи чланови СТХ тима: Схрути Схривастава - Професионални Сцрум мајстор са 9 година искуства у БФСИ, е-трговини и Б2Б доменима. Схрути је стручњак за тестирање аутоматизације и водећи сцрум тимове.Ансхул Кумар Сривастава - Професионални менаџер производа окренут ка резултатима и окретан практичар са 7 година искуства у БФСИ и Телеком сектору.
Препоручено читање
- Онлине квиз Агиле Сцрум: Проверите своје знање о Агиле Сцрум-у
- Канбан вс Сцрум вс Агиле: Детаљна упоредба за проналажење разлика
- Како испоручити софтверске функције високе вредности у кратком временском периоду помоћу Агиле Сцрум процеса
- Агиле Манифест: Разумевање агилних вредности и принципа
- САФе Агиле Туториал: Шта је Сцалед Агиле Фрамеворк
- 30+ најквалитетнијих питања и одговора за Сцрум интервју (ЛИСТА 2021)
- Агиле Вс Ватерфалл: Која је најбоља методологија за ваш пројекат?
- Топ 31 агилна питања и одговори у интервјуу