Kuinka suorittaa onnistunut kehitysprosessi (vaikka et olisi tekninen)

Eikö se olisi greeeeeat… (Office Space, 1999)

Laurence Peter muotoili periaatteen, jonka mukaan ”johtajat nousevat epäpätevyytensä tasolle” vuonna 1969. Erityisesti muut kuin tekniset johtajat ovat ansainneet huonon maineen ohjelmistokehittäjien kanssa.

Office Space kuvaa ei-teknisen johtajan Bill Lumberghissa, yllä. Dilbert tarjoaa klassisen "Pointy-Haired Boss" -tuotteen.

Tämä artikkeli on tarkoitettu kaikille, jotka haluavat organisoida kehitysprosessin tehokkaasti tulematta joukkueesi vesijäähdyttimien vitsiksi. Kerron, mitä olen vuosien varrella oppinut hallitsemaan kehitys- ja julkaisuprosesseja johtajana ja ohjelmistoarkkitehtina UCLA: ssa ja Stanfordin yliopistossa.

Suurin oppimaani, jonka olen oppinut, on, että avain onnistuneiden ohjelmistojen julkaisujen ylläpitämiseen on täysin ei-tekninen.

Kyse on prosessista.

Jotkut kehitysprosessin näkökohdat hyötyvät teknisestä osaamisesta, mutta sitä ei vaadita. Ohjelmistojen onnistunut vapauttaminen tuotantoon on paljon enemmän vakaan prosessiarkkitehtuurin kuin pelkkä suunnittelu tai koodi.

Oletetaan, että olet jo sopinut aloittavan jotain tämän artikkelin tarkoituksia varten. Tuotteen hyväksyntäputki on erilainen prosessi. Tänään keskitymme sovitun tuotteen saamiseen konsepista tuotantoon.

Mitä rakentaa

Tiimisi täytyy koota selkeä etenemissuunnitelma koodilleen. Arkkitehdit ja valmistajat käyttävät piirustuksia. Sinunkin pitäisi.

Pitäisikö minun käyttää näitä suunnitelmia tai vain siivellä sitä? Hmm… (lähde)

Etenemissuunnitelmasi tulisi sisältää joukko kaavioita, jotka kukin täyttävät erilaisen tarkoituksen. Nämä kaaviot eroavat yksittäisissä sovelluksissa. Käyttöliittymän malli, sovellusarkkitehtuurikaavio ja liiketoimintaprosessimalli ovat yleisiä. Yksityiskohtaisemmat komponenttikaaviot, kuten UML (Unified Modeling Language) -diagrammit ja virtausmallit, ovat myös usein hyödyllisiä.

Teknisen asiantuntemuksen avulla voit käyttää näitä kaavioita kritisoidaksesi ryhmäsi arkkitehtuuria ja varmistaaksesi, että ne ovat oikealla tiellä. Jopa ilman teknistä taitoa, nämä kaaviot ovat kriittisiä.

Voit käyttää niitä ohjaamaan tuottavia keskusteluja tuotteen valmistumisesta. Sinun ei enää tarvitse piirtää “% täydellistä” ohutlevystä tai parhaan arvauksen perusteella kehitysryhmältä. Voit seurata kaavion kunkin kohteen tilaa määrittääksesi, kuinka lähellä sovellus on valmis. Voit myös projisoida tulevaisuuden nopeuden sen perusteella, kuinka nopeasti joukkue valmisti aiemmat komponentit.

Kehitystä edeltävää dokumentaatiota ei ole ”oikeaa” määrää, mutta on yksi väärä määrä: ei mitään. Harjoittele ryhmäsi kanssa hyväksyttävää etenemissuunnitelmaa, ennen kuin he alkavat koodata. Ensimmäinen tarkistuspiste kehitysprosessissasi on tarkistaa nämä asiakirjat ja varmistaa, että ne ovat täyttäneet tämän sopimuksen.

Mitä ei rakentaa

Ryhmäsi ei voi rakentaa kaikkea. Ei myöskään pitäisi. Sinun on varmistettava, että kehittäjät keskittyvät laserilla siihen, mitä he todella tarvitsevat rakentaa.

