Kövesse ezeket a legfontosabb lépéseket a sikeres szoftverfejlesztési projekt elindításához

Gyakran előfordul, hogy a projekt kezdete felkészületlenül ragadja meg. Lehet, hogy az első naptól kezdve a projekt csapatába tartozik, de az ütemterv szoros, és nincs elég idő a felkészülésre. Még rosszabb, hogy figyelmen kívül hagyhat néhány lépést, és ez később visszatérhet.

A projekt elindul, de néhány hónap múlva sötét foltba kerül. Visszatértek azok a bosszantó dolgok, amelyek miatt elkeserített a korábbi megbízások során.

Ha ez túl ismerősnek hangzik, ez a cikk az Ön számára készült. Kövesse ezeket az irányelveket a projekt indításakor, és állítsa be magát a sikerhez.

Készítsen világos kommunikációs utakat

Az első naptól kezdve győződjön meg arról, hogy a szerepek jól körülhatárolhatók és mindenki tudja, ki mit kezel. Az emberek hozzáférést kérnek a külső rendszerekhez, magyarázatot kérnek vagy vészhelyzeteket jeleznek. Bármi legyen is a forgatókönyv, győződjön meg arról, hogy a legfontosabb kapcsolattartók könnyen azonosíthatók. Tartsa ezeket az információkat jól ismert helyen, és mindenki számára hozzáférhetővé tegye.

Határozza meg a bevált módszereket és konvenciókat

Amikor a projekt elindul, ne kezdje el azonnal a kódolást. Ha így tesz, akkor a kódbázisa gyakran összekuszálódott rendetlenség lesz, amelyet senki sem akar érinteni vagy fenntartani.

Szánjon egy kis időt arra, hogy felmérje korábbi tapasztalatait, és meghatározza, mi ment jól és mi nem. Ez segít meghatározni, hogy miként akarnak történni ennek az új kezdeményezésnek. Vonja be az egész csapatot a gyakorlatba, és ügyeljen arra, hogy meghallgassa, amit mondanak.

A végeredménynek az egész csapat által érvényesített konvenciók és bevált gyakorlatok listájának kell lennie. Kövesse ezeket a konvenciókat, és sokkal jobban szervezett és koherens megoldást dolgoz ki.

Készítsen értelmes Done definíciót

Hányszor tudta meg közvetlenül a bemutató előtt, hogy nem mutathat be egy funkciót, mert valami hiányzik? Tudom, túl gyakran.

A fejlesztők hajlamosak úgy gondolni, hogy egy szolgáltatás megtörtént, ha már működik a helyi gépükön. A teljes szoftverfejlesztési ciklus azonban ennél sokkal többet foglal magában.

Lehet, hogy a szolgáltatás csak a helyi gépen működik, ezért legalább egy másik környezetben kell tesztelnie. Ezután fel kell kérnie társait, hogy vizsgálják felül a munkáját. Ez biztosítja az elfogadási kritériumok és a minőségi előírások betartását.

A következő lépés a telepítési lépések hozzáadása, hogy a funkciót a demo környezetben kiadhassa. Ezeket a lépéseket a Kész definícióban kell összefoglalnia, minden más releváns lépéssel együtt.

Ezt követően győződjön meg arról, hogy csapata a feladat elvégzése előtt ellenőrző listaként használja a Kész definíciót. Ez sokkal nagyobb önbizalmat fog biztosítani abban, hogy a megoldott jegy az, amire számítasz.

Válasszon megfelelő folyamatos integrációs rendszert

A folyamatos integráció kulcsfontosságú minden projekt számára. Biztosítani akarja, hogy az új fejlesztéseket minimális erőfeszítéssel kiadhassa. Szerencsére a lehetőségek széles választéka áll rendelkezésre a piacon, a Jenkins és a TeamCity kettő közülük. Néhány nagyon fontos tényezőt kell azonban figyelembe venni a választás során.

