Jobb webfejlesztési munkafolyamat: összefolyás, levegőztetés és még sok más

Közel két évig front-end fejlesztőként dolgoztam, hasznos tapasztalatokat szereztem a design / digitális ügynökségek számos webfejlesztési projektjének részeként.

Az egyik nyilvánvaló, de értékes tanulság, amit megtanultam, hogy az egyes csoportok közötti együttműködés egyetlen céllal, de külön felelősséggel és célokkal nem könnyű. Különböző szempontok és nehézségi szintek vannak az együttműködés szempontjából, és amelynek konkrét részével itt szeretnék foglalkozni, az a munkafolyamat.

Tapasztalataim alapján, valamint a tervező és a fejlesztő barátaim segítségével felépítettem egy kis csapat (5–15 fő) számára kifejlesztett weboldal-fejlesztési munkafolyamatot. A rendszer Confluence, Jira, Airtable és Abstract abból áll. Ebben a cikkben megosztom a munkafolyamat miértjét és mikéntjét.

Motiváció egy új munkafolyamat kiépítésére

A testreszabott webhely kézbesítéséhez a weboldal készítőinek által biztosított sablonok használata nélkül a tehetség minimumkövetelményei közé tartozik egy tervező, fejlesztő és projektmenedzser. Miután részt vettem pár esetben, megéreztem, hogy valami baj van a munkafolyamatunkkal: a fontos információk nem mindig voltak összehangolva mind a belső szerepek között, mind pedig a kliensen kívül. Ez a nem hatékony kommunikáció egyértelműen lelassította a fejlesztési ciklust és kárt okozott a csapatnak.

Tehát elkezdtem megoldani ezt a problémát.

A Google a munkafolyamat létrehozásával és fejlesztésével kapcsolatos erőforrások után kutatott. Noha sokat tanultam a nagyszerű forrásokból, szinte egyiket sem találtam webfejlesztési projektekre egy design / digitális ügynökségnél. Vagy tervezési rendszer, vagy kódolási irányelvek terjedtek ki a tervezési vagy a front-end szerepekre, vagy egy munkafolyamat, amelyet egy csapat számára készítettek el saját termékkel.

Ennek eredményeként úgy döntöttem, hogy cserébe kiválasztom a problémáink megoldásához szükséges alkatrészeket, és testreszabott munkafolyamatot alakítottam ki a weboldal fejlesztéséhez.

Problémák és célok

Az alábbiakban bemutatom azokat a problémákat, amelyeket a meglévő munkafolyamatunk alapján ellenőriztem, és a megfelelő fejlesztési célokat:

1. Vízesés módszertana

Probléma: Tapasztalataim alapján a webhelyprojektek vízeséses megközelítést alkalmaznak, mivel az ügyfeleknek nincs koncepciójuk a minimálisan életképes termékről (MVP). Ahelyett, hogy szétválasztanák a funkcionalitást a nézetektől és a modulálástól, az ügyfelek hajlamosak hagyományos oldalanként gondolkodni a webhelyről, ami mind a tervezőket, mind a fejlesztőket arra kényszeríti, hogy egymás után dolgozzanak. Ezáltal a projekt során univerzális perspektívát veszítenek. Ez a helyzet sok oda-vissza felesleges felülvizsgálatot eredményez az oldalak között.

Cél: Az ügyfelek gondolkodásmódjának megváltoztatása arrogáns és irreális. A cél az, hogy megtaláljuk a módját a követelmények mielőbbi elkülönítésének és a lehető legmoduláltabb módon, az oldalankénti modell alapján történő belső fejlődésnek.

2. Univerzális tervezési tokenek és alkatrészek, amelyeket a tervezők és a fejlesztők is kezelnek

Probléma: Ez egy gyakori probléma, amelyre sok cikk osztott meg nagyszerű megoldásokat, amelyek többnyire egy olyan tervezési rendszer felépítését javasolják, amelyet stílusstílus- / könyvtárgenerátorok kezelnek. Bár nagyszerű megoldás, egy olyan hely kezelése, amely alig adott szerkesztési engedélyt a tervezőknek, nem volt helyénvaló.

Cél: Kivéve az univerzális tervezési tokenek és nyelvek létrehozását, amelyeket a tervezők, a fejlesztők és a menedzserek egyaránt megérthetnek, olyan rendszert kiépíteni, amely mindenki számára lehetővé teszi az eszközök szinkron módon történő kezelését.

3. Pontos, frissített haladás irányítópult

Probléma: Noha a számkövetők, a kanban és a több projektmenedzsment modell hasznos és praktikus, a legtöbbjük nem tudott egyenes, rugalmas és barátságos haladás irányítópultként működni. Ez a fajta irányítópult sok időt spórolna meg a csapatnak, mert megakadályozná a csapattagokat abban, hogy aktívan jelentést tegyenek vagy kérdezzenek a konkrét feladatok jelenlegi helyzetéről. Megkönnyíti a vezetők életét is, ha túl sok erőfeszítés nélkül világos ismeretekkel rendelkeznek az egész projektről.

