Çfarë duhet të dinë zhvilluesit e programeve kompjuterikë rreth vitit 2021

Testimi i kodit të ulët, kodi AI, efekti i qëndrueshëm i COVID-19 dhe aftësitë e nevojshme për të qëndruar në krye

Forrester bëri 5 parashikime për zhvillimin e software-it në 2021. Bill Detwiler bisedon me veteranin e industrisë së software-it VP dhe analistin kryesor Jeffrey Hammond, autori kryesor i raportit, për atë që zhvilluesit dhe drejtuesit e IT duhet të presin në 2021.

Zhvillimi i software-it është në një gjendje ndryshimi. Platformat me kod të ulët dhe pa kod po zhvendosin disa nga proceset e dev-it tek jo-programuesit. AI po ndryshon mënyrën e testimit të software-it që shkruajmë. Dhe pandemia COVID-19 ka detyruar ekipet dev të rimendojnë sesi funksionojnë, kur të gjithë janë në distancë.

Forrester sapo lëshoi ​​pesë parashikime të vitit 2021 për zhvillimin e software-it dhe ne patëm një shans për të biseduar me Jeffrey Hammond, nënkryetar dhe analist kryesor që shërben për drejtuesit e zhvillimit të aplikacioneve në Forrester dhe autori kryesor i këtij raporti, për podcastin e Zhvilluesit Dinamik të TechRepublic. Hammond është gjithashtu një ish zhvillues dhe menaxher i ekipit dev, me mbi 25 vjet përvojë në industrinë e software-it. Më poshtë është një transkript i intervistës i redaktuar për lexueshmëri.

Parashikimet e vitit 2021 për zhvilluesit e programeve kompjuterikë dhe zhvillimin e aplikacioneve

Jeffrey Hammond, Zëvendës President dhe Analist Kryesor që Shërben Drejtuesit e Zhvillimit të Software-it në Forrester

Bill Detwiler: Në rregull. Pra, Jeffrey, ti ishe Autori dhe Analisti kryesor në një grup parashikimesh që Forrester sapo dha, Parashikimet 2021 Rreth Zhvillimit të Software-it. Dhe e di që këtu do të flasim për kod të ulët dhe pa kod. Por, para se të arrijmë në këtë, më tregoni se si Forrester bashkon këto parashikime dhe si arrini në përfundimet që bëni në këtë raport?

Jeffrey Hammond: Po. Unë mendoj se autori kryesor do të thotë bari i maceve, sepse ajo që ndodh është ekipi ynë të bashkohet, kemi rreth tetë prej nesh, dhe ne zbresim në një gropë metaforike metaforike ku të gjithë kemi mendime. Dhe imagjinoni se, tetë analistë me mendime të forta. Almostshtë pothuajse si të thuash se është një mendim i arkitektëve. Për këtë po flasim.

Dhe kështu ne e luftojmë atë. Ne themi, “Unë jam duke parë këtë, dhe unë mendoj se do të jetë një punë me të vërtetë e madhe vitin e ardhshëm.” Dhe pastaj John Rymer, në pension së fundmi, thotë, “Unë e shoh këtë dhe mendoj se do të jetë i madh”.

Tani, sfida është që ne vetëm të zgjedhim pesë më të mirat. Pra, nëse keni shtatë ose tetë analistë, kjo është më pak se një për analist. Pra, ne i bashkojmë këto, ne i trokasim vërtet, dhe ne kemi dalë me gjërat që ne mendojmë se janë me të vërtetë të vendosura për të lëvizur gjilpërën në vitin e ardhshëm.

Ky ishte veçanërisht argëtues sepse në të vërtetë ka disa mendime mjaft të forta për disa nga këto parashikime. Dhe nuk jam i sigurt që të gjithë jemi 100% në të njëjtën faqe, por kjo është ajo që e bën ushtrimin një vërtet të vlefshëm nga këndvështrimi im.

1. AI dhe ML do ta bëjnë automatizimin e provës më të mençur

Bill Detwiler: Pra, si vendosni në të vërtetë me cilën parashikim të shkoni kur keni ato ide konkurruese? Apo ndoshta po, dua të them, nuk e nxirrni në një rrjet boksi. Apo funksionon si Gjykata e Lartë, ku keni votuar gjyqtarë të ndryshëm? Si mund të arrini në një konsensus ose të paktën të zgjidhni një fitues?

Jeffrey Hammond: Po. Ndoshta ekziston ekuivalenti virtual i shkrepjeve të shkrepura para dhe prapa. Por më lejoni t’ju jap një shembull. Pra, një nga parashikimet që kemi vendosur atje ishte, të paktën një e treta e profesionistëve të testit do të përdornin të mësuarit në makinë për ta bërë automatizimin e testit më të zgjuar vitin e ardhshëm. Ka një bisedë më të madhe në atë botë. Biseda është me të vërtetë rreth rolit që AI do të luajë në zhvillimin duke ecur përpara.

Tani, ka disa njerëz që në thelb do të thonë: “Ju e dini çfarë? Në pesë vjet ne do të kemi një kod për të shkruar UA, dhe kjo do t’i bëjë zhvilluesit shumë më pak të kërkuar, sepse shumë nga kodi bazë i infrastrukturës që ne shkruajmë sot është diçka që mund të automatizohet dhe të shkruhet nga një makinë “.

