Արագաշարժ մտածելակերպ ընդդեմ արագաշարժ մեխանիզմներ

https://flic.kr/p/bkcj5q

Ես բազմիցս գտնում եմ, որ ծրագրային ապահովման թիմերը չափազանց կենտրոնացած են մեխանիզմների վրա և կորցնում են հիմնական սկզբունքի տեսողությունը: Դա հատկապես վերաբերում է արագաշարժ մեթոդաբանություններին: Scrum- ի նման մեթոդներն այնքան շատ մեխանիզմներ ունեն, որ նորերը արագաշարժությամբ լիովին կորչում են: Սկզբնապես ես դա գրել եմ որպես էլ-նամակ իմ թիմին ՝ պարզաբանելու համար, թե ինչպիսին է իմ կարծիքը Agile- ի մասին, բայց ես այն ուղարկել եմ հիմա շատ մարդկանց, որ Սքոթ Հանսելմանի խորհուրդը վերցնելով ՝ ես այն վերածում եմ բլոգային գրառման:

Ես ինքս ինձ ինչ-որ տեղ որակավորված եմ համարում այս պատկերացումը տրամադրելու համար: Ես արագաշարժ պրակտիկացի եմ այն ​​օրվանից, երբ Agile- ի զարգացումը ներգրավված է պտուտակահան օգտագործելով `ձեր սեփական խորանարդները ապամոնտաժել և ստեղծել նստատեղերի բաց պլան:

Իմ կարիերայի սկզբում ես աշխատել եմ բժշկական ծրագրային ապահովման ընկերության հետ: Մենք կառուցեցինք աշխատասեղանի ծրագրակազմ ՝ հիվանդանոցներում տեղադրված բժիշկների աշխատասեղանի վրա տեղադրված պատկերի վերանայման համար: Տեղակայման գործընթացը ներառում էր սկավառակների հետ մեկ այլ քաղաք ճանապարհորդելը և աշխատասեղանները, և պատկերի սերվերները տեղադրելը: Մենք ենթակա էինք FDA- ի հաստատմանը, այնպես որ մենք ստիպված էինք կառուցել այնպիսի ակնարկներ, որոնք եղել են FDA- ի հաստատման միջոցով: Սա իդեալական միջավայր էր ստեղծում վերևից ներքև, ջրվեժի մեթոդաբանության համար: Բոլոր ակնոցները գրվել են, հաստատվել, դուրս գրվել, և մենք կառուցել ենք այդ ակնոցները և միայն այդ ակնոցները: Դեռևս այն ժամանակ, երբ անձնակազմի թիմը սկսեց ճանապարհորդել տեղադրման թիմի հետ, և բժիշկներին հետևելը, օգտագործելով մեր ծրագրակազմը, մենք գիտակցում էինք, որ մենք կարող ենք այդքան լավը անել միայն այն դեպքում, եթե մենք կարողանայինք խոսել հաճախորդի հետ ցիկլի ավելի վաղ: Մենք ծածկագրեցինք ճշգրիտ ակնարկներ, և այնուամենայնիվ առաքեցինք այնպիսի բան, որն այնքան օգտակար չէր, որքան կարող էր լինել: Այս գրաֆիկը ցույց է տալիս իմ փորձի մի մասը:

Ինչպե՞ս կարող է խթանել ծրագրային ապահովման զարգացումը ՝ https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Այս անգամ իմ թիմը լսեց մի բան, որը կոչվում է արագաշարժ մանիֆեստ և մի պրակտիկ, որը կոչվում է Ծայրահեղ ծրագրավորում: Հաշվի առնելով, որ այն ստորագրվել են արդյունաբերության վետերանների կողմից, որոնց գրքերը, որոնք մենք ակտիվորեն կարդում էինք, այնպիսի մարդիկ, ինչպիսիք են Մարտին Ֆոուլերը և Քենթ Բեկը, պրակտիկային շատ լեգիտիմություն էին տալիս: Հինգ հոգուց բաղկացած իմ թիմը ապամոնտաժեց մեր խորանարդները, քաշեց մեր Վարչապետին (վստահված անձ մեր հաճախորդի համար), որ գա մեր կողքին նստելու, ինդեքս քարտերով տախտակ կազմելու և գնացինք աշխատանքի ՝ կազմելով XP, քանի որ մենք գնում էինք միասին: Մենք ունեցել ենք պլանավորման և ցուցադրման շաբաթական ցիկլ, շատ զուգավորում և քննարկում: Ես աշխատել եմ դրա տարբեր կրկնողությունների և տատանումների մեջ ՝ տարբեր ընկերություններում մոտ 15 տարի: Թվում էր, թե մի թիմ ընդհանրապես չի հետևում որևէ մեթոդաբանությանը, բայց դա այն էր, որ թիմի բոլոր անդամները խորը արագաշարժ ֆոնի վրա էին, որմնադրությունն ու համագործակցությունն իրենց գործնական ռեժիմն էին, և նրանց հարկադրված գործընթաց չէր պետք:

Այսպիսով, Agile- ը բաց հարկի պլանների մասին է, թե շատ է խոսվում: Եթե ​​ունեք stand-ups և հետադարձումներ, ապա կարող եք պնդել, որ դանդաղ եք: Որտեղ է տեղավորվում Scrum- ը կամ TDD- ն: Հաճախ մարդիկ շատ են բռնում գործընթացի առանձնահատկություններից `Scrum- ը կամ Kanban- ը: Երկու շաբաթ կամ մեկ շաբաթ սպրինտ: Եթե ​​դուք չունեք հետագա խնամք, արդյո՞ք արագաշարժ եք: Մեծանալով ակտիվ զարգացում ունենալով Agile մեթոդներով, մյուս ծրագրավորողների հետ հավասարապես զբաղվելով, զարգացնելով և հարմարվելով գործելակերպին, ինձ լավ պատկերացում է տվել, և այս գրառումը `հիմնական սկզբունքները պարզելն է:

Հեշտ լինելը կարողանում է արագորեն բավարարել հաճախորդների կարիքները: Դա նշանակում է, որ մենք ավելի արագ գրում ենք ծածկագիրը: Ոչ. Մենք չենք կարող հաղթել ֆիզիկայի օրենքները, և ամուր բազմաֆունկցիոնալ կիրառումը ժամանակ է պահանջում:

Այն, ինչ մենք պետք է անենք, դա է

  1. Բացահայտեք հիմնական բիզնես խնդիրները, որոնք մենք ցանկանում ենք լուծել կոդով
  2. Հիպոթեզը փորձարկելու համար արագ ներկայացրեք տեսական լուծում
  3. Կատարեք և հարմարվեք, քանի որ կարիքները փոխվում են, կամ մենք ավելին ենք սովորում
  4. Կատարեք դա համագործակցելով `հաճախորդի հետ թիմի ներգրավված մաս

