Pregunta: Responda el siguiente estudio de caso 11‐1 Pantallas informativas en los ferrocarriles holandeses (Nederlandse Spoorwegen) Cada día, más de 650.000 pasajeros completan una media de 1,2 viajes en tren en los ferrocarriles holandeses (Nederlandse Spoorwegen). Es importante que estos pasajeros tengan la información más actualizada sobre llegadas, salidas y

Responda el siguiente estudio de caso 11‐1 Pantallas informativas en los ferrocarriles holandeses (Nederlandse Spoorwegen) Cada día, más de 650.000 pasajeros completan una media de 1,2 viajes en tren en los ferrocarriles holandeses (Nederlandse Spoorwegen). Es importante que estos pasajeros tengan la información más actualizada sobre llegadas, salidas y conexiones de trenes en la red. Esta fue la razón por la que los Ferrocarriles Holandeses, que se enorgullecen de que sus trenes llegan a tiempo en su mayoría, decidieron construir un sistema para proporcionar información de viaje a sus pasajeros en todas las estaciones de tren holandesas. Los horarios de salida de los trenes se almacenaron de forma centralizada y se actualizaron con información introducida manualmente o mediante sensores en la infraestructura. Los Ferrocarriles Holandeses decidieron subcontratar el contrato para la construcción del sistema a una empresa india. Los requisitos para el nuevo sistema (llamado PUB para publicación) se entregaron al proveedor de subcontratación que se esperaba que utilizara el método en cascada y poca participación del cliente. Este enfoque no funcionó y después de tres años, el contrato se canceló debido a la incapacidad del proveedor de entregar un sistema que funcionara. Dutch Railways decidió subcontratar nuevamente, pero esta vez a Xebia, un proveedor que usaría Scrum para construir el sistema en estrecha cooperación con el personal de Dutch Railway. El proyecto PUB fue parte de un programa que involucró muchos otros proyectos de software relacionados para construir e implementar pantallas en todas las estaciones de los Países Bajos.i Dados los problemas que los ferrocarriles holandeses habían experimentado anteriormente con la subcontratación, Xebia decidió dar un impulso de tres semanas. ‐Salir con un gerente de proyecto, un arquitecto de sistemas y un Scrum Master para asegurarse de que todo estuviera configurado correctamente antes de que comenzaran los sprints. Pero el problema de identificar al propietario del producto se hizo evidente de inmediato. Idealmente, el propietario del proyecto debería ser alguien que tenga el tiempo, el conocimiento empresarial y la autoridad necesarios para priorizar los requisitos. A falta de esa persona, se designaron dos Product Owners: analistas de negocios que habían estado involucrados en el intento anterior de construir PUB. Desafortunadamente, los propietarios del proyecto no sabían cómo escribir historias de usuarios, por lo que Scrum Master los ayudó a producir el trabajo inicial del producto con historias de usuarios para comenzar. Un equipo Scrum de siete personas en los Países Bajos inició el proyecto acordando normas para trabajar juntos y proporcionando estimaciones aproximadas de cuánto tiempo llevaría completar las funciones requeridas, estimaciones que se utilizarían para comunicar el progreso en el gráfico de desarrollo de versiones. Las estimaciones del proyecto fueron especialmente importantes porque el proyecto debía cumplir con los plazos del programa. Dos desarrolladores indios se unieron al equipo Scrum en los Países Bajos en su tercera iteración (tan pronto como la inmigración y las limitaciones logísticas les permitieron hacerlo), ya que se sabía que pronto se agregarían equipos scrum indios al proyecto PUB. El equipo de Holanda trabajó en iteraciones de dos semanas llamadas sprints. Las primeras iteraciones permitieron a los equipos crear, probar y demostrar historias de usuarios en el núcleo del sistema, lo que agradó enormemente al cliente, Dutch Railways. Después de la quinta iteración, los dos desarrolladores indios regresaron a la India y se les unieron ingenieros para formar dos equipos Scrum completos. Al final, hubo tres equipos Scrum distribuidos, cada uno con su propio probador y con compañeros holandeses e indios. Los equipos utilizaron sesiones diarias de Skype, viajes programados periódicamente, un boletín de noticias del proyecto después de cada iteración y actualizaciones informales por parte del propietario del producto para comunicarse entre sí y compartir conocimientos. Sus herramientas incluían ScrumWorks para gestionar electrónicamente el trabajo pendiente del producto y el trabajo pendiente del sprint, gráficos de evolución publicados diariamente en una pared de las salas del equipo y una pizarra computarizada. La programación de pares se realizó sólo con pares ubicados conjuntamente. Se creó un equipo local de Scrum holandés para abordar las barreras del equipo y realizar actividades de cumplimiento específicas de cara al cliente, como redactar documentación en holandés que cumpliera con el enfoque de documentación en cascada que Dutch Railways quería mantener y discutir los requisitos con las partes interesadas técnicas. El Scrum Master tuvo que modificar la típica reunión de planificación de Sprint de dos partes porque los Product Owners querían hablar holandés. Entonces, en la primera parte modificada, el propietario del producto aclaró las historias de los usuarios y estableció las prioridades sin que los miembros del equipo indio estuvieran presentes. Luego, la segunda parte se realizó en inglés a través de Skype sin los Product Owners. La información de la primera parte se comunicó a los compañeros de equipo indios en la segunda parte y se identificaron y estimaron las tareas para completar las historias de los usuarios. Los Ferrocarriles Holandeses quedaron satisfechos con PUB cuando lo entregaron: 100.000 líneas de código que reflejan 20 años-hombre de esfuerzo durante un período de once meses. Lamentablemente, el despliegue a nivel nacional se vio obstaculizado por otros proyectos del programa que no se completaron según lo previsto. Es difícil decir que el proyecto PUB se entregó “a tiempo” y “dentro del presupuesto”, ya que la funcionalidad requerida, los plazos y el presupuesto cambiaron durante el proyecto. Sin embargo, durante estos turnos, se discutían con el cliente los factores de éxito del proyecto. Una empresa de auditoría externa concluyó: “La mantenibilidad de los sistemas es muy buena; La calidad del código fuente es muy alta”.

Pregunta n.º 1 Describe los desafíos de utilizar equipos Scrum distribuidos. ¿Qué tan efectivos cree que fueron los cambios realizados en las prácticas típicas de Scrum en el proyecto PUB para abordar estos desafíos? (15 puntos)

Pregunta n.º 2 Evalúe el sistema PUB que desarrolló Xebia utilizando las cuatro dimensiones del éxito del proyecto. ¿Qué tan exitoso crees que es este proyecto? (15 puntos)