Voy a un taller tras otro con el mismo enfoque unidimensional: demasiada gente, todos miran la pantalla mientras alguien captura los requisitos/suposiciones, etc., seco, aburrido, no atractivo, los requisitos se pierden porque la gente quiere estar en otro lugar, móvil. teléfonos y computadoras portátiles llenan las mesas, etc. para capturar los requisitos de las partes interesadas y brindar una excelente solución a los problemas de las partes interesadas.
Ayer me topé con el Desarrollo de Aplicaciones Conjuntas (JAD). Parece prometer todo lo contrario de lo que he estado experimentando anteriormente. ¿Cómo puedo implementar este enfoque? ¿Existen alternativas con el mismo resultado final de compromiso y colaboración?
En cuanto a la implementación, puedo recomendar de todo corazón el libro " Requisitos de colaboración " de Ellen Gottesdiener. También se hace referencia en la biografía de la página de Wikipedia de JAD.
Este libro le enseñará todo lo que necesita saber sobre cómo planificar, realizar y evaluar talleres de elicitación de requisitos facilitados de una manera similar a JAD, que son interactivos y divertidos.
He usado estas técnicas en el pasado con muy buenos resultados, y todavía uso la EDT de su taller como una lista de verificación cuando preparo talleres para hacer las cosas.
Cuidado: esto es un trabajo duro. El éxito de un buen taller depende en gran parte de las actividades de preparación y seguimiento.
buena suerte stephan
El diseño de aplicaciones conjuntas (JAD) intenta formalizar un proceso para recopilar requisitos y desarrollar un diseño a partir de esos requisitos. Una forma de verlo es como una fusión de las fases de requisitos y diseño del modelo en cascada , con algunos principios ágiles orientados a las personas combinados para aumentar el compromiso entre los participantes.
Repite conmigo: no hay una bala de plata. Di eso 1000 veces antes de pasar más tiempo buscando un marco o proceso para resolver los problemas de tu taller.
Ya sabes cuáles son tus problemas con tu proceso actual; los explicas bastante claramente en tu pregunta. Déjame destacarlos para ti:
En otras palabras, está organizando talleres en los que nadie quiere participar, y el facilitador de la reunión está hablando con las personas en lugar de involucrarlas.
No hay nada particularmente novedoso en el enfoque JAD de este tema. Adoptarlo simplemente formaliza un enfoque que se enfoca en aumentar la participación al:
De hecho, JAD no es tan diferente de los principios subyacentes de Scrum. Piense en Sprint Goals, Sprint Reviews y stand-ups diarios en los que solo pueden participar "cerdos". En mi opinión, ese es un modelo bastante bueno para lo que JAD está tratando de lograr, solo limitado al diseño de aplicaciones.
El papel clave en JAD es el de facilitador. Esta persona es un árbitro de proceso y un terapeuta de grupo todo en uno. Por ejemplo:
JAD se centra principalmente en las fases de diseño y recopilación de requisitos de un proyecto. No es un marco de gestión de proyectos completo, por lo que las comparaciones directas con otras metodologías parten de una premisa defectuosa. Aún así, hay algunas similitudes y contrastes útiles para explorar.
Como se mencionó anteriormente, JAD comparte algunos principios en común con Scrum. Incluso se podrían hacer comparaciones útiles entre un Scrum Master efectivo y un facilitador JAD, ya que ambos son fundamentalmente roles de líder-servidor.
Al igual que Scrum, JAD no es realmente tan prescriptivo. Hay algunos roles obligatorios, algunos artefactos obligatorios y algunas reuniones obligatorias, pero los detalles de implementación son suyos para crearlos dentro del marco general.
A diferencia de Scrum, JAD se enfoca en un diseño grande y directo. Muchas metodologías ágiles como Scrum eliminan la necesidad de realizar talleres de diseño de varios días porque se centran en el diseño emergente a través de la entrega iterativa . Cada sprint implica un poco de análisis, un poco de diseño y mucho trabajo duro, en lugar de tratar de hacer todo el análisis y el diseño al comienzo del proyecto.
Si no está atascado con un modelo de desarrollo en cascada, entonces ciertamente pasaría algún tiempo evaluando los diversos marcos ágiles. Sin embargo, tenga en cuenta que los cambios organizativos necesarios para implementar un marco ágil de forma eficaz suelen ser más amplios que los cambios necesarios para implementar JAD. Su experiencia puede ser diferente.
jmort253