Eduka tarkvara arendamise protsessi käivitamine

Traditsiooniline tootearendus toimub üldiselt ühel “õigel” viisil, muutes selle ennustatavuse ja reprodutseerimise hõlpsaks. Tarkvaraarendusprotsess ei ole siiski täppisteadus, kus on vaid üks õige viis asjade tegemiseks. Tarkvaraarendusprotsess sarnaneb palju kunstiga, kus oma toote loomiseks on mitu erinevat lähenemisviisi.

Kosmose mittetehnilistel liidritel pole tarkvaraarendajate seas head mainet. Kuid näete, edukate tarkvaraväljaannete käivitamise võti on täiesti mittetehniline. Asi on protsessis. See pole vajalik, kuid teatavad arendusprotsessi osad saavad kasu tehnilisest oskusteabest. Tarkvara edukas tootmisesse laskmine pole vähem ainult koodi või disaini küsimus ja pigem robustse protsessiarhitektuuri küsimus. Täna räägime toote saamisest ideest tootmiseni.

Väärtuspõhine avaldus

Enne alustamist veenduge, et teie väärtuspõhine avaldus näeb välja järgmine:

Teie toode on: selgitage, mis teie toode on.

See aitab: kes on teie sihtrühm?

Lahendage: milliseid probleeme teie sihtrühmal on, mida see toode lahendab?

Autor: Kuidas teie toode seda lahendab?

With: Mis on teie salajane kaste?

Kui töötate põhimõtteliselt oma ettevõtte jaoks lihtsat lisandmoodulit, võib osa sellest olla liiga suur. Kuid kui proovite midagi uut, võib see aidata teil keskenduda.

Teekaart

Nende koodi saamiseks peab teie meeskond koostama selge teekaardi. See peab sisaldama skeemide komplekti, millest igaüks täidab eraldi eesmärki. Üksikute rakenduste jaoks on need skeemid erinevad. Rakenduse arhitektuuriskeem, kasutajaliidese makett ja äriprotsesside mudel on tavalised. Tehniline ekspertiis võimaldab teil nende skeemide abil paremini meeskonna arhitektuuri hinnata ja veenduda, et meeskond on õigel teel. Need skeemid on olulised isegi tehnilistele oskustele vaatamata. Toote valmimisel võite nende abistamiseks produktiivseid vestlusi suunata. Nii ei pea te arendusmeeskonnast kõige paremini arvama, kui protsent on täielik. Et teada saada, kui lähedal on toode valmimiseni, saate diagrammil jälgida iga üksuse olekut. Ja selle põhjal, kui kiiresti meeskond eelnevad komponendid komplekteeris, saate tuleviku kiirust prognoosida.

Olge dokumenteerimisel tähelepanelik

Protsesside dokumenteerimine on meetod teie meeskonna käitumise skriptimiseks uuel viisil. Eriti kui olete jaotatud meeskond, on oluline, et oleks olemas koht, kus teie meeskond leiaks vajaliku, ilma et oleks vaja oodata, et teised eri ajavööndites olevad liikmed veebi jõuaksid ja nende küsimustele vastaksid. Samuti on vales koguses arenduseelset dokumentatsiooni, mitte ühtegi, kuid pole õiget summat. Mõelge välja, mis koos teie meeskonnaga toimiva teekaardi moodustab, enne kui nad istuvad koodiks. Teie arendusprotsessis on esimene kontrollpunkt see dokumentatsioon üle vaadata ja veenduda, et nad on selle lepingu täitnud.

Te ei pea ratast leiutama

Peate veenduma, et teie meeskond on keskendunud sellele, mida nad tegelikult vajavad ülesehitamiseks. Alustage juba olemasolevate toodete peamiste eristajate määratlemisega. Selle eristamise toetamiseks tuleb kulutada suurem osa teie meeskonna pingutustest ja ajast.

