Jako front-end vývojář pracuji asi dva roky a podílel jsem se na tvorbě široké škály projektů. Jednou z lekcí, které jsem se naučil, je, že spolupráce mezi různými týmy vývojářů, kteří sdílejí stejný cíl, ale mají různé úkoly a odpovědnosti, není jednoduchá.
Po konzultaci s ostatními členy týmu, designéry a vývojáři jsem vytvořil cyklus tvorby webu určený pro malé týmy (5-15 lidí). Zahrnuje nástroje jako Confluence, Jira, Airtable a Abstract. V tomto článku se podělím o funkce organizace pracovního postupu.
Skillbox doporučuje: Dvouletý praktický kurz .
Připomínáme: pro všechny čtenáře "Habr" - sleva 10 000 rublů při zápisu do jakéhokoli kurzu Skillbox pomocí propagačního kódu "Habr".
Proč je to všechno potřeba?
Minimální tým potřebný k vytvoření webu od nuly je designér, programátor a projektový manažer. V mém případě tým vznikl. Po vydání pár stránek jsem ale nabyl pocitu, že je s tím něco špatně. Někdy jsme jednoduše plně nerozuměli svým povinnostem a komunikace s klientem zůstala velmi nenaplněná. To vše zpomalovalo proces a všechny znepokojovalo.
Začal jsem pracovat na vyřešení problému.
Vyhledávání Google poskytuje dobré výsledky ohledně našeho problému.
Aby byla práce více vizuální, vytvořil jsem diagram pracovního postupu, který poskytuje pochopení toho, jak se zde pracuje.
Kliknutím na obrázek se otevře v plném rozlišení.
Cíle a cíle
Jednou z prvních technik, kterou jsem se rozhodl otestovat, byl „kaskádový model“ (Vodopád). Používal jsem to, abych upozornil na problémy a pochopil, jak je řešit.
Problém: Klient nejčastěji nevyhodnocuje proces tvorby webu modulárně, jak to dělají vývojáři. Vnímá to jako běžný web, to znamená, že přemýšlí z hlediska jednotlivých stránek. Podle jeho názoru designéři a programátoři vytvářejí jednotlivé stránky, jednu po druhé. Výsledkem je, že zákazník jednoduše nerozumí tomu, co následuje během samotného procesu.
Úkol: Nemá smysl klienta přesvědčovat o opaku, nejlepší možností je vyvinout modulární proces tvorby webu v rámci firmy na základě modelu stránka po stránce.
Univerzální designové tokeny a komponenty jsou spravovány jak vývojáři, tak designéry.
Problém: Toto je běžná situace, kterou řeší mnoho strategií. Existuje mnoho zajímavých řešení, ve většině případů se navrhuje vytvořit návrhový systém, který je řízen generátory stylů / knihoven. Ale v naší situaci přidání další komponenty do procesu vývoje, která by nám umožnila spravovat úrovně přístupu pro designéry, prostě nebylo možné.
Úkol: vybudovat univerzální systém, ve kterém mohou designéři, vývojáři a manažeři pracovat synchronně, aniž by se navzájem rušili.
Přesné sledování vývoje
Problém: I když je k dispozici mnoho užitečných nástrojů pro sledování problémů a měření celkového pokroku, většina z nich není flexibilní nebo optimální. Tento nástroj může být užitečný tím, že týmu ušetří čas, který by normálně strávil otázkami a vysvětlováním konkrétních úkolů. Usnadňuje také život manažerům tím, že jim poskytuje přesnější pochopení celého projektu.
Úkol: vytvořte řídicí panel pro sledování průběhu úkolů prováděných různými členy týmu.
Sada nářadí
Po experimentování s různými nástroji jsem se rozhodl pro následující sadu: Confluence, Jira, Airtable a Abstract. Níže odhalím výhody každého z nich.
Soutok
Role nástroje: informační a zdrojové centrum.
Pracovní prostor Confluence se poměrně snadno nastavuje, má spoustu funkcí, integraci s různými aplikacemi a má individuální přizpůsobitelné šablony. Není to univerzální řešení, ale je ideální jako informační a zdrojové centrum. To znamená, že do databáze musí být vložen jakýkoli odkaz nebo technický detail související s projektem.
Nástroj vám umožní řádně zdokumentovat každou komponentu a jakékoli další podrobnosti o projektu.
Hlavní výhodou Confluence je přizpůsobení šablon dokumentů. Kromě toho jej lze použít k implementaci jednotného úložiště specifikací a různé projektové dokumentace, oddělující úrovně přístupu účastníků. Nyní se nemusíte bát, že máte po ruce starou verzi specifikace, jako se to stává při zasílání dokumentů e-mailem.
Další informace o nástroji .
Jira
Role nástroje: monitorování problémů a správa úkolů.
Jira je velmi výkonný nástroj pro plánování a řízení projektů. Hlavní částí funkcionality je vytváření přizpůsobitelných pracovních postupů. Abychom mohli efektivně řídit problémy (což je to, co potřebujeme), stojí za to věnovat zvláštní pozornost správnému použití typu požadavku a typu problému (typu problému).
Aby se tedy vývojáři ujistili, že sestavují komponenty na základě správného návrhu, je třeba je upozornit pokaždé, když se v návrhu něco změní. Jakmile je komponenta aktualizována, musí návrhář otevřít problém, přiřadit odpovědného vývojáře a přiřadit mu správný typ problému.
S Jirou si můžete být jisti, že naprosto všichni účastníci procesu (připomínám, v našem případě je jich 5–15) dostávají správné úkoly, které se neztratí a najdou svého vykonavatele.
Další informace o Jira .
Vzduch
Role nástroje: správa komponent a deska postupu.
Airtable je směs tabulek a databází. To vše umožňuje přizpůsobit fungování všech výše diskutovaných nástrojů.
Příklad 1: Správa komponent
Pokud jde o generátor stylů, není vždy vhodné jej používat – problém je v tom, že jej návrháři nemohou upravovat. Kromě toho by nebylo dobré použít knihovnu komponent Sketch, protože má mnoho omezení. Tuto knihovnu s největší pravděpodobností nebudete moci používat mimo program.
Airtable také není dokonalý, ale je lepší než mnoho jiných podobných řešení. Zde je ukázka šablony tabulky správy komponent:
Když vývojář přijme komponentu návrhu, vyhodnotí výsledný ABEM zaznamenáním komponenty do tabulky. Celkem je 9 sloupců:
- Název - název součásti podle principu ABEM.
- Náhled – Zde je umístěn buď snímek obrazovky nebo obrázek komponenty stažené z jiného zdroje.
- Odkazovaná stránka je odkaz na stránku komponenty.
- Podřízená komponenta – odkaz na podřízené komponenty.
- Modifikátor - kontroluje přítomnost možností stylu a definuje je (například aktivní, červený atd.).
- Kategorie komponent je obecná kategorie (text, propagační obrázek, postranní panel).
- Stav vývoje - skutečný průběh vývoje a jeho definice (dokončeno, probíhá atd.).
- Odpovědný – vývojář, který je za tuto komponentu zodpovědný.
- Atomová úroveň je atomová kategorie této složky (podle konceptu atomového designu).
- Data lze odkazovat ve stejné nebo v různých tabulkách. Spojením bodů zabráníte zmatkům při škálování. Data lze navíc bez problémů filtrovat, třídit a měnit.
Příklad 2: Průběh vývoje stránky
Chcete-li vyhodnotit postup vývoje stránky, potřebujete šablonu, která je vytvořena speciálně pro tento účel. Stůl může sloužit jak potřebám samotného týmu, tak i klienta.
Veškeré informace o stránce lze označit zde. Toto je termín, odkaz na prototyp InVision, cíl, podřízená komponenta. Okamžitě je patrné, že operace je velmi pohodlné provádět, a to jak s ohledem na dokumentaci a aktualizaci návrhu, tak i na stav vývoje front-endu a back-endu. Navíc se tyto operace provádějí současně.
Abstraktní
Role nástroje: jediný zdroj správy verzí pro návrhové prostředky.
Abstrakt lze nazvat GitHub pro aktiva ve Sketchu a šetří návrhářům nutnost kopírovat a vkládat soubory. Hlavní výhodou tohoto nástroje je, že poskytuje úložiště návrhů, které funguje jako „jediný zdroj pravdy“. Návrháři musí aktualizovat hlavní větev na nejnovější verzi schváleného rozvržení. Poté musí informovat vývojáře. Ti by zase měli pracovat pouze s návrhářskými aktivy z hlavní pobočky.
Jako závěr
Poté, co jsme implementovali nový vývojový proces a všechny výše zmíněné nástroje, rychlost naší práce vzrostla minimálně dvojnásobně. Není to dokonalé řešení, ale je to velmi dobré. Je pravda, že aby to fungovalo, musíte vynaložit velké úsilí - vyžaduje to „ruční práci“, abyste vše aktualizovali a udržovali v provozuschopném stavu.
Skillbox doporučuje:
- Praktický kurz .
- Online kurz .
- Praktický roční kurz .
Zdroj: www.habr.com