Az egyik a csapat preferenciája, a másik pedig az eszköz ára. Mindig bölcsebb egy olyan folyamatos integrációs eszközt használni, amelyet csapata korábban is használt. Ez azt jelenti, hogy mindenki ismeri az eszközt, és nem kell különösebb erőfeszítéseket tennie egy új rendszer elsajátítása érdekében.

Ne hagyja figyelmen kívül az árképzési tényezőt. Ha a választott eszköze drága, akkor a projekt szponzorai nem hajlandók fizetni érte. Mindannyian tudjuk, hogy ez megtörténik, de ez még nem a világ vége.

Rengeteg hatékony, folyamatos integrációs eszköz ingyenes. Szánjon időt arra, hogy tesztelje őket, és válassza ki az Ön számára legmegfelelőbbet.

Válassza ki eszközeit és alkalmazásait

Egy dolog, amelyet el akar kerülni, az, hogy túl sok különböző eszközt használ ugyanazon cél eléréséhez. Képzeljük el, hogy a csapatának ki kell dolgoznia egy REST API-t.

Az egyik kevésbé tapasztalt csapattagodnak, Johnnak segítségre van szüksége a felhasználók létrehozásának végpontjának teszteléséhez. Segítséget kér Alex-től, aki szívesen segít, amíg rájön, hogy John a SOAP UI-t használja végpontjainak tesztelésére.

Alex, a Postman nagy rajongója, néhány percet próbál megérteni az eszköz használatával, de túl sok siker nélkül. Néhány próbálkozás után feladja, ezért úgy döntenek, hogy elérik George-ot, a csapat legtapasztaltabb srácát.

George azonban old school programozó. Szereti a parancssorból mindent megtenni, ezért arra kéri Johnt, írja át az API-hívásait, hogy tesztelje őket a cURL segítségével. Ez nem ideális helyzet senkinek.

Tudjuk, hogy a fejlesztők szeretnek szabadon választani saját eszközöket, de nem mindig optimális az ilyen munka. Hosszú távon a csapat többet profitál ugyanazon eszközkészlet használatából. Próbálja meg elkerülni ezt a fajta helyzetet azáltal, hogy minden célra speciális eszközöket választ.

Ne legyen túl merev, hallgassa meg csapata preferenciáit, de egyértelműen válasszon. Ne felejtse el mindenkinek elmagyarázni, hogy ez miért fontos, és vásárolja meg társaitól. Végül is nem akarsz kontrollfreak lenni.

Használja okosan a verzióvezérlő rendszereket

A verziókezelő rendszerek elengedhetetlenek minden szoftverprojektnél. Használat nélkül nem lehet együttműködve fejleszteni a szoftveres megoldást. Nem elég azonban kiválasztani egy verziókezelő rendszert, és közölni a választással a csapatával.

Egy kis időt kell fektetnie annak meghatározásához, hogy miként szeretné használni a rendszert az új projektjéhez. Jó kiindulópont a meglévő munkafolyamatok összehasonlítása és annak eldöntése, hogy mi a legjobb a felhasználási esetekhez.

Ezután érvényesítenie kell a munkafolyamatot a csapatával. Ha a visszajelzés pozitív, akkor valószínű, hogy a verziókezelő rendszert rendeltetésszerűen használják.

Kerülje el a több dokumentumkezelő rendszert

Az egyik legfájdalmasabb dolog az, amikor meg kell találnia egy információt, és nem tudja, hol keresse. Ez általában azért történik, mert túl sok olyan hely van, ahol lehet. Nem lehet ilyen bonyolult!

Amikor a DevOps srác meg akarja találni a minőségbiztosítási szerver IP-jét, egyetlen helyre kell néznie. Ennek megvalósításához válasszon egy jó dokumentumkezelő rendszert, és ragaszkodjon hozzá.

Tartsa szervezetten, és szembesüljön mindenkivel, aki megpróbál információkat tárolni a rendszeren kívül. Hosszú távon mindenki meg fogja látni az előnyeit, még azok az emberek is, akiket kiabálnak.

Határozza meg a megoldáshoz szükséges környezeteket

