¿Cómo es trabajar en un gran equipo de programación?

Siempre me sentí afortunado de trabajar en un pequeño equipo de programación. Creo que lo máximo con lo que he trabajado son 11 programadores. ¿Cómo es trabajar en un proyecto con cientos de desarrolladores? Miles? ¿Qué escala y qué no?

EDITAR: ¡Gracias por todas las respuestas! Parece que hay muy pocos aspectos positivos:

• posible trabajar en bases de código megagrandes
• mejor desarrollo profesional interno
• protección de los empleados contra la gestión abusiva (esto es más -ve en pequeño que + ve en grande)

¿Hay algún otro beneficio para los equipos grandes?

Encuentro que la burocracia escala muy bien.

Aparte de eso, no mucho. Los proyectos grandes tienen equipos grandes porque no hay otra manera, no porque sea más eficiente (por desarrollador). Usted paga un costo tan pronto como agrega una segunda persona a la mezcla en términos de ineficiencia (es decir, transferencia de conocimiento y comunicación).

El proyecto más grande en el que trabajé tenía aproximadamente 70 desarrolladores en 5 sitios diferentes. Incluso un cambio de una línea tomó un mínimo de un día, aunque eso se debió en parte al hecho de que la construcción tardó más de 45 minutos en un enlace de red de Zurich a Londres y el inicio de la aplicación tomó otros 45 minutos. Los registros demoraron unos 5 minutos por archivo. No estoy bromeando. Los desarrolladores de Londres podrían hacer esto en una fracción del tiempo.

De todos modos, lo que sueles encontrar es que en proyectos grandes tendrás un montón de miembros del equipo con los que no interactúas tanto. Es más como una colección de mini proyectos libremente afiliados. Una vez leí que el desarrollo de Microsoft tendía a dividir los proyectos en equipos de 5-7 desarrolladores, incluso para proyectos grandes como Microsoft Office.

Parte de la diferencia es también la diferencia entre pequeñas y grandes empresas: las grandes tienden a tener más procesos, más reglas, menos flexibilidad, etc. Pero eso de ninguna manera está garantizado.

Sin embargo, puede ser bueno para el desarrollo profesional. En una empresa pequeña, alguien tiene que irse o morir antes de que pueda obtener un ascenso (o la empresa tiene que crecer para que el equipo se expanda y usted se mueva hacia arriba), mientras que en departamentos de desarrollo más grandes puede moverse entre equipos, etc.

Además, a veces puede encontrar algunas personas realmente inteligentes para unirse y aprender. En las pequeñas empresas, estar tan aislados y ser autosuficientes puede ser propicio para que los programadores se vuelvan un poco "extraños", como un ermitaño.

La comunicación es lo que he encontrado que es lo más importante que comienza a degradarse a medida que crece el tamaño del equipo. Se hace más difícil comunicar y asegurar que todos sigan en la misma página. Trabajo indirectamente en un equipo de unos 75 desarrolladores, utilizamos una base de código común, pero muchos de los 75 se dividen en grupos más pequeños para "actividades" individuales. Para nosotros, la comunicación es solo una pesadilla total.

La administración de grupos más grandes también es más difícil, ya que en la mayoría de los entornos después de 8-12 personas se involucran miembros adicionales de la administración, lamentablemente esto solo exagera el problema de comunicación, ya que generalmente crea un entorno de tipo "silo" donde los subconjuntos individuales comienzan a separarse grupo grande y tratar de mantener el conocimiento dentro de su grupo.

Cuando hice software para sistemas de armas teníamos GRANDES equipos de desarrolladores de software. Como ninguna persona puede entender los requisitos (algunos de los cuales se clasificaron), se trataba de equipos y de cómo los equipos interactuaban entre sí.

1. La gestión de la configuración, el proceso de compilación nocturno, fue muy importante. En aquellos días se necesitaba un gran clúster informático distribuido para recompilar al mundo todas las noches.

2. Las autorizaciones de trabajo, y cobrar su tiempo a la línea de pedido correcta en el cronograma general del proyecto general, fue un gran dolor de cabeza. Abajo a las 0.1 h. incrementos

Pero el mayor acuerdo fue la notificación de cambio. Particularmente cambios de interfaz.

Esto fue tan importante que inventaron este loco proceso de dos capas. La mayor parte del esfuerzo se centró en asegurarse de que la Solicitud de notificación de cambio de interfaz (no la notificación en sí, sino la solicitud de notificación) tuviera un software de soporte elaborado con una base de datos e informes y demás.

Una vez que se aprobó la solicitud, el aviso real fue más o menos evidente. Lo que significa que realmente fue un proceso de una capa y la solicitud efectivamente fue el aviso. Pero cuando estás haciendo un desarrollo en cascada, hay que pensar en todo mucho tiempo antes de que aparezca cualquier desarrollador.

