Mi gerente me promovió recientemente a "diseñador de software". No soy consciente de que este título existe. Hasta donde yo sé, SA crea un diseño de código de alto nivel y hace diagramas.

Me cuesta entender qué diseño de código de alto nivel debo hacer. Según mi gerente, debería diseñar todas las clases y todos los métodos dentro de esas clases. Es decir, diseñaría toda la estructura del código y permitiría a mi equipo implementar la funcionalidad de cada función o clase. Por ejemplo, en un sistema CRUD debería poder planificar qué función se debe usar o qué clases se crearán.

Dada mi experiencia en el diseño de software, esto me pareció extremadamente imposible de hacer. Como desarrollador, siempre creo mis propias clases, defino e implemento mis propias funciones. Nunca he experimentado diseñar funciones para otros.

Mis preguntas son:

• ¿Es esto común? Para un sistema muy grande, ¿la base del código no cambia todo el tiempo?
• Se puede hacer esto?

Me doy cuenta de que podría estar haciendo una pregunta obvia y estúpida aquí, pero siempre he sido un desarrollador habitual hasta ahora y, por lo tanto, no tengo experiencia en el diseño de sistemas completos.

Notas preliminares sobre títulos:

• A veces, lo que realmente haces no coincide en absoluto con tu título oficial. Como ejemplo, hace años, me contrataron como "analista-programador en el departamento de I + D"; sin embargo, nadie contratado hizo análisis, ni programación, ni investigación, ni desarrollo. Lo que yo (y otros) realmente hicimos fue codificar. Un mono podría hacer la mitad de las cosas que hice. Cualquier interno de pregrado podría hacer la otra mitad.

• A menudo, el título no importa. En algunas empresas, puede terminar haciendo muchas tareas diferentes y diversas, y simplemente no hay un título que describa todo eso. En una empresa, hice las tareas de un arquitecto, un jefe de equipo, un gerente, un tipo de experiencia de usuario, un codificador y un especialista en productividad, y me aseguré de que dos equipos se comunicaran correctamente entre sí. No hay un título único para eso.

• Finalmente, los títulos pueden tener diferentes significados en diferentes compañías, o las personas que dan títulos en primer lugar no tienen la menor idea sobre el significado real del título, si es que lo hay. En algunos casos, solo hay títulos de moda y palabras de moda. No necesita un administrador del sistema, eso está pasado de moda. Necesita un especialista de DevOps. No trata de inteligencia empresarial o minería de datos cuando intenta contratar a alguien: ¡habla de Big Data!

Así que olvídate de los títulos y concéntrate en lo que te pidieron exactamente. Afortunadamente, tu pregunta hace exactamente eso.

¿Es esto común? Para un sistema muy grande, ¿la base del código no cambia todo el tiempo?

No lo he visto, y no creo que pueda ser sostenible.

Se puede hacer esto?

Sí, pero a costa de que la gente normal abandone el equipo.

Lo que su gerente puede tener en mente es que usted hace el diseño y lo presenta en forma de diagramas UML. Es anticuado, pero a quién le importa? La práctica fue bastante popular en algunas empresas, y aún funciona decentemente bien en otras. Puede ser un enfoque adecuado si eres muy hábil, pero todos los demás miembros de tu equipo son programadores principiantes: simplemente no tienen suficiente experiencia para hacer el diseño adecuado por sí mismos, y estás en una muy buena posición para ayudar ellos.

Si yo fuera usted, comenzaría hablando con su gerente, para determinar si realmente es esto lo que tiene en mente. En caso afirmativo, juegue el juego y pruebe este enfoque durante una semana o dos . ¿Qué podría pasar?

O descubrirá que el enfoque funciona bien para su equipo, en cuyo caso, agradezca a su gerente por su conocimiento, o el enfoque no funcionará.

En este caso, hable primero con su equipo para identificar todos juntos por qué no funcionó y qué se debe hacer para mejorar el proceso (en otras palabras, hacer una retrospectiva). Luego, implemente los cambios en el proceso si está en condiciones de hacerlo, o visite a su gerente y analícelo con él.

Entonces repite. Cada dos semanas (o lo que parece apropiado en su contexto).

Idealmente, Arquitecto de software es otro término para Ingeniero de software sénior , tal vez con algunas responsabilidades adicionales, o como una forma de proporcionar un reconocimiento general de esa persona de que es el punto de contacto oficial sobre cuestiones técnicas con los sistemas con los que trabaja, o que los miembros menos conocidos del equipo de desarrollo pueden confiar en ellos cuando no saben por qué alguna parte del sistema ha sido diseñada de una manera particular. o están luchando con un problema cuando no pueden encontrar una solución buena / aceptable a un problema.

