Kuidas juhtida edukat arendusprotsessi (isegi kui te pole tehniline)

Kas see poleks greeeeeat ... (Office Space, 1999)

Laurence Peter sõnastas põhimõtte, et “juhid tõusevad oma ebakompetentsuse tasemele” 1969. aastal. Eelkõige on mittetehnilised juhid teeninud tarkvaraarendajatega halva maine.

Kontoriruum kujutab ülaltoodud Bill Lumberghi mittetehnilist juhti. Dilbert pakub klassikalist “Pointy-juustega boss”.

See artikkel on mõeldud kõigile, kes soovivad arendusprotsessi tõhusalt korraldada, muutumata teie meeskonna vesijahutusega nalja tagumikuks. Jagan seda, mida olen aastate jooksul UCLA ja Stanfordi ülikooli juhataja ja tarkvaraarhitektina arendamise ja väljalaskeprotsesside juhtimisel õppinud.

Suurim õpitud õppetund on see, et edukate tarkvaraväljaannete säilitamise võti on täiesti mittetehniline.

Asi on protsessis.

Mõningad arendusprotsessi aspektid saavad kasu tehnilisest oskusteabest, kuid seda pole vaja. Tarkvara edukas tootmisesse laskmine on palju rohkem robustse protsessiarhitektuuri küsimus kui pelgalt disain või kood.

Selle artikli jaoks eeldame, et olete juba kokku leppinud, et hakkate midagi ehitama. Tootekinnitusprotsess on erinev protsess. Täna keskendume kokkulepitud toote saamisele kontseptsioonist tootmiseni.

Mida ehitada

Teie meeskond peab kokku panema oma koodi jaoks selge tegevuskava. Arhitektid ja tootjad kasutavad jooniseid. Ka sina peaksid.

Kas ma peaksin neid plaane kasutama või lihtsalt seda tiivustama? Hmm… (allikas)

Teie teekaart peaks sisaldama skeemide komplekti, millel kõigil on erinev eesmärk. Need skeemid erinevad üksikute rakenduste puhul. Levinud on kasutajaliidese makett, rakenduse arhitektuuriskeem ja äriprotsessimudel. Sageli on kasulikud ka üksikasjalikumad komponentide skeemid, näiteks UML-skeemid ja voosemudelid.

Tehniline ekspertiis võimaldab teil neid skeeme kasutada oma meeskonna arhitektuuri kritiseerimiseks ja nende õigel teel püsimiseks. Isegi ilma tehniliste oskusteta on need skeemid kriitilised.

Saate neid kasutada produktiivsete vestluste pidamiseks toote valmimise kohta. Enam ei pea te joonistama "% komplekti" õhukesest õhust ega ka arendusmeeskonna parimatest arvamistest. Diagrammil saate jälgida iga üksuse olekut, et teha kindlaks, kui lähedal rakendus on lõpetatud. Samuti saate tulevase kiiruse prognoosida selle põhjal, kui kiiresti meeskond eelnevad komponendid komplekteeris.

Arenduseelse dokumentatsiooni jaoks pole õiget kogust, kuid on üks vale summa: mitte ükski. Enne kodeerimise alustamist töötage koos oma meeskonnaga välja, mis on vastuvõetav teekaart. Teie arendusprotsessi esimene kontrollpunkt on see dokumentatsioon üle vaadata ja veenduda, et nad on selle lepinguga täidetud.

Mida mitte ehitada

Teie meeskond ei saa kõike üles ehitada. Ka ei peaks. Peate tagama, et teie arendajad keskenduvad laseril sellele, mida nad tegelikult vajavad ehitamiseks.

Miks te just seda rakendust ehitate? Määratlege võtme eristamine olemasolevatest toodetest. 80% teie meeskonna ajast peaks kuluma selle eristamise toetamisele.

Skeemidest, mis teil nüüd peaksid olema, on siin abi. Kas teie rakendus sisaldab logimise komponenti? Registreerumine ja sisselogimine? Nende komponentide jaoks on enamikes keeltes juba olemas suurepärased tasuta avatud lähtekoodiga tarkvara (FOSS) raamistikud. Mõned neist on saadaval äärmiselt lubavate litsentside alusel.

Tesla illustreerib seda kontseptsiooni suurepäraselt. Nende esimene peamine diferentseerija oli kasutada liitium-ioon aku, et muuta elektriautod gaasiga konkurentsivõimeliseks. Liitiumioon saavutas selle, vähendades aku kaalu ja suurendades tööulatust.

Lõpuks asus Tesla välja ehitama oma autode toetamiseks terveid infrastruktuure, nagu see „Superlaaduri” jaam… kuid mitte enne, kui nad olid oma eristavat algtoodet (allikat) täiustanud