Ka të tjerë prej nesh që do të thonë: “Ju e dini çfarë? E gjithë ajo që do të bëjë është të përfundojë duke krijuar më shumë software që zhvilluesit duhet të mbajnë”. Dhe më pas, “Po, me të vërtetë nuk mund të shohim që kërkesa për zhvillues të mirë të shembet shpejt e shpejt”.

Kështu që ju vendosni ato dy ekstreme dhe keni një diskutim vërtet të fortë. Dhe çfarë bëni ju është se ju ktheheni në hulumtim, dhe shkoni tek të dhënat dhe thoni, “Çfarë po shohim? Çfarë po bëjnë klientët? Çfarë po na tregojnë shitësit që janë mbi horizont?”

Dhe ju shkoni nga kjo, “AI do t’i bëjë zhvilluesit të vjetëruar përkundrejt AI nuk do t’i bëjë kurrë zhvilluesit të vjetëruar shumë mirë, një nga fushat që AI me të vërtetë ka filluar të ketë një ndikim është testimi.”

Shumë zhvillues nuk e duan veçanërisht idenë për të dalë atje dhe për të shkruar raste testimi të automatizuar. Nuk është ajo për të cilën ata duan të kalojnë kohën e tyre. Ata duan të ndërtojnë funksionalitetin e biznesit, ata duan të zgjidhin problemet. Ata duan të nxisin vlerën e biznesit.

Por ju e dini se çfarë? Ato raste të provës duhet të shkruhen. Pra, është një shembull i shkëlqyeshëm i një zone ku zhvilluesit do të dëshironin që makineritë të bënin më shumë, ku makineritë janë në gjendje të bëjnë më shumë, ku ne shohim prova të mjeteve dhe teknikave që janë atje duke bërë më shumë.

Ju e bashkoni atë së bashku dhe thoni: “Epo, nëse ekstrapolojmë këtë trend, ne shohim që rritet vetëm ndërsa kalojmë në vitin e ardhshëm”. Nuk e di nëse kjo ndihmon apo jo, por …

2. 75% e org-ve do të përdorin platforma me kod të ulët

Bill Detwiler: Jo, ky është një shpjegim i shkëlqyeshëm sepse më çon në pyetjen time të radhës dhe atë për të cilën me të vërtetë dëshiroja të flisja, e cila është kodi i ulët, lëvizja pa kod, sepse kjo është një tjetër nga ato teknologji.

Jeffrey Hammond: Oh, shufra e rrufesë me kod të ulët.

64.5 orë Hadoop, MapReduce, Shkëndijë dhe më shumë për t’ju përgatitur për një nga karrierat e IT me rritjen më të shpejtë të sotme

Bill Detwiler: Ashtu është. It’sshtë një tjetër nga teknologjitë, siç flisnit me AI, që do të ketë një efekt dramatik ose mund të ketë një efekt dramatik, në varësi të kë kërkoni, në peizazhin e zhvillimit të aplikacionit që po ecën përpara.

Ju po flisnit se si AI mund të shihet si shtim i asaj që zhvilluesit tashmë po bëjnë dhe në të vërtetë marrin përsipër diçka që mbase nuk u pëlqen ta bëjnë. Pra, në atë mënyrë, është kompliment, nuk është kundërshtar për sa i përket një loje me shumën zero. Ose kemi AI që e bën këtë, ose kemi zhvillues që e bëjnë atë.

Dhe kështu që më çon te parashikimi i kodit të ulët dhe pa kod që ke këtu. A do të jenë zhvilluesit akoma sa është e nevojshme për të shkruar kodin, kur keni përdorues të biznesit ose profesionistë të tjerë të biznesit jo-programues që shkruajnë kod? Apo akoma do të keni të gjithë kodin për të ruajtur? Cili është parashikimi që të gjithë po bënit për vitin 2021 rreth kodit të ulët, pa kod?

Jeffrey Hammond: Pra, parashikimi specifik është deri në fund të vitit, 75% e dyqaneve të zhvillimit do të vendosin dhe do të përdorin zgjidhje me kod të ulët. Kështu që vini re se nuk është 75% e zhvilluesve. Pra, nëse dikush në organizatë po përdor kod të ulët, atëherë kjo llogaritet në atë 75%.

Në disa mënyra, unë ndjehem sikur për sa kohë që kam qenë një zhvillues, i cili është gati 30 vjet tani, kjo ide e polarizimit të detyruar është diçka me të cilën ne kemi pasur të bëjmë. Dhe në disa mënyra ndjehem sikur kodi i ulët ka qenë një nga ato fusha që ka qenë në atë mënyrë.

Unë hyra si një financë e madhe, e drejtë në kodin PowerBuilder në organizata shumë të mëdha. 4GL përsëri në fillim të viteve nëntëdhjetë në Windows. Sa të ndryshme janë ato 4GL nga disa prej mjeteve me kod të ulët sot, nga ana konceptuale?

Nëse do të duhej të binim për të parë, do të kishim ndërfaqe të funksioneve të huaja që mund t’i thërrisnim për të bërë gjëra të tilla si blloqe leximi. Nëse do të kishim nevojë për të hyrë në bazat e të dhënave, ne do të shkonim të flisnim me një DBA dhe të thonim, “Unë kam nevojë që ju të shkruani një procedurë të ruajtur që merr këto argumente dhe i kthen këto të dhëna”.

