Körülbelül két éve dolgozom front-end fejlesztőként, és sokféle projekt létrehozásában vettem részt. Az egyik tanulság, amit megtanultam, hogy nem könnyű az együttműködést a különböző fejlesztői csapatok között, akiknek ugyanaz a célja, de eltérőek a feladataik és felelősségei.
A többi csapattaggal, tervezőkkel és fejlesztőkkel egyeztetve készítettem egy weboldalkészítési ciklust, amelyet kis csapatoknak (5-15 fő) terveztem. Olyan eszközöket tartalmaz, mint a Confluence, Jira, Airtable és Abstract. Ebben a cikkben megosztom a munkafolyamat megszervezésének jellemzőit.
A Skillbox a következőket ajánlja: Két éves gyakorlati tanfolyam .
Emlékeztetünk: a "Habr" minden olvasója számára - 10 000 rubel kedvezmény, ha a "Habr" promóciós kóddal bármely Skillbox tanfolyamra jelentkezik.
Miért van szükség minderre?
A weboldal létrehozásához minimálisan szükséges csapat egy tervező, programozó és projektmenedzser. Az én esetemben megalakult a csapat. De néhány oldal megjelenése után az az érzésem támadt, hogy valami nincs rendben vele. Néha egyszerűen nem értettük meg teljesen a felelősségünket, és az ügyféllel való kommunikáció sok kívánnivalót hagyott maga után. Mindez lelassította a folyamatot, és mindenkit megzavart.
Elkezdtem dolgozni a probléma megoldásán.
A Google-keresés jó eredményeket ad a problémánkra.
Az elvégzett munka vizuálisabbá tétele érdekében létrehoztam egy munkafolyamat-diagramot, amely bemutatja, hogyan történik itt a munka.
A képre kattintva teljes felbontásban megnyílik.
Célok és célok
Az egyik első technika, amelyet úgy döntöttem, hogy tesztelek, a „kaszkádmodell” (Waterfall) volt. Arra használtam, hogy rávilágítsak a problémákra és megértsem, hogyan kell megoldani őket.
Probléma: A kliens leggyakrabban nem modulárisan értékeli a webhelykészítés folyamatát, ahogyan a fejlesztők teszik. Rendes oldalnak fogja fel, vagyis egyedi oldalakban gondolkodik. Véleménye szerint a tervezők és a programozók egymás után hoznak létre egyedi oldalakat. Ennek eredményeként az ügyfél egyszerűen nem érti, hogy mi következik a tényleges folyamat során.
Feladat: Nincs értelme az ügyfelet meggyőzni az ellenkezőjéről, a legjobb megoldás a cégen belüli weblapkészítés moduláris folyamatának kidolgozása oldalankénti modell alapján.
Az univerzális tervezési tokeneket és összetevőket a fejlesztők és a tervezők egyaránt kezelik.
Probléma: Ez egy gyakori helyzet, amelyet sok stratégia kezel. Számos érdekes megoldás létezik, a legtöbb esetben javasolt egy tervezési rendszer létrehozása, amelyet stílus útmutató / könyvtár generátorok vezérelnek. A mi helyzetünkben azonban egyszerűen nem volt lehetséges olyan újabb összetevő hozzáadása a fejlesztési folyamathoz, amely lehetővé tenné a tervezők hozzáférési szintjének kezelését.
Feladat: olyan univerzális rendszer felépítése, amelyben a tervezők, fejlesztők és menedzserek szinkronban, egymás zavarása nélkül dolgozhatnak.
Pontos fejlődéskövetés
Probléma: Bár számos hasznos eszköz áll rendelkezésre a problémák nyomon követésére és az általános előrehaladás mérésére, a legtöbb nem rugalmas vagy optimális. Az eszköz hasznos lehet azáltal, hogy megspórolja a csapat idejét, amelyet általában kérdésekre és konkrét feladatok pontosítására fordítanak. A menedzserek életét is megkönnyíti azáltal, hogy pontosabb megértést ad nekik az egész projektről.
Feladat: hozzon létre egy irányítópultot, amely nyomon követheti a csapat különböző tagjai által végrehajtott feladatok előrehaladását.
szerszámkészlet
Különböző eszközökkel való kísérletezés után a következő készlet mellett döntöttem: Confluence, Jira, Airtable és Abstract. Az alábbiakban bemutatom mindegyik előnyeit.
Összefolyásánál
Az eszköz szerepe: információs és forrásközpont.
A Confluence munkaterülete viszonylag könnyen beállítható, és számos funkcióval, különböző alkalmazásokkal való integrációval és egyedi, testreszabható sablonokkal rendelkezik. Ez nem egy mindenre alkalmas megoldás, de információs és forrásközpontnak ideális. Ez azt jelenti, hogy minden, a projekttel kapcsolatos referenciát vagy műszaki részletet be kell vinni az adatbázisba.
Az eszköz lehetővé teszi az egyes komponensek és a projekttel kapcsolatos egyéb részletek megfelelő dokumentálását.
A Confluence fő előnye a dokumentumsablonok testreszabása. Ezen túlmenően használható a specifikációk és a különböző projektdokumentációk egyetlen tárházának megvalósítására, elkülönítve a résztvevők hozzáférési szintjeit. Most már nem kell attól tartanod, hogy a specifikáció egy régi verziója van a kezedben, ahogy az történik, amikor e-mailben küldöd el a dokumentumokat.
További információ az eszközről .
Jira
Az eszköz szerepe: problémafigyelés és feladatkezelés.
A Jira egy nagyon hatékony projekttervezési és -menedzsment eszköz. A funkcionalitás fő része a testreszabható munkafolyamatok létrehozása. A problémák hatékony kezelése érdekében (amire szükségünk van) érdemes kiemelt figyelmet fordítani a kéréstípus és a problématípus (problématípus) helyes használatára.
Tehát annak érdekében, hogy a fejlesztők a megfelelő terv alapján építsenek alkatrészeket, minden alkalommal értesíteni kell őket, amikor valami változás történik a tervben. Amint az összetevő frissül, a tervezőnek meg kell nyitnia egy problémát, ki kell jelölnie egy felelős fejlesztőt, hozzárendelve a megfelelő problématípust.
A Jira-val biztos lehetsz abban, hogy a folyamat abszolút minden résztvevője (hadd emlékeztessem önöket, esetünkben 5-15-en vannak) megfelelő feladatokat kapnak, amelyek nem tévednek el, és megtalálják a végrehajtójukat.
Tudj meg többet Jiráról .
Airtable
Az eszköz szerepe: alkatrészkezelés és folyamattábla.
Az Airtable táblázatok és adatbázisok keveréke. Mindez lehetővé teszi az összes fent tárgyalt eszköz működésének testreszabását.
1. példa: Alkatrészkezelés
Ami a stílus útmutató generátort illeti, nem mindig kényelmes a használata - a probléma az, hogy a tervezők nem tudják szerkeszteni. Ezen túlmenően nem lenne jó döntés a Sketch komponens könyvtárat használni, mivel számos korlátja van. Valószínűleg egyszerűen nem fogja tudni használni ezt a könyvtárat a programon kívül.
Az Airtable sem tökéletes, de jobb, mint sok más hasonló megoldás. Íme a komponenskezelési táblázat demója:
Amikor a fejlesztő elfogad egy tervezési komponenst, kiértékeli az eredményül kapott ABEM-et úgy, hogy rögzíti a komponenst egy táblázatban. Összesen 9 oszlop van:
- Name - az alkatrész neve az ABEM elv szerint.
- Előnézet – Ide kerül egy képernyőkép vagy egy másik forrásból letöltött komponens képe.
- A hivatkozott oldal egy komponens oldalára mutató hivatkozás.
- Gyermekkomponens – hivatkozás a gyermekkomponensekre.
- Módosító – ellenőrzi a stílusbeállítások meglétét, és meghatározza azokat (például aktív, piros stb.).
- A komponenskategória egy általános kategória (szöveg, promóciós kép, oldalsáv).
- Fejlesztési állapot - a tényleges fejlesztési folyamat és annak meghatározása (befejezett, folyamatban, stb.).
- Felelős - az a fejlesztő, aki felelős ezért az összetevőért.
- Az atomi szint ennek a komponensnek az atomi kategóriája (az atomtervezés koncepciója szerint).
- Az adatokra ugyanabban vagy különböző táblázatokban lehet hivatkozni. A pontok összekapcsolása megakadályozza a méretezés során bekövetkező zavart. Ezen kívül az adatok gond nélkül szűrhetők, rendezhetők és módosíthatók.
2. példa: oldal fejlesztési folyamat
Az oldalfejlesztés előrehaladásának értékeléséhez szükség van egy kifejezetten erre a célra készített sablonra. Az asztal kiszolgálhatja magának a csapatnak és az ügyfélnek az igényeit is.
Az oldallal kapcsolatos bármilyen információ itt megjelölhető. Ez egy határidő, egy hivatkozás az InVision prototípusához, egy cél, egy gyermekkomponens. Azonnal észrevehető, hogy a műveletek nagyon kényelmesek, mind a tervezés dokumentálása és frissítése, mind a front-end és a back-end fejlesztés állapota tekintetében. Ezenkívül ezeket a műveleteket egyidejűleg hajtják végre.
Absztrakt
Az eszköz szerepe: a tervezési eszközök verziókezelésének egyetlen forrása.
Az absztrakt a Sketch eszközeinek GitHub-nak nevezhető, és megkíméli a tervezőket a fájlok másolásától és beillesztésétől. Az eszköz fő előnye, hogy olyan tervezési adattárat biztosít, amely „az igazság egyetlen forrásaként” működik. A tervezőknek frissíteniük kell a fő ágat a jóváhagyott elrendezés legújabb verziójára. Ezt követően értesíteniük kell a fejlesztőket. Ezek viszont csak a fő ágból származó tervezői eszközökkel működjenek.
Következtetésként
Miután bevezettük az új fejlesztési folyamatot és az összes fent említett eszközt, munkánk sebessége legalább kétszeresére nőtt. Nem tökéletes megoldás, de nagyon jó. Igaz, ahhoz, hogy működjön, sok erőfeszítést kell tennie - „kézi munkát” igényel, hogy frissítse és működőképes állapotban tartsa.
A Skillbox a következőket ajánlja:
- Gyakorlati tanfolyam .
- Online tanfolyam .
- Gyakorlati évfolyam .
Forrás: will.com