Tenemos un nuevo proyecto en marcha, y en este momento los desarrolladores se han dividido en dos equipos, el equipo A y el equipo B. Este proyecto tiene 2 partes que requieren desarrollo en toda la pila de desarrollo. Muestra muy simplificada de nuestra pila que se muestra a continuación:
Cada parte del proyecto requiere desarrollo en toda la pila, por lo que normalmente esperaría un enfoque de desarrollador de pila completa, que es cómo hemos estado desglosando nuestro trabajo dentro del equipo B, diseñando y resolviendo las interacciones entre las diferentes partes.
Sin embargo, recientemente he aprendido que el equipo A quiere estar a cargo de ciertas partes de la pila, y están proponiendo una división entre los dos equipos, donde la capa de abstracción de datos (y poner contenido en la capa de datos) es manejada por sin desarrollo del equipo B. La división se vería similar a esto:
Para mí esto se siente muy poco natural. Cada equipo tiene diferentes objetivos y escalas temporales para lograr estos objetivos, pero el Equipo B tendrá una dependencia del Equipo A para implementar las funciones. La solución propuesta es que las interfaces comunes se definen por adelantado (probablemente haya una escala de tiempo de 2 años en el proyecto, por lo que podrían ser numerosas). El Equipo A luego desarrollará los bits necesarios para estas interfaces desde el principio a pesar de tener su propio conjunto de objetivos, mientras que el Equipo B rechaza todas las llamadas a corto plazo para que puedan progresar.
Me preocupa este enfoque con respecto a:
- Las interfaces pueden cambiar y el Equipo A puede no tener el ancho de banda o el tiempo para acomodar los requisitos cambiantes.
- Los errores en el código del Equipo A podrían evitar que el Equipo B progrese, y de nuevo pueden no ser la prioridad para solucionarlos debido a que el Equipo A tiene una cola de priorización diferente.
- Falta de conocimiento difundido entre los equipos: el equipo B puede no comprender completamente lo que sucede debajo del capó y puede tomar malas decisiones de diseño debido a esto.
Se ha sugerido que muchas compañías en la industria tienen sub-equipos y deben ser capaces de manejar esto. Según tengo entendido, generalmente los equipos se dividen como esperaba inicialmente (Full Stack) o dividiendo la pila de tecnología como se muestra a continuación:
Así que estoy interesado en saber qué está haciendo el resto de la industria. ¿La mayoría de las divisiones son verticales / horizontales? ¿Tiene sentido una división diagonal? Si se produjera una división diagonal, ¿me parecen válidas mis preocupaciones y hay algo más por lo que el Equipo B deba preocuparse? Para tener en cuenta, probablemente seré responsable del éxito o el fracaso del equipo B.
Respuestas:
Sus inquietudes son extremadamente válidas. Especialmente los primeros dos puntos acerca de que el Equipo A no tiene tiempo para agregar funciones o corregir errores que afectan al Equipo B. He visto que esto sucede en mi propio trabajo varias veces.
Esta podría ser una buena idea si:
Se sabe que el Equipo A estará trabajando en los proyectos que requieren nuevas funciones en la base de datos, mientras que el objetivo del Equipo B es esencialmente hacer funciones "solo frontend". Por ejemplo, si el Equipo B está escribiendo la nueva aplicación de iPhone de su empresa, es probable que no agreguen nuevos campos de base de datos por un tiempo, ya que necesitan portar / reimplementar todas las características de la versión de escritorio.
La "pila completa" se ha vuelto lo suficientemente compleja como para que ningún desarrollador (o equipo de desarrollo) pueda "poseer" todo de manera efectiva. Por "propio" me refiero no solo a agregar características y corregir errores, sino a comprender y preocuparnos por todo el sistema hasta el punto de que puedan evitar agregar más deudas técnicas con el tiempo. En este caso, la división "diagonal" es el movimiento sensato si el Equipo A posee una UI / API web que es extremadamente simple o inevitablemente estrechamente acoplada a la implementación DAL / base de datos (¿quizás algunas herramientas de diagnóstico interno?), Mientras que el Equipo B sí todo lo complicado de la interfaz de usuario.
La gerencia comprende el riesgo de que el Equipo A se convierta en un cuello de botella y estaría dispuesto a des diagonalizar las cosas si este riesgo se convierte en un problema real o cuando lo haga.
No puedo hablar de lo que es más o menos común en la industria, pero al menos donde trabajo, existe una clara necesidad de que todos los desarrolladores de aplicaciones sean "full stack". Lo que sí tenemos son equipos de "infraestructura" que desarrollan / mantienen nuestra base de datos interna, nuestro marco de servicios web y nuestro marco de interfaz de usuario (¿mencioné que mi empresa es enorme?), Para que todos nuestros cientos de aplicaciones puedan tener una pila completa mientras que la empresa en su conjunto aún puede proporcionar un rendimiento y una interfaz de usuario consistentes a todos nuestros servicios.
Recientemente, nuestra empresa ha estado creando un nuevo marco de interfaz de usuario, por lo que hubo un período en el que algunas de nuestras nuevas aplicaciones estaban bloqueadas por errores y características faltantes en el nuevo marco. Este ya no es el caso, principalmente porque a algunos de nosotros se nos dio permiso para enviar solicitudes de extracción al equipo propietario del marco (no del todo "des-diagonalización", pero se entiende).
fuente