Dhe një ditë më vonë, ata do të ktheheshin dhe do ta bënin atë. Shpejt përpara 30 vjet, dhe Mendix ose OutSystems ose Power i sotëm po e bën atë, përveç që ndoshta po thërret një funksion pa server. Po thërret një Lambda, ose po hyn në një API që drejtohet nga një kontejner në majë të një grupi Kubernetes.

Për mua, vlera e vërtetë këtu është ideja se në cilin nivel abstraksioni dua të punoj. Dhe këtu hyjnë pa kod dhe kod të ulët, sepse nga perspektiva pa kod, ka përdorues që duhet të punojnë në një nivel të caktuar abstraksioni, sepse nuk kanë njohuri për të shkuar më thellë.

Dhe kjo do të ishte dikush që mund të përdorë një mjet pa kod të kërkuar. Të gjithë duhet të fillojnë diku, por edhe zhvilluesit profesionistë ndonjëherë do të zgjedhin të punojnë në një nivel më të lartë abstraksioni për shkak të qëllimeve të tyre.

Ndoshta dua të përdor Lambda, sepse nuk dua të merrem me autoskalimin e grupeve në Kubernetes. Unë thjesht dua që kjo të ndodhë në mënyrë që të përqendrohem në logjikën e biznesit. Mbase dua të përdor një Mendix ose OutSystems sepse e dini çfarë? Unë kam për të marrë një kërkim gjurmimi dhe gjurmimi në tre javë.

Ose biznesi ka nevojë për të zbatuar marrjen në bord, dhe çdo ditë që nuk e kemi, ne po humbasim miliona dollarë sepse institucionet tona të shitjes me pakicë janë të mbyllura. Kjo është ajo që pamë me kod të ulët në vitin 2020. Se ato janë përdorur në shumë prej këtyre situatave ku shpejtësia ishte gjëja më e rëndësishme, dhe për shkak të kësaj, zhvilluesit zgjodhën një nivel më të lartë të abstraksionit dhe ata morën aplikime.

Për mua, unë mendoj se ajo që duhet të bëjmë, është që ne duhet të shohim atë që po shohim këtu si më shumë një spektër nga nivele të larta të abstraksionit, në nivele të ulëta të abstraksionit dhe të kuptojmë që një biznes do të angazhohet në pika të shumta në atë spektër bazuar në atë që ata po përpiqen të përmbushin. Dhe mendoj se ka një vend për kod të ulët në çdo organizatë, nëse e shikoni në atë mënyrë.

Bill Detwiler: Nëse jeni dikush që flisni me zhvilluesit, kështu që zhvilluesit e linjës së parë, koduesit, të cilët shikojnë pa kod dhe kod të ulët dhe po mendojnë: “Si do të më ndikojë kjo dhe si duhet të përgatitem për të?” Cfare thua ti

Unë e marr atë që po thua nga një perspektivë e ndërmarrjes, dhe madje edhe nga kërkimi për të theksuar shpejtësinë, por nëse je dikush që është një zhvillues i ri vitin e parë, je akoma në një kolegj ose ndonjë lloj programi trajnimi që po mëson të kodosh , çfarë duhet të dinë ata për kodin e ulët dhe pa kodin, dhe si mendojmë se do të ndikojë në punët që ata janë duke bërë, duke kërkuar vitin e ardhshëm ose duke bërë vitin e ardhshëm dhe madje pesë vjet nga tani?

Jeffrey Hammond: Unë mendoj se një nga gjërat që do të bëjë është diçka që kemi pasur në një nga parashikimet tona të tjera, të cilat potencialisht do të ndryshojnë mënyrën se si ne organizojmë ekipet e zhvillimit të software-it.

Në një dyqan klasik të TI-së, të gjithë zhvilluesit janë në organizatën e IT-së dhe ata mblidhen në CIO, dhe ndoshta marrin kërkesa nga biznesi, ose flasin me një sponsor biznesi çdo dy javë ose diçka e tillë, por ekziston një organizatë shumë e lundruar.

Ndërsa kemi parë gjithnjë e më shumë organizata që përqafojnë Agile në shkallë, ata kanë filluar të vendosin pronarë të produkteve në ato skuadra, dhe ata pronarë të produkteve mund të vijnë nga biznesi, por prapëseprapë ata janë mjaft të vetë-organizuar teknikisht.

Ndërsa filloni të shihni më shumë zhvillues të biznesit që përfshihen në zhvillim përmes kodit të ulët, unë mendoj se keni potencialin të shihni edhe më shumë ekipe hibride ku zhvilluesit nguliten brenda organizatës së biznesit, ose përmes menaxhimit të matricës ose edhe të rreshtuar ose të caktuar ato organizata.

Prandaj imagjinoni një botë ku në vend të një përdoruesi të biznesit mund t’ju jetë duke ju dhënë një skicë, ose duke ju dhënë një dokument të kërkesave, dhe si një zhvillues, ju duhet ta interpretoni atë. Imagjinoni që një zhvillues mund të jetë duke bërë disa nga kornizat tel ose një përdorues biznesi dhe duke bërë disa nga ndërfaqet e ndërfaqes.

