¿Por qué los procesos? Reid Holmes Traducción: Jorge Pincay Ponce Los procesos de software son un mecanismo para nosotros estructurar el diverso conjunto de actividades que están involucrados en la construcción de sistemas de software modernos, porque nuestro objetivo final es construir un sistema exitoso y sostenible que se usará en los próximos años. Cuando pensamos en estructurar el proceso para nuestro sistema, lo hacemos en términos de dimensiones simples. Primero, pensamos en qué estamos realmente tratando de construir.
1 A continuación, queremos considerar quién va a hacer el edificio, y especificar correctamente ¿Quiénes son las personas involucradas en todo este proceso de desarrollo de software? A continuación, queremos pensar ¿cómo van estos diferentes equipos a coordinarse el uno con el otro?, ¿Cómo van a construir realmente el sistema?, y finalmente, por supuesto, necesitamos una línea de tiempo, porque en última instancia, queremos entregar nuestro software. Entonces, ¿cuándo se va a hacer todo? La construcción de sistemas de software implica la colaboración y cooperación de una amplia variedad de interesados en los proyectos. Tenemos a los desarrolladores, que son en realidad el equipo que va a construir el producto, el equipo de QA que es quien va a estar validando que el producto funciona, el equipo de DevOps que asegurará que el producto se pueda ejecutar en la práctica y se puede implementar, por supuesto, tendremos involucrado algo de gestión para ayudar a coordinar estos diversos equipos técnicos. Pero también hay partes interesadas no técnicas que están involucradas y que juegan un papel importante. Por ejemplo, tendremos algún tipo de equipo de ventas y marketing, que va a poder vender nuestro producto a los clientes. Vamos a tener nuestros usuarios, que usarán el producto, y con suerte estarán involucrados en la construcción y el ciclo de retroalimentación del software. Si nuestro producto es exitoso tendremos un equipo de soporte, capaz de apoyar a esos usuarios de forma continua y también capaz de ayudar a retroalimentar al equipo técnico, para garantizar que el producto pueda utilizarse con éxito en la práctica. Cómo se ha visto, todas las partes interesadas tienen diferentes antecedentes, diferentes conocimientos, diferentes objetivos y diferentes restricciones; esto significa que todos tendrán diferentes opiniones sobre cómo el software debe ser construido, por lo que es importante que puedan comunicarse de manera efectiva y concreta, para tener un consenso sobre cómo se debe construir el sistema en el futuro. La construcción de un consenso requiere diferentes tipos de documentación y procesos para ayudar a todos a entender lo que realmente está sucediendo. Y los tipos de artefactos que usarán las diferentes partes interesadas variará, en función de sus antecedentes y experiencia. Cada actor interesado en el producto necesitará una forma diferente de documentación para comunicarse de manera efectiva y concreta con los demás. Y este tipo de documentación realmente se descompone en cuatro amplias categorías: • Especificación, • Desarrollo, • Validación,
•
Despliegue y evolución.
Cuando pensamos en la especificación del sistema, vamos a pensar, tal vez, en declaraciones de misión, objetivos de negocios y requisitos en sí mismos. Los tipos de partes interesadas, como gerentes, usuarios y ventas, que están realmente involucrados en definir lo que el sistema debe hacer, van a estar muy involucrados en ese tipo de documentos. Cuando pensamos en documentos de estilo de desarrollo, vamos a pensar en planes arquitectónicos de sistemas, planes de diseño y planes de implementación. Ahora, estos son menos significativos para el equipo de marketing, pero van a ser extremadamente importantes para los gerentes, desarrolladores y equipos QA.
2 A continuación, cuando pensamos en los documentos de validación, pensamos en planes de prueba, evaluaciones de riesgos. Y estos documentos son específicamente utilizados por el equipo QA para asegurarse de que estén validando el sistema de manera efectiva. Ahora estos documentos, de nuevo, se usarán en conjunto con el equipo de desarrollo, para asegurarse de que ambos están trabajando desde el mismo conjunto de ideas y con una comprensión compartida. Finalmente, tendremos documentos sobre el despliegue y la evolución. Entonces estos incluirán planes de DevOps y estrategias de mantenimiento, para que podamos entender cómo evolucionará el sistema a largo plazo. Es importante tener en cuenta que no todos los equipos usan cada uno de estos documentos para cada proyecto. Por ejemplo, si estás construyendo una aplicación relativamente pequeña, es posible que no tengas un plan arquitectónico, porque tu sistema es tan simple que realmente puedes seguirlo desde sus componentes principales de alto nivel. Al mismo tiempo, sin embargo, puede que los necesitemos para ayudar a aumentar la transparencia entre las diferentes partes interesadas del producto, porque ese es realmente su papel. El papel/rol de los documentos es asegurarse de que todas las partes interesadas sean capaces de entender completamente cuáles son los riesgos y como se va a construir el sistema. Entonces, realmente, la documentación es un mecanismo clave para mitigar el riesgo asociado con la construcción de productos de software, asegurándose de que todos estén en sintonía de lo que se está construyendo, qué va a pasar y cuándo.