Tim Lister - co-auteur fan boeken
- "Minsklike faktor. Súksesfolle projekten en teams" (it orizjinele boek hjit "Peopleware")
- "Walzing with the Bears: Managing Risk in Software Projects"
- "Adrenaline-gekke en zombifisearre troch patroanen. Gedrachspatronen fan projektteams"
Al dizze boeken binne klassikers op har mêd en binne skreaun tegearre mei kollega's yn . Yn Ruslân binne syn kollega's meast ferneamd - и , dy't ek in protte ferneamde wurken skreau.
Tim hat 40 jier ûnderfining yn softwareûntwikkeling; yn 1975 (gjin fan dejingen dy't dizze habrapost skreaun binne dit jier berne), wie Tim al de útfierende vice-presidint fan Yourdon Inc. Hy besteget no syn tiid oan rieplachtsjen, lesjaan en skriuwen, mei sa no en dan besites oan konferinsjes oer de hiele wrâld.
Wy diene spesjaal foar Habr in ynterview mei Tim Lister. Hy sil de DevOops 2019-konferinsje iepenje, en wy hawwe in protte fragen, oer boeken en mear. It ynterview wurdt útfierd troch Mikhail Druzhinin en Oleg Chirukhin fan 'e konferinsjeprogrammakommisje.
Michael: Kinne jo in pear wurden sizze oer wat jo no dogge?
Tim: Ik bin it haad fan it Atlantic Systems Guild. Wy binne seis yn it Gilde, wy neame ússels haadpersoanen. Trije yn 'e FS en trije yn Jeropa - dêrom wurdt it gilde Atlantyske neamd. Wy binne al safolle jierren tegearre dat jo se gewoan net telle kinne. Wy hawwe allegear ús spesjaliteiten. Ik haw de lêste desennia of mear mei kliïnten wurke. Myn projekten omfetsje net allinich behear, mar ek ynstelling fan easken, projektplanning en evaluaasje. It liket derop dat projekten dy't min begjinne meastentiids min einigje. Dêrom is it wurdich te soargjen dat alle aktiviteiten echt goed trochtocht en koördinearre binne, dat de ideeën fan 'e makkers wurde kombineare. It is de muoite wurdich om nei te tinken oer wat jo dogge en wêrom. Hokker strategyen te brûken om it projekt te foltôgjen.
Ik haw in protte jierren kliïnten op ferskate manieren advisearre. In nijsgjirrich foarbyld is in bedriuw dat robots makket foar knibbel- en heupoperaasjes. De sjirurch operearret net folslein selsstannich, mar brûkt in robot. Feiligens hjir, earlik sein, is wichtich. Mar as jo besykje om easken te besprekken mei minsken dy't rjochte binne op it oplossen fan problemen ... It sil nuver klinke, mar yn 'e FS is d'r (Federal Drug Administration), dy't produkten lykas dizze robots lisinsje. Foardat jo wat ferkeapje en it brûke op libbene minsken, moatte jo in lisinsje krije. Ien fan 'e betingsten is om jo easken sjen te litten, wat de tests binne, hoe't jo se hawwe testen, wat de testresultaten binne. As jo de easken feroarje, dan moatte jo dit heule enoarme testproses hieltyd wer trochgean. Us kliïnten wisten fisueel ûntwerp fan applikaasjes op te nimmen yn har easken. Se hiene screenshots direkt as ûnderdiel fan 'e easken. Wy moatte se útlûke en útlizze dat al dizze programma's foar it grutste part neat witte oer knibbels en heupen, al dizze dingen mei de kamera, ensfh. Wy moatte de easken dokuminten opnij skriuwe sadat se noait feroarje, útsein as guon echt wichtige ûnderlizzende betingsten feroarje. As fisueel ûntwerp net yn 'e easken is, sil it bywurkjen fan it produkt folle rapper wêze. Us taak is om dy eleminten te finen dy't omgean mei operaasjes op 'e knibbel, heupen, rêch, lûke se út yn aparte dokuminten en sizze dat dit de fûnemintele easken sille wêze. Litte wy in isolearre groep easken meitsje oer knibbeloperaasjes. Dit sil ús tastean om in stabiler set fan easken te bouwen. Wy sille prate oer de hiele produktline, en net oer spesifike robots.
Der waard in soad wurk dien, mar se kamen dochs op plakken dêr't se earder wiken en moannen oan werhelle testen sûnder sin of need trochbrochten, om't har op papier beskreaune easken net oerienkomme mei de echte easken dêr't de systemen foar boud waarden. De FDA fertelde har elke kear: jo easken binne feroare, no moatte jo alles fanôf it begjin kontrolearje. Folsleine rechecks fan it heule produkt fermoarde it bedriuw.
Dat, d'r binne sokke prachtige taken as jo josels oan it begjin fine fan wat ynteressant, en de earste aksjes sette de fierdere regels fan it spul. As jo derfoar soargje dat dizze iere aktiviteit goed begjint te wurkjen fan sawol in bestjoerlik as in technysk eachpunt, is d'r in kâns dat jo mei in geweldich projekt einigje. Mar as dit diel fan 'e spoaren gien is en earne ferkeard gien is, as jo de fûnemintele ôfspraken net fine kinne ... nee, it is net dat jo projekt needsaaklikerwize sil mislearje. Mar jo sille net mear kinne sizze: "Wy hawwe it geweldich dien, wy hawwe alles echt effektyf dien." Dit binne de dingen dy't ik doch as ik kommunisearje mei kliïnten.
Michael: Dat is, jo lansearje projekten, dogge in soarte fan kickoff en kontrolearje dat de rails yn 'e goede rjochting geane?
Tim: Wy hawwe ek ideeën oer hoe't wy alle puzelstikken byinoar sette kinne: hokker feardichheden wy nedich binne, wannear binne se krekt nedich, hoe't de kearn fan it team der útsjocht en oare sokke fûnemintele dingen. Binne wy folsleine wurknimmers nedich of kinne wy ien dieltiid oannimme? Planning, behear. Fragen lykas: Wat is it wichtichste foar dit bepaalde projekt? Hoe dit te berikken? Wat witte wy fan dit produkt of projekt, wat binne de risiko's en wêr't de ûnbekenden lizze, hoe sille wy mei dit alles omgean? Fansels, op dit stuit begjint immen te roppen "Wat oer agile?!" Okee, jo binne allegear fleksibel, mar wat dan? Hoe sjocht it projekt der krekt út, hoe helje jo it út op in wize dy't by it projekt past? Jo kinne net gewoan sizze dat "ús oanpak alles útstrekt, wy binne in Scrum-team!" Dit is ûnsin en ûnsin. Wêr geane jo neist hinne, wêrom soe it wurkje, wêr is it punt? Ik lear myn kliïnten nei te tinken oer al dizze fragen.
19 jier agile
Michael: Yn Agile besykje minsken faaks neat foarôf te definiearjen, mar sa let mooglik besluten te nimmen, sizzende: wy binne te grut, ik sil net tinke oer de algemiene arsjitektuer. Ik sil net tinke oer in boskje oare dingen; ynstee sil ik wat leverje dat op it stuit wurket oan 'e klant.
Tim: Ik tink dat agile metoaden, begjinnend mei yn 2001, iepene de yndustry syn eagen. Mar oan 'e oare kant is neat perfekt. Ik bin allegear foar iterative ûntwikkeling. Iteraasje makket in protte sin yn 'e measte projekten. Mar de fraach wêr't jo oer neitinke moatte is: as it produkt ienris út is en yn gebrûk is, hoe lang duorret it? Is dit in produkt dat seis moanne duorret foardat it ferfongen wurdt troch wat oars? Of is dit in produkt dat in protte, in protte jierren sil wurkje? Fansels sil ik gjin nammen neame, mar... Yn New York en har finansjele mienskip binne de meast fûnemintele systemen tige âld. Dit is geweldich. Jo sjogge nei har en tinke, as jo mar werom yn 'e tiid kinne gean, nei 1994, en fertel de ûntwikkelders: "Ik kaam út 'e takomst, fan 2019. Untwikkelje dit systeem gewoan sa lang as jo nedich binne. Meitsje it útwreidzjen, tink oer de arsjitektuer. It wurdt dan foar mear as fiifentweintich jier ferbettere. As jo ûntwikkeling wat langer fertrage, sil gjinien yn 'e grutte skema fan dingen merken!" As jo dingen op 'e lange termyn ynskatte, moatte jo beskôgje hoefolle it yn totaal sil kostje. Soms is goed ûntwurpen arsjitektuer it echt wurdich, en soms is it net. Wy moatte om ús hinne sjen en ús ôffreegje: binne wy yn de goede situaasje foar sa'n beslút?
Dus in idee as "Wy binne foar agile, de klant sels sil ús fertelle wat hy wol krije" - it is super nayf. Klanten witte net iens wat se wolle, en noch mear dat se net witte wat se kinne krije. Guon minsken sille begjinne te neamen histoaryske foarbylden as arguminten, ik haw al sjoen dit. Mar technysk avansearre minsken sizze dat meastentiids net. Se sizze: "It is 2019, dit binne de kânsen dy't wy hawwe, en wy kinne de manier wêrop wy nei dizze dingen sjogge folslein feroarje!" Yn stee fan besteande oplossingen nei te meitsjen, se wat moaier en mear kammen te meitsjen, moatte jo soms útgean en sizze: "Litte wy folslein opnij útfine wat wy hjir besykje te dwaan!"
En ik tink net dat de measte klanten sa oer it probleem tinke kinne. Se sjogge allinnich wat se al hawwe, dat is alles. Dêrnei komme se mei fersiken lykas "litte wy dit in bytsje ienfâldiger meitsje," of wat se gewoanlik sizze. Mar wy binne gjin obers of serveersters, dus wy kinne in bestelling nimme, hoe dom it ek útfalt en dy dan yn 'e keuken bakke. Wy binne har gidsen. Wy moatte har eagen iepenje en sizze: hey, wy hawwe hjir nije kânsen! Besefene jo dat wy de manier wêrop dit diel fan jo bedriuw dien wurdt wirklik kinne feroarje? Ien fan 'e problemen mei Agile is dat it it bewustwêzen fan wat in kâns is, wat in probleem is, wat moatte wy sels dwaan, hokker beskikbere technologyen it bêste binne foar dizze bepaalde situaasje.
Miskien bin ik hjir te skeptysk: der bart in protte prachtige dingen yn 'e agile mienskip. Mar ik haw in probleem mei it feit dat yn stee fan it definiearjen fan in projekt, minsken begjinne te goaien harren hannen. Ik soe hjir freegje - wat dogge wy, hoe sille wy it dwaan? En op ien of oare manier op magyske wize docht it altyd bliken dat de klant better witte moat as elkenien. Mar de klant wit it bêste allinne as er kiest út dingen dy't al boud troch immen. As ik in auto wol keapje en ik wit de grutte fan myn famyljebudzjet, dan sil ik gau in auto selektearje dy't past by myn libbensstyl. Hjir wit ik alles better as elkenien! Mar tink derom dat immen de auto's al makke hat. Ik haw gjin idee hoe't te útfine in nije auto, Ik bin gjin saakkundige. As wy oanpaste of spesjale produkten meitsje, moat de stim fan 'e klant rekken holden wurde, mar dit is net mear de ienige stim.
Oleg: Jo hawwe it Agile Manifesto neamd. Moatte wy it op ien of oare manier bywurkje of bewurkje mei it moderne begryp fan 'e kwestje?
Tim: Ik soe him net oanreitsje. Ik tink dat it in geweldich histoarysk dokumint is. Ik bedoel, hy is wat hy is. Hy wurdt 19 jier, hy is âld, mar yn syn tiid makke hy in revolúsje. Wat hy goed die, wie dat er in reaksje útlokte en minsken oer him begûnen te flústerjen. Jo wurken nei alle gedachten noch net yn 'e yndustry yn 2001, mar doe wurke elkenien neffens prosessen. Software Engineering Institute, fiif nivo's fan it software folsleinensmodel (CMMI). Ik wit net oft sokke leginden út de djippe âldheid wat sizze, mar doe wie it in trochbraak. Ynearsten leauden minsken dat as de prosessen goed ynsteld wiene, dan soene de problemen fan harsels ferdwine. En dan komt it Manifest en seit: "Nee, nee, nee - wy sille basearre wêze op minsken, gjin prosessen." Wy binne masters fan softwareûntwikkeling. Wy begripe dat it ideale proses in mirage is; it bart net. D'r is tefolle eigensinnigens yn projekten, it idee fan ien perfekt proses foar alle projekten makket gjin sin. De problemen binne te kompleks om te beweare dat d'r mar ien oplossing is foar alles (hallo, nirvana).
Ik nim my net oan om nei de takomst te sjen, mar ik sil sizze dat minsken no mear oer projekten begûn binne te tinken. Ik tink dat it Agile Manifesto heul goed is om út te springen en te sizzen: "Hey! Jo binne op in skip, en jo sels ride dit skip. Jo moatte in beslút nimme - wy sille gjin universele resept foar alle situaasjes foarstelle. Jo binne de bemanning fan it skip, en as jo binne goed genôch, kinne jo fine in wei nei it doel. D'r wiene oare skippen foar jo, en d'r sille oare skippen nei jo wêze, mar dochs, yn in sin, is jo reis unyk. Soksawat! It is in manier fan tinken. Foar my is d'r neat nijs ûnder de sinne, minsken hawwe earder farre en sille wer farre, mar foar jo is dit jo haadreis, en ik sil jo net fertelle wat jo krekt oerkomme sil. Jo moatte de feardichheden hawwe fan koördinearre wurk yn in team, en as jo se echt hawwe, sil alles útkomme en jo komme wêr't jo woenen.
Peopleware: 30 jier letter
Oleg: Wie Peopleware in revolúsje lykas it Manifest?
Tim: Peopleware... Tom en ik ha dit boek skreaun, mar wy tochten net dat it sa barre soe. Op ien of oare manier resonearre it mei de ideeën fan in protte minsken. Dit wie it earste boek dat sei: softwareûntwikkeling is in heul minsklike yntinsive aktiviteit. Nettsjinsteande ús technyske aard binne wy ek in mienskip fan minsken dy't wat grut bouwe, sels enoarm, heul kompleks. Nimmen kin sokke dingen allinich meitsje, krekt? Dus it idee fan "team" waard tige wichtich. En net allinnich út in behear eachpunt, mar ek foar technyske minsken dy't byinoar kamen te lossen echt komplekse djippe problemen mei in boskje ûnbekenden. Foar my persoanlik hat dit in enoarme test fan yntelliginsje west yn myn karriêre. En hjir moatte jo sizze kinne: ja, dit probleem is mear as ik sels oan kin, mar tegearre kinne wy in elegante oplossing fine dêr't wy grutsk op wêze kinne. En ik tink dat it dit idee wie dat it meast resonearre. It idee dat wy in part fan 'e tiid op ús eigen wurkje, in diel fan' e tiid as diel fan in groep, en faaks wurdt it beslút makke troch de groep. Oplossen fan groepproblemen is rap in wichtich skaaimerk wurden fan komplekse projekten.
Nettsjinsteande it feit dat Tim in enoarm oantal petearen hat jûn, wurde heul pear fan har op YouTube pleatst. Jo kinne sjen nei it rapport "The Return of Peopleware" fan 2007. De kwaliteit lit fansels folle te winskjen oer.
Michael: Is der wat feroare yn de lêste 30 jier sûnt it boek waard publisearre?
Tim: Jo kinne sjen op dit út in protte ferskillende hoeken. Sosjologysk sjoen... eartiids, yn ienfâldiger tiden, sieten jo en jo team op itselde kantoar. Jo koenen alle dagen tichtby wêze, tegearre kofje drinke en wurk beprate. Wat echt feroare is, is dat teams no geografysk kinne wurde ferdield yn ferskate lannen en tiidsônes, mar dochs wurkje se oan itselde probleem, en dit foeget in hiele nije laach fan kompleksiteit ta. Dit klinkt miskien âlde skoalle, mar d'r is neat as face-to-face kommunikaasje wêr't jo allegear byinoar binne, gearwurkje, en jo kinne nei in kollega rinne en sizze, sjoch wat ik ûntduts, hoe fynsto dit? Face-to-face petearen jouwe in rappe manier om oer te gean nei ynformele kommunikaasje, en ik tink dat agile entûsjasters it ek leuk moatte. En ik bin ek benaud, om't de wrâld yn 'e realiteit tige lyts is, en no is it allegear bedekt mei ferdielde teams, en it is allegear heul kompleks.
Wy libje allegear yn DevOps
Michael: Sels út it eachpunt fan 'e konferinsjeprogrammakommisje hawwe wy minsken yn Kalifornje, yn New York, Europa, Ruslân ... der is noch gjinien yn Singapore. It ferskil yn geografy is frij grut, en minsken begjinne te fersprieden noch mear. As wy it oer ûntwikkeling hawwe, kinne jo ús dan mear fertelle oer devops en it ôfbrekken fan barriêres tusken teams? Der is in konsept dat elkenien yn har bunkers sit, en no binne de bunkers ynstoart, wat fine jo fan dizze analogy?
Tim: It liket my ta dat yn it ljocht fan resinte technologyske trochbraken, devops fan grut belang is. Earder hiene jo teams fan ûntwikkelders en behearders, se wurken, wurken, wurken, en op in stuit ferskynde der in ding wêrmei't jo nei de admins komme koene en it útrolje foar produksje. En hjir begûn it petear oer de bunker, om't de admins in soarte fan bûnsmaten binne, teminsten gjin fijannen, mar jo prate allinich mei har as alles klear wie om nei produksje te gean. Binne jo mei wat nei har ta gien en sein: sjoch wat in oanfraach wy hawwe, mar kinne jo dizze applikaasje útrôlje? En no is it hiele konsept fan levering foar it better feroare. Ik bedoel, d'r wie dit idee dat jo feroaringen fluch koene trochdrukke. Wy kinne produkten op 'e flecht bywurkje. Ik glimkje altyd as Firefox op myn laptop opdûkt en seit, hey, wy hawwe jo Firefox op 'e eftergrûn bywurke, en sa gau as jo in minút hawwe, wolle jo hjir klikke en wy jouwe jo de lêste release. En ik wie as, "Oh ja, poppe!" Wylst ik sliepte, wurken se oan it leverjen fan my in nije release direkt op myn kompjûter. Dit is prachtich, ongelooflijk.
Mar hjir is de muoite: jo hawwe dizze funksje mei it bywurkjen fan de software, mar it yntegrearjen fan minsken is folle dreger. Wat ik wol stimme by de DevOops keynote is dat wy no folle mear spilers hawwe dan wy ea hiene. As jo gewoan tinke oan elkenien belutsen by mar ien team .... Jo tochten it as in team, en it is folle mear dan allinich in team fan programmeurs. Dit binne testers, projektmanagers, en in boskje oare minsken. En elkenien hat syn eigen miening oer de wrâld. Produktmanagers binne folslein oars as projektmanagers. Behearders hawwe har eigen taken. It wurdt in nochal lestich probleem om alle dielnimmers te koördinearjen om troch te gean bewust te wêzen fan wat der bart en net gek te wurden. It is needsaaklik om de taken fan 'e groep te skieden en taken dy't foar elkenien jilde. Dit is in tige drege taak. Oan 'e oare kant tink ik dat it allegear folle better is as in protte jierren lyn. Dit is krekt de wei wêrop minsken groeie en leare om goed te gedragen. As jo yntegraasje dogge, begripe jo dat d'r gjin ûndergrûnske ûntwikkeling moat wêze, sadat de software op it lêste momint net as in jack-in-the-box derút krûpt: lykas, sjoch wat wy hjir dien hawwe! It idee is dat jo yntegraasje en ûntwikkeling kinne dwaan, en oan 'e ein sille jo op in kreaze en iterative manier útrolje. Dit alles betsjut in protte foar my. Dit makket it mooglik om mear wearde te meitsjen foar de brûkers fan it systeem en foar jo klant.
Michael: It hiele idee fan devops is om sinfolle ûntwikkelingen sa betiid mooglik te leverjen. Ik sjoch dat de wrâld mear en mear begûn te fersnellen. Hoe oanpasse oan sokke fersnellingen? Tsien jier lyn bestie dit net!
Tim: Fansels wol elkenien mear en mear funksjonaliteit. Gjin needsaak om te bewegen, gewoan mear opsteapje. Soms moatte jo sels fertrage foar de folgjende inkrementele update om wat nuttichs te bringen - en dat is folslein normaal.
It idee dat jo moatte rinne, rinne, rinne is net it bêste. It is net wierskynlik dat immen har libben sa libje wol. Ik wol graach dat it ritme fan leveringen it eigen ritme fan it projekt bepaalt. As jo gewoan in stream fan lytse, relatyf betsjuttingsleaze dingen produsearje, jout it allegear gjin betsjutting. Ynstee fan mindlessly besykje dingen sa betiid mooglik frij te litten, wat it wurdich is te besprekken mei de liedende ûntwikkelders en produkt- en projektmanagers is strategy. Hat dit sels sin?
Patterns en antipatterns
Oleg: Jo prate meast oer patroanen en antipatterns, en dit is it ferskil tusken it libben en dea fan projekten. En no, devops barst yn ús libben. Hat it ien fan har eigen patroanen en anty-patroanen dy't it projekt op it plak kinne deadzje?
Tim: Patterns en anty-patroanen komme de hiele tiid foar. Iets om oer te praten. No, d'r is dit ding dat wy "glimmende dingen" neame. Minsken hâlde echt fan nije technology. Se wurde gewoan fassineare troch de glâns fan alles dat cool en stylich sjocht, en se stopje fragen te stellen: is it sels nedich? Wat sille wy berikke? Is dit ding betrouber, makket it sin? Ik sjoch faaks minsken, sa te sizzen, op it snijflak fan technology. Se wurde hypnotisearre troch wat der yn 'e wrâld bart. Mar as jo in tichterby sjogge hokker nuttige dingen se dogge, is d'r faaks gewoan neat nuttich!
Wy bepraten krekt mei ús kameraden dat dit jier in jubileumjier is, fyftich jier lyn dat minsken op 'e moanne lâne. Dit wie yn 1969. De technology dy't minsken holpen dêr te kommen is net iens technology fan 1969, mar earder 1960 of 62, om't NASA allinich brûke woe wat goed bewiis fan betrouberens hie. En sa sjogge jo it en begripe - ja, en se wiene wier! No, nee, nee, mar jo komme yn problemen mei technology gewoan om't alles te hurd oanstutsen wurdt, út alle barsten ferkocht. Oeral roppe minsken: "Sjoch, wat in ding, dit is it nijste ding, it moaiste fan 'e wrâld, geskikt foar absoluut elkenien!" No ja, dat is it... meastentiids blykt dit allegear mar in lokmiddel te wêzen, en dan moat it allegear fuortsmiten wurde. Miskien komt it allegear om't ik al in âld man bin en mei in protte skepsis nei sokke dingen sjoch, as minsken útrinne en sizze dat se de ienige, meast juste manier fûn hawwe om de bêste technologyen te meitsjen. Op dit stuit wurdt in stim yn my wekker dy't seit: "Wat in rommel!"
Michael: Ja, hoe faak hawwe wy heard oer de folgjende sulveren kûgel?
Tim: Krekt, en dit is de gewoane gong fan saken! Bygelyks... it liket derop dat dit om 'e wrâld al in grap wurden is, mar hjir prate minsken faak oer blockchain-technology. En se hawwe eins sin yn bepaalde situaasjes! As jo echt betrouber bewiis fan eveneminten nedich hawwe, dat it systeem wurket en dat gjinien ús ferrifele, as jo feiligensproblemen hawwe en al dat guod byinoar mingd - blockchain makket sin. Mar as se sizze dat Blockchain no oer de wrâld sil sweepje, alles op syn paad ferveegje? Dream mear! Dit is in tige djoere en komplekse technology. Technysk kompleks en tiidslinend. Ynklusyf suver algoritmysk, elke kear as jo de wiskunde opnij moatte berekkenje, mei de minste feroaringen ... en dit is in geweldich idee - mar allinich foar bepaalde gefallen. Myn hiele libben en karriêre hawwe hjir oer gongen: nijsgjirrige ideeën yn heul spesifike situaasjes. It is heul wichtich om krekt te begripen wat jo situaasje is.
Michael: Ja, de wichtichste "kwestje fan it libben, it universum en alles": is dizze technology of oanpak geskikt foar jo situaasje of net?
Tim: Dizze fraach kin al besprutsen wurde mei de technologygroep. Miskien sels in adviseur ynhelje. Besjoch it projekt en begryp - sille wy no wat goed en nuttich dwaan, better dan earder? Miskien past it, miskien wol it net. Mar it wichtichste, nim sa'n beslút net standert, gewoan om't immen flapte: "Wy hawwe wanhopich in blockchain nedich! Ik lies krekt oer him yn in tydskrift op it fleantúch!” Serieus? It is net iens grappich.
De mytyske "devops-yngenieur"
Oleg: No implementeart elkenien devops. Immen lêst oer devops op it ynternet, en moarn ferskynt in oare fakatuere op in wervingsside. "devops yngenieur". Hjir wol ik jo oandacht foar lûke: tinke jo dat dizze term, "devops yngenieur," rjocht hat op it libben? Der is in miening dat devops in kultuer is, en wat komt hjir net by.
Tim: Sa sa. Lit se dan daliks wat útlis jaan oer dizze term. Iets om it unyk te meitsjen. Oant se bewize dat d'r in unike kombinaasje fan feardichheden is efter in fakatuere lykas dizze, ik sil it net keapje! Ik bedoel, no, wy hawwe in baantitel, "devops yngenieur," in nijsgjirrige titel, ja, wat dan? Jobtitels binne oer it algemien in heul ynteressant ding. Litte wy sizze "ûntwikkelder" - wat is it dochs? Ferskillende organisaasjes betsjutte folslein oare dingen. Yn guon bedriuwen skriuwe heechweardige programmeurs tests dy't mear sin meitsje as tests skreaun troch spesjale profesjonele testers yn oare bedriuwen. Dus wat, binne se no programmeurs of testers?
Ja, wy hawwe baantitels, mar as jo fragen lang genôch stelle, docht bliken dat wy allegear probleemoplossers binne. Wy binne oplossingsikers, en guon hawwe wat technyske feardichheden en guon hawwe ferskillende. As jo libje yn in omjouwing wêr't DevOps is penetrearre, binne jo dwaande mei de yntegraasje fan ûntwikkeling en administraasje, en dizze aktiviteit hat wat frij wichtich doel. Mar as jo frege wurde wat jo krekt dogge en wêr't jo ferantwurdlik foar binne, dan docht bliken dat minsken al dy dingen fan âlds diene. "Ik bin ferantwurdlik foar de arsjitektuer", "Ik bin ferantwurdlik foar de databases" ensafuorthinne, wat jo ek sjogge - dit alles wie foar "devops".
As immen my har wurktitel fertelt, harkje ik net folle. It is better om him te fertellen wêr't hy eins ferantwurdlik foar is, dit sil ús it probleem folle better begripe kinne. Myn favorite foarbyld is as in persoan beweart in "projektmanager" te wêzen. Wat? It betsjut neat, ik wit noch net wat jo dogge. In projektmanager kin in ûntwikkelder wêze, de lieder fan in team fan fjouwer minsken, koade skriuwe, wurk dwaan, dy't in teamleader wurden is, dy't minsken sels ûnder harsels erkenne as lieder. En ek, in projektmanager kin in manager wêze dy't seishûndert minsken op in projekt beheart, oare managers beheart, ferantwurdlik is foar it opstellen fan skema's en it plannen fan budzjetten, dat is alles. Dit binne twa folslein ferskillende wrâlden! Mar harren baan titel klinkt itselde.
Litte wy dit in bytsje oars omdraaie. Wêr bisto echt goed yn, hast in protte ûnderfining, hast talint foar? Wêr sille jo ferantwurdlikens foar nimme, om't jo tinke dat jo de taak oan kinne? En hjir sil ien daliks begjinne te ûntkenne: nee, nee, nee, ik ha hielendal gjin winsk om te gean mei projektmiddels, it is net myn saak, ik bin in technyske dude en ik begryp brûkberens en brûkersynterfaces, ik wit net wol überhaupt legers fan minsken beheare, lit my better oan it wurk gean.
En trouwens, ik bin in grut foarstanner fan in oanpak wêrby't dit soarte fan skieding fan feardichheden goed wurket. Wêr't technici har karriêre kinne groeie sa fier as se wolle. Dochs sjoch ik noch altyd organisaasjes dêr't techny's kleie: ik sil nei projektbehear moatte, want dat is de ienige manier yn dit bedriuw. Soms liedt dit ta skriklike útkomsten. De bêste techies binne hielendal gjin goede managers, en de bêste managers kinne technology net omgean. Lit ús hjir earlik oer wêze.
Ik sjoch hjir no in soad fraach nei. As jo in technyk binne, kin jo bedriuw jo helpe, mar nettsjinsteande, jo moatte jo eigen karriêrepaad wirklik fine, om't technology hieltyd feroaret en jo moatte josels opnij útfine! Yn mar tweintich jier kinne technologyen op syn minst fiif kear feroarje. Technology is in nuver ding ...
"Eksperts op alles"
Michael: Hoe kinne minsken omgean mei sa'n snelheid fan technologyferoaring? Har kompleksiteit groeit, har oantal groeit, it totale bedrach fan kommunikaasje tusken minsken groeit ek, en it docht bliken dat jo gjin "ekspert yn alles" wurde kinne.
Tim: Rjochts! As jo wurkje yn technology, ja, jo moatte perfoarst wat spesifyk kieze en deryn ferdjipje. Guon technology dy't jo organisaasje nuttich fynt (en miskien eins nuttich wêze sil). En as jo der net mear yn ynteressearje - ik soe noait leaud hawwe dat ik dit soe sizze - no, miskien moatte jo ferhúzje nei in oare organisaasje wêr't de technology ynteressanter of handiger is om te studearjen.
Mar yn 't algemien, ja, jo hawwe gelyk. Technologien groeie yn alle rjochtingen tagelyk; gjinien kin sizze "Ik bin in saakkundige technolooch yn alle technologyen dy't bestean." Oan de oare kant binne der spûnsminsken dy’t technologyske kennis letterlik opfange en der gek op binne. Ik haw in pear fan sokke minsken sjoen, se sykhelje letterlik en libje it, it is nuttich en nijsgjirrich om mei har te praten. Se bestudearje net allinich wat der binnen de organisaasje bart, mar yn 't algemien prate se der oer, se binne ek echt coole technologen, se binne heul bewust en doelbewust. Se besykje gewoan te bliuwen op 'e top fan' e welle, nettsjinsteande wat har haadtaak is, om't har passy de beweging fan Technology is, de promoasje fan technology. As jo sa'n persoan ynienen moetsje, moatte jo mei him nei lunch gean en oer de lunch ferskate koele dingen beprate. Ik tink dat elke organisaasje op syn minst in pear fan sokke minsken nedich hat.
Risiko's en ûnwissichheid
Michael: Honored yngenieurs, ja. Litte wy risikobehear oanreitsje wylst wy tiid hawwe. Wy begûnen dit ynterview mei in diskusje oer medyske software, wêr't flaters liede kinne ta skriklike gefolgen. Doe hawwe wy praat oer it Lunar Program, wêr't de kosten fan in flater miljoenen dollars binne, en mooglik ferskate minsklike libbens. Mar no sjoch ik de tsjinoerstelde beweging yn 'e sektor, minsken tinke net oer risiko's, besykje se net te foarsizzen, observearje se net iens.
Oleg: Bewege fluch en brekke dingen!
Michael: Ja, ferhúzje fluch, brek dingen, mear en mear dingen, oant jo stjerre fan wat. Fanút jo eachpunt, hoe moat de gemiddelde ûntwikkelder it learen fan risikobehear no oanpakke?
Tim: Litte wy hjir in line lûke tusken twa dingen: risiko's en ûnwissichheid. Dit binne ferskillende dingen. Unwissichheid komt foar as jo op in bepaald momint net genôch gegevens hawwe om ta in definityf antwurd te kommen. Bygelyks, op it heul iere stadium fan in projekt, as immen jo freget "wannear sille jo it wurk ôfmeitsje," as jo in frij earlik persoan binne, sille jo sizze: "Ik haw gjin idee." Jo gewoan net witte, en dat is goed. Jo hawwe de problemen noch net bestudearre en binne net bekend mei it team, jo kenne har feardigens net, ensfh. Dit is ûnwissichheid.
Der ûntsteane risiko's as mooglike problemen al identifisearre wurde kinne. Dit soarte fan ding kin barre, de kâns is grutter as nul, mar minder as hûndert prosint, earne yn tusken. Dêrtroch kin fan alles barre, fan fertraging en ûnnedich wurk, mar sels oant in fatale útkomst foar it projekt. De útkomst, as jo sizze - jonges, litte wy ús paraplu's opfolde en it strân ferlitte, wy sille it noait ôfmeitsje, it is allegear foarby, punt. Wy makken de oanname dat dit ding soe wurkje, mar it wurket hielendal net, it is tiid om te stopjen. Dit binne de situaasjes.
Faak binne problemen it maklikst op te lossen as se al ûntstien binne, as it probleem op dit stuit bart. Mar as in probleem krekt foar jo is, dogge jo gjin risikobehear - jo dogge probleemoplossing, krisisbehear. As jo in liedende ûntwikkelder of manager binne, moatte jo jo ôffreegje wat der kin barre dat soe liede ta fertragingen, fergriemde tiid, ûnnedige kosten, of it ynstoarten fan it heule projekt? Wat sil ús stopje en opnij begjinne? As al dizze dingen wurkje, wat sille wy mei har dwaan? D'r is in ienfâldich antwurd dat jildich is foar de measte situaasjes: rinne net fuort fan risiko's, wurkje der oan. Sjoch hoe't jo in risikofolle situaasje kinne oplosse, it ta neat ferminderje, it fan in probleem feroarje yn wat oars. Yn stee fan te sizzen: goed, wy losse problemen op sa't se ûntsteane.
Unwissichheid en risiko moatte op 'e foargrûn wêze fan alles wêr't jo mei omgean. Jo kinne in projektplan nimme, beskate krityske risiko's fan tefoaren besjen en sizze: dêr moatte we no mei oan, want as dat misgiet, dan makket neat oars út. Jo moatte gjin soargen meitsje oer de skientme fan it tafelkleed op 'e tafel as it net dúdlik is oft jo iten kinne koekje. Earst moatte jo alle risiko's identifisearje fan it tarieden fan in lekker diner, omgean mei har, en pas dan tinke oer alle oare dingen dy't gjin echte bedriging foarmje.
Nochris, wat makket jo projekt unyk? Litte wy sjen wat ús projekt fan 'e rails kin meitsje. Wat kinne wy dwaan om de kâns dat dit bart te minimalisearjen? Normaal kinne jo se net gewoan 100% neutralisearje en mei in dúdlik gewisse ferklearje: "Dat is it, dit is gjin probleem mear, it risiko is oplost!" Foar my is dit in teken fan folwoeksen gedrach. Dit is it ferskil tusken in bern en in folwoeksene - bern tinke dat se ûnstjerlik binne, dat neat ferkeard gean kin, alles komt goed! Tagelyk sjogge folwoeksenen hoe't trijejierrige bern op it boarterstún springe, de bewegingen mei de eagen folgje en tsjin harsels sizze: "ooh-ooh, ooh-ooh." Ik stean tichtby en meitsje my klear om te fangen as it bern wol falt.
Oan 'e oare kant is de reden wêrom't ik dit bedriuw sa leuk fyn omdat it risikofolle is. Wy dogge dingen, en dy dingen binne risikofolle. Se fereaskje in folwoeksen oanpak. Entûsjasme allinich sil jo problemen net oplosse!
Adult engineering tinken
Michael: It foarbyld mei bern is goed. As ik in gewoane yngenieur bin, dan bin ik bliid om in bern te wêzen. Mar hoe geane jo nei mear folwoeksen tinken?
Tim: Ien fan 'e ideeën dy't like goed wurket mei sawol in begjinner as in fêststelde ûntwikkelder is it konsept fan kontekst. Wat wy dogge, wat wy sille berikke. Wat is echt wichtich op dit projekt? It makket net út wa't jo binne op dit projekt, oft jo in stazjêre binne as de haadarsjitekt, elkenien hat kontekst nedich. Wy moatte elkenien oan it tinken krije op gruttere skaal as syn eigen wurk. "Ik meitsje myn stik, en sa lang as myn stik wurket, bin ik bliid." Nee en wer nee. It is altyd de muoite wurdich (sûnder grof te wêzen!) om minsken te herinnerjen oan de kontekst wêryn se wurkje. Wat wy allegearre besykje te berikken tegearre. Ideeën dy't jo in bern kinne wêze, salang't alles goed is mei jo stik fan it projekt - asjebleaft, doch dat net. As wy überhaupt de einstreek oerstekke, komme wy dy allinnich tegearre oer. Jo binne net allinich, wy binne allegear byinoar. As alle minsken yn it projekt, sawol âld as jong, begûnen te praten oer wat krekt wichtich is foar it projekt, wêrom't it bedriuw jild ynvestearret yn wat wy allegear besykje te berikken ... de measten fan harren sille har folle better fiele om't se sil sjen hoe't har wurk korrelearret mei it wurk fan elkenien oars. Oan de iene kant begryp ik it stik dêr't ik persoanlik ferantwurdlik foar bin. Mar om it wurk ôf te meitsjen hawwe wy ek alle oare minsken nedich. En as jo echt tinke dat jo klear binne, hawwe wy altyd wurk te dwaan yn it projekt!
Oleg: Relatyf sprutsen, as jo wurkje neffens Kanban, as jo de knelpunt fan guon testen treffe, kinne jo ophâlde wat jo dêr diene (bygelyks programmearje) en gean de testers helpe.
Tim: Krekt. Ik tink dat de bêste techies, as jo har goed sjogge, se binne in soarte fan har eigen managers. Hoe kin ik dit formulearje ...
Oleg: Jo libben is jo projekt, dat jo beheare.
Tim: Krekt! Ik bedoel, jo nimme ferantwurdlikens, jo begripe it probleem, en jo komme yn kontakt mei minsken as jo sjogge dat jo besluten har wurk kinne beynfloedzje, dingen lykas dat. It giet net oer gewoan oan jo buro sitte, jo wurk dwaan, en net iens realisearje wat der om jo hinne bart. Nee nee nee. Trouwens, ien fan 'e bêste dingen oer Agile is dat se koarte sprints foarstelden, om't op dizze manier de stân fan saken fan alle dielnimmers dúdlik te observearjen is, kinne se it allegear byinoar sjen. Wy prate alle dagen oer elkoar.
Hoe te krijen yn risiko behear
Oleg: Is der in formele kennisstruktuer op dit mêd? Bygelyks, ik bin in Java-ûntwikkelder en wol risikobehear begripe sûnder in echte projektmanager te wurden troch oplieding. Ik sil wierskynlik earst McConnell's "Hoefolle kostet in softwareprojekt kostet" lêze, en wat dan? Wat binne de earste stappen?
Tim: De earste is om te begjinnen mei kommunikaasje mei minsken yn it projekt. Dit soarget foar in direkte ferbettering yn 'e kultuer fan kommunikaasje mei kollega's. Wy moatte begjinne troch standert alles út te iepenjen, ynstee fan it te ferbergjen. Sis: dit binne de dingen dy't my hinderje, dit binne de dingen dy't my nachts oerein hâlde, ik waard hjoed nachts wekker en wie as: myn God, hjir moat ik oer tinke! Sjogge oaren itselde ding? As groep, moatte wy reagearje op dizze potinsjele problemen? Jo moatte in diskusje oer dizze ûnderwerpen stypje kinne. D'r is gjin foarôf tare formule wêrmei't wy wurkje. It giet net oer it meitsjen fan hamburgers, it giet allegear om minsken. "Make a cheeseburger, sell a cheeseburger" is net ús ding, en dêrom hâld ik sa folle fan dit wurk. Ik fyn it leuk as alles wat managers eartiids diene no eigendom wurdt fan it team.
Oleg: Jo hawwe it yn boeken en ynterviews oer hoe't minsken mear soarchje oer lok dan oer sifers op in grafyk. Oan 'e oare kant, as jo it team fertelle: wy geane nei devops, en no moat de programmeur konstant kommunisearje, dit kin fier bûten syn komfortsône wêze. En op dit stuit kin er, lit ús sizze, djip ûngelokkich wêze. Wat te dwaan yn dizze situaasje?
Tim: Ik bin net wis krekt wat te dwaan. As in ûntwikkelder is te isolearre, se sjogge net wêrom't it wurk wurdt dien yn it foarste plak, se sjogge gewoan op harren diel fan it wurk, en se moatte komme yn wat ik neam "kontekst." Hy moat útfine hoe't alles meiinoar ferbûn is. En fansels bedoel ik gjin formele presintaasjes of sa. Ik haw it oer it feit dat jo mei kollega's kommunisearje moatte oer it wurk as gehiel, en net allinich oer it diel dêr't jo ferantwurdlik foar binne. Hjir kinne jo begjinne mei it besprekken fan ideeën, mienskiplike ôfspraken om jo wurk goed byinoar te meitsjen en hoe't jo tegearre in mienskiplik probleem oanpakke kinne.
Om har te helpen oanpasse, wolle se faaks techyen nei training stjoere, en besprekke se training. In freon fan my wol sizze dat training foar hûnen is. Der is training foar minsken. Ien fan 'e bêste dingen oer learen as ûntwikkelder is ynteraksje mei jo leeftydsgenoaten. As immen echt goed is yn wat, moatte jo se wurkje sjen of mei har prate oer har wurk of sa. Guon konvinsjonele Kent Beck praat hieltyd oer ekstreme programmearring. It is grappich om't XP sa'n ienfâldich idee is, mar it soarget foar safolle problemen. Foar guon is XP dwaan as twongen wurde om neaken te stripjen foar freonen. Se sille sjen wat ik doch! Se binne myn kollega's, se sille net allinich sjen, mar ek begripe! Freeslik! Guon minsken begjinne serieus senuweftich te wurden. Mar as jo realisearje dat dit de ultime manier is om te learen, feroaret alles. Jo wurkje nau gear mei minsken, en guon minsken begripe it ûnderwerp folle better as jo.
Michael: Mar dit alles twingt jo om út jo komfortensône te stappen. As yngenieur moatte jo út jo komfortensône komme en kommunisearje. As probleemoplosser moatte jo josels konstant yn in swakke posysje sette en tinke oer wat der mis gean kin. Dit soarte wurk is ynherent ûntwurpen om oerlêst te wêzen. Jo sette josels bewust yn stressfolle situaasjes. Meastentiids rinne minsken fan har ôf, minsken wolle graach lokkige bern wêze.
Tim: Wat kin dien wurde, kinst útkomme en iepen sizze: “Alles is goed, ik kin it oan! Ik bin net de iennichste dy't him ûngemaklik fielt. Litte wy ferskate ûngemaklike dingen besprekke, allegear tegearre, as in team! Dit binne ús mienskiplike problemen, wy moatte har omgean, wite jo? Ik tink dat eigensinnige sjeny-ûntwikkelders binne as mammoeten, se ferdwûnen. En harren betsjutting is tige beheind. As jo net kommunisearje kinne, kinne jo net goed meidwaan. Dêrom gewoan prate. Wês earlik en iepen. It spyt my tige dat dit foar immen onaangenaam is. Kinne jo jo foarstelle, in protte jierren lyn wie d'r in stúdzje wêryn't de wichtichste eangst yn 'e Feriene Steaten net de dea is, mar riede wat? Eangst foar spreken yn it iepenbier! Dat betsjut dat der earne minsken binne dy't leaver stjerre as in komplimint lûdop sizze. En ik tink dat it genôch is foar jo in pear basisfeardigens, ôfhinklik fan wat jo dogge. Sprekfeardigens, skriuwfeardigens - mar allinich safolle as jo echt nedich binne yn jo wurk. As jo wurkje as analist, mar kin net lêze, skriuwe of prate, dan, spitigernôch, hawwe jo neat te dwaan yn myn projekten!
De priis fan kommunikaasje
Oleg: Is it yn tsjinst fan sokke útgeande meiwurkers om ferskate redenen net djoerder? Ommers, se binne hieltyd petear yn plak fan wurkjen!
Tim: Ik bedoelde de kearn fan it team, en net allinich elkenien. As jo ien hawwe dy't echt cool is yn it ôfstimmen fan databases, hâldt fan databases ôfstimmen, en sil trochgean mei it ôfstimmen fan jo databases foar de rest fan syn libben en dat is it, cool, hâld it op. Mar ik haw it oer minsken dy't yn it projekt sels wenje wolle. De kearn fan it team, rjochte op it ûntwikkeljen fan it projekt. Dizze minsken moatte wirklik konstant mei elkoar kommunisearje. En benammen oan it begjin fan it projekt, as jo risiko's besprekke, manieren om globale doelen te berikken en sa.
Michael: Dit jildt foar elkenien dy't belutsen is by it projekt, nettsjinsteande spesjalisaasje, feardichheden of wurkwizen. Jo binne allegear ynteressearre yn it sukses fan it projekt.
Tim: Ja, jo fiele dat jo genôch ûnderdompele binne yn it projekt, dat jo taak is om it projekt te helpen realisearje. Oft jo in programmeur, analist, ynterface-ûntwerper, elkenien binne. Dit is de reden dat ik elke moarn oan it wurk kom en dit is wat wy dogge. Wy binne ferantwurdlik foar al dizze minsken, nettsjinsteande harren feardichheden. Dit is in groep minsken dy't folwoeksen petearen hawwe.
Oleg: Yn feite, sprekkende meiwurkers, ik besocht te simulearjen de beswieren fan minsken, benammen managers, dy't frege wurde om te wikseljen nei devops, nei dizze hiele nije fyzje fan 'e wrâld. En dy beswieren moatte jo as adviseurs folle better bewust wêze as ik as ûntwikkelder! Diele wat managers it meast soargen meitsje?
Tim: Behearders? Hm. Meastentiids binne managers ûnder druk fan problemen, konfrontearre mei de needsaak om driuwend wat los te litten en in levering te meitsjen, en sa. Se sjogge hoe't wy hyltyd wat beprate en beprate, en se sjogge it sa: petearen, petearen, petearen... Wat oare petearen? Wer oan it wurk gean! Want praten fielt har gjin wurk oan. Jo skriuwe gjin koade, testje gjin software, lykje neat te dwaan - wêrom stjoere jo net om wat te dwaan? De levering is ommers al oer in moanne!
Michael: Gean wat koade skriuwe!
Tim: It liket my dat se gjin soargen meitsje oer wurk, mar oer it gebrek oan sichtberens fan foarútgong. Om it te meitsjen dat wy tichterby súkses komme, moatte se ús sjen litte drukke op knoppen op it toetseboerd. De hiele dei fan moarns oant jûns. Dit is probleem nûmer ien.
Oleg: Misha, jo tinke oer wat.
Michael: Sorry, ik ferlear yn gedachten en fong in flashback. Dit alles die my tinken oan in nijsgjirrige rally dy't juster barde... Der wiene juster tefolle rallyen... En it klinkt allegear hiel fertroud!
Libben sûnder salaris
Tim: Trouwens, it is net nedich om "rallyen" te organisearjen foar kommunikaasje. Ik bedoel, de meast brûkbere diskusjes tusken ûntwikkelders barre as se gewoan mei elkoar prate. Jo rinne yn 'e moarntiid mei in bakje kofje, en der binne fiif minsken byinoar en fûleindich beprate wat technysk. Foar my, as ik de manager fan dit projekt bin, is it better om gewoan te glimkjen en earne oer myn bedriuw te gean, lit se it besprekke. Se binne al safolle mooglik belutsen. Dit is in goed teken.
Oleg: Trouwens, yn jo boek hawwe jo in bult oantekeningen oer wat goed en wat min is. Brûke jo sels ien fan har? Relatyf sprutsen, no hawwe jo in bedriuw, en ien dat op in heul ûnortodokse manier strukturearre is ...
Tim: Unortodoks, mar dit apparaat past perfekt by ús. Wy kennen inoar al lang. Wy fertrouwe elkoar, wy fertrouden elkoar in protte foardat wy partners waarden. En wy ha bygelyks hielendal gjin leanen. Wy wurkje gewoan, en as ik bygelyks jild fan myn kliïnten fertsjinne, dan gie al it jild nei my. Dêrnei betelje wy ledejild oan de organisaasje, en dit is genôch om it bedriuw sels te stypjen. Plus, wy binne allegear spesjalisearre yn ferskate dingen. Ik wurkje bygelyks mei boekhâlders, folje belestingoanjefte yn, doch allerhande bestjoerlike dingen foar it bedriuw, en gjinien betellet my der foar. James en Tom wurkje op ús webside en gjinien betellet se ek. Salang't jo jo fergoedingen betelje, sil gjinien tinke oan jo te fertellen wat jo moatte dwaan. Tom wurket bygelyks no folle minder as eartiids. No hat er oare belangen; hy docht guon dingen net foar it Gilde. Mar sa lang as er syn fergoedings betellet, sil gjinien nei him ta komme en sizze: "Hey, Tom, gean oan it wurk!" It is hiel maklik om te gean mei kollega's as der gjin jild tusken jo is. En no is ús relaasje ien fan 'e fûnemintele ideeën yn relaasje ta ferskate spesjaliteiten. It wurket en it wurket hiel goed.
Bêste advys
Michael: Gean werom nei "bêste advys", is d'r wat dat jo jo kliïnten hieltyd wer fertelle? Der is in idee oer 80/20, en guon advys wurdt wierskynlik faker werhelle.
Tim: Ik tocht ris dat as jo in boek skriuwe as Waltzing mei Bears, it de rin fan 'e skiednis feroarje soe en de minsken ophâlde, mar... No, sjoch, bedriuwen dogge faak dat alles goed is mei har. Sadree't der wat slims bart, is it in skok en in ferrassing foar harren. "Sjoch, wy hawwe it systeem hifke, en it giet gjin systeemtests troch, en dit is noch trije moannen fan net pland wurk, hoe koe dit barre? Wa wist it? Wat koe der mis gean? Serieus, leauwe jo dit?
Ik besykje út te lizzen dat jo net te lilk wurde moatte oer de hjoeddeistige situaasje. Wy moatte it útprate, wirklik begripe wat der ferkeard west hawwe koe, en hoe te foarkommen dat sokke dingen yn 'e takomst barre. As in probleem ferskynt, hoe sille wy it bestride, hoe sille wy it befetsje?
Foar my liket dit allegear eng. Minsken omgean mei komplekse, ferfelende problemen en bliuwe te pretend dat as se gewoan de fingers oerstekke en hoopje op it bêste, it "bêste" wirklik sil barre. Nee, sa wurket it net.
Oefenje risikobehear!
Michael: Nei jo miening, hoefolle organisaasjes dogge mei oan risikobehear?
Tim: Wat my irritearret is dat minsken gewoan risiko's opskriuwe, nei de resultearjende list sjogge en oan it wurk gean. Yn feite is it identifisearjen fan risiko's foar har risikobehear. Mar foar my klinkt dit as in reden om te freegjen: goed, der is in list, wat sille jo krekt feroarje? Jo moatte jo standert sekwinsjes fan aksjes feroarje mei dizze risiko's yn 'e rekken. As d'r ien fan 'e dreechste parten fan it wurk is, moatte jo it oanpakke, en pas dan trochgean nei wat ienfâldiger. Begjin yn 'e earste sprints komplekse problemen op te lossen. Dit liket al op risikobehear. Mar normaal kinne minsken net sizze wat se feroare hawwe nei it gearstallen fan in list mei risiko's.
Michael: En dochs, hoefolle fan dizze bedriuwen binne belutsen by risikobehear, fiif prosint?
Tim: Spitigernôch, ik haatsje te sizzen dit, mar dit is wat hiel ûnbelangrik diel. Mar mear as fiif, om't d'r echt grutte projekten binne, en se kinne gewoan net bestean as se net op syn minst wat dogge. Litte wy gewoan sizze dat ik tige ferrast wêze sil as it op syn minst 25% is. Lytse projekten beäntwurdzje sokke fragen meastentiids sa: as it probleem ús oangiet, dan losse wy it op. Dan komme se harsels mei súkses yn de problemen en dogge se mei probleembehear en krisisbehear. As jo besykje in probleem op te lossen en it probleem is net oplost, wolkom by krisisbehear.
Ja, ik hear faaks, "wy sille problemen oplosse as se ûntsteane." Wiswier sille wy? Sille wy echt beslute?
Oleg: Jo kinne it nayf dwaan en gewoan wichtige invarianten skriuwe yn it projekthânfêst, en as de invarianten brekke, start it projekt gewoan op 'e nij. It docht bliken hiel piembucky.
Michael: Ja, it barde mei my dat doe't risiko's waarden trigger, it projekt gewoan opnij definiearre waard. Moai, bingo, probleem oplost, meitsje jo gjin soargen mear!
Tim: Litte wy op de resetknop drukke! Nee, sa wurket it net.
Keynote by DevOops 2019
Michael: Wy komme by de lêste fraach fan dit ynterview. Jo komme nei de folgjende DevOops mei in keynote, kinne jo it gerdyn fan geheimhâlding opheffe oer wat jo sille fertelle?
Tim: Op dit stuit skriuwe seis fan harren in boek oer wurkkultuer, de ûnútsprutsen regels fan organisaasjes. Kultuer wurdt bepaald troch de kearnwearden fan 'e organisaasje. Meastentiids fernimme minsken dit net, mar nei't wy in protte jierren yn konsultaasje wurke hawwe, binne wy wend om it op te merken. Jo ynfiere in bedriuw, en letterlik binnen in pear minuten begjinne jo te fielen wat der bart. Wy neame dit "smaak". Soms is dizze geur echt goed, en soms is it, no, oeps. Dingen binne hiel oars foar ferskate organisaasjes.
Michael: Ik wurkje ek al jierren yn konsultaasje en begryp goed wêr't jo it oer hawwe.
Tim: Eins is ien fan 'e dingen dy't it wurdich is om oer te praten op' e keynote, dat net alles wurdt bepaald troch it bedriuw. Jo en jo team, as mienskip, hawwe jo eigen teamkultuer. Dit kin it hiele bedriuw wêze, of in aparte ôfdieling, in apart team. Mar foardat jo seine, hjir is wat wy leauwe, hjir is wat wichtich is ... Jo kinne in kultuer net feroarje foardat de wearden en leauwen efter spesifike aksjes wurde begrepen. Gedrach is maklik te observearjen, mar sykjen nei leauwen is lestich. DevOps is gewoan in geweldich foarbyld fan hoe't dingen hieltyd komplekser wurde. Ynteraksjes wurde allinich komplekser, se wurde hielendal net skjinner of dúdliker, dus jo moatte tinke oer wêr't jo yn leauwe en wêr't elkenien om jo hinne swiet.
As jo rappe resultaten wolle berikke, is hjir in goed ûnderwerp foar jo: hawwe jo bedriuwen sjoen wêr't gjinien seit "Ik wit it net"? D'r binne plakken wêr't jo in persoan letterlik martelje oant hy jout dat hy wat net wit. Elkenien wit alles, elkenien is in ongelooflijke erudit. Jo benaderje elke persoan, en hy moat de fraach direkt beäntwurdzje. Yn stee fan te sizzen "Ik wit it net." Hoera, se hierden in stel eruditen! En yn guon kultueren is it oer it algemien tige gefaarlik om te sizzen "ik wit it net"; it kin wurde waarnommen as in teken fan swakte. D'r binne ek organisaasjes wêryn, krekt oarsom, elkenien kin sizze "Ik wit it net." Dêr is it folslein legaal, en as immen begjint te rommeljen yn antwurd op in fraach, is it folslein normaal om te antwurdzjen: "Jo witte net wêr't jo it oer hawwe, krekt?" en meitsje it allegear in grap.
Ideaallik wolle jo in baan hawwe wêr't jo konstant lokkich kinne wêze. It sil net maklik wurde, net alle dagen is sinne en noflik, soms moat je hurd wurkje, mar as je begjinne mei de balans op te nimmen, komt it út: wow, dit is echt in prachtich plak, ik fiel my goed om hjir te wurkjen, sawol emosjoneel as yntellektueel. En d'r binne bedriuwen wêr't jo as adviseur hinne geane en daliks realisearje dat jo it trije moanne net úthâlde kinne en yn skrik fuortrinne soene. Dêr wol ik it by it rapport oer hawwe.
Tim Lister komt mei in keynote nei de DevOops 2019-konferinsje, dy't plakfine sil op 29-30 oktober 2019 yn Sint-Petersburch. Jo kinne keapje kaartsjes . Wy wachtsje op jo by DevOops!
Boarne: www.habr.com