Sepse ajo që unë tentoj të gjej është se biznesi me të vërtetë kujdeset për pikselët, dhe ata kujdesen për mënyrën se si funksionojnë ato pixel dhe ata interesohen për mënyrën se si ato pixel rrjedhin. Ata nuk kujdesen për mënyrën e strukturimit të API-ve. Ata nuk u intereson mënyra se si grupimet Kubernetes janë ngritur në këmbë. Ata nuk kujdesen për mënyrën se si funksionet autoskale lart e poshtë, ata thjesht kujdesen që kjo të funksionojë.

Dhe kështu mendoj se si një zhvillues profesionist, një nga gjërat që do të thotë është që, ne ndoshta fillojmë të përqendrohemi në cilësitë teknike të sistemit pak më shumë, dhe ne marrim pak më shumë ndihmë nga biznesi në aspektin e funksionalitetin dhe vlerën që duhet të japim, dhe mbase edhe disa nga llogaritjet ose tel-kornizat që na është dashur të interpretojmë në të kaluarën.

Ju madje mund ta shihni se nga një botë më pak e koduar, pasi ne fillojmë të shohim gjithnjë e më shumë organizata që flasin për sistemet e dizajnit, ku ata artikulojnë se si duhet të duket dhe veprojë sistemi, dhe ka pak më pak ngarkesë pune nga një perspektivë zhvillimi nga një front-fund.

Kështu do të thuhet plotësisht: “Epo, zhvilluesit e përparmë nuk janë të nevojshëm”, absolutisht jo. Hero, aplikacione celulare, aplikacione me të cilat përballen klientët, ju akoma do të djersitni detajet dhe do të shikoni për mundësitë atje. Por mbase për disa nga punonjësit që përballen me aplikime, ne mund të bëjmë më shumë punën e përparme me këto skuadra hibride të kombinuara. A ka kuptim kjo?

3. Ekipet ndër-funksionale do të bëhen normë dhe kërkojnë metoda dhe mjete të reja menaxhimi

Bill Detwiler: Po, po. Dhe është diçka që rrjedh në një nga parashikimet e tjera nga raporti, i cili po flet për ekipe ndër-funksionale dhe duke folur për menaxhim bashkëpunues të punës. Ju lutemi flisni për atë parashikim në më shumë detaje.

Kam parë dhe kam biseduar me njerëz që janë në organizata të zhvillimit të aplikacioneve, që përshkruajnë të njëjtën gjë. Dhe unë kam parë që personalisht në një lavjerrës lëviz dhe mbrapa në 20 vitet e mia në teknologji.

Pra, flisni pak për këtë, dhe duket se është saktësisht, siç thoni ju, duke u kthyer prapa drejt “, Hej, ne do të vendosim zhvillues. Ne do t’i vendosim ata më pranë përdoruesve të fundit, në krahasim me te një pjesë e këtyre organizatave monolite të IT-së.

Por kjo ndonjëherë nuk është një tranzicion i lehtë për të bërë për disa njerëz, apo jo? Kërkon aftësi pak më të ndryshme. Dua të them, më kujtohet se po kaloja shkollën dhe shkollën inxhinierike, dhe kishte të bënte më shumë me: “Mirë, ju jeni një inxhinier, ju do të punoni dhe …”

Unë isha një matematikë inxhinierike dhe shkenca kompjuterike mënyra kryesore në atë kohë. Dhe ishte, “Ju do të punoni vetë. Ju nuk do të keni një ekip vërtet të madh. Ndoshta do të merrni kontribute nga disa grupe të tjera, por do të jeni ju, dhe do të shkojë .. “Dhe kjo –

Jeffrey Hammond: Vendosi në një zyrë dhe jepi Jolt Cola dhe fus pica nën derë. Kjo është gjithçka që ju nevojitet, apo jo?

Bill Detwiler: Kjo ishte gjithçka. Por kjo është plotësisht dhe krejtësisht … ishte ndryshe. Dhe kjo nuk ishte mënyra se si ishte vetëm pesë vjet më vonë. Dhe ishte kjo para dhe prapa, kjo shtytje dhe tërheqje nga profesorët, të cilët dolën në … Unë jam duke u takuar me veten time, … vitet ’60, ’70 dhe ’80, dhe ende i kisha ato mentalitete, dhe disa nga njerëzit më të rinj të cilët kishin ardhur së bashku ndoshta në vitet ’80, dhe tani ne jemi duke lëvizur në vitet ’90.

Pra, flisni për numrin një, parashikimin rreth ekipeve ndër-funksionale, dhe atë për të cilin duhet të mendojnë zhvilluesit në të vërtetë se si ata e bëjnë tranzicionin, dhe si zhvillojnë drejtuesit e zhvillimit të aplikacioneve, dhe si sigurohen që stafi i tyre ta bëjë suksesin e tranzicionit?

Jeffrey Hammond: E drejtë. Unë mendoj se është me të vërtetë e rëndësishme sepse ka më shumë kërkesa nga një perspektivë kulturore që vendosen për zhvilluesit. Dhe për vite, ne në thelb kemi thënë: “Hej, shiko, mjetet janë të shkëlqyera, por nëse nuk ke kulturën e duhur të zhvillimit, nuk do të jesh i suksesshëm në lidhje me Agile dhe në lidhje me rritjen e shpejtësisë, dhe kjo për zhvilluesit gjithashtu. “