Cél: Olyan irányítópult-rendszer létrehozása, amely szerkesztési engedélyt biztosít az egyes feladatokért felelős egyének számára.

Munkafolyamat-diagram

Mielőtt belevetnénk magunkat a kezelőeszközök részletes bemutatásába, vessünk egy pillantást az általam szervezett absztrakt egyszerűsített munkafolyamatra. Nagyjából csak egy normális munkafolyamat vizualizálása, amely a legtöbb ügynökségnél van, de itt két szempontot kell megjegyezni.

1. Fejlesztői értékelés

Először is, amikor az ügyféltől származó követelményeket vagy kérdéseket a menedzser jóváhagyja és dokumentálja, kivéve a feladatot egy tervezőnek, akkor egy fejlesztőhöz is eljutnak értékelésre. Ebben a folyamatban a fejlesztő áttekinti a feladat specifikációját, ellenőrizve, hogy vannak-e meglehetősen bonyolult funkciók vagy szolgáltatások. Ha pozitív, akkor a fejlesztő elkezdhet dolgozni rajta, vagy előzetesen értesítheti a tervezőt a lehetséges problémákról.

2. Az igazság egyetlen forrása

Figyelje meg azt is, hogy miután a terv megvalósítását az ügyfél jóváhagyta, és mielőtt átadná a feladatot a fejlesztő kezének, a tervező által lefolytatott regisztráció / módosítás / törlés a tervezési boltban folyamaton megy keresztül . Ennek oka, hogy a fejlesztőnek mindig csak egy, a fejlesztéshez készen tartott, folyamatosan karbantartott és frissített eszközöket tartalmazó dizájnboltnak kell kitennie.

Most belemerülhetünk az általam készített kezelőeszközökbe, és megnézhetjük, hogy az eszközök hogyan segítenek megoldani problémáinkat.

Az eszközök verem

Miután kísérletezett a piac különböző lehetőségeivel, az általam itt javasolt verem Confluence, Jira, Airtable és Abstract áll. Az alapvető bevezetésen és néhány kulcsfontosságú alkalmazási példán kívül nem térek ki az eszközök használatának minden részletére.

Megjegyzés: a rendszer feltételezi, hogy a fejlesztői csapat az atomtervezési módszertant és az ABEM elnevezési rendszert alkalmazza.

1. Összefolyás

Szerep: információs és erőforrásközpont

Noha eleinte félelmetes, a Confluence hatékony munkaterületet kínál, amelyet könnyen lehet szervezni, és rengeteg funkcióval, alkalmazások integrációjával és testreszabott sablonokkal rendelkezik. Határozottan nem univerzális megoldás minden problémára, de tökéletes a specifikációk, követelmények, találkozójegyzetek és egyebek dokumentálásához.

Ezért a Confluence ebben a veremben információ- és erőforrásközpontként működik, ami azt jelenti, hogy a projekt minden kapcsolódó hivatkozását és részletét itt kell megfelelően dokumentálni.

A Confluence kedvenc előnye a dokumentum sablonok testreszabásának képessége. Ez a szolgáltatás igazán kényelmessé teszi a munkafolyamat szabványosítását.

Példa: Komponensfunkcionalitás áttekintése

A fentiekben említettem a fejlesztői értékelési folyamatot , ami valójában bonyolult munka. Ennek oka, hogy ez a folyamat magában foglalja az összetevő alapinformációit, a fejlesztő FSM felülvizsgálatát (ha szükséges), a GYIK teret és egyebeket. A Confluence által biztosított sablon és eszközök rugalmassága azonban ezt rendkívül egyszerűvé teszi. Csak készítsen egy sablont a konfigurációs beállításokban, és máris mehet.

2. Jira

Szerep: kérdéskövetés és művelettípus-kezelés

A Jira szintén az atlassiai család tagja, és rendkívül hatékony kérdéskövető és projekttervező szoftver. A kedvenc részem a testreszabott kiadási munkafolyamatok elkészítése. Mivel rengeteg nagyszerű oktatóanyag van a Jira erejének kihasználásáról, az egyetlen dolog, amit itt szeretnék kiemelni, az alább említett probléma típus használata.

Példa: Frissítse a fejlesztőt a tervezési áruház változásaival típusok szerint

Annak biztosítása érdekében, hogy a fejlesztők a tervezési nézetek alapján építsék fel az alkatrészeket, értesítést kell kapniuk arról, ha valami frissül a tervezési áruházban, beleértve a regisztrálást, a módosítást és a törlést . Tehát, amikor egy összetevőt frissítenek, a tervezőnek ki kell nyitnia egy problémát a felelős fejlesztővel, és ki kell választania a megfelelő kérdés / művelet típust.

