Agile mąstysena vs judrūs mechanizmai

https://flic.kr/p/bkcj5q

Ne kartą pastebėjau, kad programinės įrangos komandos per daug susikoncentruoja į mechanizmus ir pamiršta pagrindinį principą. Tai ypač pasakytina apie „Agile“ metodikas. Tokiuose metoduose kaip „Scrum“ yra tiek daug mechanizmų, kad visi naujieji, kurie yra judrūs, visiškai pasimeta. Iš pradžių parašiau tai kaip el. Laišką savo komandai, norėdamas išsiaiškinti, koks buvo mano požiūris į Agile, tačiau dabar išsiunčiau jį tiek daug žmonių, kad, pasinaudodamas Scotto Hanselmano patarimais, paversiu jį tinklaraščio įrašu.

Manau, kad esu pakankamai kvalifikuotas pateikti šią įžvalgą. Aš esu veržlus praktikas nuo tų dienų, kai judrus vystymasis buvo atliekamas naudojant atsuktuvą - išardyti savo kabinas ir sudaryti atvirą sėdėjimo planą!

Ankstyvos karjeros metu dirbau medicinos programinės įrangos įmonėje. Sukūrėme vaizdų peržiūros programinę įrangą, kuri buvo įdiegta gydytojo darbalaukyje ligoninėse. Diegimo procesas apėmė keliones su kompaktiniais diskais į kitą miestą ir stalinių kompiuterių bei vaizdo serverių diegimą. Mums buvo reikalingas FDA patvirtinimas, todėl turėjome remtis specifikacijomis, kurios buvo patvirtintos FDA. Tai sukūrė idealią aplinką krioklio iš viršaus į apačią metodikai. Visos specifikacijos buvo nurašytos, patvirtintos, pasirašytos ir mes remėmės tik tomis specifikacijomis. Tik tada, kai „dev“ komanda pradėjo keliauti kartu su įrengimo komanda ir stebėdama, kaip gydytojai naudojasi mūsų programine įranga, supratome, kad galime padaryti daug geriau tik tuo atveju, jei jau pabendrausime su klientu anksčiau. Mes užkodavome tikslias specifikacijas ir vis tiek pristatėme tai, kas nebuvo tokia naudinga, kaip galėjo būti. Šis paveikslėlis parodo tam tikrą mano patirtį.

Kaip gali suklysti programinės įrangos kūrimas iš https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Maždaug tuo metu mano komanda išgirdo apie vadinamąjį „Agile“ manifestą ir praktiką, vadinamą „Extreme Programming“. Atsižvelgiant į tai, kad ją pasirašė pramonės veteranai, kurių knygas mes aktyviai skaitėme, tokie žmonės kaip Martinas Fowleris ir Kentas Beckas praktikavo labai teisėtai. Mano penkių asmenų komanda išardė mūsų kabinas, patraukė į savo kabinetą (kliento įgaliotinį) ateiti sėdėti šalia mūsų, pastatyti lentą su rodyklės kortelėmis ir nuvykti į darbą, sudarydami XP, kaip mes ėjome. Mes turėjome savaitinį planavimo ir demonstracinių darbų ciklą, daug porų ir diskusijų. Apie 15 metų dirbau įvairiose iteracijose ir variantuose. Atrodė, kad viena komanda visiškai nesivadovavo jokia metodika, tačiau taip buvo todėl, kad visi komandos nariai buvo iš labai judraus fono, iteracija ir bendradarbiavimas buvo jų numatytoji darbo būsena ir jiems nereikėjo primesto proceso.

Taigi ar judrus yra apie atvirų grindų planus ar daug kalba? Jei turite „stand-up“ ir retrospektyvų, ar galite teigti, kad esate judrus? Kur tinka „Scrum“ ar TDD? Dažnai žmonės per daug įsitraukia į proceso specifiką - „Scrum“ ar „Kanban“? Dvi savaitės ar viena savaitė sprintas? Jei neturite vilkinčių vilčių, ar tikrai esate judrus? Aš užaugau aktyviai kurdamas, naudodamas „Agile“ metodus, su kitais kūrėjais vienodai įsitraukęs, kurdamas ir adaptuodamas praktiką. Tai man suteikė gerą supratimą ir šis įrašas yra nustatyti pagrindinius principus.

Būdamas judrus, gebi greitai patenkinti klientų poreikius. Ar tai reiškia, kad kodą rašome greičiau? Ne. Negalime sumušti fizikos įstatymų, o tvirtai daugiafunkcinei programai sukurti reikia laiko.

Ką turime padaryti, tai turime

  1. Nurodykite esmines verslo problemas, kurias norime išspręsti naudodami kodą
  2. Greitai pateikite teorinį sprendimą, kad patikrintumėte hipotezę
  3. Pakartokite ir prisitaikykite, kai keičiasi poreikiai arba mes sužinome daugiau
  4. Darykite tai bendradarbiaudami su užsakovu su užimta komandos dalimi