Miksi olet juuri rakentamassa tätä sovellusta? Määritä tärkein erottelu olemassa olevista tuotteista. 80% joukkueesi ajasta tulisi kulua tuon erottelun tukemiseen.

Kaaviot, jotka nyt pitäisi olla, ovat hyödyllisiä täällä. Sisältääkö sovelluksesi hakkuukomponentin? Rekisteröinti- ja kirjautumisprosessi? Näille komponenteille on jo olemassa erinomaisia ​​ilmaisia, avoimen lähdekoodin ohjelmistoja (FOSS) useimmilla kielillä. Jotkut ovat saatavana erittäin sallivilla lisensseillä.

Tesla kuvaa loistavasti tätä konseptia. Heidän ensimmäinen keskeinen erottaja oli käyttää litium-ioniakkua sähköautojen kilpailuttamiseksi kaasulla. Litium-ioni saavutti tämän vähentämällä akun painoa ja lisäämällä kantamaa.

Lopulta Tesla ryhtyi rakentamaan kokonaisia ​​infrastruktuureja tukemaan heidän autojaan, kuten tämä

Ensimmäinen Tesla-prototyyppi yksinkertaisesti muutti olemassa olevan sähköisen urheiluauton lyijyhaposta litiumparistoiksi. Heidän ensimmäinen tuotantosuunnitelmansa oli enimmäkseen Lotus Elise rodster (aikaisempi urheiluauto), jossa oli Tesla-akku ja -moottori.

Ryhmäsi oppitunti on käyttää jo olemassa olevaa mahdollisuuksien mukaan. Jos voit käyttää tai mukauttaa FOSS-pakettia, tee se. Vaikka joudut lisensoimaan maksukoodin muualta, se on melkein aina sen arvoista.

Hanki kaikki rakennustelineet nopeasti paikoilleen, jotta voit testata litium-ioni-akkuasi. Sitten voit jatkaa läpi ja korvata mitä tahansa, mikä auttaa tuotetta erottelemaan entisestään korostamatta tuotantovalmiuden viivyttämistä.

Toinen kehityspisteesi tarkistuspiste on tarkistaa suunniteltu arkkitehtuuri tiimisi kanssa ja tunnistaa, mitä hyvin rajoitettua osaa he aikovat rakentaa tyhjästä.

Jos se kuulostaa jo olemassa olevalta, ja se ei ole tuotteen painopiste, haasta tiimisi selvittääksesi, miksi heidän mielestään heidän on tehtävä se uudelleen.

Älä heitä sitä vain seinän yli

Liian usein kehitysryhmät “heittävät vapautuksen seinän yli” työnsä jälkeen ja kävelevät pois. Julkaisemisen jälkeiset virheet on tukitiimin käsiteltävä. (lähde)

Kun olet tunnistanut käyttämäsi valmiiksi rakennetut tekniikat, muista tarkistaa ne tuotannon tukiryhmän kanssa.

Tietokantojen ja palvelinten järjestelmänvalvojien on suunniteltava kaikkien uusien tekniikoiden asentamista ja tukemista. Tämä on kolmas tarkistuspiste kehitysprosessissasi: toimintavalmius.

Tuotannon tukitiimin pitäminen varhaisessa vaiheessa on 90% salaisesta kastikkeesta, joka tunnetaan nimellä DevOps. Jos et ole vielä kuullut tästä, DevOps on ajatus, että ohjelmistokehitys- ja tuotantotoimintojen joukkueiden tulisi yhdistyä yhteisten tavoitteiden mukaisesti.

Ehdotettuihin etuihin kuuluvat huomattavasti nopeammat julkaisut, luotettavampi koodi ja automatisoinnin vuoksi enemmän aikaa kehittämiseen. Nämä ovat kaikki suuria siunauksia, mutta ne seuraavat vahvaa viestintäprosessia. Automaatio seuraa, ei korvaa yhteistyötä.

Toteutus ja testaus

Nyt joukkue kirjoittaa koodin. Tee yhteistyötä toteutustiimisi kanssa suunnitellaksesi prosessi työn jakamiseksi keskenään. Ei ole yhdenmukaista kaikille -lähestymistapaa, ja tässä johdon ”pehmeät taidot” ovat dramaattisesti suurempia kuin kaikki tekniset taidot.