3. Levegő

Szerep: összetevőkezelés és haladás irányítópult

Az airtable, ami a táblázat és az adatbázis keveréke, működőképessé teszi ezt a verem. Két elképesztő funkció támogatja a munkafolyamatomat: négyféle nézetátmenet egyetlen táblázatban és a kapcsolódó tartalom összekapcsolása. Itt bemutatok két példát e két funkció használatára.

1. példa: Komponensek kezelése

Hogyan kezeli az összetevő könyvtárat? Úgy döntöttünk, hogy nem használunk stílusvezérlő-generátort, mert a szerkesztők számára nem elérhető. A Sketch komponens könyvtár használata sem volt helyénvaló, mert túl sok korlátozás van benne, ha megpróbáljuk magának a szoftvernek a körén kívül használni.

Nem mondanám, hogy az Airtable tökéletes megoldás, de ez a legegyszerűbb és legrugalmasabb megoldás, amire gondolhattam. Vessen egy pillantást az alkatrészkezelő táblázat bemutató sablonjára itt:

Miután benyújtotta a fejlesztőnek egy újonnan regisztrált tervezési nézetet, amely készen áll a fejlesztésre, az ABEM rendszer alapján megvizsgálja a nézetet, és regisztrálja a táblázatba. A táblázat 9 oszlopot tartalmaz, beleértve:

1. Név: a komponens elnevezése ABEM elvben

2. Előnézet: képernyőkép vagy az alkatrész exportált képe

3. Linkelt oldal: az oldalra mutató link tartalmazza ezt az összetevőt

4. Gyermekkomponens: a gyermekkomponensekre mutató link tartalmazza ezt

5. Módosító: ellenőrzi, hogy vannak-e stílusváltozatok (pl .: - aktív, - piros)

6. Komponens kategória: általános kategória besorolás (pl .: szöveg, hős, oldalsáv)

7. Fejlesztési állapot: a fejlesztés előrehaladásának állapota (függőben, kijelölt, folyamatban lévő, befejezett, felülvizsgálat alatt)

8. Megbízott: az alkatrészért felelős fejlesztő

9. Atomszint: ennek az összetevőnek az atomkategóriája (atom, molekula, organizmus)

A legjobb itt az, hogy hivatkozhat az adatokra ugyanabban és más táblázatokban is. A pontok ez a kapcsolata megakadályozza, hogy a dolgok egyre szebbé váljanak a méretarány növekedésével. Vegye figyelembe azt is, hogy a nézeteket egyszerűen szűrheti, rendezheti és módosíthatja.

2. példa: Oldalfejlesztési állapot

Mivel itt feltételezzük, hogy elkerülhetetlenül oldalanként értékeljük a fejlesztés előrehaladását, szükség van egy erre a célra tervezett táblasablonra. Ez a táblázat előrehaladási irányítópult lehet mindkét belső csapat számára, és egyszerre osztható meg az ügyféllel.

Az oldalra vonatkozó bármilyen információ, ideértve a határidőt, az InVision prototípus linkjét, a megbízottat és a gyermek komponenseket, itt szervezhető. Vegye figyelembe, hogy nagyon kényelmes dokumentálni és frissíteni a tervezés, a kezelőfelület és a háttérfejlesztés állapotát egyszerre.

4. Kivonat

Szerep: az igazság egyetlen forrása és a tervezési eszközök verziókezelése

Az Abstract a GitHub a Sketch eszközökhöz, amely megmenti a tervezőket a fájlok másolásának és beillesztésének pokolától. Ez a cikk nem tartozik a verziókezelési folyamat kezelésének részleteinek bemutatására. A legfontosabb elvonás itt az, hogy az Abstract az a design áruház, amely az igazság egyetlen forrása . A tervezőknek folyamatosan frissíteniük kell a master ágat a megerősített tervezés legújabb verziójára, majd értesíteniük kell a fejlesztőket. Másrészt a fejlesztők csak a fő ágban lévő tervezési eszközöket vehetik referenciaként.

További elvégzendő munka

Saját tapasztalatom alapján a teljes projekt fejlesztése az új munkafolyamat elfogadása után legalább kétszer gyorsabb volt, mint korábban. Ez nem tökéletes megoldás, mert még mindig sok kézi munkát igényel a frissítés és a karbantartás.

De úgy gondolom, hogy ez hasznos hivatkozás lehet a jobb munkafolyamatot kereső weboldal-fejlesztő csapatokra, és remélhetőleg több ember is megoszthatja a munkafolyamatokat a jövőben!

? 中文版 連結 (kínai változat)  / Eredetileg a vinceshao.com oldalon tették közzé