Rreth 10 vjet më parë, unë shkrova një artikull mbi praktikat më të mira të ekipeve të zhvillimit me performancë të lartë, dhe kaq shumë prej tyre janë ende në pikën e sotme. Në parim filloi punën që Dan Pink kishte bërë në mes të viteve 2000 rreth motivimit të brendshëm dhe në thelb bëri që zhvillimi të jetë një profesion krijues, dhe është një profesion heuristik.

Dhe kështu ju doni zhvillues që janë të aftë të shprehin mendim krijues, të marrin autonomi për veprimet e tyre, të punojnë në një kulturë zotërimi dhe të blejnë në qëllime të përbashkëta. Dhe nëse i keni ato gjëra, atëherë ata duan të ndiejnë ndjeshmëri për përdoruesin përfundimtar. Ata duan të mësojnë për atë që përdoruesi dëshiron. Ata duan të mësojnë rreth teknologjive të reja që do të kënaqin dhe t’i japin vlerën atij përdoruesi.

Dhe funksionon deri në kulturë. Do të të jap një shembull. Unë kam pasur një bisedë me Amazon gjatë viteve, dhe një nga gjërat interesante rreth Amazon është vetëm rreth 10% e ekipeve të tyre të shërbimit në të vërtetë kanë një menaxher produkti.

Dhe këto janë shërbimet që janë të ekspozuara nga jashtë për klientët. 90% tjetër, menaxheri i inxhinierisë është linja kryesore e organizatës së ekipit. Kështu që menaxherët e inxhinierisë ndoshta vijnë nga një sfond shumë teknik, por megjithatë ai ekip ende matet për sasinë e ripërdorimit për shërbimin që ata krijojnë në pjesën tjetër të Amazon.

Pra, nëse mateni për ripërdorimin, si siguroheni që ripërdorimi juaj është i mirë? Ju dilni atje dhe i kuptoni nevojat e të tjerëve. Ju kuptoni se çfarë duhet të bëjë ekipi juaj për t’u siguruar që skuadrat e tjera mund të marrin vlerë nga përpjekja që po bëni. Ju në thelb po veproni si menaxher i produkteve defacto.

Dhe kështu këto gjëra, ndjeshmëria dhe autonomia janë shumë të rëndësishme për suksesin. Pra, nëse doni që një zhvillues të keni një rrugë karriere që shkon në atë lloj menaxheri inxhinierik të rolit, ose fillon të ngjitet në zinxhirin e karrierës në një moment, nuk ka rëndësi vetëm teknologjia, por janë edhe ato aftësi të tjera më të buta.

Kështu që ju mund të më vendosni në atë anë të argumentit për të cilin keni biseduar. Dhe kështu ndërsa këto ekipe fillojnë të marrin më shumë funksione, aftësia për të punuar me një menaxher produkti që mund të mos ketë një formim teknik, ose mund të mos ketë një diplomë teknike dhe të jetë në gjendje të përkthejë atë që po përpiqet të arrijë.

Aftësia për të punuar me një përdorues biznesi i cili mund të tërheqë atë që dëshiron, ose të skicojë një dizajn ekrani, por të mos kuptojë që një pjesë e informacionit që ata po kërkojnë është në të vërtetë mjaft e vështirë për t’u mbledhur nga të gjitha ato sisteme ekzistuese që ju kanë, që mund të mos jenë të aftë as të sigurojnë të dhëna në kohë reale dhe ta bëjnë atë bisedë në një mënyrë ku ata nuk ndihen të nënvlerësuar, ose nuk ndihen të margjinalizuar, unë mendoj se është shumë e rëndësishme.

Dhe ajo që e bën atë edhe më të rëndësishëm, arrin në një nga parashikimet e tjera që kishim, e cila është, ne nuk do të kthehemi në zyrë së shpejti. Ideja e bashkërendimit fizik si një mënyrë për të qetësuar këto sfida dhe si një mënyrë për të qenë në gjendje të shohim atë që njerëzit e tjerë po mendojnë, si një mënyrë për të bërë biseda me gjerësi bande të lartë, ne nuk do ta kemi atë si një luks.

Dhe kështu ndërsa për vite me radhë ne kemi thënë, “Kultura është kritike, organizimi është kritik. Mjetet, ato mund të ndihmojnë, por nuk janë aq të rëndësishme sa t’i përmirësojmë këto gjëra të tjera.” Pothuajse duhet të bëjmë një kthesë prej 180 gradësh.

Dhe kështu kur flasim për gjëra të tilla si mjete bashkëpunuese të menaxhimit të punës ose mjete të menaxhimit të një rryme vlere, arsyeja që ato bëhen më të rëndësishme tani se kurrë, është sepse shumë nga ajo që duhet të bëjmë tani duhet të bëhet përmes mekanizmave dixhital.

Unë do t’ju jap një shembull, Microsoft. Amanda silver, kishte një prezantim se si Microsoft i është përshtatur një kulture plotësisht të largët tani. Dhe një nga gjërat që ajo tha është, “Ne duhet të jemi në gjendje të transportojmë nga kudo tjetër”. Kjo nuk ishte diçka që ata kishin bërë më parë.

Dhe kështu, menaxhimi i vlerës së rrjedhës është një nga ato gjëra që nëse zbatohet si duhet, dhe mjetet e mbështesin atë, zhvilluesit mund ta dërgojnë nga kudo. Ata mund të shtyjnë nga kudo, mund të ndërtojnë nga kudo, dhe kështu që u mundëson këtyre ekipeve të jenë edhe më autonome sesa mbase kanë më parë.

