Original source: https://agilemodeling.com/essays/modelstorming.htm
La tormenta de modelos es un modelado justo a tiempo (JIT): usted identifica un problema que necesita resolver, rápidamente reúne a algunos compañeros de equipo que pueden ayudarlo, el grupo explora el problema y luego todos continúan como antes. Es común en equipos ágiles, los programadores extremos (XPers) lo llaman sesión de diseño stand-up o sesión de preguntas y respuestas del cliente, y claramente también es común en equipos tradicionales. Todo el mundo modela tormentas en algún momento y creo que ya es hora de que empecemos a hablar sobre ello para que podamos encontrar maneras de mejorarlo aún más. Mi experiencia es que la gran mayoría de las sesiones de modelado involucran a unas pocas personas, generalmente solo dos. o tres, que discuten un tema mientras dibujan en un papel o una pizarra. Estas “sesiones de tormenta de modelos” suelen ser eventos improvisados, en los que un miembro del equipo le pide a otro que modele con ellos, y suelen durar entre cinco y diez minutos (es raro modelar una tormenta durante más de treinta minutos). Las personas se reúnen, se reúnen alrededor de una herramienta de modelado compartida (por ejemplo, la pizarra), exploran el tema hasta que están satisfechos de haberlo entendido y luego continúan (a menudo codificando).
Asalto del modelo de análisis
Modelarás tormentas para analizar requisitos. Por ejemplo, una parte interesada puede decirle que el sistema que está creando debe poder editar la información de los estudiantes. Juntos crean un boceto de cómo se verá la pantalla (consulte la Figura 1) , dibujando varios ejemplos hasta que lleguen a una comprensión común de lo que se debe construir. Bocetos como este son modelos inclusivos porque se utilizan herramientas y técnicas de modelado simples, lo que permite la práctica del Modelado Ágil (AM) de Participación Activa de las Partes Interesadas . Tenga en cuenta que es posible que también haya creado un modelo como este como parte de sus esfuerzos de modelado de iteración ; las “reglas” no están grabadas en piedra.
Figura 1. Bocetos de pantalla.
Asalto del modelo de diseño
Los desarrolladores ágiles, incluidos los XPers, no siempre van directamente al código una vez que han elegido trabajar en un requisito (al contrario de lo que le dirán los detractores del desarrollo ágil). Esto se debe a que el model storming también es muy común en arquitectura y diseño. Los programadores de Java a menudo trabajarán con código complejo dibujando un diagrama de secuencia UML rápido (consulte la Figura 2 ), los XPers crearán tarjetas de Colaborador de Responsabilidad de Clase (CRC) en fichas estándar (consulte la Figura 3 ) para explorar problemas de diseño estructural detallados y Visual Basic. los programadores pueden optar por dibujar diagramas de flujo para modelar una regla de negocios compleja (consulte la Figura 4 ). Independientemente de los modelos que necesites crear, seguirás siendo un asalto a los modelos.
Figura 2. Diagrama de secuencia de nivel de servicio.
Figura 3. Tarjetas CRC dibujadas a mano.
Figura 4. Diagrama de flujo de matrícula en la Universidad.
Es importante comprender que no se necesita una pizarra para modelar una tormenta, solo se necesita una herramienta inclusiva y compartida con la que la gente pueda trabajar fácilmente. Por ejemplo, las tarjetas CRC de la Figura 3 están escritas en fichas, no dibujadas en una pizarra.
¿Por qué funciona esto?
¿Por qué la creación de modelos JAT funciona mucho mejor que intentar modelar todo desde el principio ? Por varias razones:
- Los requisitos van a cambiar a lo largo de la iniciativa , nos guste o no.
- Al esperar a analizar los detalles JIT, tienes mucho más conocimiento del dominio que si lo hubieras hecho al comienzo de una iniciativa. Por ejemplo, si un requisito se va a implementar tres meses después, si explora los detalles de ese requisito en ese momento tendrá tres meses más de conocimiento del dominio que si lo hubiera hecho al principio, por lo tanto, podrá hacer preguntas más inteligentes. .
- Si ha estado entregando software funcional de forma regular, sus partes interesadas ahora tienen tres meses de experiencia con el sistema que ha creado. En otras palabras, pueden darte mejores respuestas.
- Modelar todo desde el principio en detalle parece resultar en un desperdicio significativo . Sí, durante la iteración 0 querrás hacer una visión inicial de los requisitos y una visión inicial de la arquitectura , pero eso no significa que debas profundizar en los detalles.
Dicho esto, a veces será necesario modelar requisitos complejos o modelar activos heredados un poco antes de implementarlos . En realidad, esto es algo poco común, independientemente de lo que los modeladores tradicionales puedan esperar, pero sucede de vez en cuando.
Adoptando el modelo Storming
¿Cómo apoya usted el asalto a modelos en su entorno? En primer lugar, cuanto más espacio haya en la pizarra, mejor. Algunas empresas se muestran reacias a instalar pizarras blancas; aparentemente, las preocupaciones sobre la decoración de interiores, como tener impresiones atractivas en la pared, son mucho más importantes para ellas que hacer que los equipos de desarrollo de software sean eficaces. Mi consejo es no sólo tener mucho espacio en la pizarra disponible para las personas, sino que también debe asegurarse de que sea visible para las personas una vez que regresen a sus estaciones de trabajo para que puedan trabajar fácilmente desde ellas.
Deberá desarrollar un protocolo para trabajar en las pizarras, especialmente cuando esté bien borrar algo. La cultura de su equipo también es fundamental para su éxito; debe ser aceptable pedir ayuda a las personas y, a su vez, que se les pida que sirvan de modelo con los demás. Debe reconocer que esta es una forma normal y eficaz de trabajar. No recuerdo un equipo en el que no modeláramos la tormenta, pero tampoco recuerdo haber leído un libro o artículo que hablara sobre esta técnica con gran detalle. ¿No sería bueno si la industria de TI pudiera comenzar a hablar sobre lo que realmente hacemos en la práctica, en lugar de lo que creemos que deberíamos hacer?
I’ve always been captivated by the wonders of science, particularly the intricate workings of the human mind. With a degree in psychology under my belt, I’ve delved deep into the realms of cognition, behavior, and everything in between. Pouring over academic papers and research studies has become somewhat of a passion of mine – there’s just something exhilarating about uncovering new insights and perspectives.