Dudaría en descartar Waterfall en todos los ámbitos tan rápido.
Aunque es un modelo defectuoso para construir sistemas de software, no es un mal modelo de enseñanza para instruir sobre buenas prácticas para cada etapa del ciclo de vida. Independientemente del modelo de proceso que aplique al proyecto, aún realiza la ingeniería de requisitos, la arquitectura y el diseño del sistema, la implementación, las pruebas, el lanzamiento y el mantenimiento (incluida la refactorización y la mejora). La diferencia es cómo se organizan y conducen estas fases, pero todas las actividades aún suceden.
Yo diría que su transición de Waterfall a Scrum en el medio del proyecto no es la mejor idea. Una clave para el éxito de Scrum es un proyecto de larga duración. Los primeros tres a cinco sprints son el equipo que establece una velocidad, aprende el proceso y pasa por el desarrollo del equipo. Aunque estás haciendo los movimientos, en realidad no es Scrum en ese punto. Además, tratar de crear un plan de estudios exclusivamente basado en Scrum es probablemente una mala idea, ya que Scrum no es una bala de plata: es mejor enseñar las mejores prácticas en lugar de una sola metodología. En la fuerza laboral, no todos los proyectos van a usar Scrum. De hecho, en algunos entornos, Scrum sería perjudicial para el éxito del proyecto.
Ya ha encontrado problemas con Scrum en un entorno académico, y algunos de ellos son difíciles de abordar adecuadamente.
El problema en su lista de incompatibilidades es que la estimación es difícil. Sí lo es. Pero la única forma de mejorar en la estimación es estimar y comparar los datos reales con las estimaciones. Los estudiantes deben estimar el tamaño, el tiempo y el esfuerzo utilizando varios medios (puntos de la historia, líneas de código fuente, horas, páginas, horas-persona) temprano para que estén más preparados para hacerlo después de graduarse e ingresar a la fuerza laboral.
La necesidad de documentación es algo que puede abordarse tanto desde la perspectiva del profesor como desde la perspectiva de los estudiantes. Los enfoques Lean nos dicen que la documentación que no agrega valor ni al equipo ni al cliente es un desperdicio (en términos de tiempo y costo). Sin embargo, se necesita cierta documentación para lograr algunos objetivos tanto de los estudiantes como del profesor (el cliente / cliente) para diversos fines. En general, parece una oportunidad para enseñar la personalización de procesos y la gestión cuantitativa de proyectos (que tiene un papel incluso en los métodos ágiles).
Con respecto a las reuniones y la programación de Scrum, hay dos ideas que me vienen a la mente. La primera es que esto indica que Scrum podría no ser el mejor proceso para usar en un entorno académico. No existe un "mejor modelo de proceso" singular para proyectos de software, con factores como el cronograma, el personal, la visibilidad y la experiencia del equipo de desarrollo (entre otros).
En general, sugeriría enfatizar las buenas prácticas, la adaptación del proceso y la mejora del proceso en lugar de las metodologías individuales. Esto le permitirá ser el más efectivo para todos los que tomen los cursos, y exponerlos a una variedad de metodologías de proceso y comprender cuáles son las mejores prácticas para un conjunto de condiciones dado.
Dado que está trabajando para crear un plan de estudios universitario, le daré una visión general de alto nivel de cómo encaja el plan de estudios de ingeniería de software en la universidad a la que asistí .
La ingeniería de software introductoria pasó por el proyecto en un modelo en cascada, con las conferencias durante cada fase correspondientes a diferentes formas de llevar a cabo las actividades de esa fase. Los equipos progresaron a través de las fases al mismo ritmo. Tener esos límites claramente definidos encaja bien en el modelo de enseñanza para un grupo de personas con experiencia mínima o mínima trabajando en equipos para construir software. A lo largo del curso, se hicieron referencias a otras metodologías (varios métodos ágiles (Scrum, XP), Rational Unified Process, Spiral Model) con respecto a sus ventajas y desventajas.
En cuanto a las actividades, hubo cursos específicos para discutir los requisitos de ingeniería, arquitectura y diseño (dos cursos, uno centrado en el diseño detallado utilizando métodos orientados a objetos y otro centrado en la arquitectura del sistema), una serie de cursos centrados en el diseño e implementación de varios clases de sistemas (sistemas en tiempo real e integrados, sistemas empresariales, sistemas concurrentes, sistemas distribuidos, etc.) y pruebas de software.
También hay tres cursos dedicados al proceso de software. Proceso de ingeniería de software y gestión de proyectos que se centra en las mejores prácticas para gestionar un proyecto de software con respecto a múltiples metodologías. Un segundo curso de proceso enseña mediciones, métricas y mejora de procesos (enfatizando CMMI, Six Sigma y Lean). Finalmente, hay un curso de proceso que enseña el desarrollo ágil de software (Scrum, Extreme Programming, Crystal, DSDM discutido) utilizando un proyecto llevado a cabo utilizando la metodología Scrum.
El proyecto final fue un proyecto de dos trimestres que se realizó para una empresa patrocinadora y fue ejecutado en su totalidad por el equipo del proyecto estudiantil, con la orientación de los patrocinadores y un asesor de la facultad. Cada aspecto de cómo llevar a cabo el proyecto depende de los estudiantes, dentro de las limitaciones establecidas por los patrocinadores. Los únicos plazos obligatorios de la universidad fueron una presentación intermedia a mitad del proyecto (10 semanas), una presentación final al final y una presentación de póster cuádruple poco antes del final. Todo lo demás dependía del patrocinador y del equipo.