Levo uns dous anos traballando como programador front-end e participei na creación dunha gran variedade de proxectos. Unha das leccións que aprendín é que a colaboración entre diferentes equipos de desenvolvedores que comparten o mesmo obxectivo pero que teñen tarefas e responsabilidades diferentes non é doada.
En consulta con outros membros do equipo, deseñadores e desenvolvedores, creei un ciclo de creación de sitios web deseñado para equipos pequenos (5-15 persoas). Inclúe ferramentas como Confluence, Jira, Airtable e Abstract. Neste artigo compartirei as características da organización do fluxo de traballo.
Skillbox recomenda: Curso práctico de dous anos .
Recordámolo: para todos os lectores de "Habr" - un desconto de 10 rublos ao inscribirse en calquera curso de Skillbox usando o código promocional "Habr".
Por que é necesario todo isto?
O equipo mínimo necesario para crear un sitio web desde cero é un deseñador, programador e xestor de proxectos. No meu caso, o equipo formouse. Pero despois do lanzamento dun par de sitios, tiven a sensación de que algo andaba mal. Ás veces simplemente non entendiamos completamente as nosas responsabilidades e a comunicación co cliente deixaba moito que desexar. Todo isto freou o proceso e perturbou a todos.
Comecei a traballar para resolver o problema.
Unha busca en Google dá bos resultados sobre o noso problema.
Para facer o traballo feito máis visual, creei un diagrama de fluxo de traballo que dá unha comprensión de como se fai o traballo aquí.
Fai clic na imaxe para abrir a resolución completa.
Obxectivos e obxectivos
Unha das primeiras técnicas que decidín probar foi o “modelo en cascada” (Cascada). Useino para destacar problemas e comprender como resolvelos.
Problema: a maioría das veces, o cliente non avalía o proceso de creación do sitio web de forma modular, como fan os desenvolvedores. Percíbeo como un sitio normal, é dicir, pensa en función de páxinas individuais. Na súa opinión, deseñadores e programadores crean páxinas individuais, unha tras outra. Como resultado, o cliente simplemente non entende o que segue durante o proceso real.
Tarefa: non ten sentido convencer ao cliente do contrario; a mellor opción é desenvolver un proceso modular para a creación dun sitio web dentro da empresa baseado nun modelo páxina por páxina.
Os tokens e compoñentes de deseño universais son xestionados tanto por desenvolvedores como por deseñadores.
Problema: esta é unha situación común que abordan moitas estratexias. Hai moitas solucións interesantes, na maioría dos casos proponse crear un sistema de deseño que estea controlado por unha guía de estilo/xeradores de bibliotecas. Pero na nosa situación, engadir outro compoñente ao proceso de desenvolvemento que nos permitise xestionar os niveis de acceso dos deseñadores simplemente non foi posible.
Tarefa: construír un sistema universal no que deseñadores, desenvolvedores e xestores poidan traballar de forma sincronizada sen interferir entre si.
Seguimento preciso do desenvolvemento
Problema: aínda que hai moitas ferramentas útiles dispoñibles para rastrexar problemas e medir o progreso xeral, a maioría non son flexibles nin son óptimas. A ferramenta pode ser útil aforrando o tempo do equipo que normalmente se dedicaría a preguntas e aclaracións sobre tarefas específicas. Tamén facilita a vida dos xestores dándolles unha comprensión máis precisa de todo o proxecto.
Tarefa: crea un panel para seguir o progreso das tarefas realizadas polos diferentes membros do equipo.
Conxunto de ferramentas
Despois de experimentar con diferentes ferramentas, decanteime polo seguinte conxunto: Confluence, Jira, Airtable e Abstract. A continuación desvelarei os beneficios de cada un.
Confluencia
Papel da ferramenta: centro de información e recursos.
O espazo de traballo de Confluence é relativamente sinxelo de configurar, ten moitas funcións, integracións con diferentes aplicacións e ten modelos individuais e personalizables. Non é unha solución única, pero é ideal como centro de información e recursos. Isto significa que calquera referencia ou detalle técnico relacionado co proxecto debe ser introducido na base de datos.
A ferramenta permítelle documentar correctamente cada compoñente e calquera outro detalle sobre o proxecto.
A principal vantaxe de Confluence é a personalización dos modelos de documentos. Ademais, pódese utilizar para implementar un único repositorio de especificacións e documentación de proxecto diversa, separando os niveis de acceso dos participantes. Agora non tes que preocuparte de ter a man unha versión antiga da especificación, como ocorre cando envías documentos por correo electrónico.
Máis información sobre a ferramenta .
Jira
Papel da ferramenta: seguimento de problemas e xestión de tarefas.
Jira é unha ferramenta de planificación e xestión de proxectos moi poderosa. A parte principal da funcionalidade é a creación de fluxos de traballo personalizables. Para xestionar eficazmente os problemas (que é o que necesitamos), convén prestar especial atención ao uso correcto do tipo de solicitude e do tipo de problema (tipo de problema).
Polo tanto, para asegurarse de que os desenvolvedores están construíndo compoñentes baseados no deseño correcto, deben ser notificados cada vez que algo cambia no deseño. Tan pronto como se actualice o compoñente, o deseñador debe abrir un problema, asignar un desenvolvedor responsable, asignándolle o tipo de problema correcto.
Con Jira, podes estar seguro de que absolutamente todos os participantes no proceso (permíteme recordarche, no noso caso hai entre 5 e 15) reciben tarefas correctas que non se perden e atopan o seu executor.
Máis información sobre Jira .
Apañeiros
Papel da ferramenta: xestión de compoñentes e táboa de progreso.
Airtable é unha mestura de follas de cálculo e bases de datos. Todo isto fai posible personalizar o funcionamento de todas as ferramentas comentadas anteriormente.
Exemplo 1: Xestión de compoñentes
En canto ao xerador de guías de estilo, non sempre é cómodo de usar; o problema é que os deseñadores non poden editalo. Ademais, non sería unha boa decisión utilizar a biblioteca de compoñentes de Sketch, xa que ten moitas limitacións. O máis probable é que simplemente non poidas usar esta biblioteca fóra do programa.
Airtable tampouco é perfecto, pero é mellor que moitas outras solucións similares. Aquí tes unha demostración do modelo da táboa de xestión de compoñentes:
Cando un desenvolvedor acepta un compoñente de deseño, avalía o ABEM resultante rexistrando o compoñente nunha táboa. Hai 9 columnas en total:
- Nome - o nome do compoñente segundo o principio ABEM.
- Vista previa: é onde se coloca unha captura de pantalla ou unha imaxe do compoñente descargado doutra fonte.
- Unha páxina ligada é unha ligazón á páxina dun compoñente.
- Compoñente fillo: unha ligazón a compoñentes fillos.
- Modificador: comproba a presenza de opcións de estilo e defíneas (por exemplo, activa, vermella, etc.).
- A categoría de compoñentes é unha categoría xeral (texto, imaxe promocional, barra lateral).
- Estado de desenvolvemento: o progreso real do desenvolvemento e a súa definición (completado, en curso, etc.).
- Responsable: o programador responsable deste compoñente.
- O nivel atómico é a categoría atómica deste compoñente (segundo o concepto de deseño atómico).
- Os datos pódense referenciar na mesma táboa ou en diferentes táboas. Conectar os puntos evitará confusións ao escalar. Ademais, os datos pódense filtrar, clasificar e modificar sen ningún problema.
Exemplo 2: progreso do desenvolvemento da páxina
Para avaliar o progreso do desenvolvemento da páxina, necesitas un modelo creado especificamente para este fin. A mesa pode atender tanto as necesidades do propio equipo como do cliente.
Calquera información sobre a páxina pódese anotar aquí. Este é un prazo, unha ligazón ao prototipo de InVision, un destino, un compoñente fillo. De inmediato faise notar que as operacións son moi cómodas de realizar, tanto no que se refire á documentación e actualización do deseño, como ao estado do desenvolvemento front-end e back-end. Ademais, estas operacións realízanse simultaneamente.
Abstracto
Papel da ferramenta: unha única fonte de control de versións para os recursos de deseño.
Resumo pódese chamar GitHub para os recursos en Sketch, e evita que os deseñadores teñan que copiar e pegar ficheiros. A principal vantaxe da ferramenta é que ofrece un repositorio de deseño que actúa como unha "fonte única de verdade". Os deseñadores deben actualizar a rama mestra á última versión do deseño aprobado. Despois diso, teñen que avisar aos desenvolvedores. Eses, á súa vez, deberían funcionar só con activos de deseñadores da rama principal.
Como conclusión
Despois de implementar o novo proceso de desenvolvemento e todas as ferramentas mencionadas anteriormente, a velocidade do noso traballo aumentou polo menos dúas veces. Non é unha solución perfecta, pero é moi boa. É certo, para que funcione, cómpre esforzarse moito: require un "traballo manual" para actualizalo e mantelo todo en condicións de funcionamento.
Skillbox recomenda:
- Curso práctico .
- Curso en liña .
- Curso práctico anual .
Fonte: www.habr.com