Работам како front-end програмер околу две години и учествував во креирањето на широк спектар на проекти. Една од лекциите што ги научив е дека соработката помеѓу различни тимови на програмери кои ја делат истата цел, но имаат различни задачи и одговорности не е лесна.
Во консултација со другите членови на тимот, дизајнери и програмери, создадов циклус на креирање веб-страници дизајниран за мали тимови (5-15 луѓе). Вклучува алатки како што се Confluence, Jira, Airtable и Abstract. Во оваа статија ќе ги споделам карактеристиките на организирање на работниот тек.
Skillbox препорачува: Двегодишен практичен курс .
Потсетуваме: за сите читатели на „Хабр“ - попуст од 10 рубли при запишување на кој било курс Skillbox користејќи го промотивниот код „Хабр“.
Зошто е потребно сето ова?
Минималниот тим потребен за креирање веб-страница од нула е дизајнер, програмер и проект менаџер. Во мојот случај, тимот беше формиран. Но, по објавувањето на неколку страници, добив чувство дека нешто не е во ред со тоа. Понекогаш едноставно не ги разбиравме целосно нашите обврски, а комуникацијата со клиентот оставаше многу да се посакува. Сето тоа го забави процесот и ги вознемири сите.
Почнав да работам на решавање на проблемот.
Пребарувањето на Google дава добри резултати за нашиот проблем.
Со цел да ја направам работата повизуелна, создадов дијаграм на работниот тек кој дава разбирање за тоа како се работи овде.
Кликнете на сликата за да се отвори во целосна резолуција.
Цели и цели
Една од првите техники што решив да ја тестирам беше „каскадниот модел“ (Водопад). Го користев за да истакнам проблеми и да разберам како да ги решам.
Проблем: Најчесто, клиентот не го оценува процесот на креирање веб-страница модуларно, како што прават програмерите. Тој го доживува како обичен сајт, односно размислува во однос на поединечни страници. Според него, дизајнерите и програмерите создаваат поединечни страници, една по друга. Како резултат на тоа, клиентот едноставно не разбира што следи што следи во текот на вистинскиот процес.
Задача: Нема смисла да се убеди клиентот во спротивното; најдобрата опција е да се развие модуларен процес за креирање веб-локација во компанијата врз основа на модел од страница по страница.
Универзалните дизајнерски токени и компоненти ги управуваат и развивачите и дизајнерите.
Проблем: Ова е вообичаена ситуација која многу стратегии ја решаваат. Има многу интересни решенија, во повеќето случаи се предлага да се создаде систем за дизајн кој е контролиран од генератори на стилски водич / библиотека. Но, во нашата ситуација, додавањето на друга компонента во процесот на развој што ќе ни овозможи да управуваме со нивоата на пристап за дизајнерите едноставно не беше можно.
Задача: изградба на универзален систем во кој дизајнерите, програмерите и менаџерите можат да работат синхроно без да се мешаат едни со други.
Точно следење на развојот
Проблем: Иако има многу корисни алатки достапни за следење на проблемите и мерење на целокупниот напредок, повеќето не се флексибилни или оптимални. Алатката може да биде корисна со заштеда на времето на тимот што вообичаено би се потрошило на прашања и појаснувања за конкретни задачи. Исто така, им го олеснува животот на менаџерите со тоа што им дава попрецизно разбирање на целиот проект.
Задача: креирајте контролна табла за следење на напредокот на задачите што ги извршуваат различни членови на тимот.
Комплет алатки
Откако експериментирав со различни алатки, се решив на следниот сет: Confluence, Jira, Airtable и Abstract. Подолу ќе ги откријам придобивките од секоја од нив.
сливот
Улога на алатката: информативен и ресурсен центар.
Работниот простор на Confluence е релативно лесен за поставување, има многу функции, интеграции со различни апликации и има индивидуални, приспособливи шаблони. Тоа не е едно решение за сите, но е идеално како информативен и ресурсен центар. Ова значи дека секоја референца или технички детали поврзани со проектот мора да бидат внесени во базата на податоци.
Алатката ви овозможува правилно да ја документирате секоја компонента и сите други детали за проектот.
Главната предност на Confluence е прилагодувањето на шаблоните за документи. Дополнително, може да се користи за имплементирање на единствено складиште на спецификации и разновидна проектна документација, одвојувајќи ги нивоата на пристап на учесниците. Сега не треба да се грижите дека имате стара верзија на спецификацијата при рака, како што се случува кога испраќате документи по е-пошта.
Повеќе информации за алатката .
Jira
Улога на алатката: следење на проблеми и управување со задачи.
Jira е многу моќна алатка за планирање и управување со проекти. Главниот дел од функционалноста е создавање на приспособливи работни текови. Со цел ефикасно да управуваме со проблемите (што ни е потребно), вреди да се обрне посебно внимание на правилната употреба на типот на барање и типот на прашање (тип на проблем).
Значи, за да бидете сигурни дека програмерите градат компоненти врз основа на правилен дизајн, тие треба да бидат известувани секогаш кога нешто ќе се промени во дизајнот. Штом компонентата се ажурира, дизајнерот треба да отвори проблем, да додели одговорен развивач, доделувајќи му го точниот тип на проблем.
Со Jira, можете да бидете сигурни дека апсолутно сите учесници во процесот (дозволете ми да ве потсетам, во нашиот случај има 5-15 од нив) добиваат правилни задачи кои не се губат и го наоѓаат својот извршител.
Дознајте повеќе за Jira .
Airtable
Улога на алатката: управување со компоненти и табла за напредок.
Airtable е мешавина од табели и бази на податоци. Сето ова овозможува да се прилагоди работата на сите алатки дискутирани погоре.
Пример 1: Управување со компоненти
Што се однесува до генераторот за водич за стилови, не е секогаш погодно да се користи - проблемот е што дизајнерите не можат да го уредуваат. Дополнително, не би било добра одлука да се користи библиотеката со компоненти Sketch, бидејќи има многу ограничувања. Најверојатно, едноставно нема да можете да ја користите оваа библиотека надвор од програмата.
И Airtable не е совршен, но е подобар од многу други слични решенија. Еве демо на шаблонот за табела за управување со компоненти:
Кога развивачот прифаќа дизајнерска компонента, тој го оценува добиениот ABEM со снимање на компонентата во табела. Има вкупно 9 колони:
- Име - името на компонентата според принципот ABEM.
- Преглед - тука се става или слика од екранот или слика на компонентата преземена од друг извор.
- Поврзана страница е врска до страницата на компонентата.
- Детска компонента - врска до детски компоненти.
- Модификатор - проверува присуство на опции за стилови и ги дефинира (на пример, активни, црвени, итн.).
- Категоријата на компоненти е општа категорија (текст, промотивна слика, странична лента).
- Развојен статус - вистинскиот развој на напредокот и неговата дефиниција (завршен, во тек, итн.).
- Одговорен - развивачот кој е одговорен за оваа компонента.
- Атомско ниво е атомска категорија на оваа компонента (според концептот на атомски дизајн).
- Податоците може да се референцираат во исти или во различни табели. Поврзувањето на точките ќе спречи забуна при скалирање. Покрај тоа, податоците може да се филтрираат, сортираат и менуваат без никакви проблеми.
Пример 2: напредок во развојот на страницата
За да го оцените напредокот во развојот на страницата, потребен ви е шаблон кој е создаден специјално за оваа намена. Табелата може да послужи и за потребите на самиот тим и на клиентот.
Секоја информација за страницата може да се означи овде. Ова е краен рок, врска до прототипот на InVision, дестинација, детска компонента. Веднаш станува забележливо дека операциите се многу погодни за извршување, како во поглед на документирање и ажурирање на дизајнот, така и во однос на статусот на развој на предниот и заден дел. Покрај тоа, овие операции се вршат истовремено.
Апстракт
Улогата на алатката: единствен извор на контрола на верзијата за дизајнерски средства.
Апстрактот може да се нарече GitHub за средства во Sketch и ги спасува дизајнерите од потребата да копираат и залепуваат датотеки. Главната предност на алатката е тоа што обезбедува складиште за дизајн што делува како „единствен извор на вистината“. Дизајнерите мора да ја ажурираат главната гранка на најновата верзија на одобрениот распоред. После тоа, тие треба да ги известат програмерите. Тие, пак, треба да работат само со дизајнерски средства од главната гранка.
Како заклучок
Откако го имплементиравме новиот развоен процес и сите алатки споменати погоре, брзината на нашата работа се зголеми најмалку двапати. Тоа не е совршено решение, но е многу добро. Точно, за да работи, треба да вложите многу напор - потребна е „рачна работа“ за да се ажурира и одржува сето тоа во работна состојба.
Skillbox препорачува:
- Практичен курс .
- Онлајн курс .
- Практичен годишен курс .
Извор: www.habr.com