Mendësia e shkathët vs mekanizmat e shkathët

https://flic.kr/p/bkcj5q

Në mënyrë të përsëritur konstatoj se skuadrat e softuerëve përqendrohen shumë në mekanizma dhe nuk e shohin parimin themelor. Kjo është veçanërisht e vërtetë për metodologjitë e shkathëta. Metoda të tilla si Scrum kanë kaq shumë mekanizma sa që ata të rinj për të shkathët plotësisht humbasin. Unë fillimisht e shkrova këtë si një email për ekipin tim për të sqaruar se cili ishte pikëpamja ime për Agile, por unë ua kam dërguar atë kaq shumë njerëzve tani, që duke marrë këshillat e Scott Hanselman, unë po e kthejë atë në një postim në blog.

Unë e konsideroj veten disi të kualifikuar për të siguruar këtë pasqyrë. Unë jam një praktikues i shkathët që nga ditët kur zhvillimi i shkathët përfshinte përdorimin e një kaçavidë - të çmontoni kabinat tuaja dhe të krijoni një plan të hapur për shtrojë!

Në fillim të karrierës sime kam punuar me një kompani të softuerit mjekësor. Ne ndërtuam një softuer desktop për rishikimin e figurave që u instalua në desktopin e mjekut në spitale. Procesi i vendosjes përfshinte udhëtimin me CD në një qytet tjetër dhe instalimin e desktopëve dhe serverëve të figurave. Ne i nënshtroheshim aprovimit të FDA-së, kështu që duhej të ndërtonim specifik që kishin qenë me aprovimin e FDA-së. Kjo krijoi një mjedis ideal për metodologjinë e ujëvareve nga lart-poshtë. Të gjitha specifikat u shkruajtën, u aprovuan, u nënshkruan dhe u ndërtuam vetëm për ato syze dhe ato syze vetëm. Nuk ishte deri kur skuadra dev filloi të udhëtonte me ekipin e instalimit dhe duke parë mjekët të përdorin softuerin tonë, ne kuptuam se mund të bënim shumë më mirë vetëm nëse mund të bisedonim me klientin më herët në cikël. Ne i koduam specifikat e sakta, dhe megjithatë dorëzuam diçka që nuk ishte aq e dobishme sa mund të ishte. Kjo grafikë tregon disa nga përvoja ime.

Si mund të shkojë keq nga zhvillimi i softverit nga https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Rreth kësaj kohe skuadra ime dëgjoi diçka që quhet Manifesti i shkathët dhe një praktikë e quajtur Programim ekstrem. Duke pasur parasysh që ajo u nënshkrua nga veteranët e industrisë, librat e të cilëve ne po lexonim në mënyrë aktive, njerëz si Martin Fowler dhe Kent Beck, i dhanë praktikës shumë legjitimitet. Ekipi im prej pesë vetash çmontoi kuzhinat tona, tërhoqi në kryeministrin tonë (prokurë për klientin tonë) për të ardhur të ulet pranë nesh, vendosi një bord me karta indeksi dhe shkoi në punë, duke përbërë XP ndërsa shkuam. Ne patëm një cikël javor të planifikimit dhe demos, shumë çiftim dhe diskutime. Kam punuar në iteracione dhe variante të ndryshme të kësaj, në kompani të ndryshme për rreth 15 vjet. Një ekip dukej se nuk ndiqte fare metodologji, por ishte për shkak se të gjithë anëtarët e ekipit ishin me prejardhje të thellë të shkathët, iteracioni dhe bashkëpunimi ishte gjendja e tyre e paracaktuar e funksionimit dhe ata nuk kishin nevojë për një proces të imponuar.

Pra, është e shkathët në lidhje me planet me dysheme të hapur apo po flasim shumë? Nëse keni ngritje dhe retro mund të pretendoni se jeni i shkathët? Ku përshtatet Scrum ose TDD? Shpesh njerëzit kapen shumë me specifikat e procesit - Scrum apo Kanban? Dy javë apo një javë sprint? Nëse nuk keni kujdes për backlog, a jeni vërtet i shkathët? Duke u rritur duke bërë zhvillim aktiv duke përdorur metoda të shkathëta, me zhvilluesit e tjerë të angazhuar në mënyrë të barabartë, duke zhvilluar dhe përshtatur praktikat, më ka dhënë një pasqyrë të mirë dhe ky postim është të identifikojë parimet themelore.

Të qenit i shkathët është në gjendje të plotësojë shpejt nevojat e klientëve. A do të thotë kjo që ne shkruajmë kod më shpejt? Jo. Ne nuk mund të mposhtim ligjet e fizikës, dhe një kërkesë solide shumë funksionale kërkon kohë për të ndërtuar.

Ajo që duhet të bëjmë është

  1. Identifikoni problemet thelbësore të biznesit që duam t'i zgjidhim me kod
  2. Dorëzoni një zgjidhje teorike shpejt për të provuar hipotezën
  3. Itero dhe adaptohesh ndërsa ndryshojnë nevojat, ose mësojmë më shumë
  4. Bëni atë në bashkëpunim, me klientin një pjesë të angazhuar të ekipit

Do gjë tjetër që bëjmë është t’i bëjmë 2 dhe 3 më lart më pak të dhimbshëm - të dimë nëse po e plotësojmë nevojën sa më shpejt të jetë e mundur, dhe nëse jo të jemi në gjendje të ndryshojmë shpejt. Nëse keni vendosur të ndërtoni (vs Buy), ju po shkruani softuer personal. Kjo do të thotë se ka kërkesa dhe mjedise të specializuara.

