No hay duda de que vivimos en una sociedad dominada por el marketing. Hay t\u00e9rminos y conceptos que venden. Son como sellos de distinci\u00f3n que muchos intentan poner en su tarjeta de presentaci\u00f3n aunque la similitud con la realidad sea, en muchos casos, solo parcial.<\/p>\n\n\n\n\n\n\n\n
Hoy vamos a hablar sobre Scrum, un marco de trabajo que est\u00e1 de moda. Es \u00e1gil y moderno (aunque no nuevo). Y est\u00e1 claro que \u00e1gil y moderno suena mejor que lento y anticuado. Pero lo cierto es que, aunque Scrum tenga ventajas, tambi\u00e9n presenta inconvenientes y no se puede utilizar en cualquier tipo de \u201cproyecto\u201d. <\/p>\n\n\n\n
De hecho, Scrum no es un marco de trabajo apto para proyectos, sino para productos. No obstante, muchos desarrolladores creen (o al menos aseguran) que est\u00e1n aplicando Scrum. \u00bfPor qu\u00e9? Pues porque la palabra Scrum es m\u00e1s sexy<\/em> que otras alternativas m\u00e1s acordes con la realidad. Pero eso lo veremos m\u00e1s adelante. Vayamos por partes.<\/p>\n\n\n\n Antes de nada, es interesante recordar de d\u00f3nde venimos. El desarrollo de software tradicional se realizaba usando la metodolog\u00eda de trabajo en cascada. En pocas palabras se puede resumir de la siguiente manera: El desarrollo se divide en varias fases que se van implementando una detr\u00e1s de otra en un orden espec\u00edfico:<\/p>\n\n\n\n Esta metodolog\u00eda tiene un gran inconveniente: es de sentido \u00fanico. El principal problema es que una vez empezada la implementaci\u00f3n, no se pueden cambiar los requerimientos. Por desgracia, en el mundo del software, los requerimientos no est\u00e1n totalmente claros desde el principio o \u00e9stos pueden querer ser modificados durante el desarrollo, bien porque el cliente cambie de idea o bien porque las necesidades hayan cambiado. Esto sucede especialmente en proyectos largos.<\/p>\n\n\n\n \u00bfEs, por tanto, el desarrollo en cascada una mala metodolog\u00eda? Para nada. Es simplemente una metodolog\u00eda de trabajo que funciona de forma eficaz para proyectos en los que toda la informaci\u00f3n est\u00e1 definida desde el principio. Hay multitud de industrias donde se aplica el desarrollo en cascada con \u00e9xito. Simplemente, presenta limitaciones de flexibilidad, lo cual puede ser un problema para el desarrollo de un proyecto de software.<\/p>\n\n\n\n Scrum es un marco de trabajo \u00c1gil que se basa en la entrega de incrementos en ciclos de trabajo llamados Sprints. En cada Sprint se realiza la entrega de una parte totalmente funcional del producto. Cada Sprint tiene una fase de An\u00e1lisis de requerimientos, dise\u00f1o del sistema, implementaci\u00f3n, testeo, despliegue.<\/em> Una de las ventajas de este marco de trabajo es que los requerimientos se definen (o al menos se discuten) antes de cada sprint. Por lo tanto, el equipo define en cada Sprint qu\u00e9 es lo pr\u00f3ximo que se va a implementar. Esto permite reaccionar a posibles cambios en el mercado, o simplemente, en beneficios de los intereses de los usuarios finales del producto.<\/p>\n\n\n\n Habr\u00e9is notado que en el desarrollo en cascada he hablado de proyecto mientras que en Scrum he hablado de producto. Esto no ha sido casualidad.<\/p>\n\n\n\n La metodolog\u00eda en cascada es un modelo de gesti\u00f3n de proyectos. Un proyecto tiene un presupuesto y una duraci\u00f3n determinada. Es decir, cuando se ejecuta un proyecto, se debe conocer cuanto va a costar y cuando va a terminar.<\/p>\n\n\n\n Con el marco de trabajo Scrum se gestiona el desarrollo de un producto y, por tanto, no hay fecha de finalizaci\u00f3n. Scrum se utiliza para el desarrollo iterativo de productos durante un periodo de tiempo indefinido. Al comenzar el desarrollo no se sabe cu\u00e1l va a ser el resultado final, pues las funcionalidades a implementar se van definiendo a medida que se va desarrollando y seg\u00fan las decisiones que se vayan tomando para satisfacer las demandas del mercado. Por eso es flexible.<\/p>\n\n\n\n Si hemos le\u00eddo con atenci\u00f3n, la respuesta es sencilla: no. Scrum se puede aplicar para el desarrollo de un producto, no para un proyecto (aunque en los \u00faltimos a\u00f1os se est\u00e1n realizando aproximaciones de Scrum aplicadas a proyectos). Y en el desarrollo de software de consultoras, lo que abundan son los proyectos.<\/p>\n\n\n\n Por este motivo, los proyectos desarrollados bajo el marco de trabajo Scrum suelen fallar<\/strong> o bien estos proyectos son en realidad desarrollados usando una metodolog\u00eda de trabajo que recuerda a Scrum pero que no es Scrum realmente, ya que el marco de trabajo no se aplique correctamente (de hecho, en un proyecto no se puede aplicar). En consecuencia, los principios que hacen que Scrum funcione tampoco se pueden cumplir, entre otros motivos.<\/p>\n\n\n\n El Pseudo-Scrum<\/strong> es una aproximaci\u00f3n al desarrollo en cascada y Scrum, con las ventajas del uno y del otro. El prefijo Pseudo<\/em> puede llegar a transmitir la idea de que es una metodolog\u00eda menos v\u00e1lida que Scrum, pero esto no es cierto. A veces tambi\u00e9n se usa el apelativo h\u00edbrido<\/em>, que suena mejor. Pero lo que importa no es c\u00f3mo lo llamemos, sino la metodolog\u00eda en s\u00ed. Es importante escoger la firma de trabajo que mejor se adapte a las necesidades y no elegirla en base a lo que est\u00e9 de moda o suene bien. El objetivo final es asegurar el \u00e9xito del proyecto o producto y la satisfacci\u00f3n tanto del cliente como del equipo que trabaja internamente.<\/p>\n\n\n\n Resumiendo, llamamos Pseudo-Scrum a un marco de trabajo que parece usar rasgos de Scrum pero que no es Scrum puro. A continuaci\u00f3n, vamos a explicar c\u00f3mo lo hacemos en WATA Factory.<\/p>\n\n\n\n Antes de nada mencionar que en WATA Factory <\/strong>aplicamos la forma de trabajo que mejor se adapta a cada proyecto. Usamos Scrum en el desarrollo de algunos productos, pero este marco de trabajo, por lo general, no se adapta a los requerimientos de nuestros clientes. En la inmensa mayor\u00eda de los casos, los clientes necesitan saber qu\u00e9 van a recibir, cu\u00e1nto va a costar su desarrollo y cu\u00e1ndo va a realizarse la entrega. Esto es, por definici\u00f3n, incompatible con Scrum.<\/p>\n\n\n\n Nuestro Pseudo-Scrum es un h\u00edbrido entre el desarrollo en cascada y Scrum<\/strong>, tomando las ventajas de cada uno.<\/p>\n\n\n\n En primer lugar, tenemos una fase de toma y an\u00e1lisis de requerimientos<\/strong>. Posteriormente realizamos un prototipo interactivo<\/strong>, para que el cliente conozca cu\u00e1l ser\u00e1 el producto resultante. Adicionalmente realizamos una oferta<\/strong> que incluye coste de desarrollo y fecha de entrega, a menos que, junto con el cliente podamos trabajar en base a presupuestos de horas para la mejora continua de un producto en cuesti\u00f3n, en cuyo caso aplicar\u00edamos Scrum puro<\/em>.<\/p>\n\n\n\n Usando el desarrollo en cascada, el equipo t\u00e9cnico ya no volver\u00eda a tener contacto con el cliente hasta la fecha de entrega, ya que todo estar\u00eda previamente definido. Sin embargo, aqu\u00ed es donde entra Scrum.<\/p>\n\n\n\n La implementaci\u00f3n la realizamos en iteraciones del producto mediante entregas totalmente funcionales. Es decir, el cliente podr\u00eda utilizar la funcionalidad entregada. Esto tiene dos ventajas. La primera es que el cliente puede hacer uso de su producto antes de la entrega final. La segunda es que el cliente puede ver y probar la funcionalidad. Una vez implementada, el cliente a veces detecta mejoras en la parte del producto desarrollado. Una implementaci\u00f3n con Pseudo-Scrum<\/em> permite al cliente redefinir aquellas funcionalidades que considere oportunas durante el desarrollo.<\/p>\n\n\n\n Por supuesto los cambios deben ser de la misma magnitud que la implementaci\u00f3n original para mantener la fecha de entrega y el coste de desarrollo. O bien, se compensa descartando o simplificando otra funcionalidad. Para ello, trabajamos con un Backlog<\/em> priorizado, en el que el cliente decide el orden de implementaci\u00f3n de las funcionalidades.<\/p>\n\n\n\n Son frecuentes las cr\u00edticas hacia las formas de trabajo que recuerdan a Scrum o dicen serlo, pero que en realidad no siguen el marco de trabajo fielmente. En parte, es entendible. Si no se est\u00e1 usando Scrum no hay que predicar que se est\u00e1 usando. Lo que no es correcto es decir que la implementaci\u00f3n pura<\/em> es la correcta y cualquier otra opci\u00f3n es tan solo un intento de imitaci\u00f3n. Nada m\u00e1s lejos de la realidad.<\/p>\n\n\n\n Usa la metodolog\u00eda que mejor se adapte a cada situaci\u00f3n, y defi\u00e9ndela con la cabeza alta.<\/p>\n","protected":false},"excerpt":{"rendered":" No hay duda de que vivimos en una sociedad dominada por el marketing. Hay t\u00e9rminos y conceptos que venden. Son como sellos de distinci\u00f3n que muchos intentan poner en su tarjeta de presentaci\u00f3n aunque la similitud con la realidad sea, en muchos casos, solo parcial.<\/p>\n","protected":false},"author":16,"featured_media":7149,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[89,183],"tags":[276,145],"class_list":["post-6562","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-noticias","category-tecnologia","tag-pseudo-scrum","tag-scrum"],"yoast_head":"\nDe d\u00f3nde venimos: Desarrollo en cascada<\/h2>\n\n\n\n
Introducci\u00f3n a Scrum<\/h2>\n\n\n\n
Proyecto vs. Producto<\/h2>\n\n\n\n
\u00bfPuedo usar Scrum en mi proyecto?<\/h2>\n\n\n\n
Pseudo-Scrum en WATA Factory<\/h2>\n\n\n\n
Usa Pseudo-Scrum con orgullo<\/h2>\n\n\n\n