Su pregunta es difícil porque afecta a muchas áreas: proceso, liderazgo y diseño de software (o arquitectura). Voy a suponer que ya tienes un proceso estándar, pero si no lo haces, prueba uno de los procesos ágiles. Hablaré sobre liderazgo y arquitectura de software.
Liderazgo. El gran libro de Fred Brooks, The Mythical Man-Month, habla de tener un líder técnico del mismo modo que un equipo quirúrgico tiene un líder. Personalmente, me gusta más la colaboración de la que veo con los médicos, así que tratemos al equipo quirúrgico de Brooks como un extremo. Aún así, necesita a alguien que coordine técnicamente quién hace qué, cosas como asignar gente a trabajar en diferentes partes del sistema, decidir cuáles son las partes más difíciles (más riesgosas) (para que no se difieran hasta que sean costosas). cambiar/corregir) y tomar decisiones cuando el equipo no está de acuerdo. Este tipo de liderazgo técnico es necesario ya sea que esté creando software, autos o pogo sticks.
Arquitectura/Diseño. El mantra estándar es que "cada sistema tiene una arquitectura", pero el corolario es que no todas las arquitecturas se eligen deliberadamente. Puede copiar implícitamente la arquitectura de su último proyecto, digamos un sistema de 3 niveles. O puede decidirse una vez que sepa que está utilizando un marco como EJB. Al comienzo de un proyecto, tomará decisiones arquitectónicas y algunas serán difíciles de cambiar más tarde. ¿Cómo persistirán los datos? ¿Usará un marco (por ejemplo, Spring, EJB, RoR)? ¿Procesará los datos de forma incremental o por lotes?
Casi cualquier arquitectura puede verse forzada a cumplir sus requisitos. Por ejemplo, podría usar RoR para construir un termostato. Pero le resultará más fácil cuando su arquitectura se ajuste bien a los requisitos. A veces tendrá requisitos, como una baja latencia de la interfaz de usuario, que pueden ser ayudados por una elección inteligente de arquitectura, como el uso de AJAX. Entonces, el comienzo de su proyecto es una oportunidad para pensar sobre estas cosas y hacerlas bien. (Y esto no significa que vayas a la montaña, pienses mucho, y luego dicta tus respuestas al equipo; una vez más, prefiero la colaboración).
No tenga miedo de pensar en la arquitectura por adelantado, especialmente sobre las formas en que puede ayudarlo a evitar dificultades, pero tampoco intente decidir todo con anticipación. Tendrá problemas si una parte de su equipo comenzó a usar Ruby on Rails mientras que otra parte comenzó a usar EJB, por lo que debe tomar algunas decisiones técnicas, las que se le imponen a usted y las que abordarán sus mayores riesgos.
Una última cosa: las primeras discusiones de arquitectura son una bendición y una maldición. Son una bendición, ya que obtienen sus ideas temprano y le permiten elegir su diseño en lugar de equivocarse en él. Pero son una maldición en el sentido de que todos tendrán opiniones, y puede ser difícil hacer que todos apunten en la misma dirección (es decir, a la necesidad de un liderazgo técnico).
Recomiendo el Capítulo 12 de Applied Software Architecture para obtener orientación sobre su pregunta. La lista de títulos da una buena idea de sus consejos: crear una visión, el arquitecto como asesor técnico clave, el arquitecto toma decisiones, los entrenadores de los arquitectos, las coordenadas del arquitecto, los instrumentos del arquitecto, los defensores del arquitecto. El libro 97 Things que mencionas es más una colección de perlas de sabiduría que una guía cohesiva de la arquitectura.
George Fairbanks, Autor de Just Enough Software Architecture
gran respuesta, mucho mejor que la mía =) 1 –