Kjo përmbajtje është vetëm për abonentët
Të mësuarit e shkathët
Përmbledhje Libri
Hyrje
Çfarë ka në këtë libër për mua?
Një hyrje tek shkathtësia.
Konsumatorët nuk e dinë gjithnjë çfarë duan-apo për çfarë kanë nevojë. Siq thonte njëherë Henry Fordi, nëse ai do t’i kishte pyetur njerëzit se çfarë donin, ata do të kishin thënë: ‘’kuaj më të shpejtë.’’
Natyrisht, Fordi ju dha atyre vetura. Por imagjinoni sikur mos t’ua kishte dhënë ato.Do të ishin shkuar vite huq për t’u munduar për ta mbushur kërkesën. Gjasat janë, se deri sa produkti i Fordit ta kishte marrë tregun, dikush tjetër tashmë do të kishte filluar të shiste vetura të qëndrueshme dhe të lira. Produkti i tij do të kishte qenë i vdekur që në fillim.
Në këtë pulsim, sidoqoftë, do të flasim për zhvillimin e softverit, jo për veturat. Por do të shikojmë në të njëjtin problem. Ai problem mund të përmblidhet në një pyetje të vetme: si e dërgoni një produkt të vlefshëm tek një konsumator, edhe nëse konsumatori nuk mund t’iu tregojë se për çfarë ka nevojë apo do.
Një përgjigje është grupi i praktikave dhe parimeve të njohura si shkathtësi. Nëse e keni dëgjuar këtë fjalë më parë, ndoshta keni hasur edhe në disa koncepte të ndërlidhura – si scrum, kanban, XP dhe lean. Shpesh, ekziston një tundim për të nxituar për të diskutuar këto metodologji së bashku me shkathtësinë.
Për Andrew Stellman dhe Jennifer Greene, autorët e ”Të mësuarit e shkathët”, kjo rrezikon vendosjen e kartës para kalit. Në fund të fundit, nuk ka kuptim të futemi në rrëmujë, nëse nuk kemi treguar pse ju dhe organizata juaj duhet të konsideroni të shkathët në radhë të parë. Pra, kjo është ajo që ne do të bëjmë në këtë pulsim: do ta shohim arsyen e shkathtësisë.
Për ta bërë këtë, do ta ndjekim një projekt nga fillimi në fund. Përgjatë rrugës, do ta shohim se si parimet e shkathtësisë mund ta ndihmojnë një ekip të zhvilluesve softverik të punojnë në mënyrë më efektive dhe efikase-dhe të sjellin një produkt më të mirë.
Ideja kyçe
Ju mund të dizajnoni një softver të mirë në një vakum.
Le të flasim për lexuesit e librave elektronike për një sekond.
Nuk duhet shumë për ta kuptuar pse janë aq të njohura. Vetë objekti ka të bëjë me madhësinë e kopertinës së zakonshme, por përmban mijëra libra. Edhe më mirë se kaq, çdo tekst është i përgjigjshëm ndaj jush, lexuesve.Mund t’i zmadhoni fjalët, ta ndryshoni fontin, apo të ktheheni para dhe prapa në mes të tekstit kryesor dhe referencave.Me një klik të vetëm, mund të keni qasje në librari dhe në katalogje; me një tjetër klik, mund të huazoni apo të shkarkoni libra të rinjë në pajisjen tuaj.
Shkurtimisht, ky është një softver i mrekullueshëm. Është i dizajnuar mirë. I përshtatshëm. Intuitiv. Ai e kënaq çdo aksionar. Lexuesit e kanë të lehtë ta përdorin, dhe i shfaq tekstet në mënyrë të saktë, gjë që është me rëndësi për autorët.Ai poashtu i ndihmon libraristët dhe botuesit të shesin dhe shpërndajnë libra.
Lexuesit e parë të librave elektronikë nuk i bënin të gjitha këto gjëra.Në fakt, u desh një dekadë zhvillimi para se softveri të mbërrinte ku është tani. Por në fillim të viteve të 2000-ta, nuk ishte e qartë se çfarë do ta bënte një lexues i librave elektronikë të çmueshëm. Ne e dimë këtë sot vetëm për shkak të pasqyrës së pasme 20/20-që na shpie tek eksperimenti ynë i vogël i mendimit.
Le të kthehemi pas në kohë. Imagjinoni sikur të na ishte dhënë një detyrë për zhvillimin e softverit për të shfaqur libra elektronikë në paisje të reja që mbahen në dorë. Si do t’i qaseshim detyrës tonë?
Mirë, ne aktualisht do ta bëjmë këtë në mënyrën më të keqe të mundshme sepse kjo nuk është ajo lloj kompanie që po eksploron mënyra të reja të ndërtimit të softverit. Ky është një operim i demoduar, me liderë që udhëheqin, dhe ndjekës-që jemi ne, zhvilluesit (develloperët)-që pasojnë. Shkurt, kjo nuk është ajo lloj zyreje kur do ta dëgjoni fjalën ‘’shkathtësi.’’Prandaj le ta shohim si zhvillohen gjërat.
Ekipi i hardverit tashmë e ka bërë një prototip. Imagjinoni një tabletë të trashë të zezë me një port USB për ngarkimin e librave dhe një tastierë të vogël të vështirë për të bashkëvepruar me lexuesin. Na takon ne të ndërtojmë softuerin që do të shfaqë libra elektronikë në këtë vegël.
Kompania jonë e aplikon atë që njihet në projektet e saj si Procesi Ujëvarë.Kjo domethënë se projektet ngarkohen nga fillimi. Të gjitha kërkesat e produktit përcaktohen ne fillim. Siq thamë, liderët udhëheqin dhe ndjekësit ndjekin. Të gjithë aksionarët-menagjerët e lartë, përfaqësuesit e botuesëve, shitësit me pakice online, e kështu me radhë-ulen dhe bëjnë një plan. Ata i skicojnë kërkesat dhe vijnë me veqanti që i shënjon të gjitha kutitë përkatëse. Çdo tjetër fazë e procesit, nga dizajni tek zhvillimi dhe testimi, rrjedh në rrjedhën e poshtme nga këto vendime ashtu si një trup uji rrjedh në rrjedhën e poshtme nga një ujëvarë.
Pra cila është veqantia? Me një fjalë, gjithçka.Ky lexues i librave online do të jetë revolucionar. Do të ketë tonelata veqorishë. Do t’i kapë statistikat e tregut për botuesit. do të ketë një vitrinë në internet për lexuesit që të blejnë libra. Autorët do të jenë në gjendje të shikojnë paraprakisht dhe redaktojnë librat e tyre ndërsa i shkruajnë. Dhe gjithçka do të jetë gati për 18 muaj.
Shkoni një vit e gjysmë më përpara. Meqenëse është një eksperiment mendimi, nuk kemi nevojë të jemi realistë, prandaj do të themi se projekti është përfunduar në kohë. Dhe është i tëri aty-çdo kërkesë në veqanti është zbatuar, testuar dhe verifikuar. Të gjithë janë të lumtur.
A mund ta hamendësoni çfarë ndodh më tutje? Lexuesi e merr tregun…dhe përplaset. Shumë keq. Askush nuk e blen atë.
Dhe çfarë mund të ketë shkuar keq?
E vërteta është se nevojat e njerëzve nuk janë statike-ato ndryshojnë me kohën. Nëse zgjidhja juaj e vetme është një kali, atëherë ju doni një kalë më të shpejtë.Por një kalë, pa marrë parasysh sa i shpejtë është, nuk hyn shumë në punë nëse të gjithë tashmë po ngasin vetura. Njësoj, softveri për të cilin njerëzit kishin 18 muaj më parë nuk është softveri që ju nevojitet tani.Qëkur filloi projekti ynë, është shfaqur një standard i ri i industrisë për librat elektronikë.Asnjë shitës nuk dëshiron ta botojë formatin tonë të pastandardizuar-është shumë për të kërkuar. Dhe kështu, asnjëra prej veqorive tona revolucionare nuk është mbështetur, që domethënë se ato nuk i hyjnë në punë askujt.
Kjo poashtu nënkupton se kemi humbur shumë kohë dhe para duke përgaditur një softver që nuk është shumë i vlefshëm. Pra çfarë duhet të kemi bërë ndryshe?
Ideja kyçe 2
Lansoni një softver me të meta sot, dhe nesër do të përfundoni me një produkt më të mirë përfundimtar.
Ja ku kemi gabuar: ishim të papërgjegjshëm. I kaluam 18 muaj duke punuar në një fluskë për ta zbatuar një plan që ishte i vjetër tashmë para se ta arrinte tregun. Nuk kishte rregullime. Nuk ishim fleksibilë. Projekti jonë, shkurt thënë, nuk ishte i përsëritshëm.
Një proces dizajni përsëritës nuk ndodh në vakum. Në vend të kësaj ai i rrotullon produktet tona shpejtë, duke i shpierë tek konsumatorët sa më shpejt që mundet dhe duke marrë komente.Ato komente janë baza e përmirësimeve, të cilat kthehen prapë tek konsumatorët-prapë, sa më shpejtë të jetë e mundur-në mënyrë që ata të mund të ofrojnë komente të reja. Në atë pikë, cikli rifillon. Për ta përsëritur ciklin, në fund të fundit, domethënë ‘’të veprohet përsëritshëm.’’
Ky lak reagimi është në zemër të proceseve të shkathëta.Mendoni për fjalën ‘’shakthtësi’’ ashtu siq e përdorim në gjuhën e përditshme. Ajo përshkruan një mënyrë të lëvizjes shpejtë dhe shkathët-të qenit i përgjgijshëm ndaj ambientit dhe të angazhoheni me atë që është para jush.Një alpinist i shkathët, për shembull, përgjigjet për çdo dorë dhe këmbë që has.Ai bën ndryshime të shpejta për t’i shmangur rrëshqitjet dhe dorezat e ngatërruara. E njëjta gjë vlen edhe me dizajnimin e sfotverit. Ekipet e shkathëta i përdorin proceset përsëritëse për t’u përgjigjur shpejtë dhe shkathët ndaj gabimeve dhe përzierjeve që mund të hasin. Ata mund të mos ndërtojnë softuerin që synuan të ndërtonin, por kjo është shumë më mirë sesa të ndërtoni diçka të padobishme.
Pra egziston një parim i parë i shkathtësisë. Mund ta frazojmë atë kështu: Prioriteti më i lartë është ta kënaqni konsumatorin përmes ofrimit të hershëm dhe te vazhdueshëm të softuerit të vlefshëm.
Tani, le ta ndajmë parimin edhe më shumë.
Softveri mund të ndërtohet në botën reale-në botën e qenieve njerëzore të papërsosura.Edhe ekipet më punëtore nuk i arrijnë detajet e rëndësishme. Developerët më të talentuar nuk ja dalin t’i parashikojnë kërkesat jetike. Mënyra më e mirë për t’i korigjuar gabimet është ta vendosim softverin që jemi duke ndërtuar në duart e konsumatorëve-njerëzit që aktualisht do ta blejnë atë. Si developerë, në varemi plotësisht në vlerësimet e tyre. Ja pse duhet ta lansojmë softverin herët.
Lansimi i hershëm i softverit nuk është vetëm një kundërhelm ndaj përsosurisë-kjo ofron vlerë për konsumatorët. Nëse ata sot kanë një veqori të vetme, sadoqoftë penguese, ata mund të bëjnë diçka që s’kane mundur dje.Duke përdorur aktualisht një produkt, ata mund t’i qartësojnë nevojat e tyre.Kjo nënkupton se ata do të jenë në gjendje të na japin një ide më të qartë të asaj që duan të bëjë produkti i tyre. Dhe pasi të jemi të kyçur në këtë qark reagimi, ne jemi në rrugën e krijimit të një produkti përfundimtar që i plotëson ato nevoja.
Ideja kyçe 3
Pranimi i ndryshimit ka të bëjë krejtësisht me përvetësimin e një mendësie të duhur.
Pra egziston një përgigje për pyetjen që kemi bërë më herët-ajo që duhej të kishim bërë është ta vendosim softverin tonë në duart e konsumatorëve, në mënyrë që ata ta përdorin atë dhe të na japin koment. Sikur ta kishim bërë këtë, do ta kishim kuptuar se egizstonte një problem dhe do kishim ndërruar rrugë. Kjo do të na kishte kursyer shumë kohën që kemi shpenzuar në ndërtimin e një gjëje të pavlerë të shtrenjtë.
Natyrisht, ndryshimi i drejtimit në mes të një projekti është më lehtë të thuhet sesa të bëhet.Në praktikë, zakonisht është një përvojë e dhimbshme dhe e pakëndshme. I keni marrë vendimet e vështira. Edini çfarë po ndërtoni. E dini se çfarë presin konsumatorët tuaj.Rrjedha e punës tuaj ka rënë në vijë.Nuk është lundrim i qetë, por jeni duke përparuar.Dhe pastaj vjen dikush jashtë projektit dhe thotë se keni qenë në shtegun e gabuar gjithë kohën. Gjithë ai planifikim dhe punë ishte për asgjë.Se duhet të bëni një rreth prapa dhe të filloni përsëri. Për më keq, personi që ju thotë ta ndryshoni drejtimin është i njëjti person që ju ka vënë në atë drejtim në radhë të parë! Ata ju thanë të ndërtoni një gjë, dhe tani që jeni në gjysmë të saj, ata po ju thonë të bëni diçka tjetër.Është demoralizuese-jorespektuese madje. Nuk është qudi që bëhi mbrojtës dhe ju rezistoni ndryshimeve.
E kuptueshme? Sigurisht. E dobishme?Aspak. Pyetja e rëndësishme sidoqoftë është se si mund ta kaloni këtë ndjenjë?
Epo është qështje mendësie, dhe i ka dy pjesë. E para është ta pranoni se është shumë e vështirë të ndërtoni një softver të çmueshëm nëse nuk jeni vazhdimisht duke kontrolluar dhe rishikuar-prioritetet tuaja. Por ndryshimi i drejtimit në mes të rrugës në një projekt është frustrues, por nuk është asgjë aq shfryrëse sa të arrini fundin e një projekti dhe ta kuptoni se keni ndërtuar një copë mbeturine.
Pjesa e dytë ka të bëjë me perspektivën, dhe ka formën e një ushtrimi.
Ky nuk është gjithnjë një ushtrim i lehtë-ai kërkon një kokë të ftoftë dhe me shumë empati sesa mund të dëshironi t’ia ofroni personit që ju ka rrënuar ditën tuaj. Por mund të jetë ndriques. Filloni duke ia bërë vetes tuaj dy pyetje: E para, A ju ka dërguar konsumatori juaj me qëllim në drejtimin e gabuar? Me siguri jo, apo jo? Dhe e dyta, si u ndje ai kur e kuptoi se e kishte katranosur gjithçka dhe ju kishte marrë kohë pune muaj të tërë? Gjasat janë, se ai është shumë i turpëruar.Ai me siguri nuk ka ardhur tek ju për ta pranuar gabimin. Edhepse është gjë e mirë që nuk e kanë bërë-thjesht ju kanë kursyer më shumë kohë të humbur! Dhe nuk është vetëm afati juaj që ka humbur. Orari i klientit tuaj është shtyrë poashtu. Kompania e tyre është duke hargjuar para të mira për të ndërtuar një softver që i përmbush nevojat e tij, dhe ky gabim nënkupton se projekti nuk po jep rezultate. Me fjalë të tjera, kjo është frustruese për çdokënd.
Kur e shikoni mirë qështjen, të dy jeni në një situatë të vështirë. E vetmja mënyrë që teorikisht mund të shmangni prishjet do të ishte të lexoni mendjen e klientit tuaj. Klienti juaj, nga ana tjetër, duhet të jetë në gjendje të parashikojë të ardhmen. Në një botë ideale, të dy do të jeni në gjendje t’i bëni ato gjëra. Por softueri nuk është ndërtuar në një botë ideale; ju nuk do të punoni me shikues telepatikë. Pranojeni këtë dhe gabimet – së bashku me ndryshimet që sjellin – do të jenë shumë më të lehta për t’u përballuar.
Ideja kyçe 4
Proceset përsëritëse ju mbajnë në kontakt me konsumatorët tuaj.
Mire le të kthehemi aty ku filluam.Si munden parimet e shkathëta që i eksploruam të na ndihmojnë me projektin problematik të librit elektronik? Le ta zbulojmë duke ekzekutuar sërish projektin.
Së pari, le t’ia kujtojmë vetes arsyen pse lexuesi dështoi. Atij i mungonin disa veqori të rëndësishme të përdorura duke garuar me lexuesit e librave eletronike, sikurse mbështetja e një formati standard të një industrie. Vëreni sidoqoftë, se ky problem nuk do të mund të ishte parashikuar-apo shmangur. Kur ekipi ynë shkoi në punë, nuk kishte asnjë standard të industrisë. Theksi ynë, atëherë, duhet të jetë në reagimin e ekipit ndaj asaj që zbulon sapo të ketë filluar puna.
Këtë herë, projekti do të jete duke shkuar në mënyrë të shkathët.Do të fillojmë me një takim të madh ku do të përmbledhim kërkesat dhe specifikimet, por nuk do t’i përmbahemi atij plani për 18 muaj rresht. Në vend të kësaj, ne do ta ndajmë atë vit e gjysmë në sprinte njëmujore – një cikël i vetëm i ciklit të reagimit që diskutuam më parë. E thënë ndryshe, ne do të përditësojmë dizajnin tonë në përgjigje të komenteve çdo muaj.
Në fillim nuk do të ketë shumë gjëra për të testuar, natyrisht, prandaj do të shkojmë menjëherë tek sprinti i katërt. Kur projekti i menagjerit, ekipi, dhe aksionarët të takohen, një nga developerët raporton se ka një standard të industrisë së re për formatet e librave elektronikë. Ekipi e përfshin këtë informatë të re në sprintin e radhës dhe ndërton një librari që e mbështet formatin e ri. Deri kah sprinti i gjashtë, jemi gati ta përfshijmë atë format në ndërfaqen e përdoruesit të lexuesit.
Siq mund ta shihni, çdo sprint përafërsisht hartohet në çdo përsëritje ose version të softuerit që ekipi po ndërton. Pra le ta mbajmë muajin e njëmbëdhjetë-sprintin dhe përsëritjen e e njëmbëdhjetë.Tani e kemi një ndërtim funksional i cili mund të mbushet në prototipet të cilat mund t’i sjellë ekipi i hardverit. Kur menagjeri i projektit të flet me përdoruesit e hershëm të softverit, ai mëson se ata do të donin të ishin në gjendje të dërgojnë email artikujt e gazetave dhe PDF-at në paisjet e tyre. Ky është fokusi për sprintin e radhës së ekipit.
Kjo qasje nuk ka të bëjë vetëm me testimin dhe përfshirjen e veqorive të reja, sidoqoftë-disa veqori mund të hidhen poshtë. Për shembull, ndoshta ajo vitrinë e internetit nuk ka kuptim.Egziston një format i standardizuar i librit elektronik, në fund të fundit, prandaj nuk kemi pse ta krijojmë një platformë unike tonën. Kjo është e dobishme sepse e liron kohën për të punuar në veqori të tjera, më të rëndësishme.
Ky version projekti ka më shumë gjasa të përfundojë mirë. Ne vazhdimisht kemi lansuar softvere për testim në botë reale dhe kemi bërë ndryshime kohore si përgjigje ndaj atyre testeve. Dallimi i madh këtu është se jemi në kontakt me konsumatorët dhe përdoruesit. Kur e përdorëm procesin ujëvarë ne u izoluam plotësisht nga këto grupe pasi të ishin miratuar kërkesat e projektit. Këtë herë, megjithatë, ne nuk e kemi harruar qëllimin tonë përfundimtar: ndërtimin e një softueri të vlefshëm dhe funksional që plotëson nevojat reale. Dhe kjo është arsyeja e shkathtësisë.
Përmbledhja Finale
Sapo keni përfunduar pulsimet e ‘’Të mësuarit e shkathtësisë’’, nga Andrew Stellman dhe Jennifer Greene.
Mesazhi kryesor këtu është se:
Ka shumë mënyra për të punuar me shkathtësi, por çdo qasje mbështetet në të njëjtat parime thelbësore. E para është reagimi. Proceset e shkathtësisë kanë të bëjnë me reagime. Ju nuk prisni deri në fund të një projekti për të testuar softuerin që keni ndërtuar – ju e merrni atë sa më shpejt të jetë e mundur. Testimi real i identifikon problemet herët dhe ndihmon klientin tuaj të qartësojë se çfarë duhet të bëjë ai softuer. Parimi i dytë? Nuk ka gjë të tillë si plani perfekt. Çdo projekt do të kërkojë rregullime ad-hoc, ndryshime dhe ridizajnime. Por kjo është një gjë e mirë – kështu ndërtohet softueri më i mirë.