Actualmente estoy trabajando con un profesor en mi universidad para desarrollar nuevos planes de estudio para los cursos de Ingeniería de Software y Diseño Capstone que se ofrecen en mi universidad.
Hasta hace poco, ambos cursos usaban el modelo de cascada exclusivamente y, por lo tanto, los estudiantes pasaban la mayor parte de su tiempo escribiendo informes largos. Después de mucha presión de mi parte, mi profesor decidió incluir Scrum en el plan de estudios de Ingeniería de Software el semestre pasado.
La primera mitad del semestre todavía era en cascada, con estudiantes escribiendo informes de diseño de 40 páginas y documentos de especificación de software. A mediados del semestre, todos los equipos debían lanzar una demostración de sus aplicaciones. En ese momento, el curso cambió a Scrum, con dos sprints de 3 semanas. Ahora estamos tratando de descubrir cómo eliminar la cascada por completo y crear un plan de estudios exclusivamente basado en Scrum.
Desafortunadamente, encontramos algunas incompatibilidades entre Scrum y los estudiantes:
- Las reuniones diarias de Scrum son casi imposibles para los estudiantes. Incluso durante la clase en sí, es inconveniente para los estudiantes realizar reuniones de Scrum ya que el profesor suele dar clases.
- Calcular puntos / horas es difícil, ya que los estudiantes no tienen experiencia y, por lo tanto, no pueden predecir con precisión cuánto tiempo tomará algo.
- Scrum funciona mejor con desarrolladores de tiempo completo que comparten el edificio, pero los estudiantes tampoco lo son. Como máximo, los estudiantes dedican 15-20 horas por semana al curso, y organizar reuniones de trabajo puede ser extremadamente difícil. Los equipos pueden tener hasta 10 estudiantes (y siempre hay uno o dos holgazanes).
- ¡Los profesores anhelan la documentación! No he oído hablar de ningún informe de Scrum, solo los atrasos y las listas de consumo (que no estoy seguro serán suficientes para apaciguar a los académicos).
- Los estudiantes a menudo asumen que ágil significa "saltar directamente y comenzar a codificar sin mirar atrás". Esto lleva a algunos de los códigos más horribles imaginables. Por lo tanto, estoy buscando una manera de hacer cumplir el diseño adecuado sin requerir un documento de 50 páginas o una pila de diagramas UML.
Dados estos problemas, ¿cómo cree que mi profesor y yo podemos adaptar Scrum para que funcione en un entorno académico (e incluso deberíamos molestarnos con Scrum en primer lugar)? Además, ¿sigue siendo valioso enseñar el modelo de cascada?
Gracias de antemano por cualquier comentario!
Respuestas:
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.
fuente
Cuando hice mi maestría en ingeniería de software, había un curso llamado Software Process que trataba sobre XP, Scrum y otros enfoques ágiles. Esencialmente, toda la clase formó una compañía de software hipotética y recibió instrucciones de desarrollar una pieza de software bastante elaborado durante el tiempo que duró el curso. Las conferencias fueron sobre cosas como las prácticas de XP, hacer reuniones de pie, etc.
La mayoría de los estudiantes han escuchado acerca de estas técnicas y generalmente están interesadas en aplicarlas. Por supuesto, no hay forma de obligar al equipo a trabajar de manera iterativa, etc. Pero ese fue realmente el punto del curso: convertirse en una motivación para celebrar muchas reuniones cortas, trabajar de forma iterativa, hacer construcciones continuas, etc. porque descubres rápidamente es simplemente la forma más fácil y confiable de producir cualquier cosa de valor con un grupo de personas y una pequeña cantidad de tiempo.
Una cosa para recordar: asegúrese de jugar bien con el cliente y cambiar algunos requisitos clave a mitad de camino. O "olvide" mencionarlos inicialmente.
fuente
¿El propósito es facilitar el desarrollo, o aprender Scrum, o, supongo, ambos? Consideraría carreras cortas para acelerar el proceso de aprendizaje.
Quizás pueda reemplazar los stand-ups diarios con una forma menos estricta, cuando funcione mejor para los estudiantes. Además, no todos necesitan participar en cada reunión.
Calcular el tiempo del calendario es aún más difícil, por las mismas razones :-) Con los puntos de la historia no calcula cuánto tiempo tomará algo: estima su tamaño relativo. La duración se deriva.
¿Quizás probar con equipos más pequeños? 10 está en la escala superior para un equipo Scrum. Creo que también puedes tener éxito con equipos distribuidos que no sean de tiempo completo, ¡pero, por supuesto, es más difícil! Que sea una lección en sí misma.
Scrum no dicta qué tipo de documentación se requiere. De hecho, ni siquiera los gráficos de consumo son obligatorios. Esto no significa que la documentación esté prohibida: el equipo debe producir la documentación necesaria, incluidos los informes que los profesores consideren necesarios.
No solo estudiantes :-) La mayoría de los equipos Scrum usan prácticas XP como TDD (Test Driven Development) y refactorización: propongo que incorpores eso en los planes de estudio.
Sí, al menos por dos razones: en primer lugar, no es seguro que sus alumnos usen Scrum en su vida laboral, y en segundo lugar, me imagino que es más fácil comprender la esencia del desarrollo ágil si tiene algo con qué compararlo.
fuente
Suena un poco similar a un tema que tomé una vez.
Algunos pensamientos:
fuente
Mi consejo es separar y aislar lo que estás tratando de enseñar. Si se trata de un curso de diseño de software o algún otro tema de ingeniería de software (algoritmos o demás), concéntrese en eso. Si involucrar SCRUM se convierte en un obstáculo (como lo insinúa), no se moleste con eso.
Cómo lo hicimos cuando estaba en la universidad fue tener un curso dedicado para metodologías ágiles. El curso incluyó un proyecto de desarrollo que debía ejecutarse según SCRUM o XP. El software real que se iba a entregar era trivial, ya que el enfoque del curso no era la programación o el diseño, sino el proceso. El razonamiento aquí es el mismo por el que no se deben mezclar asignaturas de desarrollo de software "núcleo duro" con asignaturas de metodología, ya que una tiende a eclipsar a la otra y los estudiantes en su mayoría no están lo suficientemente preparados o capacitados para manejar ambas en esa etapa.
Los resultados del curso fueron cosas como informes de planificación de sprint, informes de progreso semanales, retrospectivas, informes de preparación y cada semana tuvimos al menos dos sesiones que incluyeron una reunión grupal de stand-up / scrum donde los TA circularían y escucharían.
Este curso también incluyó TDD (Test Driven Development) y funcionó muy bien.
Ciertamente lo es. Muchas compañías usan versiones de este modelo para sus proyectos (PPS, RUP, PROPS, etc.). Muchos encuentran (correctamente, en mi opinión) que SCRUM "puro" es más adecuado para el mantenimiento continuo que los proyectos. SCRUM (y Agile en general) requiere una cierta flexibilidad en el alcance y la posibilidad de negociar los requisitos y la entrega en el camino. No todos los proyectos funcionan así, son binarios: entregar X en el punto Y en el tiempo, todo lo demás es un fracaso.
fuente
El objetivo de un curso académico de Ingeniería de Software es enseñar a las etapas fundamentales del ciclo de vida del software: análisis, diseño, implementación, pruebas junto con el uso de estándares de calidad de software reales en lugar del código de calidad de tarea regular.
Sin embargo, debido a las razones por las que usted dijo que SCRUM no es un proceso adecuado, es valioso demostrar la práctica usando un proceso que no es en cascada : los estudiantes toman muchos cursos por semestre, muchos también tienen trabajos reales mientras estudian, por lo tanto, no puede tener 100 % de miembros del equipo dedicados o realizan reuniones diarias.
Considere usar un proceso iterativo menos ágil como UP (RUP) en su lugar.
Para mostrar el valor en comparación con el proceso en cascada, cambie los requisitos entre iteraciones. Esto mostrará la diferencia entre UP y la cascada y dará pistas sobre el valor del uso de procesos ágiles.
Demostrar la cascada después de esto será redundante ya que UP cubre todas las etapas de la cascada.
Como los semestres son relativamente cortos, 2 pequeñas iteraciones serían realistas.
Proporcione un marco amplio para que lo usen los estudiantes, ya que el énfasis de este curso no debe ser la profundidad de la implementación, hay otros cursos para eso, en su lugar, debe enfatizar los estándares de codificación y las pruebas unitarias.
Durante el curso, las conferencias enseñan la teoría de algunos procesos, por ejemplo, cascada, UP, XP, SCRUM y Kanban (junto con otros temas, por ejemplo, requisitos de escritura, UML, pruebas, etc.).
Para los estudiantes que completaron el curso anterior, considere un taller SCRUM por separado como un curso optativo que toma un período de dos semanas a tiempo completo durante el semestre de verano.
fuente
Scrum funciona si tiene un proyecto a largo plazo / semestre y la clase se divide en grupos de 6 a 10 personas. Luego, podría dedicar los últimos 10 minutos de tiempo de clase a la reunión de scrum.
fuente