¿Existen mejores prácticas con respecto al traspaso de la arquitectura al desarrollo?

Estamos buscando mejorar el proceso para entregar tareas desde la arquitectura hasta el desarrollo.

En un extremo de la escala, no hay una guía de arquitectura que corra el riesgo de caos, con cada desarrollador haciendo las cosas a su manera.

En el otro extremo de la escala donde se especifica todo, la especificación lleva más tiempo que el desarrollo, y corre el riesgo de tener tareas de desarrollo muy aburridas.

¿Alguien ha encontrado un punto medio óptimo entre estos extremos? ¿Qué artefactos entregas al desarrollo? Por ejemplo: ¿módulos, estructura de clases o diagramas de secuencia?

Comenzaré diciendo que el concepto mismo de un equipo separado de "Arquitectura" es una afrenta a las buenas prácticas de desarrollo de software. Los equipos de arquitectura en entornos corporativos tienden a ser la culminación de los peores artistas de toro pseudointelectual de la torre de marfil * * que se pueden encontrar entre el grupo de desarrolladores.

Otras organizaciones tratan a los grupos de Arquitectura como una recompensa política y una justificación para un salario masivo para los miembros más importantes, independientemente de sus méritos, conocimientos o habilidades. La mayoría consisten en ambos tipos.

Todos los desarrolladores pueden y deben ser arquitectos y deben participar en los diseños de alto nivel de una empresa. La sola idea de que un solo grupo tiene un control dictatorial completo sobre todos los aspectos del diseño de software y que debe transmitirse a los desarrolladores que no contribuyeron al diseño, no entienden el razonamiento detrás de las opciones de diseño y pueden comprender fallas críticas en que el diseño es más cómodo y más cercano a la implementación real y al código existente, es francamente completamente defectuoso desde su núcleo, y resultará consistentemente en uno de tres escenarios:

• Los desarrolladores no comprenden el diseño, o lo rechazan directamente debido a las realidades de la implementación actual, y terminan determinando su propio diseño indocumentado e implementando eso en su lugar. La situación son documentos de diseño formales que no reflejan la implementación del software.

• Los desarrolladores siguen ciegamente el diseño que puede o no tener en cuenta los requisitos actuales o los aspectos únicos de las historias de los usuarios, lo que resulta en una implementación defectuosa y de baja calidad.

• Los desarrolladores inteligentes que entienden los documentos de diseño y pueden implementarlos, se aburren rápidamente de no involucrarse en discusiones de diseño. Es probable que estén excluidos de participar en el grupo de Arquitectura debido a problemas políticos o de antigüedad, por lo que se frustran, aburren y se van a pastos más verdes. Esto afecta negativamente al proyecto, lo que resulta en una fuga de cerebros que causa que continúe el círculo vicioso de mala calidad del software.

La mejor manera de mitigar este problema es CAMBIAR el grupo de Arquitectura y posiblemente ponerlos en posiciones de liderazgo tecnológico. El papel del grupo de Arquitectura debería ser más o menos un "scrum of tech leads" si lo desea. Raramente deberían reunirse y solo debatir los temas de dirección técnica de más alto nivel, por ej. piense en la migración de Java a Scala, Abandonando Oracle para MySQL, posiblemente escribiendo bibliotecas de utilidades comunes que exigen un cierto TIPO de proceso de diseño sobre otro, cambiando de StarUML a Altova UML.

El diseño de software real y real será un proceso comunitario que involucrará a TODOS los desarrolladores de software, establecido por la dirección de nivel extremadamente alto del grupo de Arquitectura.

Siempre ha habido problemas en cómo fluye la información desde la arquitectura hasta las pruebas y operaciones de desarrollo. La forma de abordar estos problemas depende de varios factores, como:

• tamaño del software
• complejidad
• cultura en su organización
• creencia.

Para ciertas combinaciones de estos factores, es apropiado un enfoque ágil puro, equipos multifuncionales con diseño emergente. La información fluye trabajando juntos. Las disciplinas documentan lo que necesitan.

Para otras combinaciones de estos factores, un pequeño equipo de arquitectos, probadores, expertos en operaciones y desarrolladores líderes podría comenzar con iteraciones de arquitectura construyendo lentamente la arquitectura, documentando y recibiendo comentarios inmediatos sobre sus decisiones de arquitectura. Poco a poco se pueden agregar al equipo más desarrolladores que implementan características y el equipo central original se puede hacer más pequeño.

