En Brightcove creemos en la mejora continua. Esto no sólo se aplica a nosotros mismos y a nuestro software: también se aplica a nuestros procesos. Recientemente, un grupo de personas nos reunimos para hablar sobre cómo nos estaba funcionando nuestro proceso de revisión de la arquitectura y decidimos renovarlo. Queremos un proceso de revisión de la arquitectura que sea:
- Iterativo
- Cómodo
- Adaptable a distintos tipos de proyectos
- Respetuosa con la experiencia de los participantes
El resultado final fue el siguiente documento que describe nuestro proceso actualizado.
¿QUÉ ES LA ARQUITECTURA?
La arquitectura de software consiste en tomar decisiones estructurales fundamentales que son costosas de cambiar una vez implantadas (fuente).
¿CUÁL ES EL PROCESO?
Diseñar software es un proceso continuo. Si fuera posible saber todo lo que necesitamos saber para tomar decisiones perfectas de antemano, no necesitaríamos agile. Para reflejarlo, nuestro proceso de revisión de la arquitectura tiene varios pasos que pueden adaptarse a las necesidades de cada proyecto.
Puede que no sea necesario realizar todos estos pasos. Puede ser útil repetir los pasos. En general, una revisión y una retrospectiva deben considerarse el mínimo. Haga lo que tenga más sentido para alcanzar los siguientes objetivos:
- Tomar las mejores decisiones posibles sobre arquitectura de software
- Elaborar documentación de ingeniería útil
- Aprende sobre la marcha y adapta tus planes a lo que vayas aprendiendo
- Mantén a tus compañeros informados de lo que has decidido y de lo que has aprendido
Las siguientes secciones describen cada paso del proceso.
TALLER DE ARQUITECTURA
Tal vez esté planeando un nuevo proyecto, pero aún no sabe cómo llevarlo a cabo. Tal vez tengas un reto que aún no está totalmente definido. Tal vez tenga tres perspectivas diferentes sobre un reto y no esté seguro de cómo elegir una. Tal vez tenga una idea para un cambio arquitectónico y le gustaría conectarla con el planteamiento de un problema. En lugar de atrincherarse y tratar de responder a estas preguntas en un silo, es bueno empezar a hablar con otros expertos desde el principio. Esto facilita la incorporación de comentarios y la consideración de grandes cambios antes de que el plan esté demasiado establecido. También ayuda a que la revisión de la arquitectura se desarrolle sin problemas, ya que la arquitectura estará más preparada.
LISTA DE CONTROL
- Invitar a expertos en la materia (por ejemplo, jefes de los equipos afectados).
- Invitar al canal Slack de revisiones de arquitectura
- Sugerir de 3 a 8 asistentes
SUGERENCIAS
- Empiece por proporcionar el contexto completo y explicar el problema que hay que resolver. Invitar a alguien que no tenga conocimientos previos puede ayudar a afinar el planteamiento del problema y a cuestionar los supuestos.
- Los talleres de arquitectura pueden ser especulativos. Puede que la idea no acabe saliendo adelante, o que en su lugar se convierta en un proyecto de la hackweek. Pero no hay problema. Si lo único que has conseguido es que algunos expertos debatan y aprendan más sobre los retos a los que nos enfrentamos, ha sido una victoria.
- Si hay demasiadas incógnitas para seguir adelante, plantéate algunas actividades de investigación y vuelve a intentarlo. Los prototipos, los picos de investigación y la lectura son herramientas útiles en esta fase.
- Invite también a no expertos. Es una buena oportunidad para que la gente adquiera más experiencia en el diseño arquitectónico. La mejor manera de aprender a diseñar buena arquitectura es intentarlo uno mismo y fracasar unas cuantas veces u observar cómo lo hacen otras personas.
REVISIÓN DE LA ARQUITECTURA
Una revisión de arquitectura es la presentación de su arquitectura a un público amplio. Aquí queremos la mayor participación posible. Estás solicitando comentarios adicionales y educando a la audiencia sobre tu proyecto. Si es posible, esto debe hacerse antes de que comience el desarrollo.
LISTA DE CONTROL
- Invitar al canal Slack principal de ingeniería
- Recordatorio #ingeniería justo antes de empezar la reunión
- Crear documentación de ingeniería antes de la revisión de la arquitectura y compartirla con los participantes con antelación.
- En la reunión, repase la documentación, explíquela en detalle y solicite preguntas y comentarios.
SUGERENCIAS
- Empiece proporcionando el contexto completo y explicando el problema que hay que resolver. Recuerde: su audiencia probablemente incluya a personas que son nuevas en Brightcove y a personas que no tienen ningún contexto sobre su área de ingeniería. Evite decir "como usted ya sabe...", ya que puede alejar a los recién llegados y reducir la participación.
- Elabore documentación de ingeniería que se actualizará en el futuro, no sólo un documento puntual. Al final del proyecto, lo ideal es disponer de documentación actualizada de lo que se ha construido. Esta documentación puede utilizarse como referencia, para compartirla con las partes interesadas, para preparar a los nuevos miembros del equipo, etc.
- Sea visual en su documentación. Los diagramas y las fotos de pizarras blancas pueden ayudar a los lectores a asimilar tus ideas con eficacia.
- Es posible que sientas que esto es una defensa en lugar de un ciclo de retroalimentación. Si sientes que estás a la defensiva, recuerda que no necesitas tener todas las respuestas ahora. Está bien decir: "Gracias por plantearlo, nos pondremos en contacto con usted cuando hayamos tenido tiempo para pensarlo".
- No se espera que hagas todo lo que te digan. Los desacuerdos están bien. Pasar algo por alto no es tan estupendo. A medida que las personas aprenden unas de otras, gravitarán hacia las mejores ideas.
DOCUMENTACIÓN
A continuación se ofrecen algunas sugerencias sobre qué incluir en la documentación. No todas ellas serán pertinentes para todos los proyectos.
- Interacciones del sistema
- Interfaces
- Modelización de dominios
- Plan de despliegue
- Tecnologías utilizadas
- Dónde vivirán los anfitriones
- Plan de seguimiento
- COGs
- Facturación
- Experiencia del usuario
- Mantenibilidad
- Compromisos aceptados (deuda técnica, etc.)
- Seguridad
- Patrones potenciales de abuso
- Prácticas de codificación seguras
- Autenticación / autorización
- Auditoría / registro
DIRECTRICES PARA LOS PARTICIPANTES
- Presentar nuevas ideas a un gran grupo puede ser bastante estresante. Por favor, ¡ayúdales a tener una buena experiencia!
- Evita defender tus ideas elevando lo que está en juego, por ejemplo: "Si no haces esto, el proyecto fracasará". Céntrate en explicar las ramificaciones concretas que crees que se están pasando por alto.
- Evite decir "Por qué no...". Esto sugiere que el presentador está cometiendo un descuido evidente. Suele tratarse de una cuestión de perspectiva, por lo que enfocarlo desde la curiosidad y la exploración puede conducir a una conversación más constructiva.
- Si tienes la sensación de que algo no va a funcionar, pero no estás seguro de por qué, quizá sea mejor pensarlo un poco más antes de sacar el tema. O, si quieres plantear una corazonada, llámala por su nombre. Por ejemplo: "Tengo la corazonada de que hay un problema con el uso de esta herramienta en la que no estamos pensando, así que quiero volver sobre ello más tarde".
ACTUALIZACIÓN DE ARQUITECTURA
En los proyectos de larga duración, es útil reunirse periódicamente para hablar de los avances del proyecto. Esto sirve de retroalimentación sobre los progresos realizados hasta el momento, de revisión de la arquitectura actualizada y de oportunidad para cambiar los planes en función de lo aprendido.
LISTA DE CONTROL
- Invite a todos los participantes en el proyecto
- Invitar al canal Slack de revisiones de arquitectura
- Actualice la documentación de ingeniería que creó en la revisión para que refleje el estado más reciente del software.
- Solicite notas retrospectivas antes de la reunión. Deje un espacio para que los asistentes escriban lo que funciona, lo que no funciona y las medidas que sugieren.
- En la reunión, repase la documentación técnica actualizada, llame la atención sobre los cambios y solicite preguntas y comentarios.
- En la reunión, haz que todos lean sus notas retro y fomenta el debate
SUGERENCIAS
- Para proyectos de larga duración, puede ser aconsejable hacerlo al menos una vez al trimestre. Así se pueden descubrir problemas ocultos o nuevas ideas novedosas, aunque el proyecto vaya bien.
- Si crees que ya es hora de celebrar esta reunión, probablemente tengas razón. No esperes al final del trimestre, del proyecto, etc.
ARQUITECTURA RETRO
Celebre esta reunión después de que el software haya sido enviado. Esencialmente, es lo mismo que la actualización de la arquitectura, salvo que es la última y debe incluir a un público más amplio.
LISTA DE CONTROL
- Invite a todos los participantes en el proyecto
- Invitar al canal Slack principal de ingeniería
- Actualice la documentación de ingeniería que creó en la revisión para que refleje el estado más reciente del software.
- Solicite notas retrospectivas antes de la reunión. Deje un espacio para que los asistentes escriban lo que funcionó, lo que no funcionó y los cambios sugeridos.
- En la reunión, repase la documentación técnica actualizada, llame la atención sobre los cambios y solicite preguntas y comentarios.
- En la reunión, haz que todos lean sus notas retro y fomenta el debate
SUGERENCIAS
- La retrospectiva es una reunión en la que no siempre es mejor ceñirse al orden del día. Si alguien quiere hablar de un reto concreto, hay que dejarle tiempo. Siempre puedes programar más tiempo si es necesario.