Skeemid peaksid siin abiks olema. Kas teie taotlus sisaldab registreerumist ja sisselogimist? Raie komponent? Asi on selles, et teie meeskond kasutaks juba olemasolevat igal võimalusel. Seejärel saate kõik tellingud kiiresti oma kohale, et saaksite oma toodet testida. Seejärel korrake läbi kõik, ilma et peaksite viivitama tootmisvalmidusega, muutke kõike, mis aitab teie toodet veelgi eristada.

DevOps

Järgmine kontrollpunkt on teada saada, millist osa nad plaanivad nullist üles ehitada, kui olete kavandatud arhitektuuri üle vaadanud. Seejärel määrake kindlaks eelvalmistatud tehnoloogiad, millega töötate, ja uurige neid koos tootmise tugirühmaga.

Järgmine kontrollpunkt on operatsioonideks valmisolek. Tohutu osa salajast kastmest, mida DevOps nimetab, hoolitseb selle eest, et tootmise tugimeeskond oleks varakult silmuses. DevOps on veendumus, kus tootmisoperatsioonide meeskonnad ja tarkvaraarendus töötavad koos ühiste eesmärkide nimel. Eeliste hulka kuulub usaldusväärne kood, kiiremad väljalasked ja automatiseerimise tõttu rohkem aega arendamiseks. Need eelised on kõik suurepärased, kuid need on tugeva suhtlusprotsessi tulemus. Pidage meeles, et automatiseerimine on koostöö.

Rakendamine ja testimine

Juhtimisest nõutavad pehmed oskused varjutavad kõik tehnilised oskused täielikult. Tehke oma rakendusmeeskonnaga koostööd, et töötada välja protsess, mille alusel omavahel tööd jagada. Alati leidub hunnik arendajaid, kes soovivad kõik huvitavad tööd läbi töötada ja eiravad ühtegi pukseerimistööd. Nad võivad väita, et nad on kõige targemad inimesed ja peaksid seetõttu endale ülesanded valima. Mõni teine ​​oleks muutustele vastu ja jääks ainult sama töö juurde, mida nad on varem teinud. Töö õiglane jaotamine on see, millesse peaksite püüdma oma meeskonna kaasata. Lükake kõiki kasvama vastavalt ning tegema koostööd ja jagama.

Iteratiivne kohaletoimetamine

Tavaliselt jagate agiilses arendusprotsessis rakendusprotsessi mitte ühe tähtajana, vaid mitmesse kontrollpunkti. Neid nimetatakse iteratsioonideks. Vaadake teie määratletud teekaarti. Ja enne uute komponentide alustamist veenduge, et olete alustanud vähemalt täielikult valmis. See vähendab riski ja annab teile täpse pildi arengu kiirusest.

Kui iteratsioonid lõpule viia, lükake kood aktsepteerimistestide keskkonda. See hõlmab katse- või pilootkasutajaid, kes suhtlevad osalise tootega. Nad testivad, et veenduda, kas see vastab kujundus ootustele, ja annavad tagasisidet selle kohta, kuidas see võiks parem olla. Kuid aktsepteerimise testimine ei asenda ühiku testimist. Ja olete valmis alustama väljalaskehaldusprotsessi, kui olete kogunud piisavalt testitud koodi toote piisava väljalaske jaoks.

Koodi ülevaade

Nüüd on teie meeskond veendunud, et kood on tehtud ja vastuvõtmise testijad on kindlad, et toode töötab nii nagu peaks. Järgmine kontrollpunkt on veendumuse kinnitamine, et teie kood on tooteks valmis. Teil ei pruugi olla meeskonna koodi ise üle vaadata, kui teil pole tehnilisi teadmisi ja see on korras. Te ei pea seda tegema. Teie protsess peaks. Töötage koos oma meeskonnaga välja koodi ülevaatamise protsess, mis nende jaoks sobib. Luuakse vastastikuse koodi ülevaatamise programm, töötades üle meeskonna piiride. Kasutades oma skeemid võrdluspunktina, paluge neil selgitada, kuidas kood skeemis esitatud eesmärke täidab. Koodi ülevaatamisprotsessi lõpuks peavad ülevaatajad ja arendaja tundma, et nad on koodi eest vastutavad.