Menaxhimi i punës bashkëpunuese është e njëjta mënyrë. Mundëson komunikim me gjerësi bande të lartë, kështu që nuk e keni këtë model të portofolit të projektit nga lart-poshtë, ku të gjithë presin që menaxheri i projektit ose menaxheri i programit të marrë një vendim, dhe pastaj ata të ecin përpara.

Kjo i lejon skuadrat të kenë biseda me bandë të lartë, edhe nëse nuk janë më në të njëjtën pod. Kështu që kërkon komoditetin e kolokacionit fizik dhe e zëvendëson atë me atë që unë do ta quaja kolokacion shpirtëror. Skuadrat, edhe pse nuk janë pranë njëra-tjetrës, përsëri mund të angazhohen në një bashkëpunim me bandë të lartë, e cila është kritike për suksesin e Agile.

Bill Detwiler: Si e bën këtë dhe nuk mbingarkon njerëzit? Meqenëse mendoj se me takime të pafundme ose 50 thirrje Zoom në ditë, ose Ekipet, Hangouts ose WebEx, ose cilado qoftë platforma juaj e zgjedhjes, si e bëni këtë pa mbingarkuar njerëz me shumë komunikim? Cili është ekuilibri i duhur?

Jeffrey Hammond: Unë u vë shumë atyre menaxherëve për të vendosur tonin e duhur. Stack Overflow, kohët e fundit kishte një pjesë që ata e shkruajtën në Journal of the ACM, ku ata shkruan për disa nga praktikat që ata kanë zbuluar.

Një nga ata që me të vërtetë ngeci, po linte një konferencë të hapur video gjatë gjithë ditës, edhe kur njerëzit po punonin. Shumicën e kohës ato janë të heshtura, por nëse dikush ka një ndërprerje përparësie ose ata kanë një pyetje apo diçka të tillë, të gjithë janë atje, kështu që ata thjesht mund ta pyesin atë.

Dhe atëherë nëse dikush ka përgjigjen, ata mund të përgjigjen shumë shpejt. Nuk është aq ndryshe sesa të hapësh kokën lart mbi pod, dhe të thuash: “Hej, dikush di se çfarë të bëjë për këtë?”

Kështu që nuk është se ato janë në të vërtetë … collaborationshtë bashkëpunim pasiv. Gjëra të vogla si: “Sigurohuni që statusi juaj të jetë vërtet i saktë nëse jeni shqetësues apo jo dhe më pas respektoni atë status”. Pra, gjëra të vogla.

Nga perspektiva e menaxhimit, mendoj se po pranon që ndërsa kalojmë nga një sprint në një maratonë, kjo shpërthim fillestar i produktivitetit që morëm, sepse njerëzit nuk po bënin më dy orë udhëtime dhe ata po bënin në mbrëmje ose në fundjavat, kur ata nuk ishin në gjendje të dilnin dhe të kalonin kohë shoqërore, ose të shihnin miqtë e tyre nuk është e qëndrueshme.

Dhe që ne do të shohim ndikime, dhe se duhet ta presim atë, dhe nëse nuk po i shohim ato ndikime, nëse akoma po shohim njerëz që punojnë në një nivel më të lartë të produktivitetit sesa normalisht, mbase është koha të ndërhyjmë dhe thuaj, “Hej, po kryen në fundjavë. Me të vërtetë nuk duhet ta bësh atë.”

“Le t’i bëjmë fundjavat fundjavë dhe le të sigurohemi që kemi të bëjmë me këtë nga një perspektivë e ngarkesave të gjata.” Unë mendoj se monitorimi i simptomave të djegies është vërtet kritik tani për menaxherët në ekipet e zhvillimit.

Bill Detwiler: Dhe kjo është diçka që unë e di, ose të paktën nga përvoja ime mund të jetë e vështirë për ekipet që ndoshta janë shumë … Dhe ky është një mbivendosje e plotë. Kështu që nuk po them se të gjithë janë kështu. Theshtë kuptimi midis njerëzve që unë njoh, veçanërisht nëse keni ekipe që kanë anëtarë, të cilët nuk janë shumë komunikues në lidhje me marrjen e atyre reagimeve.

Pra, si menaxher, është e vështirë të shohësh ato shenja derisa të ndodhë diçka vërtet e keqe, derisa të kesh një incident. Dhe unë nuk jam duke thënë se nuk është përgjegjësia e menaxherit, nuk e merr përgjegjësinë prej tyre për të kërkuar ato shenja, por mund të jetë më e vështirë të dallosh nëse ke njerëz që janë numri një, nuk janë duke komunikuar ose mësuar me duke komunikuar, dhe pastaj ju keni barrierën e shtuar të asnjë afërsie fizike, ku nuk shihni gjuhën e trupit.

Dhe unë kam atë që po thua në lidhje me takimin, dhe ti ke sfidën shtesë për të lënë një telefonatë të zmadhuar ose një thirrje video gjatë gjithë ditës. Ne nuk jemi në zyrë. Ne jemi në shtëpitë private të njerëzve dhe kemi parë histori tmerri në lajmet e njerëzve që gërryen aksidentalisht, ose duke ndodhur gjëra në thirrjet e tyre të hapura video që mbase nuk donin të ndodhnin, kështu që është një kohë e ndërlikuar për menaxherët .

