¿Qué hacen los arquitectos en Agile? ¿Serán los arquitectos parte del equipo de desarrollo?

El hecho de que el arquitecto técnico sea ​​un rol del pasado es un concepto erróneo que probablemente surge de la configuración ágil (poder del equipo; todas las tareas se distribuyen dentro del equipo), que no es más que un concepto erróneo del “rol de TA en ágil ”, pero luego más sobre eso.

El papel de TA : en muchos casos, especialmente en grandes proyectos, tiene varias capas de aplicaciones, dependencias entre sistemas, procesos que dependen de otros, altas demandas en la arquitectura de la infraestructura … Simplemente no puede cortar esta alta complejidad en muchos tareas pequeñas (e independientes) y que se distribuyan entre muchos desarrolladores a través de muchos sprints. Este enfoque no funcionaría en un proyecto de alta complejidad.

Cuanto más complejo es el proyecto, mayor es la demanda de un TA dedicado . O incluso más de un TA; en el caso de que tenga varios TA, necesitaría un TA de dirección , este rol sería Enterprise Architect o podría llamarlo TA principal.

TA es un desarrollador senior, experimentado , o al menos familiar, con todos los dominios técnicos del proyecto y tiene una visión general del alcance del proyecto; él / ella diseña los conceptos técnicos, define soluciones / enfoques, pautas, arquitectura de infraestructura …

Además, TA es un líder en el dominio técnico ; no solo creando los conceptos, sino también a diario: se enfrenta a los desafíos cuando los desarrolladores implementan las soluciones basadas en sus directrices, cuando es necesario alienta a los desarrolladores, los motiva, los consulta y los guía. Por demanda, también es consultado por los desarrolladores. Además, TA es un consultor para el PO (propietario del producto).

Ágil y TA : en ágil, especialmente scrum, no tenemos el papel de TA definido. Hay un equipo de desarrollo y todos los miembros de desarrollo actúan como uno solo; Todas las tareas se distribuyen entre los miembros del desarrollador. Entonces, ¿qué pasa con TA?

De hecho, scrum toma un atajo aquí: simplemente excluye esta función, así como todos los NFR (requisitos no funcionales) de scrum. Scrum solo se trata de código entregable. El concepto o la infraestructura simple no tienen valor comercial directo. Por lo tanto, muchos profesionales de scrum consideran que los requisitos no funcionales (como configuración, TA, interfaces de datos …) no forman parte del equipo de scrum. Desde el punto de vista religioso, tienen razón al respecto: el scrum “listo para usar” es así, se trata de implementar y entregar software de trabajo. Pero la realidad es diferente, simplemente necesita responder a todos estos temas de asistencia técnica para poder cumplir.

Entonces, ¿cómo hacerlo entonces? Supongo que en un enfoque religioso, un TA actuaría independientemente del equipo scrum. ¿Pero quién lo dirigiría? ¿Cuándo entregaría su trabajo entonces? ¿Cuándo reaccionaría él al cambio, a mejorar? Entonces entraríamos en una especie de cascada, supongo.

Como lo hago En mis equipos, los TA son parte de los equipos de desarrollo. Incluso cuando no trabajan en la implementación, apoyan al equipo y tienen un intercambio regular. En algunos casos, creamos tickets de NFR para los TA y, a veces, utilizamos el tablero Kanban para las tareas de TA. Mientras el TA no implemente, eliminamos su capacidad para que no influya en la velocidad del equipo. Tan pronto como TA realiza alguna implementación, tomamos esta disponibilidad en velocidad.

Soy arquitecto principal y paso aproximadamente la mitad de mi tiempo en el trabajo diario del proyecto; Utilizamos Scrum para el trabajo del proyecto.

Durante la etapa inicial del proyecto (primera iteración en nuestro proyecto), un arquitecto guía al equipo hacia un diseño y una arquitectura que satisfagan los requisitos comerciales en su conjunto. Trabajo con el equipo para producir una estimación de alto nivel para todo el proyecto. Algunos de estos requisitos podrían cambiar y cambiarán durante el curso del proyecto. Tratamos de ser claros y cuidadosos con los requisitos de alto nivel y la arquitectura de la solución. Si estos cambian, todas las apuestas están canceladas y estamos de acuerdo con eso.

Una vez que pasamos la fase inicial, ayudo con el dominio, la tecnología y la resolución de problemas según sea necesario.

Durante el proyecto, puedo hacer una suposición decente cuando las cosas parecen ir mal. Puedo sentir esto solo porque estoy en standups diarios, planeando, preparando reuniones y hablando con los miembros del equipo todos los días. Creo que esta verificación intestinal también proviene de la experiencia con proyectos tecnológicos pasados. Los arquitectos son los más adecuados para este tipo de evaluación en mi opinión. Cuando esto sucede, trabajo con el equipo para desarrollar las incógnitas y restablecer las expectativas con la gerencia si es necesario. A veces, cambiamos el alcance, o cambiamos la fecha de lanzamiento anticipada, o ambos, y nuestra administración prefiere los problemas conocidos más temprano que tarde. Para repetirme, no puedo ver el riesgo y el plan de acción si no formo parte activamente del proyecto. Al final, es un fracaso para todos nosotros si el proyecto falla. Los ingenieros principales y superiores también deberían poder hacerlo, pero todavía no los he visto hacerlo en mi lugar. Cuando lo veo, supongo que tenemos un arquitecto en las obras. 🙂

Hay otros beneficios para los arquitectos desde una perspectiva egoísta; Es importante que los arquitectos aprendan de las elecciones de arquitectura y diseño que se hicieron al principio y entiendan lo que funcionó y lo que no funcionó según lo previsto durante la ejecución. Este no es un diseño grande y gordo; Creo dos o tres dibujos en la pizarra sobre los elementos clave de la arquitectura, hablo lo suficiente sobre la elección de la tecnología y cómo esto se remonta a los requisitos de alto nivel. Esto es lo que uso para convencer a nuestra gerencia, a nuestro equipo y a mí mismo de que tenemos una buena oportunidad de tener éxito.

Trabajo en visión y validación para futuras iniciativas con el tiempo restante. Comprendemos activamente problemas adicionales del mercado y validamos diseños de soluciones y tecnología a través de POC en esta fase.

En los viejos tiempos de Big Design Up Front en la década de 1990, era una práctica común tener personas con el título de Arquitecto en relieve en sus tarjetas de visita. De hecho, muchos programadores aspiraban a convertirse en arquitectos, lo que significaba más prestigio y más dinero. En este milenio, sin embargo, no recuerdo haber encontrado personas que todavía entreguen tarjetas de presentación, o personas que todavía tengan el título de Arquitecto.

La mayoría de los equipos de desarrollo de hoy en día están formados por personas bien versadas en muchos aspectos del desarrollo de software, incluido el diseño del sistema (también conocido como arquitectura de software), programación, pruebas automatizadas y DevOps. Si uno se imagina a sí mismo arquitecto, probablemente necesite convertirse en un programador aceptable y también debe convertirse en un experto razonable en DevOps.

La belleza de la producción de software ágil centrada en el equipo es que suele haber personas con fortalezas complementarias. Hoy en día todo el mundo es esencialmente un desarrollador (confirmando código, revisando solicitudes de extracción e implementando lanzamientos), pero generalmente hay un desarrollador alfa que emergerá para convertirse en el influyente de facto en la determinación de las decisiones arquitectónicas.

Espero haber respondido a su pregunta. ¡Todo lo mejor!