Visa kita, ką mes darome, yra 2 ir 3 punktų padarymas mažiau skausmingi - žinoti, ar kuo greičiau patenkiname poreikį, o jei negalime greitai pakeisti. Jei nusprendėte kurti (palyginti su pirkti), rašote pasirinktinę programinę įrangą. Tai reiškia, kad ji turi specialius reikalavimus ir aplinką.

Gavę ką nors matomo, net jei tai yra nedidelis funkcijų pogrupis, kuo greičiau priešais klientą galime gauti grįžtamąjį ryšį. Štai kodėl aš visada palaikau dėmesį sutelkdamas dėmesį į mažą gabaliuko bruožą iki galo ir gaudamas visą kelią iki gamybos. Tarkime, jūs kuriate puslapį savo palaikymo agentams, kad matytumėte visus duomenis apie klientą. Užuot daug laiko skyrę viso puslapio duomenų šaltinių tyrinėjimui ir pirmiausia parašę visas API, pabandykite gauti duomenų pogrupį puslapyje iki gaminimo pradžios. Galėsite naudotis savo integracijos ir diegimo mechanizmais, galėsite pradėti gauti atsiliepimus apie vartotojo sąsajos sistemą, kaip šis puslapis tinka su likusia jūsų programos dalimi ir tt Šiuos dalykus lengviau pritaikyti, kai turite nedidelį kodo kiekį, o ne kai sukūrėte visą API sistemą.

Čia yra keletas kitų mechanizmų, kurie yra būtini judrumui

„Sprint“: Vystydamiesi tam tikrais ciklais, leidžia mums tikrinti ir pritaikyti bei reguliariai įterpti naujus duomenis, kad įsitikintume, jog vis dar dirbame prie atitinkamų funkcijų. Programinė įranga yra atsakomybė. Turėtume kurti tik tai, ko mums reikia, ir sugebėti įtraukti tai, ko reikia, kai to reikia. Taigi svarbu reguliariai žiūrėti į tai, ką iki šiol pastatėme ir kur einame toliau. Tai veda prie antrojo punkto.

Atsižvelgiant į tai, kad planuojame nuolat vertinti ir keisti, mūsų programinę įrangą turėtų būti lengva pakeisti. Ką daryti, jei klientas, pradėjęs naudotis programa, norėjo, kad kai kurie duomenys būtų rodomi kitaip, nei buvo numatyta iš pradžių? Ar galėtume tai padaryti neliesdami viso kito puslapyje? Arba mes turime skambinti į kitą API, kad gautume duomenis - ar galėtume tą pakeitimą atlikti saugiai? Čia atsiranda gerosios plėtros praktika ir mechanizmai

Vieneto testavimas: mes turime automatinį testavimą įvairiais lygiais, todėl yra apsauginis tinklas pokyčiams. Taip pat svarbu nepamiršti, ką iš tikrųjų išbando vieneto bandymai. Vienetų testai turėtų patikrinti logiką. Jei paimsite aukščiau pateiktą pavyzdį, naudodami kitą API duomenims gauti, idealiu atveju nereikėtų keisti mūsų API, teikiančios duomenis į vartotojo sąsają, vienetų bandymų. Vienetų testai suteikia pasitikėjimo kodą atnaujinti, o tai savo ruožtu suteikia laisvę rašyti tik tai, ko jums reikia dabar, ir ilsėtis vėliau, kad bet kokiu atveju negalėtumėte sukurti 100% aprėpties metrikos.

CI / CD: Tai leidžia mums sutrumpinti atstumą tarp įsipareigojimo ir pristatymo. Tai būtina judrumui. Pašalinus diegimo kliūtis ir mes galime padaryti nedidelius gamybos pokyčius, pokyčių rizika žymiai sumažėja. Jei dislokavimas yra nuobodus, jie vyksta rečiau. Rečiau diegiant išstumiama daugybė pakeitimų, paliečiamas didelis paviršiaus plotas, todėl jie yra rizikingesni. Jei sužinote daugiau apie tai, kodėl programinės įrangos pristatymas yra svarbus, ir kokią metriką reikia naudoti norint ją optimizuoti, aš labai rekomenduoju šią Nicole Forsgren knygą.

Rūpesčių atskyrimas: Programinė įranga, kurią lengva pakeisti, yra labai svarbi silpnai susieta architektūra. Tai sumažina pokyčio paviršiaus plotą. Mikro paslaugos ir talpyklos yra keletas mechanizmų, naudojamų siekiant atskirti rūpesčius. Kuriant API, komponentus ir programas, svarbu tai atsiminti ir nepamiršti atskirti rūpesčių.

Prisiminti
Gerą kodą galima lengvai pakeisti

Geresnį kodą galima lengvai ištrinti

Geriausias kodas yra tas, kuris visai nebuvo parašytas

Svarbu, kad jūsų sukurti bitai kuo greičiau atitiktų realųjį pasaulį, kad žinotumėte, kaip turi atrodyti jūsų naujieji bitai, ir negaiškite laiko nereikalingų bitų kūrimui.