Marrja e diçkaje të dukshme, edhe nëse është një pjesë e vogël e funksionalitetit, përpara klientit sa më shpejt të jetë e mundur na lejon të marrim përshtypje më shpejt. Kjo është arsyeja pse unë gjithmonë avokoj që të përqendrohemi në ndërtimin e një pjese të vogël të veçorisë, nga fundi në fund, dhe ta marr atë deri në fund të prodhimit. Thuaj, ju po ndërtoni një faqe për agjentët tuaj të ndihmës për të parë të gjitha të dhënat në lidhje me një klient. Në vend që të shpenzoni shumë kohë për të hulumtuar burimet e të dhënave për të gjithë faqen dhe shkruani të gjitha API-të së pari, mundohuni të merrni një nënbashkësi të të dhënave në faqe gjatë gjithë rrugës për prodhim. Do të jeni në gjendje të ushtroni mekanizmat tuaj të integrimit dhe vendosjes, mund të filloni të merrni feedback në kornizën UI, si përshtatet kjo faqe me pjesën tjetër të aplikacionit tuaj, etj. Këto gjëra janë më të lehta për tu rregulluar kur keni një sasi të vogël të kodit, në të kundërt kur të keni ndërtuar një kornizë të tërë API.

Këtu janë disa nga mekanizmat e tjerë që janë thelbësorë për gatishmërinë

Sprints: Zhvillimi në cikle të bllokuara me kohë, na lejon të inspektojmë dhe përshtatemi, dhe të përfshijmë të dhëna të reja në intervale të rregullta për të siguruar që ne jemi ende duke punuar në veçoritë përkatëse. Softueri është një detyrim. Ne vetëm duhet të ndërtojmë atë që na nevojitet, dhe të jemi në gjendje të shtojmë atë që është e nevojshme, kur është e nevojshme. Prandaj është thelbësore të shikojmë rregullisht atë që kemi ndërtuar deri më tani dhe ku po shkojmë më tej. Kjo çon në pikën e dytë.

Duke pasur parasysh që ne po planifikojmë të vlerësojmë dhe ndryshojmë vazhdimisht, programi ynë duhet të jetë i lehtë për tu ndryshuar. Po sikur, pasi një klient të fillojë të përdorë aplikacionin, ata donin që disa të dhëna të shfaqeshin ndryshe nga sa ishin dizajnuar fillimisht? A mund ta bëjmë atë pa prekur gjithçka tjetër në faqe? Apo duhet të telefonojmë një API të ndryshëm për të marrë të dhëna - a mund ta bëjmë atë ndryshim të sigurt? Këtu hyjnë praktikat dhe mekanizmat e mirë të zhvillimit

Testimi i njësisë: Ne kemi testuar automatikë në nivele të ndryshme, kështu që ekziston një rrjet sigurie për ndryshime. Shtë gjithashtu e rëndësishme të jesh i ndërgjegjshëm për atë që teston njësia në të vërtetë. Testet e njësive duhet të testojnë logjikën. Nëse merrni shembullin e mësipërm, duke përdorur një API të ndryshëm për të marrë të dhëna, në mënyrë ideale, nuk duhet të kërkoni ndryshim në testet e njësive për API-në tonë që i shërben të dhënave UI. Testet e njësive ekzistojnë për t'ju dhënë besimin për të refaktuar kodin, i cili nga ana juaj ju jep lirinë e të shkruarit vetëm atë që ju nevojitet tani, dhe pushoni më vonë, për të mos prodhuar rreth 100% metrikë të mbulimit gjithsesi që mundeni.

CI / CD: Kjo na mundëson të shkurtojmë distancën midis kryerjes dhe dorëzimit. Kjo është thelbësore për shkathtësinë. Kur pengesat për vendosjen janë hequr, dhe ne mund të shtyjmë ndryshime të vogla në prodhim, rreziku nga ndryshimi është ulur shumë. Nëse dislokimet janë të lodhshme, ato janë më pak të shpeshta. Vendosjet më pak të shpeshta shtyjnë një ton ndryshimesh, duke prekur një sipërfaqe të madhe, dhe kështu janë më të rrezikshme. Nëse mësoni më shumë rreth asaj se pse ka rëndësi performanca e dorëzimit të softuerëve dhe çfarë metrike të përdorni për ta optimizuar, ju rekomandoj shumë këtë libër nga Nicole Forsgren.

Ndarja e shqetësimeve: Një arkitekturë e shoqëruar lirshëm është thelbësore për një program që është i lehtë për tu ndryshuar. Zvogëlon sipërfaqen e një ndryshimi. Shërbimet e mikrobizmave dhe kontejnerët janë disa nga mekanizmat që përdoren për të ushtruar ndarjen e shqetësimeve. Shtë e rëndësishme të mbani mend këtë dhe sigurohuni që të mbani në mend ndarjen e shqetësimeve, kur ndërtoni API, përbërës dhe aplikacione.

kujtoj
Kodi i mirë mund të ndryshohet lehtësisht

Kodi më i mirë mund të fshihet lehtësisht

Kodi më i mirë është ai që nuk ishte shkruar fare

Shtë thelbësore që pjesët që krijoni të përmbushin botën e vërtetë sa më shpejt të jetë e mundur, kështu që ju e dini se si duhet të duken pjesët tuaja të reja dhe nuk humbni kohë për të bërë copa të panevojshme.