¿Podría ver este flujo de trabajo para un equipo de desarrollo dentro de una agencia digital?

Estamos tratando de encontrar un flujo de trabajo que nuestros desarrolladores/PM puedan seguir y que le brinde al desarrollador todo lo que necesita para un proyecto. Un proceso paso a paso que siguen los PM y los desarrolladores para que a) el proyecto funcione sin problemas y b) los desarrolladores obtengan todo lo que necesitan para completar un proyecto.

Comenzamos construyendo nuestros proyectos primero a través del equipo de front-end y luego se integra más adelante. Ya sea que se trate de un sitio de Wordpress/CMS de código abierto, una aplicación web o un CMS más grande de nivel empresarial, todo sigue el mismo flujo de trabajo. Nuevamente, cualquier aporte sobre esta forma de trabajar sería útil.

El proceso debe ser detallado y eficiente, pero no tan detallado y prolongado que se vuelva ineficiente. ¿Podría ver a los siguientes trabajando dentro de una agencia?

  • PM para suministrar resumen del proyecto y diseño PDF/JPGS
  • Dev para leer el resumen del proyecto e informar cualquier consulta al PM
  • Si el desarrollador acepta/asignado al proyecto, cree un canal de holgura y agréguelo al equipo
  • PM para suministrar archivos PSD
  • Desarrollador para revisar los archivos PSD: sugiera enmiendas (si las hay) e informe al PM
  • PM para reservar con Designer y ser modificado
  • Agregar desarrollador al repositorio de Bitbucket y al tablero kanban de JIRA
  • PM para proporcionar acceso a bitbucket
  • Reunión de inicio/conversación
  • Planificación de Sprint: divide el proyecto en subtareas
  • Asigne cada tarea a las personas relevantes y planifique en consecuencia
  • Ponga el tiempo estimado en cada tarea para llenar el límite diario de 8 horas
  • Desarrollador a desarrollo en versión estática. Confirmar código para repo cada noche
  • Standup diario de 15 minutos a las 9 a.m. para revisar la tarea/el progreso del día anterior y siguiente
  • Desarrollador para mover la tarea a la columna 'En progreso' de JIRA cuando se trabaja activamente en la tarea
  • Una vez que la tarea esté completa, muévase a la columna 'UAT' y asigne al PM
  • PM para revisar la tarea y volver a asignarla al desarrollador si se requieren modificaciones/cambios. Repita hasta que sea aprobado.
  • Revisión de Browserstack en navegadores y dispositivos modernos. Utilice la lista de verificación del navegador. Agregue cualquier hallazgo o consulta a los tickets/tareas relevantes dentro de JIRA. Si no se aplican boletos, cree BUG y adjunte capturas de pantalla. Notifique a través de Slack también.
  • Todo el código debe estar validado por W3C. PM para verificar en https://validator.w3.org Informe cualquier advertencia/error a los tickets/tareas relevantes dentro de JIRA. Si no se aplican boletos, cree BUG y adjunte capturas de pantalla. Notifique a través de Slack también.
  • PM para revisar el trabajo con el cliente
  • Hable sobre cualquier comentario con dev. Defina una lista de acciones y luego agréguelas a los tickets relevantes en JIRA. Además, averigüe si las enmiendas están dentro del alcance del proyecto.
  • Una vez que todos los desarrolladores registrados pueden comenzar la integración de CMS
Hola, bienvenido a PMSE. Tal como está su pregunta, es demasiado específica y agregaría poco o ningún valor a la comunidad, por lo que, sin reformularla, es probable que se cierre. ¿Podría trabajar para que sea más genérico y se centre en los problemas en lugar de en las soluciones? ¡Gracias!

Respuestas (1)

Su flujo de trabajo debe ser lo más simple posible, lo que significa que no puede tener tantos estados como elementos en su lista, lo que también ayudará a que el proceso se desarrolle sin problemas. Si bien no puedo diseñar el flujo de trabajo para usted, puedo darle algunos consejos:

  • Los estados representan algo que ya sucedió, más específicamente una actividad que una persona o equipo terminó, es decir: "revisado con el cliente, estimado, desarrollado".

  • Las transiciones son las acciones que lo llevan de un estado a otro, después de que hizo lo que tenía que hacer en su estado actual, es decir: "enviar a revisión, enviar a desarrollo".

  • La mayoría de las transiciones tendrán información asociada de por qué se realizó la transición del problema o información requerida en el siguiente estado.
Ya veo, eso tiene más sentido. Lo que se me ocurrió suena más como una lista de los 3 que podrían simplificarse. Aunque el flujo de trabajo debe ser muy rígido para garantizar que el proceso se siga al pie de la letra, no hay estados claros. Esto debe ser como un manual de instrucciones paso a paso. Voy a modificar y poner en un diagrama de flujo.