Nëse jeni një menaxher zhvillimi ose nëse jeni një kontribues individual, një anëtar i ekipit, çfarë rekomandoni që ata të bëjnë në drejtim të sigurimit që lloji i mbase i komunikimit po ndodh rregullisht?

Jeffrey Hammond: Mm-hmm (pohues). Epo, unë mendoj se një nga gjërat është që të buxhetosh më shumë kohë për ndërveprim shoqëror. Do të të jap një shembull. Takimi i ekipit tonë ka tendencë të jetë një herë në dy javë, në mënyrë klasike. Shefi im e zhvendosi atë në javë, por nuk është se po bëjmë gjëra dyfish më shumë.

Po shtojmë më shumë kohë për vetëm pak socializim. Si po ia kalojnë të gjithë? Çfarë po bën? Si po shkojnë gjërat? Unë njoh shumë ndërmarrje të reja, historikisht kur të gjithë bashkoheshin, ata hanin mëngjes dhe darkë dhe hanin së bashku dhe gjëra të tilla.

Kështu që ne ende mund të pimë birrë së bashku të Premten, nëse ky është lloji i kulturës. Ne ende mund të flasim për projektet tona me kohë 10%, nëse keni zbatuar 10% kohë. Qëllimi është të bësh përpjekje për të nxitur akoma nivelin e ndërveprimit shoqëror që do të kesh në zyrë. Nëse nuk arrini dot në të gjithë rrugën, thjesht sigurohuni që jeni duke bërë sa më shumë si menaxher.

Një nga gjërat që po shohim është se gjithnjë e më shumë organizata po rregullojnë masat e tyre. Pra ka masa si angazhimi. Imagjinoni t’i shërbeni zhvilluesve tuaj rregullisht dhe në thelb duke thënë: “Si po ia dilni? Sa jeni të kënaqur?”

Dhe duke parë rezultatet neto të nxitësit për organizatën e zhvillimit. Fakti që menaxherët madje kujdesen për këtë është një shenjë e shkëlqyer, sepse është një tregues që ata e shikojnë talentin si një çështje strategjike që ata duhet të shikojnë. Nuk është Fred Brooks, Njeriu-Muaji Miti, nxirr një zhvillues, hidhe një tjetër dhe futi në mulli të mishit, kështu që është mirë.

Unë mendoj se ka gjëra që mund të bësh duke parë Metrikat e Rrjedhës dhe madje edhe angazhimet e kohës së ditës, nëse përdor diçka si GitHub ose përdor diçka si GitLab dhe merr një kuptim nëse dita po zgjatet përtej intervalit e kur duhet. Dhe kështu ato do të ishin llojet e gjërave që unë do të thoja se janë investime që ia vlen të merren parasysh ndërsa hyni në vitin 2021 nga një perspektivë e menaxhimit.

4. Modernizimi i IT-së i bërë nën COVID-19 duhet të vazhdojë

Bill Detwiler: Kështu që mendoj se për shkak se e prekët atë më herët, për fat të keq, COVID nuk do të zhduket në SH.B.A. në çdo kohë së shpejti. Dhe që ne ndoshta do të jemi në një farë kushtesh të ndryshuar pune, nëse jo deri në vitin 2021.

Dhe disa nga ndryshimet që organizatat kanë vendosur në vend tani do të qëndrojnë rreth edhe më shumë se kaq. Jo për shkak të pandemisë, por sepse ata e kanë kuptuar se ato kanë kuptim për shumë arsye.

Le të flasim për ato dy parashikimet e fundit që keni, që mësuan posaçërisht për të folur me këtë. Njëra ka të bëjë me modernizimin dhe tjetra ka të bëjë me arritjen e kësaj qartësie rreth teknologjisë së rrjetës. Filloni me modernizimin. Çfarë po parashikoni gjithashtu në vitin 2021 rreth kësaj?

Jeffrey Hammond: E drejtë. Pra, një nga gjërat që ndodhi në fillim të COVID është në industritë ku të ardhurat sapo ranë nga një shkëmb. Udhëtimi dhe transporti, si një shembull, me pakicë. Ne Pamë buxhetet e ndikuara. Dua të them, ju do të prisnit që të ndodhte kështu, dhe si rezultat, shumë njerëz vendosin në pritje disa nga përpjekjet e tyre për modernizim.

“Nuk ka rëndësi nëse duhet të transformojmë këto gjëra, nëse nuk do të jemi këtu për dy ose tre vjet”. Nga ana tjetër, ne pamë disa organizata që thoshin në thelb, “Shikoni, mallkoni silurët, me shpejtësi të plotë përpara. Nëse ka ndonjë gjë, ne duhet të lëvizim më shpejt për të mbijetuar. Ne duhet të dyfishojmë iniciativat tona të tregtisë elektronike. Duhet të dyfishojmë poshtë për gjëra të tilla si marrja në dyqan ose dorëzimi lokal. “

Dhe kështu që krijoi një ndarje të vogël të pasurive dhe të pasurive. Tani, ndërsa kalojmë në fazën maratonë të kësaj, kompanitë që në thelb vendosin frenat përballen me një krizë ekzistenciale. Ata ose duhet të rinisin këto programe, ose në thelb thonë se hendeku midis njerëzve që kanë shtyrë pedalin, dhe ata do të bëhen më të mëdha.

5. Përdorni mikrosherbimet dhe teknologjitë e rrjetave të shërbimit zgjerohen

Jeffrey Hammond: Pra, si rezultat, ne presim të shohim që buxhetet të kthehen, dhe kjo do të ndodhë veçanërisht pasi bëhet gjithnjë e më e qartë se si ata mund të modernizohen. Ndërsa shohim që njerëzit fillojnë të demonstrojnë më shumë sukses me vendosjen e kontejnerëve në shkallë, ndërsa shohim që organizatat gjejnë mënyra për të qenë në gjendje të shkallëzojnë arkitektura të bazuara në shërbime, duke përdorur gjëra të tilla si një rrjet shërbimi, apo edhe disa konstrukte të drejtuara nga ngjarjet.

Modelet bëhen më të qarta, që do të thotë se prapambetësit mund të fillojnë të lëvizin pas lëvizësve të parë, duke zbatuar modelet që ata lëvizës të parë kanë diskutuar.

Rrjet kaq neto, mendoj se do të shohim shumë përqendrim në … Fjalë e mbushur këtu, … arkitektura të lindura në re, qoftë reja e saj hibride apo nëse është re publike. Mendoj se në të vërtetë do të shohim mjaft eksperimente me arkitekturat hibride të reve, veçanërisht pasi organizatat fillojnë të zhbllokojnë disa nga këto ngarkesa kryesore të punës që ata po përpiqen të modernizojnë.

Kjo do të thotë zgjidhje si OpenShift, si Tonzu, madje edhe Anthos, janë diçka që shumë prej këtyre organizatave po kërkojnë ta shtyjnë fort për të parë saktësisht se sa mund të marrin prej tyre, pasi fillojnë të modernizohen në vend.

Hyrja e gjërave në kontejnerë është hapi i parë. Ju shpallët fitoren, dhe pastaj filloni me Modelet tuaja të Strangler ose fasadave tuaja, dhe filloni të prishni ato monolitë. Ndoshta jo deri në mikrosherbime, mbase te mini listat si pikënisje.

Por shumë nga ato bllokime dhe trajtime do të duhet të jenë pjesë e përpjekjeve të zbatimit për vitin 2021. Dhe këtu mendojmë se rrjetat e shërbimeve do të tregojnë disa nga aftësitë e tyre për të ofruar ndihmë në ekzekutimin e mbytjes monolite.

Zhvilluesit e software-it të Shkathtësive do të kenë nevojë në 2021 dhe më tej

Bill Detwiler: Pra, çfarë duhet të kërkojnë zhvilluesit për vitin 2021? Jemi në nëntor 2020, na kanë mbetur edhe dy muaj nga viti. Çfarë duhet të presin me të vërtetë zhvilluesit në 2021? Dua të them, kemi biseduar aq shumë, por nëse do të duhej të përmendni vetëm disa gjëra. Ju jeni ulur atje dhe po pyesni si: “Hej, unë po shikoj mundësi të ndryshme ose për karrierën time ose ku po shkon industria.”

Ne flasim për gjuhë për të mësuar, por nëse po mendoni një pamje pak më të madhe, cilat janë ato trende të mëdha që do të ishit … Një ose disa dy gjëra për të cilat mendoni se zhvilluesit duhet të shikojnë me të vërtetë, të lexojnë dhe të përgatiten për vitin tjeter?

Jeffrey Hammond: Nëse nuk e kuptoni fort rolin që luajnë kontejnerët si pjesë e zhvillimit dhe shpërndarjes së software-it , mendoj se duhet të arrini atje sa më shpejtë që të mundeni. Kjo nuk do të thotë domosdoshmërisht se ju duhet të shkoni plotësisht në Kubernetes dhe të filloni të mësoni të gjitha ndërlikimet e YAML, dhe të bëheni një ekspert i rrjeteve.

Ju mund, dua të them, ka shumë kërkesa për këtë, por së paku, duhet të kuptoni se si kontejnerët bëhen shpërndarja e paracaktuar. Pavarësisht nëse është një botë e Kubernetes apo një botë e ECS-së, apo edhe orare të tjera.

Gjithashtu, mendoj se ia vlen të kuptohet se si po zhvillohet pjesa e përparme. Ke shumë gjëra interesante që ndodhin tani, qoftë React Native, dhe React in View apo korniza Flutter, dhe rolin që ata luajnë si në zhvillimin e celularëve ashtu edhe në web.

Ju keni ndryshime ngazëllyese në mënyrën se si ne mendojmë të shkruajmë ballë me gjëra të tilla si JAMStack. Kështu që ka shumë mundësi për të mprehur aftësitë tuaja dhe për të parë se çfarë po bëjnë organizatat në atë zonë. Unë mendoj se do të ketë një shpërthim të vërtetë në idenë e marrjes së llogaritjes dhe ruajtjes deri në skaj në disa prej këtyre arkitekturave vendase të reve, ndërsa kalojmë në vitin 2021.

Do ta hedhim një vështrim në një valë të ardhshme, kështu që kjo është mjaft emocionuese për mua. Kështu që mendoj se ka shumë mundësi kur po shikoni se cilat aftësi duhet të mësoj në vitin 2021 e më tej, për të krijuar diferencim në aftësitë tuaja dhe për këtë arsye kërkesa për talentet tuaja.