Մնացած ամեն ինչ, որ մենք անում ենք, վերևից 2 և 3-ը ավելի քիչ ցավալի է. Իմանալ `որքանով ենք բավարարում անհրաժեշտությունը, և եթե հնարավոր չէ արագ փոխվել: Եթե ​​դուք որոշել եք կառուցել (vs buy), դուք գրում եք սովորական ծրագրակազմ: Սա նշանակում է, որ այն ունի մասնագիտացված պահանջներ և միջավայրեր:

Տեսանելի ինչ-որ բան ստանալը, նույնիսկ եթե դա գործառույթի փոքր ենթաբազմություն է, հաճախորդի առջև հնարավորինս շուտ թույլ է տալիս մեզ ավելի արագ արձագանքներ ստանալ: Սա է պատճառը, որ ես միշտ կողմնակից եմ, որ կենտրոնանամ հատկության մի փոքր կտոր կառուցելու վրա, վերջնարդյունքում և այդ ամենին հասնելու արտադրության: Ասեք, դուք էջ եք ստեղծում ձեր աջակից գործակալների համար ՝ հաճախորդի վերաբերյալ բոլոր տվյալները տեսնելու համար: Փոխանակ ծախսել շատ ժամանակ ամբողջ էջի վրա տվյալների աղբյուրները ուսումնասիրելու և նախևառաջ բոլոր API- ները գրելու համար, փորձեք էջի տվյալների ենթաբազմություն ստանալ ամբողջ արտադրության ճանապարհով: Դուք կկարողանաք իրականացնել ձեր ինտեգրման և տեղակայման մեխանիզմները, կարող եք սկսել հետադարձ կապ ստանալ UI- ի շրջանակում, թե ինչպես է այս էջը տեղավորվում ձեր դիմումի մնացած մասում և այլն: երբ դուք կառուցել եք API- ի մի ամբողջ ծրագիր:

Ահա մի քանի այլ մեխանիզմներ, որոնք անհրաժեշտ են շարժունության համար

Sprints. Ժամանակային բռնցքամարտիկ ցիկլերի զարգացումը թույլ է տալիս մեզ ստուգել և հարմարվել, և կանոնավոր պարբերականությամբ նոր տվյալներ ներառել `ապահովելու, որ մենք դեռ աշխատում ենք համապատասխան հատկանիշների վրա: Ծրագրակազմը պարտավորություն է: Մենք պետք է կառուցենք միայն այն, ինչ մեզ պետք է և կարողանանք ավելացնել, երբ անհրաժեշտ է: Հետևաբար անհրաժեշտ է պարբերաբար դիտարկել այն, ինչ մենք կառուցել ենք մինչ այժմ և ուր ենք գնում: Սա հանգեցնում է երկրորդ կետի:

Հաշվի առնելով, որ մենք պլանավորում ենք անընդհատ գնահատել և փոխել, մեր ծրագրաշարը պետք է հեշտ լինի փոփոխել: Ի՞նչ անել, եթե հաճախորդը դիմումը սկսելուց հետո ցանկանա, որ որոշ տվյալներ այլ կերպ ներկայացնեն, քան նախապես մշակված էին: Կարո՞ղ ենք դա անել առանց էջի մնացած ամեն ինչի վրա դիպչելու: Կամ մենք պետք է այլ API զանգահարենք ՝ տվյալներ ստանալու համար. Կարո՞ղ ենք այդ փոփոխությունն իրականացնել անվտանգ: Հենց այստեղ են ստեղծվում զարգացման լավ պրակտիկա և մեխանիզմներ

Միավորի ստուգում. Մենք տարբեր մակարդակներում ունենք ավտոմատացված թեստավորում, ուստի փոփոխությունների համար կա անվտանգության ցանց: Կարևոր է նաև զգույշ լինել, թե ինչն է իրականում ստուգում միավորի թեստերը: Միավորի թեստերը պետք է փորձարկեն տրամաբանությունը: Եթե ​​վերը նշված օրինակն եք վերցնում ՝ այլ տվյալներ ստանալու համար այլ API օգտագործելով, իդեալականորեն, չպետք է պահանջեք փոփոխություն կատարել մեր API- ի միավորների թեստերի համար, որոնք տվյալները սպասարկում են UI- ին: Միավորի թեստերը գոյություն ունեն, որպեսզի ձեզ վստահություն հաղորդեք ծածկագիրը վերափոխելուց, ինչն էլ իր հերթին հնարավորություն է տալիս գրել միայն այն, ինչ ձեզ հարկավոր է հիմա գրել, իսկ ավելի ուշ հանգստանալ ՝ ոչ մի դեպքում, որքան հնարավոր է, չպատրաստեք մոտ 100% ծածկույթի մետր:

CI / CD. Սա մեզ հնարավորություն է տալիս կրճատել հանձնառության և առաքման միջև եղած հեռավորությունը: Սա անհրաժեշտ է շարժունության համար: Երբ տեղակայման խոչընդոտները հանվում են, և մենք կարող ենք արտադրության փոքր փոփոխություններ մղել, փոփոխությունների ռիսկը մեծապես նվազում է: Եթե ​​տեղակայությունները հոգնեցուցիչ են, դրանք ավելի հազվադեպ են լինում: Ավելի քիչ հաճախակի տեղակայումը մեկ տոննա փոփոխություն է մղում ՝ շոշափելով մեծ տարածքի տարածք և, հետևաբար, ավելի ռիսկային է: Եթե ​​ավելին իմանաք այն մասին, թե ինչու է կարևոր ծրագրային ապահովման մատուցման կատարումը և ինչ մետր է օգտագործել այն օպտիմիզացնելու համար, ես խորհուրդ եմ տալիս խորհուրդ տալ Nicole Forsgren- ի այս գիրքը:

Մտահոգությունների առանձնացում. Հանգիստ զուգակցված ճարտարապետությունը անհրաժեշտ է ծրագրային ապահովման համար, որը հեշտ է փոխել: Այն նվազեցնում է փոփոխության մակերեսը: Միկրոէներգետիկ ծառայությունները և բեռնարկղերը մտահոգությունների տարանջատման համար օգտագործվող որոշ մեխանիզմներ են: Կարևոր է հիշել դա և անպայման հիշել մտահոգությունների տարանջատումը ՝ API, բաղադրիչներ և ծրագրեր կառուցելիս:

Հիշիր
Լավ ծածկագիրը հեշտությամբ կարելի է փոխել

Ավելի լավ կոդը հեշտությամբ կարելի է ջնջել

Լավագույն կոդն այն է, ինչը բնավ չի գրվել

Անհրաժեշտ է, որ ձեր ստեղծած բիթերը որքան հնարավոր է շուտ համապատասխանեն իրական աշխարհին, այնպես որ դուք գիտեք, թե ինչպիսին պետք է լինեն ձեր նոր բիթերը, և ժամանակ չեք վատնում ավելորդ բիտեր պատրաստելու մեջ: