Ljudska strana saradnje u razvoju softvera

Saradnja u razvoju softvera je, u svojoj suštini, duboko ljudski poduhvat. Artefakti koji preživljavaju — kôd, dizajnerske datoteke, git historija — samo su fosili razgovora koji su ih stvorili. Kada saradnja u razvoju softvera ide dobro, ti razgovori stvaraju softver koji odražava kolektivnu inteligenciju. Kada saradnja u razvoju softvera ide loše, artefakti odražavaju neriješene ljudske sukobe prerušene u tehnički dug. Ovaj članak pokriva ljudsku stranu saradnje u razvoju softvera koju tehnički udžbenici često zanemaruju. Pogledajte našu stranicu o nama za to kako strukturiramo timove. Prvo, uspješna saradnja u razvoju softvera zavisi od psihološke sigurnosti. Inženjeri koji se plaše da budu osuđivani zbog postavljanja pitanja prestaće ih postavljati, čime se problemi skrivaju sve dok ne postanu skupi. Nasuprot tome, timovi s jakim navikama saradnje u razvoju softvera normalizuju „Ne razumijem ovaj kôd, možeš li mi ga objasniti?" kao prednost, a ne slabost. Shodno tome, menadžeri koji žele bolju saradnju u razvoju softvera trebaju sami pokazati ranjivost — javno priznavanjem sopstvenih praznina u znanju uče tim da je priznavati praznine prihvatljivo. Pogledajte Vikipediju o psihološkoj sigurnosti za istraživačku pozadinu. Drugo, pisana komunikacija je temelj skalabilne saradnje u razvoju softvera. Verbalni razgovor je visokopropusni, ali ne ostavlja nikakav zapis; sastanci isključuju sve ko je u drugoj vremenskoj zoni. Nasuprot tome, pisana saradnja u razvoju softvera — putem dizajnerskih dokumenata, opisa pull requesta, pisanih stand-upova, RFC-ova i zapisa o arhitekturnim odlukama — skalira se kroz veličine timova i vremenske zone. Štoviše, sam čin pisanja prisiljava na jasnije razmišljanje nego ekvivalentna usmena razmjena. Treće, saradnja u razvoju softvera enormno koristi od malih timova. Iznad otprilike osam osoba, komunikacijski troškovi rastu super-linearno. Iz tog razloga, saradnja visokih performansi u razvoju softvera tipično se dešava u timovima od tri do sedam inženjera s jednim, jasnim ciljem. Nadalje, kada timovi trebaju narasti iznad te veličine, podjela na pod-timove s jasnim sučeljima daje bolju saradnju u razvoju softvera nego zadržavanje svih u jednoj velikoj prostoriji. Četvrto, pregled kôda je mjesto gdje saradnja u razvoju softvera ili cvjeta ili propada. Pregledi koji se fokusiraju na suštinu (kompromisi u dizajnu, granični slučajevi, nejasno imenovanje) jačaju saradnju u razvoju softvera; pregledi koji cjepidlačare o ličnim stilskim preferencijama je slabe. Sukladno tome, najbolje kulture saradnje u razvoju softvera imaju eksplicitne norme pregleda: ciljati na konstruktivan ton, odvojiti „mora se promijeniti" od „razmotri promjenu" i slaviti promjene koje ste našli poučnima. Dodatno, uparivanje na teškim pregledima često je brže od asinhronog pregledavanja. Peto, neslaganje je zdravo za saradnju u razvoju softvera. Timovi koji se slažu oko svega ili ne razmišljaju kritički ili suzbijaju stvarne prigovore — oba ishoda su loša. Nasuprot tome, timovi s jakom saradnjom u razvoju softvera tretiraju neslaganje kao resurs: dobro izražen prigovor obično upućuje na rizik koji niko drugi još nije artikulisao. Iz tog razloga, rituali saradnje u razvoju softvera trebaju uključivati formalne mehanizme za registrovanje neslaganja (pisana snažna mišljenja, eksplicitne odluke tehničkog lidera nakon slušanja neslaganja, arhitekturni pregledi). Šesto, saradnja u razvoju softvera zahtijeva zajednički kontekst. Novi članovi tima koji nemaju kontekst ne mogu efikasno sarađivati, bez obzira na to koliko su individualno vješti. Shodno tome, dobre kulture saradnje u razvoju softvera ulažu mnogo u uvođenje: uparivanje sa starijim inženjerima dvije sedmice, izvođenje dokumentovanih projekata učenja prije dotakanja produkcije i održavanje wiki stranica za uvođenje koje objašnjavaju zašto je sistem takav kakav jeste, a ne samo šta jest. Sedmo, saradnja u razvoju softvera kroz discipline multiplicira rezultate. Kada dizajneri, inženjeri i menadžeri proizvoda rade kao jedan tim umjesto predavanja artefakata, saradnja u razvoju softvera stvara bolji softver brže. Štoviše, međudisciplinarna saradnja u razvoju softvera rano uočava probleme: dizajner koji učestvuje u pregledima kôda primjećuje da implementacija odlazi od dizajna; inženjer koji učestvuje u korisničkim intervjuima razumije granične slučajeve prije prve linije kôda. Pogledajte našu stranicu karijera za to kako zapošljavamo za međudisciplinarne vještine. Osmo, daljinska saradnja u razvoju softvera zahtijeva namjerni napor. Signali koji su besplatni u zajedničkom uredu — govor tijela, skice na bijeloj ploči, slučajno čuti razgovori — nestaju u radu na daljinu. Iz tog razloga, kulture daljinske saradnje u razvoju softvera namjerno kompenzuju: više pisanog konteksta, eksplicitnije strukture sastanaka, politike uključene kamere za važne razgovore i redovne sedmice tima s fizičkim prisustvom. Daljinska saradnja u razvoju softvera može biti odlična, ali samo kada timovi prepoznaju troškove i svjesno ih plaćaju. Deveto, saradnja u razvoju softvera kroz vremenski period je teža od saradnje u jednom trenutku. Tim koji piše sistem gotovo nikada nije isti tim koji ga održava tri godine kasnije. Shodno tome, kulture saradnje visokih performansi u razvoju softvera pišu za buduće čitaoce: komentari objašnjavaju zašto, ne šta; arhitekturne odluke su dokumentovane s kompromisima; commit poruke pričaju priče. Saradnja u razvoju softvera koja zanemaruje ovu buduću publiku stvara sisteme koji su skupi za razvijanje čak i kada je sam kôd tehnički ispravan. Deseto, javno slavlje saradnje u razvoju softvera ojačava kulturu. Kada se težak produkcijski incident riješi kroz snažan timski rad, priča se treba ispričati — na timskoj retrospektivi, u internoj blogu, cijeloj kompaniji. Slično, kada međutimska saradnja isporuči funkcionalnost omiljenu od strane korisnika, zasluga treba biti podijeljena eksplicitno. Saradnja u razvoju softvera koja ostaje neprepoznata nestaje; saradnja u razvoju softvera koja se javno slavi kompoundira. U Square Software gledamo na saradnju u razvoju softvera kao na investiciju s najvećom polugom koju tehnološki lider može napraviti. Svaki dolar potrošen na poboljšanje saradnje u razvoju softvera — bolje pisanje, bolji sastanci, bolje uvođenje, bolje retrospektive — daje višestruke prinose kroz svaku funkcionalnost koju tim isporuči nakon toga. Nasuprot tome, timovi koji tretiraju saradnju u razvoju softvera kao meki trošak obično otkrivaju u roku od nekoliko godina da im je tvrdi tehnički output stagnirao. Jaki ljudi plus jaka saradnja u razvoju softvera nadmašuju individualnu genijalnost svaki put. Kontaktirajte nas putem stranice za kontakt za timski koučing angažmane.