Esimene Tesla prototüüp muutis olemasoleva elektrilise sportauto lihtsalt pliihappest liitiumakuks. Nende esimene tootmisjooks oli enamasti Lotus Elise rodster (eelnev sportauto), millel oli Tesla aku ja mootor.

Teie meeskonna õppetund on kasutada seal juba olemasolevat igal võimalusel. Kui saate FOSS-i paketti kasutada või kohandada, siis tehke seda. Isegi kui peate tasulise koodi litsentsima kuskilt mujalt, on see peaaegu alati seda väärt.

Saate kõik tellingud kiiresti paika, et saaksite oma liitium-ioonakut testida. Siis saate seda korrata ja välja vahetada, mis aitab teie toodet veelgi eristada, ilma et peaksite muretsema tootmisvalmiduse viivitamise pärast.

Teie arendusprotsessi teine ​​kontrollpunkt on vaadata koos meeskonnaga läbi kavandatud arhitektuur ja tuvastada, millise väga piiratud osa nad kavatsevad nullist üles ehitada.

Kui see kõlab nagu juba eksisteeriv asi ja see pole teie toote keskne teema, esitage oma meeskonnale väljakutse, miks nad usuvad, et nad peavad seda uuesti tegema.

Ärge visake seda lihtsalt üle seina

Liiga sageli viskavad arendusmeeskonnad töö lõpetamise korral müüri üle seina ja kõnnivad minema. Vabastamisjärgsed vead on tugimeeskonna käsutuses. (allikas)

Kui olete kindlaks teinud, milliseid eelmonteeritud tehnoloogiaid te kasutate, vaadake need kindlasti üle oma tooterühmaga.

Andmebaaside ja serverite administraatorid peavad kavandama uute tehnoloogiate installimise ja toetamise. See on teie arendusprotsessi kolmas kontrollpunkt: operatsioonide valmisolek.

Tootmise tugirühma varakult vaos hoidmine moodustab 90% salajasest kastmest, mida tuntakse nimega „DevOps“. Kui te pole sellest veel kuulnud, on DevOps idee, et tarkvaraarenduse ja tootmistegevuse meeskonnad peaksid ühiste eesmärkide raames ühinema.

Kavandatud eelised hõlmavad palju kiiremaid väljalaskeid, usaldusväärsemat koodi ja automatiseerimise tõttu rohkem aega arendamiseks. Need kõik on suurepärased õnnistused, kuid need tulenevad tugevast suhtlusprotsessist. Automatiseerimine järgib, mitte ei asenda koostööd.

Rakendamine ja testimine

Nüüd kirjutab teie meeskond koodi. Tehke oma rakendusmeeskonnaga koostööd, et töötada välja töö omavaheline jagamise protsess. Pole olemas kõigile sobivat lähenemisviisi ja see on koht, kus juhtimise pehmed oskused kaaluvad dramaatiliselt üle kõik tehnilised oskused.

Mõned arendajad tahavad kõik "huvitavad" tööd kokku panna ja eiravad kõiki petteteoseid. Nad võivad uskuda, et nad on ruumis kõige targem inimene ja peaksid endale ülesanded valima. Teised võivad muutustele vastu seista ja soovivad teha ainult samasugust tööd, nagu nad on varem teinud.

Juhtige oma meeskond töö õiglasesse jaotamisse. Kutsu kõiki üles kasvama vastavalt ning jagama ja tegema koostööd.

Veel üks tehniline aspekt rakenduses on see, et kood peab sisaldama piisavalt automatiseeritud teste. Need on koodi määratletud testid, mida testisüsteem suudab täita.

Kui kood hakkab krahhi lööma, kas te ei taha, et nende kuttide jätkamine oleks teie enda asemel reas? (üldkasutatav: USA valitsuse foto)

Käsitsi testiskriptid, kus inimene suhtleb koodiga, et näha, kas see töötab ebapiisavalt ja kajastavad tehnilist võlga. Teie tehniline meeskond peaks hõlmama vähemalt ühikatseid. Testipõhine arendus on populaarne lähenemisviis, et tagada kriitilise koodi alati testimine.

Saate pidada oma meeskonnaga mittetehnilist vestlust tema „testkatte” (testitava koodi osa) üle. See on üsna lihtne: paluge neil oma eeldused loetleda. Seejärel küsige, kus ja kuidas nad neid eeldusi testivad.

Kontrollpunkti, kus arendajad arvavad, et kood on täielik, nimetatakse minu poes dev-täielikuks. See tähendab, et esmane arendusprotsess on läbi, kuid ülevaatusprotsessis esile kerkivate probleemide lahendamiseks võib kirjutada lisakoodi.

