He estat treballant com a desenvolupador front-end durant uns dos anys i he participat en la creació d'una gran varietat de projectes. Una de les lliçons que vaig aprendre és que la col·laboració entre diferents equips de desenvolupadors que comparteixen el mateix objectiu però que tenen tasques i responsabilitats diferents no és fàcil.
En consulta amb altres membres de l'equip, dissenyadors i desenvolupadors, vaig crear un cicle de creació de llocs web dissenyat per a petits equips (5-15 persones). Inclou eines com Confluence, Jira, Airtable i Abstract. En aquest article compartiré les característiques de l'organització del flux de treball.
Skillbox recomana: Curs pràctic de dos anys .
Recordem: per a tots els lectors de "Habr": un descompte de 10 rubles en inscriure's a qualsevol curs de Skillbox amb el codi promocional "Habr".
Per què és necessari tot això?
L'equip mínim necessari per crear un lloc web des de zero és un dissenyador, programador i gestor de projectes. En el meu cas, l'equip es va formar. Però després del llançament d'un parell de llocs, vaig tenir la sensació que hi havia alguna cosa malament. De vegades simplement no enteníem del tot les nostres responsabilitats i la comunicació amb el client deixava molt a desitjar. Tot això va frenar el procés i va molestar a tothom.
Vaig començar a treballar per resoldre el problema.
Una cerca a Google dóna bons resultats sobre el nostre problema.
Per tal de fer que el treball es faci més visual, vaig crear un diagrama de flux de treball que dóna una comprensió de com es fa el treball aquí.
Feu clic a la imatge per obrir-la en resolució completa.
Objectius i objectius
Una de les primeres tècniques que vaig decidir provar va ser el “model en cascada” (Cascada). El vaig utilitzar per destacar problemes i entendre com resoldre'ls.
Problema: Molt sovint, el client no avalua el procés de creació del lloc web de manera modular, com ho fan els desenvolupadors. El percep com un lloc habitual, és a dir, pensa en termes de pàgines individuals. Segons la seva opinió, dissenyadors i programadors creen pàgines individuals, una darrere l'altra. Com a resultat, el client simplement no entén què passa durant el procés real.
Tasca: No serveix de res convèncer el client del contrari, la millor opció és desenvolupar un procés modular de creació d'un lloc web dins de l'empresa a partir d'un model pàgina per pàgina.
Els components i fitxes de disseny universals són gestionats tant per desenvolupadors com per dissenyadors.
Problema: aquesta és una situació comuna que aborden moltes estratègies. Hi ha moltes solucions interessants, en la majoria dels casos es proposa crear un sistema de disseny que estigui controlat per una guia d'estil/generadors de biblioteques. Però en la nostra situació, afegir un altre component al procés de desenvolupament que ens permetés gestionar els nivells d'accés dels dissenyadors simplement no era possible.
Tasca: construir un sistema universal en què dissenyadors, desenvolupadors i gestors puguin treballar de manera sincrònica sense interferir entre ells.
Seguiment precís del desenvolupament
Problema: tot i que hi ha moltes eines útils disponibles per fer un seguiment dels problemes i mesurar el progrés general, la majoria no són flexibles ni òptimes. L'eina pot ser útil estalviant el temps de l'equip que normalment es dedicaria a preguntes i aclariments sobre tasques específiques. També facilita la vida als directius, donant-los una comprensió més precisa de tot el projecte.
Tasca: crear un tauler per fer un seguiment del progrés de les tasques realitzades pels diferents membres de l'equip.
joc d'eines
Després d'experimentar amb diferents eines, em vaig acomodar al conjunt següent: Confluence, Jira, Airtable i Abstract. A continuació us desvetllaré els beneficis de cadascun.
Confluència
Paper de l'eina: centre d'informació i recursos.
L'espai de treball de Confluence és relativament fàcil de configurar, té moltes funcions, integracions amb diferents aplicacions i té plantilles individuals i personalitzables. No és una solució única, però és ideal com a centre d'informació i recursos. Això vol dir que qualsevol referència o detall tècnic relacionat amb el projecte s'ha d'introduir a la base de dades.
L'eina us permet documentar correctament cada component i qualsevol altre detall sobre el projecte.
El principal avantatge de Confluence és la personalització de les plantilles de documents. A més, es pot utilitzar per implementar un únic repositori d'especificacions i documentació del projecte diversa, separant els nivells d'accés dels participants. Ara no us haureu de preocupar de tenir una versió antiga de l'especificació a mà, com passa quan envieu documents per correu electrònic.
Més informació sobre l'eina .
Jira
Paper de l'eina: seguiment de problemes i gestió de tasques.
Jira és una eina de planificació i gestió de projectes molt potent. La part principal de la funcionalitat és la creació de fluxos de treball personalitzables. Per gestionar eficaçment els problemes (que és el que necessitem), val la pena prestar especial atenció a l'ús correcte del tipus de sol·licitud i del tipus de problema (tipus d'incidència).
Per tant, per assegurar-se que els desenvolupadors estan construint components basats en el disseny correcte, se'ls ha de notificar cada vegada que canvia alguna cosa en el disseny. Tan bon punt s'actualitza el component, el dissenyador ha d'obrir un problema, assignar un desenvolupador responsable i assignar-li el tipus de problema correcte.
Amb Jira, podeu estar segur que absolutament tots els participants en el procés (permeteu-me que us recordo, en el nostre cas n'hi ha de 5 a 15) reben tasques correctes que no es perden i troben el seu executor.
Més informació sobre Jira .
Adequat
Paper de l'eina: gestió de components i tauler de progrés.
Airtable és una barreja de fulls de càlcul i bases de dades. Tot això fa possible personalitzar el funcionament de totes les eines comentades anteriorment.
Exemple 1: Gestió de components
Pel que fa al generador de guies d'estil, no sempre és convenient utilitzar-lo; el problema és que els dissenyadors no poden editar-lo. A més, no seria una bona decisió utilitzar la biblioteca de components Sketch, ja que té moltes limitacions. El més probable és que simplement no pugueu utilitzar aquesta biblioteca fora del programa.
Airtable tampoc és perfecte, però és millor que moltes altres solucions similars. Aquí teniu una demostració de la plantilla de la taula de gestió de components:
Quan un desenvolupador accepta un component de disseny, avalua l'ABEM resultant registrant el component en una taula. Hi ha 9 columnes en total:
- Nom: el nom del component segons el principi ABEM.
- Vista prèvia: aquí es col·loca una captura de pantalla o una imatge del component baixat d'una altra font.
- Una pàgina enllaçada és un enllaç a la pàgina d'un component.
- Component fill: un enllaç als components secundaris.
- Modificador: comprova la presència d'opcions d'estil i les defineix (per exemple, activa, vermella, etc.).
- La categoria de components és una categoria general (text, imatge promocional, barra lateral).
- Estat de desenvolupament: el progrés real del desenvolupament i la seva definició (acabat, en curs, etc.).
- Responsable: el desenvolupador responsable d'aquest component.
- El nivell atòmic és la categoria atòmica d'aquest component (segons el concepte de disseny atòmic).
- Les dades es poden fer referència a les mateixes taules o diferents. Connectar els punts evitarà confusió a l'hora d'escalar. A més, les dades es poden filtrar, ordenar i canviar sense cap problema.
Exemple 2: progrés del desenvolupament de la pàgina
Per avaluar el progrés del desenvolupament de la pàgina, necessiteu una plantilla creada específicament per a aquest propòsit. La taula pot atendre tant les necessitats del propi equip com del client.
Qualsevol informació sobre la pàgina es pot anotar aquí. Aquesta és una data límit, un enllaç al prototip InVision, una destinació, un component fill. De seguida es nota que les operacions són molt còmodes de realitzar, tant pel que fa a la documentació i actualització del disseny, com a l'estat del desenvolupament front-end i back-end. A més, aquestes operacions es realitzen simultàniament.
abstracte
Paper de l'eina: una única font de control de versions per als actius de disseny.
Abstract es pot anomenar GitHub per als actius a Sketch i estalvia als dissenyadors d'haver de copiar i enganxar fitxers. El principal avantatge de l'eina és que proporciona un dipòsit de disseny que actua com a "font única de veritat". Els dissenyadors han d'actualitzar la branca mestra a la darrera versió del disseny aprovat. Després d'això, han de notificar als desenvolupadors. Aquests, al seu torn, haurien de funcionar només amb actius de dissenyadors de la branca principal.
Com a conclusió
Després d'implementar el nou procés de desenvolupament i totes les eines esmentades anteriorment, la velocitat del nostre treball va augmentar almenys dues vegades. No és una solució perfecta, però és molt bona. És cert que perquè funcioni, cal esforçar-se molt: requereix un "treball manual" per actualitzar-lo i mantenir-ho tot en condicions de funcionament.
Skillbox recomana:
- Curs pràctic .
- Curs en línia .
- Curs pràctic de l'any .
Font: www.habr.com