En mi opinión, un arquitecto de software no debe ser alguien que trabaje en una proverbial 'torre de marfil' creando diseños o tomando decisiones unilaterales para otros desarrolladores; Las decisiones de diseño aún deben ser impulsadas por las personas que participan activamente en la escritura y el mantenimiento del código, y los equipos de desarrollo deben tener una responsabilidad colectiva, siendo los desarrolladores individuales responsables de la calidad de su propio código, de comprender el diseño de un sistema, y por no introducir cambios que "rompan" la arquitectura o que introduzcan niveles inaceptables de deuda técnica.

Si bien a veces puede ser valioso capturar el diseño de alto nivel de un sistema como un medio para ayudar a un equipo de software a comunicar ideas y compartir conocimientos (particularmente a los recién llegados y desarrolladores sin experiencia), la actividad principal del diseño es escribir el código en sí (incluidas las pruebas automatizadas); Tendría sentido que un Arquitecto de software se 'apropiara' de la documentación de diseño, aunque eso no es lo mismo que decir que ellos son los que la escriben; Además, se aseguran de que el equipo cree la documentación necesaria y suficiente, y que esté disponible para revisar su exactitud.

A todos los efectos prácticos, hay poco o ningún valor para intentar separar el papel del diseño de software del desarrollo porque son esencialmente lo mismo; de hecho, la realidad suele ser bastante perjudicial porque tiende a generar una mentalidad por la cual los desarrolladores son tratados como "monos de código" de la línea de producción que tienen prohibido pensar por sí mismos.

Según su descripción, parece que su gerente quiere que asuma una posición de liderazgo y no sabe cómo articular esto

Él lo promovió y quiere que diseñe el software y divida las tareas. Su confusión sobre cómo articular es natural. Te está colocando en una posición de liderazgo que puede confundirse fácilmente con su papel de gerente.

Los equipos de desarrollo tradicionales tienen un solo administrador que se divide entre actividades externas (buscar financiación, política, talentos de caza de cabezas, vender ideas y productos, etc.) y actividades internas (coordinar el desarrollo). Pero estas actividades están en conflicto y requieren diferentes conjuntos de habilidades. Por lo general, "el gerente" es bueno en las actividades externas y malo en las internas.

Estos roles se pueden separar. En realidad es una de las características clave de la Metodología Scrum. Los equipos exitosos y productivos que conozco separaron esos roles. Y la mayoría ni siquiera sabe que están haciendo eso: uno de los programadores comenzó a organizar el equipo y el gerente lo dejó.

Esto solo funciona si existe un vínculo de confianza entre "el gerente" y el "desarrollador principal". Muchos equipos fallan. A medida que uno de los desarrolladores asume el liderazgo, el gerente puede sentirse amenazado o celoso. El equipo puede perder el respeto del gerente porque él o ella está fuera todo el tiempo y no entienden la importancia de las actividades externas. Es importante ser consciente de eso y evitar esos problemas.

Cómo dividir las tareas.

Para dividir las tareas no necesita seguir su ejemplo.

Es importante abusar de la prueba de conceptos, prototipos exploratorios funcionales para que el progreso del equipo sea más visible para él. Lo importante es que siente que el desarrollo está progresando.

Una forma de lograr eso es hacer un prototipo solo de sql. Cree tablas, complete con datos, cree casos de prueba de solo sql que ejecuten las consultas que harían las pantallas y rutinas principales. Cuando esté seguro de que la simulación es buena, divida el trabajo entre sus desarrolladores junior para construir las pantallas y las rutinas. Mientras sus desarrolladores junior están trabajando, usted está haciendo los prototipos para el próximo ciclo de desarrollo.

Todos están ocupados, la productividad es alta, el gerente está contento.

Pruébelo por un par de sprints, pero molestará seriamente a los desarrolladores que está administrando y, a su vez, se quejarán de quien esté escuchando.

Asumiría que está estableciendo las decisiones generales de arquitectura (push vs pull; patrones de mensaje; si service x debe ser DDD o CRUD bien) para el equipo; luego usando el proceso de revisión de código y el emparejamiento para mantener a todos en el camino y ayudarlos si se estancan.

Realmente no tiene que ser de arriba abajo, muerte por UML. Lo que estás buscando son clases en el lugar equivocado; la lógica de negocios no está donde la esperabas, etc.

No sea demasiado duro con el equipo si están aprendiendo algo conocido, primero trabaje en cualquier principio nuevo y luego elimine las malas prácticas persistentes.