Mindannyian tudjuk, hogy a fejlesztők, a tesztelők és az üzleti vállalkozások nem használhatják ugyanazt a környezetet. De ezt a szempontot általában figyelmen kívül hagyják a projekt kezdeti szakaszában.

Már korán el kell kezdenie mérlegelni, hogy milyen környezetek szükségesek a projektjeihez. A jóváhagyás megszerzése és beállításuk eltarthat egy ideig, ezért jobb, ha a lehető leghamarabb elkezdjük.

Iránymutatásként legalább négy környezettel kell rendelkeznie: fejlesztés, felhasználói elfogadás tesztelése (UAT), szakaszosítás és gyártás.

Fejlesztőkörnyezet

A fejlesztői környezet a fejlesztői csapat homokozója lesz. Ezért nem lesz mindig stabil, és számíthat az adatok következetlenségére.

Felhasználói elfogadás tesztelési környezet

Az UAT célja a felhasználók elfogadása, ezért az üzletemberek itt fogják elvégezni a tesztelésüket.

Beépítési és gyártási környezetek

Végül a rendezés és a produkció kéz a kézben jár, és tükrözniük kell egymást. Ez biztosítja, hogy az állomáson futtatott műveletek ugyanazokkal az eredményekkel járjanak a termelésben.

De mindegyik projekt más és más. Előfordulhat, hogy több környezetre lesz szüksége, mint a fenti, különben a magas költségek miatt nem lesz képes mindegyikre.

Bármi legyen is az eset, győződjön meg róla, hogy előre figyelembe veszi a rendszer helyzetét, és meghatározza, mire van szüksége a projekt megvalósításához.

Készítse elő a kódalapot és a projekt felépítését

A jól szervezett kódbázis hosszú utat fog megtenni. Korán kezdjen el néhány proaktív lépést, hogy a projektje hamarosan nagy sárgömbbé váljon.

Meg kell határoznia a projekt fő moduljait, a kódbázis felépítését, a fájlok elnevezését, a csomagolási szabályokat és így tovább.

Tedd a lehető leg intuitívabbá, hogy mindenki könnyen megtalálhassa a keresett dolgokat. Ezenkívül nézzen vissza a korábbi projektek tanulságaira, és győződjön meg arról, hogy nem ugyanazokat a hibákat ismételgeti-e.

Hozzon létre egy dokumentumot a helyi projekt beállításához

Még akkor is, ha nagyon kis csapattal indul, nagy eséllyel nem csak Ön lesz a projektben. Ha új emberek készülnek csatlakozni, akkor az életét a lehető legkönnyebbé és könnyebbé akarja tenni, és segít abban, hogy pillanatok alatt felgyorsuljanak. Ennek a helyi projekt beállításával kell kezdődnie.

Túl sok olyan esetet láttam, amikor az új srácnak egy teljes hetet kell töltenie, hogy a projekt futhasson a gépén. Ez általában akkor történik, ha a telepítési dokumentáció rosszul van megírva, hiányos vagy hiányzik.

Ennek elkerülése érdekében kezdjen egy olyan dokumentummal, amely meghatározza a projekt beállításához szükséges összes lépést. Ezután győződjön meg róla, hogy egyedül teszteli és finomítja.

Ezután kérje meg társait, hogy nézzék át a telepítés lépéseit, és vegyék figyelembe visszajelzéseiket. Végül egy tömör, könnyen követhető telepítési útmutatót készít, amely mindenkit gyorsan elindít.

Csomagolás

Még egy dolog. Ne kezelje ezt a dokumentumot úgy, ahogy kőbe van írva. Időről időre ellenőrizze, és ne felejtsen el új szükséges lépéseket beilleszteni a rendszer fejlődésével. A csapatod megköszöni ezt.

Ez néhány kulcsfontosságú dolog, amelyet megtehet a következő sikerprojekt elkészítéséhez. Mit adna hozzá ehhez a listához? Kérjük, hagyja alább a gondolatait.