See koodide ülevaade on ka ideaalne aeg turvalisuse ja dokumentatsiooni ülevaatamiseks. Turvaülevaade peab leidma koha kõigis koodide ülevaatustes. Üldiselt hõlmab see koodi veelkord vaatamist, et tuvastada nõrgad alad, kus häkker võiks serveri üle kontrolli saada või kasutada seda privaatsete andmete avaldamiseks. Teie arendaja saab selle eest hoolitseda, isegi kui nad lihtsalt töötavad automatiseeritud turvakoodide analüüsi tööriistaga.

Viimane kontrollpunkt

Kood on ülevaatusprotsessi läbinud. See on valmis tooteks. Kuid see ei pruugi ikkagi tootmiseks valmis olla. Peate tühjendama viimase kontrollpunkti, kasutuselevõtuvalmiduse. Kas teie koodi on tootmises lihtne kasutada? See peab sisaldama võimalikult vähe manuaalseid samme. Ja kui kood ei tööta, peab teil olema plaan naasta muudatuste juurde nagu plaanitud või tagasipöördumisplaan. Teie operatsioonide meeskond peaks tutvuma juurutamise ja tagasivõtmise dokumentidega ning andma teada, kas sellest piisab. Selle sammu saate ise teha. Kuid veenduge, et toote juurutamise juhised oleksid selged ja lihtsad. Manuaalseid samme peaks olema väga vähe, kuna iga manuaalne samm loob võimaluse inimlikeks eksimusteks. Kui olete selle kontrollpunkti ületanud, lükake see kood tootmisele.

Pärast vabastamist

Oluline on ring tagasi vaadata ja üle vaadata, kuidas protsess läks, kui olete juba lõpule jõudnud, olgu see siis õnnestumine või ebaõnnestumine. Kas testimine modelleeris tootmisstsenaariumi õigesti? Kas teie meeskond hindas toote vabastamiseks vajalikke jõupingutusi õigesti? Vaadake üle rakendamis- ja kontrollpunktide kontrollimine, kui hästi meeskond toimis. Kuidas toode tootmises töötab? Võib-olla külastage operatsioonide meeskonda ja koguge nende tagasisidet. See loob usalduse kahe meeskonna vahel, mis toob DevOpsile kaasa rohkem eeliseid. Ennekõike veenduge, et hoiate ennast ja oma meeskonda vastutavana. Teie meeskond kohandab vastavalt oma jõudlust, kuna nad harjuvad selle protsessi iga sammu eest vastutama.

Järeldus

Edukas tarkvaraväljaanne hõlmab hästi mõistetavat ja dokumenteeritud protsessi tarkvara teisaldamiseks torujuhtme kaudu ideest tooteni. Selleks ei vaja te ulatuslikku tehnilist oskusteavet. Sageli võivad tehnilised teadmised olla kargud.

Aukude ühendamisel ja kõigi teie jaoks korratava korra loomisel veenduge, et suhtlete oma meeskonnaga. See ei pea olema täiuslik kõigile asjaosalistele, kuid seda peavad mõistma kõik. Samuti veenduge, et toote nõudlus vastab kontrollpunktides teie toote kiirusele. Ja nagu iga protsessi puhul, korrake. Nii nagu kood, ei pruugi teie esimene testimata mustand olla täiuslik. Reguleerige protsessi igal läbimisel ja saate lõpuks etteaimatava, sujuva tarkvara vabastamise tee.

Algselt avaldati toote Insightsi ajaveebis ettevõttelt CognitiveClouds: Top SaaS arendusettevõte

See lugu on avaldatud keskmises suurimas ettevõtlusväljaandes The Startup, mida jälgib 295 232 inimest.

Liituge, et saada meie parimaid lugusid siit.