Jotkut kehittäjät haluavat liittää kaikki “mielenkiintoiset” työt ja jättää huijaamattomat työt huomiotta. He saattavat uskoa olevansa viisain henkilö huoneessa ja heidän pitäisi saada valintansa tehtävistä. Toiset saattavat vastustaa muutosta ja haluavat tehdä vain samanlaista työtä kuin aiemmin.

Johda joukkueesi tasapuoliseen työnjakoon. Haasta kaikkia kasvamaan asianmukaisesti ja jakamaan ja tekemään yhteistyötä.

Yksi toteutuksen tekninen näkökohta on, että koodin on sisällettävä riittävä määrä automatisoituja testejä. Nämä ovat koodimääritelmiä, jotka testijärjestelmä voi suorittaa.

Jos koodi kaatuu, etkö halua näiden kavereiden jatkavan olevan linjalla oman sijasta? (julkinen: Yhdysvaltain hallituksen kuva)

Manuaaliset ”testiskriptit”, joissa ihminen on vuorovaikutuksessa koodin kanssa nähdäkseen, toimiiko se riittämättömästi ja heijastavatko teknistä velkaa. Teknisen ryhmäsi tulisi ainakin sisällyttää yksikkötestejä. Testilähtöinen kehitys on suosittu tapa varmistaa, että kriittinen koodi testataan aina.

Voit käydä ei-teknistä keskustelua joukkueesi kanssa heidän ”testialueesta” (koodattu osa koodista). Se on melko yksinkertaista: pyydä heitä luettelemaan oletuksensa. Kysy sitten missä ja miten he testaavat nämä oletukset.

Tarkastuspisteeseen, jossa kehittäjät uskovat koodin olevan täydellinen, viitataan kaupassa myymälöksi dev-complete. Se tarkoittaa, että ensisijainen kehitysprosessi on ohi, mutta lisäkoodia voidaan kirjoittaa tarkistusprosessissa esiin nousevien ongelmien ratkaisemiseksi.

Ketterässä kehitysprosessissa jaat tyypillisesti toteutusprosessin useisiin tarkistuspisteisiin yhden kokonaan tai ei-mitään-määräajan sijasta. Näitä kutsutaan tyypillisesti iteraatioiksi.

Katso ensimmäisessä vaiheessa määrittämäsi etenemissuunnitelma. Varmista ennen uusien komponenttien käynnistämistä, että jo aloittamasi on ainakin valmis. Tämä antaa sinulle tarkan kuvan kehityksen nopeudesta ja vähentää riskiä.

Kun suoritat iteraatiot, voit viedä koodin ympäristöön "hyväksymistestausta" varten. Tähän liittyy pilotti- tai testikäyttäjät (tai tätä roolia pelaava sisäinen joukkue), jotka ovat vuorovaikutuksessa osatuotteen kanssa. He testaavat varmistaakseen, että se täyttää suunnittelun odotukset, ja antavat palautetta siitä, kuinka se voisi olla parempi.

Hyväksyntätestaus ei korvaa aiemmin mainittua yksikkötestausta. Se palvelee eri tarkoitusta. Antamalla kehitysryhmällesi nojautua hyväksyntätestaamiseen saadakseen perustoiminnalliset virheet on resepti katastrofille.

Hyväksyntätestajien palaute voidaan sisällyttää seuraavaan iteraatioon. Tämä on toinen hyvä syy olla purentamatta iso tuotepala kerralla. Haluat jättää tilaa muuttaa kurssia, kun ihmiset alkavat leikkiä tuotteella.

Kun olet kerännyt tarpeeksi testattua koodia riittävän tuotteen julkaisun muodostamiseksi, olet valmis aloittamaan julkaisunhallintaprosessin.

Etsitkö vikoja kaikista oikeista paikoista

Virheen on oltava täällä jossain… (lähde)

Kehittäjäsi tai tiimisi on saavuttanut pisteen, jossa heidän mielestään koodi on tehty. Hyväksyntätestaajat ovat tyytyväisiä tuotteen toimintaan. Seuraava prosessin tarkistuskohta on vahvistaa usko siihen, että sinulla on koodi valmis tulemaan tuotteeksi. Aloitetaan koodin tarkistaminen!

