Planteaba Carlos Junquera Cachero en su blog una serie de dudas sobre Scrum. Esto empezó siendo un comentario a ese post, pero se alargo lo suficiente como para ser un post con vida propia.
La respuesta a las preguntas es que salvo a una, Scrum no da respuesta absoluta a ninguna de ellas. Es más las metodologías modernas, en general, no dan respuestas absolutas. El desarrollo de software es un problema complejo en el que las repuestas absolutas no existen. La buena noticia es que a veces si que se pueden dar respuestas claras que funcionan en un amplio rango de situaciones.
Antes de nada, comenta Carlos que no es bueno que una empresa se centre en una única metodología. Yo no comparto esta opinión, sobre todo si se trata de una empresa pequeña o mediana. Si bien es cierto que ninguna metodología es de universal aplicación, el problema de las metodologías es que todas, incluso la más simples, exigen un proceso más o menos costoso de implantación. Todas exigen un esfuerzo notable de aprendizaje y adaptación de la metodología. No es muy optimo, en mi opinión, pagar este peaje en múltiples ocasiones. Todas las metodologías, hoy en día, tienden a ser más descriptivas que prescriptivas y como tal constituyen más marcos metodológicos (la mayoría incluso así lo dicen explícitamente) con un amplísimo rango de aplicación. Nos dicen qué debemos hacer pero no el cómo. El cómo es lo que depende de cada empresa, de cada proyecto, de cada equipo incluso. En el ‘cómo’ es además donde se encuentra la dificultad. Descubrir cómo llevar a cabo una metodología es el 90% del coste de la implantación de una metodología e insisto buscar ese cómo no es algo que yo quiera hacer dos veces. Scrum, MSF Agile, RUP o CMMI, por citar algunas de las más populares, son metodologías de amplio espectro, aplicables a una enorme variedad de proyectos. Todas en alguna ocasión han demostrado ser perfectamente útiles. Una funcionará mejor que otra para tal o cual tipo de proyecto. Pero esa diferencia es mínima, no cubre el coste de conocer, implantar, utilizar y ajustar dos metodologías en la gran mayoría de los casos.
El problema es, que ese ‘como’ del que hablo, la manera en que nosotros llevaremos a cabo una metodología, es algo que solo nosotros podemos descubrir. Léase nosotros como nuestra empresa o nuestro equipo, según el rango de aplicación de la metodología. Contar con alguien que ya haya encontrado ese ‘como’ en otras ocasiones para que nos allane el camino puede ser muy útil, incluso marcar la diferencia entre el éxito y el fracaso, porque muchas implantaciones de una metodología nunca llegan al ‘como’ o llegan a un ‘como’ erróneo.
Una vez dicho lo anterior, que solo es mi opinión basada en mi experiencia de haber vivido unas cuantas implantaciones de metodologías, unas exitosas y otras no, voy a comentar las respuestas que yo daría a las preguntas del vecino de blog:
Empezando por la que tiene respuesta clara, ¿debe de existir una demo, un ejecutable, que el Product Owner podría coger y poner en producción?: Si, al final de cada sprint se debe demostrar lo desarrollado durante el mismo y solo se puede presentar funcionalidad ‘hecha’, esto es uno de los pilares de Scrum, y por lo tanto no es opcional. Idealmente ‘hecho’ significa ‘algo que se puede poner en producción’, aunque el significado de hecho se puede establecer según las necesidades y limitaciones de cada proyecto. Eso si, cuando el significado de ‘hecho’, no es el anterior, el nuevo significado debe ser conocido por todos los implicados en el proyecto. No me extiendo más, simplemente os remitio a las reglas de Sprint Review.
Otra pregunta, ¿es mejor crear un único sprint para el análisis y el diseño?: Si te planteas esta pregunta es que deberías volver a leer todo lo que hayas leído sobre Scrum (o sobre cualquier otra metodología iterativa en general y ágil en particular). !No hay fases largas de análisis y diseño! El análisis y diseño, es algo que se hace en línea con el desarrollo, o como mucho de manera más intensa durante el inicio del Sprint. Otro tema es la arquitectura, a menudo se plantea un Sprint 0, que tiene como objetivo poder dedicar un tiempo a trazar y discutir una arquitectura inicial para el sistema, establecer a grandes rasgos los pilares arquitectónicos sobre los que se construirá el software. Ojo que esto no quiere decir que una vez cerrado el Sprint 0 la arquitectura este ‘congelada’. La arquitectura es algo vivo que evoluciona a lo largo de todo el proyecto. Resumiendo: no hacemos desarrollo en cascada, si en algo están de acuerdo todas la metodologías modernas es que el único ciclo de vida que puede funcionar es el iterativo e incremental.
La siguiente pregunta también es típica de alguien que se aproxima por primera vez a Scrum ¿Hay que definir inicialmente las personas que estarán en el proyecto desde el principio hasta el fin, permitiendoles tomar decisiones u opinar en el backlog de un sprint, pese a no pertenecer a dicho sprint? O ¿Una persona solo entra en el Scrum Team en el momento que va a realizar un sprint, y cuando no es mas necesario para la realización de mas sprints sale del equipo?. No olvidemos que el equipo en Scrum es un rol central. Nada es más importante que el equipo en Scrum. Luego parece que la respuesta evidente es que algo tan importante debe establecerse pronto. El equipo es quien llevará a cabo el proyecto, esto no quiere decir que en momentos puntuales (durante el despliegue y la integración por seguir con el ejemplo de Carlos) el equipo pueda contar con la ayuda de terceros. Pero no olvidemos que el equipo en Scrum debe ser multidisciplinar y que por lo tanto, debería contar en su interior con todo el conocimiento necesario para llevar a cabo el proyecto. El pensar que existen roles que solo intervienen en ciertas partes del proyecto es ‘erróneo’ si usamos Scrum. En Scrum, el enfoque es que si se necesita alguien con conocimientos en integración de sistemas, este debe estar presente desde el principio del proyecto: quien mejor que el para diseñar las interfaces que debe exponer la arquitectura, quien mejor que él para diseñar los contratos de datos a intercambiar, quien mejor para implementarlos o guiar a quien los implemente, quien mejor para participar en la fase de despliegue e integración?. Ninguna actividad en el ciclo de vida de un proyecto se realiza en completo aislamiento de otras. En Scrum, un mismo equipo debe ser capaz de llevar a cabo todas las actividades y cuando encuentre impedimientos siempre puede recurrir, puntualmente, a expertos ajenos al equipo.
Espero haber arrojado un poco de luz sobre las interesantes dudas planteadas por Carlos, decir que si puedo dar mi respuestas es porque yo ya las tuve antes.
Evidentemente no… aunque Scrum es una de las metodologías más simple, si no la más simple, aborda un problema complejo como el desarrollo de software y llevarla a la práctica exije amplios conocimientos sobre el tema. Pero si se puede, en cinco minutos, obtener una visión preliminar de esta metodología que nos permita hacernos idea de si puede servirnos o no. 
Desde el punto de vista de la escalabilidad, en teoria, es mejor crear y destruir el proxy, si es que hay afinidad entre número de clientes y número de proxies. Tanto es así que de hecho los proxies son 