Principalmente para proyectos gubernamentales y financieros, se requiere que se escriba más documentación por adelantado y eso puede llevar mucho tiempo sin comentarios reales sobre sus elecciones. En mi opinión, la razón más importante por la que muchos de estos proyectos fracasan. Aún así, si esta es su situación, haría la documentación para cumplir con los requisitos y luego usaría la opción 1 o 2 para construir el software y refinar / adaptar la documentación.

Espero que esto ayude.

Sé que esto no será muy popular, pero el comentario que hiciste

En el otro extremo de la escala, si todo está especificado, la especificación lleva más tiempo que el desarrollo. Y te arriesgas a tener tareas de desarrollo muy aburridas.

en realidad es algo por lo que debes esforzarte. Si el diseño y las especificaciones son lo suficientemente sólidos como para que las tareas de desarrollo sean aburridas, entonces el costo del desarrollo disminuye. Arreglar una especificación es mucho menos costoso que arreglar el código, y el mayor costo de los proyectos de software no es la compilación, es el soporte a largo plazo. Y el código de soporte que se basa en una especificación sólida es mucho menos costoso.

No estoy completamente de acuerdo con la respuesta de maple_shaft, ¡pero no había suficiente espacio en el comentario para decir todo mi comentario! ;-)

Estoy de acuerdo en que cada desarrollador puede y debe ser un arquitecto, pero eso no significa que cada desarrollador deba ser responsable de la arquitectura de un producto o sistema completo. Además, no creo que pueda pintar a todos los equipos de arquitectura con el mismo pincel ancho, y cuando se hace correctamente, los equipos de arquitectura pueden ofrecer un gran valor al proceso general de desarrollo de productos. La idea errónea es que los arquitectos deberían dictar cada aspecto del diseño del sistema. En su lugar, deberían centrarse en el diseño de nivel superior y dejar los detalles de implementación a sus equipos de desarrollo. Sin embargo, eso no quiere decir que los desarrolladores no deberían participar en el proceso de planificación y diseño desde el principio.

Cuanto más grande, más modular y, en última instancia, más complejo sea un producto, es más probable que encuentre diferentes partes del producto manejadas por diferentes equipos de desarrollo. Dichos equipos no necesitan comprender el sistema en su conjunto, siempre que tengan una comprensión completa de las partes del sistema de las que son responsables. A menudo, estos equipos adicionales son contratados como subcontratistas con el propósito específico de desarrollar un módulo en un área particular de tecnología en la que los arquitectos u otros equipos pueden no tener experiencia. Mis propios talentos particulares se encuentran en el desarrollo de API, y aún no he visto una API bien factorizada que se desarrolló completamente de forma orgánica sin ser un desastre completo en términos de usabilidad, o eso no requería que alguien se destacara como la persona que se aseguró de que hubiera un nivel de uniformidad entre los diferentes aspectos de la API. Puedo seguir enumerando muchos ejemplos y razones, pero no creo que este tipo de situaciones sean la torre de marfil BS que muchos podrían pensar que son. Desafortunadamente, hay muchos lugares, particularmente en las áreas de defensa, médica y los sectores financieros donde la paranoia corporativa resulta en un desarrollo de productos mal especificado y aún más mal administrado del tipo que estoy seguro de que maple_shaft estaba más preocupado. Estas son las cosas que creo que dan a los arquitectos un mal nombre mal merecido (en general). Desafortunadamente, hay muchos lugares, particularmente en las áreas de defensa, médica y los sectores financieros donde la paranoia corporativa resulta en un desarrollo de productos mal especificado y aún más mal administrado del tipo que estoy seguro de que maple_shaft estaba más preocupado. Estas son las cosas que creo que dan a los arquitectos un mal nombre mal merecido (en general). Desafortunadamente, hay muchos lugares, particularmente en las áreas de defensa, médica y los sectores financieros donde la paranoia corporativa resulta en un desarrollo de productos mal especificado y aún más mal administrado del tipo que estoy seguro de que maple_shaft estaba más preocupado. Estas son las cosas que creo que dan a los arquitectos un mal nombre mal merecido (en general).