Et ehkä ole mukava tai sinulla ei ole riittävää teknistä tietotaitoa tarkistaa ryhmän koodi itse. Se on okei! Sinun ei tarvitse. Prosessisi on.

Työskentele ryhmäsi kanssa tunnistaakseen prosessin koodin tarkistamiseksi, joka toimii heidän puolestaan. Jos sinulla on useita kehittäjiä, vertaisarviointi toimii hyvin. Jos et, niin onko organisaatiossasi muita kehittäjiä ryhmäsi ulkopuolella? Työskentele joukkueen rajojen yli vertaiskoodien tarkistusohjelman perustamiseksi.

Jos todella on vain yksi kehittäjä, istu heidän kanssaan ja pyydä heitä opastamaan sinua koodin läpi. Käytä kaavioita vertailupisteenä ja pyydä heitä kertomaan, kuinka koodi saavuttaa kaavion tavoitteet.

Kooditarkastusprosessin päätyttyä kehittäjän ja tarkistajien tulee tuntea olonsa mukavaksi pitääkseen vastuussa koodista.

Kooditarkistus on myös hyvä aika tarkistaa kaksi muuta kriittistä kohtaa: dokumentointi ja tietoturva.

Olen jo kirjoittanut kestävästä dokumentaatioarkkitehtuurista - tarkista, jos olet kiinnostunut!

Turvallisuustarkistuksen tulisi olla osa kaikkea koodin tarkistusta. Yleensä tämä tarkoittaa koodin toista katsomista heikkouksien havaitsemiseksi, kun hyökkääjä voisi hyödyntää sitä paljastaakseen yksityisiä tietoja tai saadakseen hallintaan palvelimen. Se on tehtävä teknisen henkilön toimesta.

Open Web Application Security Project (OWASP) julkaisee ilmaisen kattava oppaan tietoturvakatsaukseen.

Kehittäjäsi voi tehdä tämän, jos he ovat ainoat joukkueessa, vaikka he vain käyttäisivät automatisoitua suojakoodianalyysityökalua. Tämän prosessin auttamiseksi on ilmaisia ​​työkaluja, jotka on linkitetty OWASP-wikin kautta.

Poista, poista, poista!

Koodi on läpäissyt tarkistusprosessin. Se on valmis tulemaan tuotteeksi. Mutta se ei tarkoita, että se on valmis tuotantoon.

Viimeinen tyhjennettävä tarkistuskohta on käyttöönottovalmius. Onko koodisi tilassa, jossa se on helppo ottaa käyttöön tuotannossa? Tämän tulisi sisältää mahdollisimman harvat manuaaliset vaiheet.

Se tarkoittaa myös, että sinulla on oltava suunnitelma muutoksen palauttamiseksi, jos koodi ei toimi suunnitelmien mukaan. Tätä kutsutaan ”palautussuunnitelmaksi”.

Kaikki tuotekoodit eivät ole tuotannossa… (lähde)

Jos sinulla on erillinen ohjelmistotoimintoryhmä, he tulevat takaisin kuvaan. Heidän tulisi tarkistaa käyttöönottoa ja palauttamista koskevat asiakirjat ja kertoa sinulle, riittääkö se.

Jos sinulla ei ole näitä henkilöitä, voit suorittaa tämän vaiheen itse. Varmista, että tuotteen käyttöönottoon on selkeät ja yksinkertaiset ohjeet. Manuaalisia vaiheita tulisi olla hyvin vähän, koska jokainen manuaalinen vaihe antaa mahdollisuuden inhimillisiin virheisiin.

Jos käyttöönotto ei onnistu, pitäisi olla selkeä ja riittävä suunnitelma palata entiseen tilanteeseen. Tämä voi olla yhtä helppoa kuin varmuuskopion palauttaminen tai se voi edellyttää asiakasviestintää tai tietojen muuntamista.

Suunnitelman riittävyys riippuu siitä, kuinka perusteellisesti ryhmäsi testasi koodia ja kuinka laajasti tuotetta julkaistaan. Harkitse myös kaikkia tuotteeseen tai kyseiseen julkaisuun liittyviä riskejä.