Con tanta gente trabajando en paralelo, había una placa de control de configuración. Todos los diversos gerentes de equipo, más un grupo de personas cuyo trabajo era simplemente coordinar los cambios.

Mi primer trabajo de programación "real" fue trabajar con un ejército y otros para desarrollar sistemas internacionales de control de tráfico aéreo. Fue un esfuerzo muy exitoso y se nos consideró un entorno de Nivel de Modelo de Madurez de Capacidad 5. Desde entonces he estado en tiendas medianas y pequeñas. Entonces, ¿cuál es el mejor lugar para estar? Personalmente, tomaría una tienda más pequeña que una enorme cada día. Si bien algunos podrían considerar el Nivel 5 como el Santo Grial, para mí fue sofocante. Todo tiene que estar documentado, aprobado, firmado, etc. No me malinterpretes, definitivamente veo el valor, especialmente para sistemas tan críticos como el control del tráfico aéreo, pero la pregunta es cómo quieres gastar tu dinero. ¿día? ¿Quieres la libertad de poder soñar cosas y luego implementarlas, o quieres escribir a los requisitos? Quizás si me hubiera quedado más tiempo con el sistema ATC, podría haber alcanzado el nivel de poder diseñar y desarrollar, pero incluso eso requirió X número de años, Y número de aprobaciones, Z número de promociones, todo bien prescrito sin posibilidad de desviaciones. Fue sofocante.

Una última cosa, en general, encuentro que la calidad de los desarrolladores es mucho mayor en las empresas más pequeñas simplemente porque no pueden esconderse. No es difícil ser mediocre en una empresa muy grande, pero se vuelve dolorosamente obvio en una pequeña y a menudo no duran mucho.

He trabajado (brevemente) en una organización con al menos cientos de desarrolladores. Pero, por supuesto (?), La organización está dividida internamente para que usted, como solo empleado, no tenga contacto directo con todos los demás, sería muy difícil mantenerse al día.

En ese lugar en particular, el software se dividió en componentes, con equipos formados alrededor de los componentes. Algunos equipos trabajarían con un solo componente (grande), mientras que muchos equipos tenían la responsabilidad de un montón de componentes (más pequeños).

Por supuesto, esto implica todo lo que hace trabajar con una base de código muy grande; cosas como la gestión de la configuración, la construcción, la integración, etc., se vuelven importantes, grandes, cosas que a su vez son hechas por departamentos dedicados especializados. Y usted los asombra, por poder recopilar todos los resultados de los departamentos de desarrolladores y regularmente (una vez por semana, donde trabajé) integrarlos en un todo coherente que realmente funcionó.

Nunca he trabajado para un gran equipo de programadores , pero el resultado de que una organización aumente de tamaño suele ser más reglas. ¡Esto no siempre es necesariamente algo malo! Además de las reglas que dificultan la vida de todos, también hay más reglas para proteger a los empleados y garantizar un buen proceso.

He visto a gerentes de organizaciones pequeñas que se salen con la suya de inmediato.

La única diferencia que he notado con los grandes proyectos es la política de la oficina. Cuanto más grandes son los proyectos, más dominante es la política.

Mi primer proyecto fuera de la escuela fue un par de cientos de desarrolladores. Como desarrollador arrogante e ingenuo recién llegado de la escuela, realmente no estaba listo para eso. La única cosa que me salvó la hiney (y es el único que alguna vez realmente protegerle) fue la cantidad de amigos que hice.

Esa es la mayor lección que aprendí de eso. Intenta hacer amigos con todos . Incluso los idiotas. En particular, si tiene la oportunidad de dejar de trabajar por un minuto y tener una conversación con alguien con quien nunca ha hablado antes, hágalo.

Una vez pasé un año trabajando en un equipo con más de 500 personas, unos 200 de ellos eran desarrolladores. Estábamos entregando un EOA, integrando varias soluciones SOA diferentes.

En la práctica, había entre 30 y 50 equipos, cada uno con un número variable de programadores (3 en nuestro equipo), cada uno con la responsabilidad de un aspecto diferente de la entrega general.

El equipo más grande en el que trabajé fue de unas 15 personas (esto fue solo por 3 o 4 meses, en una compañía diferente). Fui líder técnico en el equipo, y me puse a trabajar a las 7 de la mañana, tenía 2 horas antes de que todos los demás entraran, era la única forma en que podía realizar mis propias tareas.

No me gustaría trabajar en un equipo con más de 8 o 10 desarrolladores, 15 eran demasiados para un solo equipo (el equipo podría haberse dividido fácilmente en dos, desafortunadamente no es mi llamado), 3 o 4 desarrolladores es un bonito tamaño cómodo en mi humilde opinión