Entonces, ¿dónde está el término medio que estaba buscando el OP? La respuesta tiene que ver con abrir canales de comunicación. Los arquitectos deben entregar especificaciones que describan sus diseños con suficiente detalle para garantizar que los equipos de desarrollo entiendan dónde están los límites. Historias y escenarios de características en el sentido más amplio, donde todo se considera una caja negra. Luego, los arquitectos deben asegurarse de que los equipos tengan acceso al tiempo del arquitecto para confirmar cualquier suposición, y que se responda cualquier pregunta sobre especificaciones que parecen demasiado amplias o poco claras. Después de eso, se trata realmente de garantizar que los equipos individuales sean conscientes de en qué están trabajando los otros equipos, y que sepan con quién comunicarse en los otros equipos para garantizar que cada parte del sistema jugará bien con las otras partes. Estos equipos se encuentran directamente. Una vez que el sistema ha sido diseñado al nivel más amplio, los arquitectos deberían ser realmente las personas a las que recurren los equipos cuando necesitan un control de la cordura, y para garantizar que se mantenga la "visión" del producto. También deben tener en cuenta cualquier proceso de integración requerido y proporcionar una "cobertura aérea" muy necesaria para los equipos de desarrollo de los gerentes, clientes y cualquier otra parte interesada, al tiempo que se aseguran de que estas diversas personas puedan reunirse para trabajar entre ellos cómo deberían funcionar las cosas.

En primer lugar, los arquitectos de la OMI deben ser facilitadores y comunicadores, y los diseñadores en segundo lugar. ¿En cuanto a qué nivel de especificación? Creo que los mejores arquitectos son los que preguntan a sus equipos sobre el nivel de detalle que un equipo quiere, y entre ellos encuentran un equilibrio que funciona. Los diferentes equipos pueden tener diferentes requisitos en términos de la cantidad de documentación o instrucciones requeridas. Los equipos de alto nivel pueden encontrar un diagrama aproximado y una conversación rápida puede ser suficiente para comenzar, mientras que los equipos llenos de desarrolladores relativamente jóvenes pueden necesitar un poco más para que funcionen. Sobre todo, el arquitecto necesita alentar a los desarrolladores a ejercer sus propios talentos de diseño para obtener el mejor resultado final de cada equipo.

Como te esfuerzas por mejorar algo, ya has detectado un problema en tu proceso. La causa raíz de la situación específica podría ser la siguiente: los desarrolladores no pueden identificarse con la arquitectura, porque alguien externo les impuso. Es muy probable que la entrega de la arquitectura al desarrollo no resuelva esta causa raíz.

Haga que la arquitectura sea parte del equipo de desarrollo. Derriba la frontera entre el arquitecto y el desarrollador. Esto asegura que la información fluirá. Si el equipo de desarrollo participa en la configuración de la arquitectura, no la considerarán algo extraño. Infundir conocimiento sobre arquitectura en el equipo. Enséñeles los factores que impulsan la arquitectura corporativa para evitar el caos que mencionó. Involucre a los desarrolladores cuando se deban tomar decisiones arquitectónicas para evitar el aburrimiento que mencionó. Ya no se requiere una transferencia y usted ha cumplido su rol como arquitecto en un equipo de desarrollo.

Debe proporcionar tanta información como sea posible para que el futuro equipo mantenga el código. Si no tiene diagramas de secuencia, por ejemplo, el desarrollador se ve obligado a rastrear el código paso a paso, perdiendo así el tiempo.

También hay espacio para que el nuevo equipo haga suposiciones que no son válidas.

En general, debe haber un documento sobre el proyecto, las especificaciones técnicas, los casos de prueba de la unidad y los diagramas de secuencia / clase.

Diría que las vistas de diagramas de clase que crean un modelo y un código son una solución. El diagrama de clases representa la vista estática de la arquitectura de su proyecto. Me refiero a que tiene paquetes> clases, intefaces, enum> atributos, métodos, etc ...> etc. Si se ve bien, el metamodelo UML2 tiene exactamente la misma estructura que un proyecto java o dotnet.

Lo que usamos en nuestros proyectos son simplemente diagramas de clases que se guardan en un solo modelo. Generamos vistas del modelo si el clasificador ya existe o creamos uno nuevo en gráfico si es nuevo. Los desarrolladores pueden ver nuestros diagramas y modelos porque están guardados en la raíz del directorio del proyecto dentro de CVS. Lo que me gusta es que también el desarrollador puede modelar porque si algo se cambia a nivel de código, el modelo se actualiza automáticamente en CVS para todo el equipo.

Funciona realmente bien y no hay necesidad real de conocer UML porque el diagrama de clase es realmente simple y la ingeniería inversa hará el trabajo y creará la vista gráfica del código. Navegación simple, vistas avanzadas y detalladas donde se pueden agregar muchos comentarios con diagramas siempre actualizados y visibles en CVS directamente en el proyecto. Mi diagrama de clase UML ahora es Magic :-)