Agiilses arendusprotsessis jagate rakendusprotsessi tavaliselt mitmeks või mitte-tähtpäevaks asemel mitmeks kontrollpunktiks. Neid nimetatakse tavaliselt iteratsioonideks.

Vaadake esimeses etapis määratletud teekaarti. Enne uue (te) komponendi käivitamist veenduge, et see, mida olete juba alustanud, oleks vähemalt valmis. See annab teile täpse ülevaate arengu kiirusest ja vähendab riski.

Pärast iteratsioonide lõpuleviimist saate suunata koodi keskkonda, kus toimub aktsepteerimise testimine. See hõlmab piloot- või testkasutajaid (või seda rolli mängivast sisemist meeskonda), kes suhtlevad osalise tootega. Nad kontrollivad, kas see vastab disaini ootustele, ja annavad tagasisidet selle kohta, kuidas see võiks parem olla.

Vastuvõtukontroll ei asenda varem nimetatud ühikatsetusi. See teenib erinevat eesmärki. Katastroofi retsept, mille abil saate oma arendusmeeskonnal tugineda vastuvõtukatsetele põhiliste funktsionaalsete vigade leidmiseks.

Vastuvõtutesteerijate tagasiside saab lisada järgmisse iteratsiooni. See on veel üks hea põhjus, miks mitte toote suurt tükki korraga maha hammustada. Kui soovite, et inimesed tootega mängima hakkaksid, jätaks ruumi kursuse muutmiseks.

Kui olete piisavalt testitud koodi kogunud, et moodustada piisav tooteväljaanne, olete valmis alustama väljalaskehaldusprotsessi.

Otsite vigu kõigist õigetest kohtadest

Viga peab siin kuskil asuma… (allikas)

Teie arendaja või meeskond on jõudnud punkti, kus nende arvates on kood tehtud. Vastuvõtmise testijad on toote toimimisviisiga rahul. Järgmine kontrollpunkt protsessis on veendumuse kinnitamine, et teil on kood tooteks saamiseks valmis. Alustame koodi ülevaatamist!

Teil ei pruugi meeskonna koodi enda üle vaatamiseks olla mugav või kui teil pole piisavalt tehnilisi teadmisi. See on okei! Te ei pea seda tegema. Teie protsess peab.

Töötage koos oma meeskonnaga välja koodide ülevaatuse protsess, mis nende jaoks sobib. Kui teil on mitu arendajat, töötab vastastikuse koodi ülevaade suurepäraselt. Kui te seda ei tee, kas on teie organisatsioonis väljaspool teie meeskonda ka teisi arendajaid? Töötage üle meeskonna piiride, et luua vastastikuse ülevaatuse programm.

Kui arendajaid on tõesti ainult üks, istuge koos nendega ja laske neil kood läbi vaadata. Kasutage oma skeemid võrdluspunktina ja paluge neil öelda, kuidas kood skeemi eesmärke täidab.

Koodi ülevaatamise protsessi lõpus peaksid arendaja ja ülevaataja (d) tundma end mugavalt selle eest, et nad on koodi eest vastutavad.

Koodi ülevaatamine on hea aeg ka kahe muu kriitilise punkti: dokumentatsiooni ja turvalisuse - ülevaatamiseks.

Juba jätkusuutlikust dokumenteerimisarhitektuurist olen juba kirjutanud - huvi korral vaadake järele!

Turvakontroll peaks olema osa igast koodikontrollist. Üldiselt hõlmab see koodi teistkordset uurimist, et tuvastada nõrkusi, kus ründaja võiks seda kasutada isiklike andmete paljastamiseks või serveri üle kontrolli saamiseks. Seda peab tegema tehniline isik.

Avatud veebirakenduste turvaprojekt (OWASP) avaldab tasuta põhjaliku turvaülevaate juhendi.

Teie arendaja saab seda teha, kui nad on meeskonnas ainsad, isegi kui nad käitavad lihtsalt automatiseeritud turvakoodide analüüsi tööriista. Selle protsessi abistamiseks on tasuta tööriistad, mis on lingitud OWASP wiki kaudu.

Eject, eject, eject!

Kood on ülevaatusprotsessi läbinud. See on valmis tooteks saama. Kuid see ei tähenda, et see oleks tootmiseks valmis.

Viimane kontrollpunkt, mille puhastada saab, on juurutusvalmidus. Kas teie kood on olukorras, kus seda on lihtne tootmiseks kasutusele võtta? See peaks hõlmama võimalikult vähe manuaalseid samme.

See tähendab ka, et teil peab olema plaan muudatuse taastamiseks juhuks, kui kood ei tööta plaanipäraselt. Seda nimetatakse tagasipöördumisplaaniks.

Kõik tootekoodid jäävad tootmisesse… (allikas)