Kun olet ohittanut tämän tarkistuspisteen, työnnä tämä koodi tuotantoon!

Levittämisen jälkeen

Onnistuminen tai epäonnistuminen, on tärkeää kiertää taaksepäin ja tarkastella prosessin kulkua.

Arvioiko ryhmäsi tarkasti tuotteen vapauttamiseen tarvittavat ponnistelut? Suunnitteliko testaus riittävästi tuotantosuunnitelmaa? Käy uudelleen käyttöönoton ja testauksen tarkistuspisteissä ja tarkista, kuinka hyvin ryhmä toimi.

Kuinka tuote toimii tuotannossa? On hyvä idea käydä operaation henkilökunnassa ja saada heidän palautetta. Tämä luo edelleen luottamusta kehitys- ja operaatioryhmien välille ja johtaa enemmän DevOps-etuja tiellä.

Missä tuotteessasi on jäljellä olevia aukkoja? Jos ne ovat kolmannen osapuolen koodeja, nyt on aika pohtia, mukautetaanko paketit vai otetaanko ne uudelleen käyttöön tyhjästä. Muutoin sinulla on nyt tietoja siitä, mitä rakennetaan seuraavalle julkaisulle.

Ennen kaikkea pidä itsesi ja joukkueesi vastuussa ponnisteluidesi tuloksista.

Vastuullisuus helpottaa itsenäisyyttä ja edistää yksilön kasvua. Kun ryhmäsi tottuu siihen, että sen pidetään vastuussa kaikista tämän prosessin vaiheista, he mukauttavat suoritustaan ​​vastaavasti.

johtopäätös

Sinun ei tarvitse olla vähiten tekninen johtamaan onnistunutta ohjelmistojen julkaisuprosessia. Tekninen taito voi auttaa, mutta siitä voi tulla myös kainalosauvo.

Avain onnistuneeseen ohjelmistojen julkaisuun on hyvin dokumentoitu, ymmärretty prosessi ohjelmistojen siirtämiseksi putkilinjan läpi ideasta tuotteeseen. Sinulla on nyt lähtökohta oman ohjelmistojulkaisuprosessin luonnokselle.

Tärkeintä on, että osallistut tiimisi kanssa tyhjien lomakkeiden täyttämiseen ja toistettavan prosessin luomiseen, joka toimii kaikille.

Sen ei tarvitse olla täydellinen kenellekään, mutta kaikkien on ymmärrettävä se.

Sinun on myös varmistettava, että tuotteesi nopeus näiden tarkistuspisteiden kautta vastaa tuotteen kysyntää. Yhdenkään näistä esineistä ei tarvitse olla monen päivän show-tulpat. Se voi olla yksinkertainen yhden sivun tarkistuslista. Sinun on määritettävä ympäristöllesi sopiva prosessi.

Kuten kaikissa prosesseissa, sinun pitäisi myös iteroida. Aivan kuten koodilla, ensimmäinen testaama luonnos ei todennäköisesti ole täydellinen. Viritä prosessi jokaisella läpiostolla ja saat lopputuloksen sujuvasta, ennustettavasta ohjelmiston julkaisupolusta.

Ja muista harjata hiuksesi. Et halua sen näyttävän ... terävältä.

Jos pidit tästä artikkelista ja haluat lukea lisää siitä, ota meihin yhteyttä! Jos haluat tietää enemmän yrityksen sovelluskehitysprosesseista, vastaa alla. Olen iloinen voidessani kertoa oppimani ryhmäni matkalla!

Saatat myös nauttia muista artikkeleistani ohjelmistokehityksen liiketoimintaprosessista:

  • Mitä puuttuu ohittamalla tarkistusluettelo
  • Kuinka organisoimme itsemme ammattimaisemmaksi kehittämismyymäläksi, kun menetimme yksinäisen susi-gurun

Jonathan on UCLA: n tutkimuksen tietojärjestelmien osaston arkkitehtuurin ja toiminnan apulaisjohtaja. Hän on saanut fysiikan tutkinnon Stanfordin yliopistosta. Hän on sittemmin työskennellyt yli 10 vuotta tietojärjestelmien arkkitehtuurin, tietopohjaisen liiketoimintaprosessien parantamisen ja organisaation johtamisen parissa.