Kui teil on eraldi tarkvaratoimingute meeskond, tulevad nad siia tagasi. Nad peaksid üle vaatama juurutamise ja tagasivõtmise dokumentatsiooni ning andma teada, kas sellest piisab.

Kui teil neid töötajaid pole, saate selle toimingu ise teha. Veenduge, et toote juurutamiseks on olemas selged ja lihtsad juhised. Manuaalseid samme peaks olema väga vähe, kuna iga manuaalne samm loob võimaluse inimlikeks eksimusteks.

Kui juurutamine ei õnnestu, peaks olema selge ja piisav plaan varasema olukorra juurde naasmiseks. See võib olla sama lihtne kui varukoopia taastamine või võib hõlmata kliendisuhtlust või andmete teisendamist.

Kas plaan on piisav, sõltub sellest, kui põhjalikult teie meeskond koodi kontrollis ja kui laialt toodeti. Kaaluge ka kõiki toote või selle konkreetse väljalaskega seotud riske.

Kui olete selle kontrollpunkti läbinud, lükake see kood tootmisele!

Pärast vabastamist

Edu või ebaõnnestumine on oluline, et teeksite ringi ja vaataksite üle, kuidas protsess kulges.

Kas teie meeskond hindas täpselt toote vabastamiseks vajalikke pingutusi? Kas testimine modelleeris tootmisstsenaariumi piisavalt? Vaadake uuesti üle kontrollimise ja juurutamise kontrollpunktid ning kontrollige, kui hästi meeskond töötas.

Kuidas toode tootmises töötab? See on hea mõte külastada operatsioonide töötajaid ja saada nende tagasisidet. See loob veelgi usalduse arendus- ja operatsioonimeeskondade vahel ning toob DevOpsist kasu veelgi.

Kus on teie tootes allesjäänud lüngad? Kui need asuvad kolmanda osapoole koodis, on nüüd aeg kaaluda, kas kohandada oma pakette või rakendada uuesti nullist. Muidu on teil nüüd sisend, mida järgmise väljalaske jaoks ehitada.

Ennekõike pidage ennast ja oma meeskonda vastutavaks oma pingutuste tulemuste eest.

Vastutus hõlbustab iseseisvust ja soodustab individuaalset kasvu. Kuna teie meeskond harjub sellega, et selle protsessi iga sammu eest võetakse vastutust, kohandavad nad oma jõudlust vastavalt.

Järeldus

Eduka tarkvara väljalaskeprotsessi käitamiseks ei pea te olema vähe tehnik. Tehniline oskus võib aidata, kuid sellest võib saada ka karku.

Tarkvara eduka väljalaske võti on hästi dokumenteeritud ja arusaadav protsess tarkvara liikumiseks torujuhtme kaudu ideelt tootele. Nüüd on teil oma tarkvara väljalaskeprotsessi koostamise lähtepunkt.

Kõige olulisem on see, et osalete koos oma meeskonnaga tühikute täitmisel ja korduva protsessi loomisel, mis töötab teie kõigi jaoks.

See ei pea olema kellelegi täiuslik, kuid seda peavad mõistma kõik.

Samuti peate tagama, et teie toote kiirus nende kontrollpunktide kaudu vastab toote nõudlusele. Ükski neist kaupadest ei pea olema mitmepäevased show-korgid. See võib olla lihtne üheleheline kontrollnimekiri. Peate määratlema protsessi, mis sobib teie keskkonnaga.

Nagu iga protsessi puhul, peaksite ka seda korrama. Nii nagu kood, pole ka teie esimene testimata mustand tõenäoliselt täiuslik. Häälestage protsessi igal läbimisel ja saate tarkvara sujuva, etteaimatava vabastamise tee.

Ja pidage meeles, et pintseldage juukseid. Te ei soovi, et see näeks välja ... terav.

Kui teile see artikkel meeldis ja soovite rohkem lugeda, palun andke mulle sellest teada! Kui soovite veel teada ettevõtte rakenduste arendamise protsesside kohta, vastake allpool. Mul on hea meel jagada oma meeskonna teekonnal saadud kogemusi!

Võite nautida ka teisi minu artikleid tarkvaraarenduse äriprotsessi kohta:

  • Mis teil puudu jääb, kui jätate kontrollnimekirja vahele
  • Kuidas korraldasime end ümber professionaalsemaks arenduspoeks, kui kaotasime üksildase hundiguru

Jonathan on UCLA teadusuuringute infosüsteemide osakonna arhitektuuri ja operatsioonide abidirektor. Ta on teeninud füüsika kraadi Stanfordi ülikoolist ja on sellest ajast alates töötanud üle 10 aasta infosüsteemide arhitektuuri, andmepõhise äriprotsesside parendamise ja organisatsiooni juhtimise alal.