Ya, ya… Keep It Simple, Stupid… ¿pero cómo?

Complejidad Que seguir el principio KISS y mantener nuestras metodologías, nuestras arquitecturas, nuestros diseños, nuestras clases etc… simples nos proporciona innumerables ventajas es algo que todos los desarrolladores de software tenemos claro desde un principio o acabamos aprendiendo a la fuerza. La simplicidad en una característica que, cuando hablamos de desarrollar o diseñar software, es buena en si misma.

 

La paradoja es, que si bien sabemos lo anteriormente comentados, no es menos cierto que a menudo acabamos con procesos de desarrollo o  con soluciones demasiados complejas. Evidentemente hay dos aspectos claves a la hora de luchar contra la complejidad: uno, detectarla, el otro combatirla.

 

Hoy voy a hablar de que estrategias tenemos a la hora de combatir la complejidad. La verdad es que antes de estar leyendo Simple Architectures for Complex Enterprises de Roger Sessions, no tenía ni una idea explícita sobre este tema. Pero lo que comenta este libro sobre el tema es sumamente interesante. Aunque siempre he creído que la complejidad es uno de los mayores enemigos de los procesos de desarrollo y los sistemas de software nunca me había plantead, antes de la lectura de este libro, de manera explicita, con que tácticas contamos a la hora de atacar la complejidad.  Las tres tácticas con las que contamos son: el particionado, la simplificación y las iteraciones.

 

El particionado consiste en dividir grupos de elementos en elementos menores. Esta táctica es quizás la más poderosa de las tres y, de manera consciente o no, la utilizamos continuamente en el desarrollo de software. Particionados nuestras arquitecturas en capas, de manera que cada una de ellas solo tenga que lidiar con las complejidades propias de su cometido. Nuestra capa de acceso a datos, solo tiene que atacar las complejidades relacionadas con la obtención o persistencia de los datos, pero no se preocupa por las complejidades de la capa de presentación. Particionar la complejidad de manera explicita nos permite atajarla de manera clara. La complejidad crece exponencialmente. Mezclar en una misma capa de la aplicación acceso a datos, e interfaz de usuario, no hace nuestra aplicación el doble de compleja sino que añade varios ordenes de magnitud.  Cuando hablamos de arquitecturas SOA, dos de los pilares de SOA abogan claramente por el particionado: los límites de los servicios son explícitos y los servicios son autónomos.

 

El particionado también es una técnica que las metodologías usan a la hora de reducir la complejidad. Las metodologías ágiles proponer dividir la complejidad de implementar un solución completa en historias de usuario independientes, testeables y simples. Esto es claramente una estrategia de particionado que nos permite atacar la complejidad de un desarrollo en pequeñas historias de una complejidad acotada.

 

En el libro, Roger Sessions cuenta un caso en el que las particiones reducen la complejidad de forma clara y visual cuando estas son adecuadas. Imagináis una tienda en la que la ropa estuviese ordenada por colores ¿no sería extremadamente complejo el proceso de compra?. Sin embargo en todas las tiendas de ropa las particiones que aparecen tiene sentido: caballeros, señoras, niños…, ropa de vestir, ropa deportiva, ropa de dormir, ropa interior… XXL, XL, L, S… con estas particiones ¡la complejidad de realizar una compra es infinitamente menor que si las partición fuese por colores!.

 

Una vez tenemos particiones explicitas, podemos proceder a utilizar la simplificación. La táctica de simplificación mas poderosa es la eliminación. No ha táctica más poderosa de simplificación que eliminar aquellas particiones que no son relevantes. Si eliminamos completamente una historia de usuario, hemos reducido su complejidad a cero: no tenemos que diseñarla, implementarla, probarla o mantenerla. Desgraciadamente esto no siempre es posible: debemos eliminar tanto como sea posible, pero evidentemente no podemos eliminar todas las particiones, es necesario un equilibrio. Pero sin duda merece la pena observar nuestro proceso de desarrollo, nuestra arquitectura, nuestros diseños y nuestras soluciones para eliminar todos aquellos elementos, todas aquellas particiones que añadan complejidad.

 

A veces, si bien no es posible eliminar completamente una partición, si podemos eliminar algunos de los elementos que la componen. Por ejemplo, en un sistema de gestión de almacenes, podemos tener historias relativas a ajustes de almacenes y a informes. No podemos eliminar completamente ninguna de estas particiones sin que el sistema pierda su utilidad, pero seguro que podemos eliminar algunas historias relativas a ajustes y algunas relativas a informes.

 

La otra manera de combatir la complejidad es la iteración. Implementar las particiones de manera iterativa y revisar la complejidad al fin de cada iteración es un mecanismo poderoso que complementa las dos tácticas anteriores. Os remito aquí a un post anterior sobre velocidad de iteración frente a calidad de iteración.

 

Recordad, contra la complejidad: partición, simplificación e iteración.

MSBuild Profiler: ¿por qué mi build tarda una eternidad?

La cuadrillita del Debugging & Optimization Team de Plain Concepts somos bastante fanáticos de los profilers. Hay un arsenal de ellos: el profiler de Visual Studio, el CLR Profiler, el Memprofiler de SciTech, VTune de Intel, el profiler de SQL Server… cada uno con sus puentos fuertes y débiles. Todos estos profilers se centran en mejorar la velocidad de ejecución de nuestros programas.

Pues bien, hoy me he topado con un profiler, el MSBuild Profiler, radicalmente diferente, pero igualmente útil. Este profiler nos permite ‘instrumetar’ una build de MSBuild para analizar donde está fugando rendimiento. El procedimiento es bien simple, este profiler es capaz de analizar la salida de un logger a medida de MSBuild, proporcionado con el propio profiler. Basta con lanzar nuestra build con ese logger como salida para que el profiler nos de información sobre donde se pierde el tiempo en nuestra build, para ello basta con usar el parámetro /l de MSBuild que permite estarblecer el logger de salida que nos interese, en este caso: MSBuildProfilerLogger:

MSBuild.exe buildfile.proj  /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c

Esto arranca una instancia de MSBuild Profiler de manera interactiva. Puede ser que no sea esto lo que nos interese, por ejemplo si queremos lanzar una build con TFSBuild. Para estas situaciones el MSBuildProfilerLogger admite un parámetro file que nos pemite genera un archivo .snapshot con la información de rendimeinto de la build:

MSBuild.exe buildfile.proj  /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c,file=out.snapshot

Luego podremos cargar en el MSBuild Profiler este archivo para ver los resultados, tal y como se muestra en la pantalla siguiente:

MSBuildProfiler 

Sin duda una herramienta excelente para acelerar nuestras builds.

Velocidad de iteración vs Calidad de iteración

Estoy leyendo Simple Architectures for Complex Enterprises de Roger Sessions. No me queda mucho así que en breve espero que tengáis una reseña sobre el libro aquí, pero hoy voy ha hablaros de una cuestión que el libro trata de manera muy amena: la velocidad de iteración vs la calidad de iteración.

Cuenta Roger Sessions en su libro una curiosa historia para ilustrar la diferencia que existe en el desarrollo de software entre iterar buscando la mayor velocidad de iteración o iterar buscando la mayor calidad de iteración. Este es un tema que ya he tratado con anterioridad en este blog: No persigas tu cola…, pero la historia que cuenta Roger Sessions es realmente ilustrativa.

El Coronel Jhon Boyd, uno de los grandes pilotos de la época de los primeros reactores de combate y estratega reconocido, estudio una anomalía en la luchas aéreas entre los dos grandes cazas de la década de los 50. Cito aquí la historia tal y como Roger Sessions la cita en su libro, traducida al español lo mejor que he sido capaz, además añado un video sobre el tema (en inglés), que no solo de informática vive el hombre:

"El Coronel John Boyd estaba interesado no solo en cualquier lucha aérea, sino específicamente en los combates entre el MiG-15s y el F-86s. Como ex-piloto y consumado diseñador de aeronaves, Boyd conocía estos dos aviones perfectamente. Él sabía que el MiG-15 era mejor técnicamente que el F-86. El MiG-15 podría subir más rápido que el F-86. El MiG-15 puede girar más rápidamente que el F-86. El MiG-15 tenía una mejor distancia de visibilidad. El F-86 tenía dos puntos a su favor. En primer lugar, tenía una mejor visibilidad lateral. Mientras que el piloto de MiG-15 podía ver más lejos, el piloto de F-86 podría ver un poco más por los laterales. En segundo lugar, el F-86 tenía un control de vuelo hidráulico. El MiG-15 tenía control de vuelo manual.

La hipótesis más común por parte de los diseñadores aéreos era que la maniobrabilidad era el componente clave a la hora de ganar duelos aéreos. Evidentemente, el MiG-15, con su giro más rápido y su capacidad para escalar más rápido, podía mejorar la capacidad de maniobra del F-86.

Pero hubo un pequeño problema con todo esto. A pesar de que el MiG-15 era considerado un avión superior por los diseñadores de aviones, el F-86 era preferido por los pilotos. La razón por la que era preferido por los pilotos fue simple: en los duelos uno-a-uno entre MiG-15 y F-86, el F-86 ganó nueve de cada diez veces."

¿Cómo un avión inferior puede ganar de manera consistente a un avión superior? Era la pregunta que surge rápidamente. Boyd, tenía una teoría:

"Boyd concluyo que la cuestión determinante a la hora de ganar un duelo aéreo no era observar, orientarse, planear o actuar mejor. La cuestión determinante para ganar un duelo aéreo era observar, orientarse planear y actuar más rápido. En otras palabras, como de rápido uno podía iterar. La velocidad de iteración, sugirió Boyd, bate a la calidad de iteración.

La siguiente pregunta que se realizo Boyd es esta: ¿por qué el F-86 iteraría más rápido?. La razón, concluyo, era algo que nadie había pensado que fuese particularmente importante, el hecho de que el F-86 contase con un mando de vuelo hidráulico mientras que el MiG-15 tenía un mando de vuelo manual. Sin ayuda hidráulica, costaba un poco más mover el mando de vuelo del MiG-15 que el del F-86. Aunque el MiG-15 girase más rápido (o pudiese llegar más alto) cada vez que el mando era movido, la cantidad de energía necesaria para mover el mando era mayor para el piloto del MiG-15. Con cada iteración, el piloto del MiG-15 sufría un poco más de fatiga que el piloto del F-86. Según se iba fatigando un poco más, tardaba un poco más en completar su ciclo de observar, orientarse, planear y actuar. El piloto del MiG-15 no perdía por que pilotase peor. Perdía por que completar el ciclo de lucha cada le costaba más tiempo."

De esta observación se deriva la Ley de la Iteración de Boyd: la velocidad de iteración bate a la calidad de iteración.

Hoy en día todas las metodologías de desarrollo son iterativas. No hay otra manera de desarrollar software que en iteraciones en las que se repite la secuencia de combate del desarrollo de software: conocer el problema, analizarlo, implementar la solución, construir, probar (con diferentes variantes). La diferencia es que unas metodologías ponen el peso en la calidad de iteración (CMMI, RUP) mientras que otras ponen el peso en la velocidad de iteración (XP, Scrum). ¿Alguien duda de quien está ganando más combates?. La idea es clara, si te vas a equivocar, equivócate pronto, rectifica rápido en lugar de tratar de no equivocarte por todos los medios y quedarte sin tiempo para rectificar. A veces se describe esto como dinero por flexibilidad en lugar de dinero por información. Las metodologías guiadas por un plan, consumen muchos recursos trantando de asegurar las maniobras adecuadas, las metodologías ágiles tratan de realizar las maniobras de manera rápida y razonablemente adecuada. Si hay problemas siempre se puede rectificar… si el coste de rectificar es razonable y si tienes la ágilidad necesaria para no morir en el intento.

La esencia del software es iterativa, como la esencia del combate aéreo y no deja de ser curioso como ese énfasis en la iteración rápida aparece en todas las buenas practicas de la ingeniería del software, igual que en combate aéreo. Perseguimos encontrar rápido los errores, intentamos incorporar temprano el feedback de los usuarios, intentamos construir el software de manera frecuente y minimizando el coste de construirlo, etc…

¿Qué opinión os merece esta reflexión? ¿Mejor primar la velocidad de iteración o la calidad de iteración?

He leído: More Joel on Software de Joel Spolsky

Cómpralo en Amazon Hay libros que se leen y libros que devoran. Aunque no se pretenda de antemano.. Hace menos de dos semanas, llegaba mi regalo de reyes. Un pedido de libros. Entre los cinco títulos que llegaban, estaba este libro que hoy comento. No era el primero entre mis preferencias de los que componían el paquete. De hecho comencé con mi regalo de reyes leyendo otro libro. Pero de repente, un día abrí el libro de Joel y zas… ¡no pude para de leer hasta que lo devoré!. En menos de una semana lo había leído. Los habituales del este blog habréis visto que el libro que tengo entre manos suele aparecer en el ‘sidebar’ del blog, pues en este caso ¡ni siquiera me ha dado tiempo a ponerlo!.

Nada oculta que soy un gran fan de Joel. Ya antes he publicado mi impresión sobre otros de sus libros: Joel on Software y The Best Software Writing I. Muchos de los artículos de este blog están influenciados por él, muchos citan alguno de sus post. Su blog es mi blog favorito, sin duda alguna y espero sus artículos con devoción, una devoción que solo tengo por la columna de Arturo Perez Reverte, en El Semanal y por Miguel Delibes. Vamos que cuando abrí el libro no esperaba ninguna novedad, y sin embargo en cada página he encontrado un aliciente continuo que me impedía dejar de leer. Todos los artículos los había leído con anterioridad, pero leer en papel tu blog favorito no tiene precio, la verdad. Además los artículos están ordenados por temática, lo que da al libro una coherencia, una continuidad y una línea argumental que el blog no tiene.

Es una caña de libro, un libro divertido sobre una multitud de temas relacionados con el desarrollo de software: desde como contratar desarrolladores, a como fijar el precio del software o como crear una empresa de desarrollo de éxito, pasando por… por todos los temas relevantes del desarrollo de software y sus aledaños. Los temas que trata Joel: la gestión del personal en proyectos informáticos, consejos para los futuros programadores, la importancia de diseño, la gestión de grandes proyectos, consejos sobre programación, cómo comenzar un negocio de software, cómo continuar con el, como lograr liberar software y cómo revisar y mantener el software liberado. Todo salpicado de amenas historias que hacen que los temas que trata, muchos de ellos pilares de la gestión proyectos de software, se queden grabados a fuego en la memoria. Sin duda, los libros de Joel son los libros de gestión de proyectos más amenos jamás escritos. Tan amenos que es facil olvidar que estas leyendo sobre desarrollo de software.

Para muestra, un botón: Martian Headsets, en el que habla sobre la falacia de los estándares web. No existe tal cosa como los estándares web, los estándares son una buen idea, de imposible implementación. Memorable. O The Perils of JavaSchools que explica como C es el tamiz que separa el gran de la paja cuando hablamos de desarrolladores. O uno, magnifico, sobre ¿economía? Camels and Rubber Duckies, en el que trata de responder a una pregunta sin respuesta: ¿Cúanto debo cobrar por mi software?. No responde a la prengunta, pero yo al menos ahora se por qué hay cientos de ediciones de Windows… segmentación del mercado, se llama el asunto, y al final la segmentación se traduce en ¡más pasta!… que cosas oigan.

Resumiendo, si ya conoces el blog de Joel, el libro te encantará, si no conoces el blog de Joel, el libro te fascinará y seguro que correrás a comprar los otros dos libros de este autor que menciono en este blog. O mejor aun, comprate los tres de un tirón, seguro que me lo agradecerás. Una compra más que recomendable.

Estaré en SecondNug: ‘Herramientas de modelado: en busca del El Dorado’

Herramientas de modelado Los chicos de SecondNug me han invitado a dar una charla, no se si lograré estar a la altura de mi amado jefe, pero lo intentare. Me pidieron una charla sobre UML. Pero UML ¡es muy aburrido! y el modelado es un campo que está evolucionado de manera muy rápida y continua, así que he abierto un poco más la temática… espero que la charla os resulte atractiva y os animeis a asistir.

Durante décadas, lo que es tanto como una eternidad en el mundo del software, los desarrolladores hemos intentado reducir la creciente complejidad de los proyectos que construimos utilizando la abstracción. La utilización de modelos ha sido una de las técnicas que más adeptos han tenido a la hora de ganar en abstracción. Desde los lenguajes 4GL hasta Oslo, pasando por el omnipresente UML, y las todopoderosas DSL las promesas han sido muchas y los resultados… bueno han sido los que han sido.

En este charla vamos a repasar la historia del modelado, vamos a introducir UML, veremos cómo han evolucionado las herramientas de modelado en la plataforma de desarrollo de Microsoft y sobre todo, vamos a mirar al futuro de la mano de VSTS 2010 y de la de Oslo, la nueva plataforma de modelado y DSL de Microsoft.

El modelado a sido El Dorado del mundo del desarrollo de software, muchos hemos creído en el, muchos lo siguen buscando, muchos intuimos que existe, pero nadie ha encontrado la solución definitiva. Pero por supuesto, en ocasiones, y utilizado correctamente, el modelado nos puede ser de utilidad.

Por cierto el evento será grabado y lo podréis ver cuando queráis.

De vuelta del MVP Summit 2009: fué en Oslo no en Redmond

MVP Summit 2009

Por fin me he recuperado del jetlag… y soy capaz de postear algo. La verdad es que este año no tenía la intención de publicar nada sobre este evento. Entiendo que quizás no sean muchos los lectores de este blog a los que les interesan las aventuras de los MVPs en su ‘sarao’ anual al otro lado del charco. Pero aquí estoy escribiendo sobre el tema, y es que ocurrio algo que merece ser contado. No, no se trata de nada que viese en los dos intensísimos días que junto a Luis Fraile y el resto de MVPs de Team System compartí con el equipo de desarrollo de esta herramienta. Vimos algunas novedades, pero casi todas ya eran públicas tras el PDC y de la otras no podemos hablar. Vamos nada que el amigo Bruno no nos hubiese contado ya en su blog.

Lo que justifica este post es la charla con la que Miguel LLopis, SDET de Microsoft, nos obsequio en la primera jornada del Summit. Habló, como no, de Oslo, en español, y asistimos un buen puñado de españoles y sudamericanos. Lo primero agradecer a Miguel el viaje desde Vancouver a Seattle, el esfuerzo de preparar la charla y sobre todo, el seguro montón de mails que ha tenido que escribir para conseguir una sala en la que dar la sesión en el Summit.

Sobre la sesión, excelente. Tener el lujo de contar con alguien que está dentro del equipo de Oslo para poder acribillarle a preguntas y comentarios fue un privilegio. Entre en esa sala con un vago conocimiento de que es Oslo y en que estado se encuentra y en dos horas, Miguel, nos puso al día. Además siempre es un placer charlar con alguien que está haciendo cosas interesantes dentro de Microsoft.

Oslo es la nueva plataforma para el modelado de Microsoft. Yo no soy muy amante de las herramientas de modelado, ni de los lenguajes de modelado. Son sin duda una de las promesas fallidas de la informática, primero 4GL, luego UML, luego DSL, luego Oslo… todas estas herramientas prometían que los desarrolladores podríamos subir el nivel de abstracción y dejar de escribir código para pasar a crear ‘dibujines’ que luego darían como resultado el código. La promesa es fallida porque es evidente que los desarrolladores seguimos utilizando el código como principal fuente de expresión.

Durante el debate que se planteó en la sesión, yo planteaba este escepticismo, compartido por parte de la sala, a Miguel. Le preguntaba ¿por que esta vez si que vais a cumplir la promesa? Tras escuchar a Miguel, creo que esta vez si se puede cumplir la promesa por varios motivos:

El modelo se expresa con código. M es el lenguaje de modelado de Oslo y nos permite crear modelos como nos gusta hacer las cosas a los desarrolladores, escribiendo código. Podemos generar nuestras propias gramáticas.

El modelo es agnóstico de su instanciación. De un mismo modelo podemos generar, mediante compilación de nuestro código M que podemos validar contra nuestra gramática y pasear mediante las librerías de Oslo tantas instanciaciones como queramos. De nuestro modelo en M, podríamos generar la capa de acceso a datos, los servicios WCF o ASPX y la interfaz de usuario Winforms o WPF, según lo que queramos hacer, según como instanciemos nuestro modelo.

No solo de código vive el hombre. Evidentemente si queremos que el modelado realmente aporte ganancias claras de productividad (Miguel habló de un 10x de mejora que no nos creímos nadie pero que todos deseamos que sea cierto), tenemos que poder utilizar ‘dibujines’ al menos para muchas de las tareas en las que la abstracción es clave. Y Oslo permite esto e incluso nos proporcionará herramientas para que ese modelado sea simple, atractivo y por fin ‘la gente del negocio puedan programa sin saberlo’…

Se cumplirá esta vez la eterna promesa… ojalá si.

Por último, Miguel lanzo un ‘call to action’ que yo voy a repetir aquí. Miguel está liderando la iniciativa para tener un centro de desarrollo sobre Oslo con contenido en español. Por lo tanto solicito a la comunidad que comencemos a generar contenido sobre el tema. Seguro que seremos muchos los que recogeremos el guante lanzado por Miguel.

En otro plano de cosas, fue una gozada poder compartir días, comidas y charlas con toda la recua de MVPs españoles. Además de poder ver a viejos amigos como Marco Amoedo, Octavio Hernandez, Juansa, Pep Lluis, Jose Luis Latorre, Julián Peris por citar algunos y conocer personalmente a varios de los habituales de Geeks.ms como Elias Mereb o Jose Miguel Torres.

¿Es posible Scrum ignorando las buenas prácticas?

Siempre podemos ignorar las buenas prácticas, quizás no pase nada malo La relación que existe entre la metodologías y las buenas prácticas ha hecho correr ríos de tinta. Es una cuestión candente que Luis Fraile o Angel Medinilla (ver la lista de Agile Spain) en la lengua de Cervantes y Martin Fowler en la de Shakespeare, entre otros muchos ‘agilistas’, han tratado con diferentes posturas. El mismo debate ha surgido en la lista de correo de Agile Spain y seguro que resurgirá en el futuro. Así que no me he podido resistir a escribir sobre el tema.

Mi visión sobre esta cuestión es clara. No me importan las metodologías con M mayúscula, me importa la metodología con m minúscula. Esta distinción la hacen los autores de Peopleware para marcar la diferencia entre ‘tener una metodología’ y ‘trabajar metódicamente’. A menudo nos encontramos con organizaciones que alardean de metodología e ignoran todo método en su trabajo diario. La diferencia entre ambas situaciones está en un única aspecto: las buenas prácticas de ingeniería del software que los equipos de desarrollo utilizan en el día a día.

Tampoco faltan los gestores que pretenden que la gestión de proyectos es un puro problema organizativo, en el que las buenas prácticas de ingeniería del software tiene un papel secundario. Este perfil de gestor es en mi opinión menos útil que el gestor que tiene una visión técnica fundamentada en las mejores prácticas de la ingeniería del software, de los problemas que surgen durante el desarrollo del proyecto. Lógicamente siempre manteniendo el equilibrio.

Desde el punto de vista del espectro metodológico hay dos vertientes claras, metodologías que son prescriptivas en lo que a ciertas buenas prácticas se refiere, como XP o MSF Agile y metodologías que no prescriben buenas prácticas como parte de su receta, como Scrum o CMMI. Scrum es totalmente agnóstico respecto a las buenas practicas. Siguiendo la premisa de que el equipo es en Scrum autoorganizado y autogestionado, este es soberano a la hora de decidir como implementar las historias comprometidas para un sprint. Scrum no exige, en principio, el uso de ninguna buena práctica.

Yo soy partidario de las buenas prácticas por encima de las metodologías. Pero ese no es el tema de hoy. El tema de hoy es contestar la pregunta ¿es posible hacer Scrum sin utilizar buenas prácticas?. Dicho esto veamos que ocurre si un equipo de Scrum decide ignorar las buenas prácticas.

Voy a tratar de demostrar, mediante reducción al absurdo, que no es posible, en proyectos de desarrollo de software, cumplir algunas reglas de Scrum sin utilizar buenas prácticas de ingeniería del software. El punto es que si ignorando algunas buenas prácticas llegamos a la conclusión de que no podemos cumplir alguna de las reglas de Scrum directamente se deriva que no estamos utilizando Scrum. Esto supone asumir también que Scrum solo es Scrum si se respetan sus reglas. Es fácil saber si estás usando Scrum o no, comprobando si estás siguiendo la reglas o no. Voy ha hablar de las tres buenas practicas utilizadas por los equipos de desarrollo ágil: Automatización de la pruebas, construcciones automatizadas y gestión de la configuración.

Un equipo ágil podría elegir no utilizar pruebas automatizadas. El precio que pagaría por esa decisión sería no poder detectar regresiones en el software de manera rápida y no poder asegura que las historias están hechas de manera inequívoca. Sin la posibilidad de detectar regresiones de manera rápida, lo que ocurriría, es que cuando el final del sprint se acercase, el equipo tendría que congelar el desarrollo de funcionalidad, dedicar un tiempo considerable a asegurar la ausencia de regresiones y a asegurar que las funcionalidades están completas, pruebas incluidas. Una de las reglas de Scrum especifica que se debe minimizar el tiempo que se dedica a la preparación del Sprint Review. La conclusión es clara: Sin automatización del testeo es imposible dedicar poco tiempo a la preparación del Sprint Review. Luego sin pruebas automatizadas, no es posible Scrum.

Un equipo ágil podría decidir no usar construcciones automatizadas. El precio que pagaría sería que no podría construir una versión lista para el despliegue con suficiente velocidad y asegurando la ausencia de errores derivados de un proceso de construcción manual. Una de las reglas de Scrum dice que el Producto Owner puede decir tras cualquier Sprint Review poner el software en producción. Sin construcciones automáticas, esta puesta en producción se demoraría y el equipo habría fallado al entregar un incremento de funcionalidad potencialmente entregable, aspecto clave en Scrum. Por lo tanto la conclusión es simple: sin construcciones automatizadas, no es posible Scrum.

Un equipo ágil, podría elegir no usar una política de gestión de la configuración adecuada . El precio que pagaría sería que no podría asegurar que el software entregado solo contiene historias completas. Recordemos que una de las reglas de Scrum dice que el equipo solo puede demostrar características completas y que nada que no se haya demostrado debe ser entregado. De esta premisa se deriva que si nuestra política de gestión de la configuración no es adecuada, no es posible Scrum.

De lo anteriormente expuesto, es simple de concluir que como la automatización de las pruebas, las construcciones automatizadas y la gestión de la configuración adecuadas, son buenas prácticas y sin ellas no hay Scrum, sin buenas prácticas, no hay Scrum.

Es más diría que sin buenas prácticas no hay agilidad, pero eso ya no soy capaz de demostrarlo formalmente. Ya lo decía mi abuelo: quien no siembra no recoge.

Azure: Eliminar la necesidad de lanzar el Development Storage para depurar

Escribía ayer mismo sobre como cambiar el servidor SQL usado por el Development Storage, pero hoy mismo he descubierto la posibildad de deshabilitar el requisito de que nuestro proyecto use el Development Storage. Esta es una opción realmente interesante cuando nuestro proyecto de Azure no necesita para nada almacenamiento o va a utilizar SQL Data Services como almacenamiento. También es muy útil cuando estamos haciendo pruebas rápidas o pequeñas demos de Azure en las que no necesitamos almacenamiento.

Para evitar la necesidad de lanzar el Development Storage para depurar simplemente tenemos que abrir la propiedades de nuestro proyecto de Azure y en la pestaña Development establecer a False la opción Start Development Storage Services:

Evitar lanzar Development Storage Services

A partir de este momento, cuando depuremos el proyecto, no se levantará automáticamente el Development Storage. Esto agilizará la depuración un poco y nos permite depurar en máquinas que no tengan ningún servidor de datos instalado o accesible.

¡Espero que os sea útil!

Azure: Cambiar el servidor SQL usado por el Development Storage

Hace unas semanas os contaba que actualizar mis conocimientos sobre pogramación concurrente y Parallels Extensions era uno de mis propositos para este año, ha sido más fácil de lo que pensaba. Como ese proposito ya está cumplido, me he planteado otro: subirme a las nubes, de la mano de Microsoft Azure y en ello estoy. Ando exprimiendo al máximo el Training Kit. Y en ese camino me estoy encontrando con algunos pequeños escollos que voy salvando. Estos escollos están relacionados sobre todo con aspectos conceptuales de la nueva plataforma pero también con pequeñas dificultades que me he encontrado. Mi intención es hablar sobre todos ellos en este blog y compartir mi proceso de aprendizaje. Hoy empezaré por comentaros dos trucos relacionados con el Development Storage.

Pero empecemos por el principio…

¿Qué es el Devlopment Storage?

Es el componente del SDK de Azure que nos permite simular el alamacenamiento en la nube que Azure proporciona en nuestra máquina de desarrollo. Cuando creamos un nuevo proyecto de Azure en  nuestro Visual Studio y lo depurarmos este componente se lanza automáticamente. Para simular el almacenamiento en la nube de manera local, el Development Storage se apoya en SQL Server Express.

El problema viene cuando no queremos utilizar SQL Server Express sino una versión de verdad de SQL Server, por ejemplo la edición para desarrolladores, que muchos ya tenemos instalada en nuestra máquina de desarrollo o incluso un servidor SQL Server de desarrollo fuera de nuestra máquina. Evidentemente a todos se nos ocurre que en algún lugar podemos configurar esto… el problema es que averiguar cual es ese lugar. Tras bucear un poco por el directorio de instalación del SDK de Azure lo encontré. Y aquí es donde viene el truco:

¿Cómo configurar el SDK de Azure para que use SQL Server en lugar de SQL Server Express? o en general ¿Cómo cambiar el servidor SQL Server que usa el SDK de azure para el Development Storage?

Pues bien, basta con buscar en el directorio de instalación del SDK de Azure el archivo DevelopmentStorage.exe.config, típicamente alojado en %ProgramFiles%Windows Azure SDKv1.0bin. Este es un típico app.config de .Net en el que podemos encontrar las siguientes secciones de configuración entre otras:

<connectionStrings>

  <add name="DevelopmentStorageDbConnectionString"

        connectionString="Data Source=.;Initial Catalog=DevelopmentStorageDb;Integrated Security=True"

        providerName="System.Data.SqlClient" />

</connectionStrings>

<developmentStorageConfig>

    <services>

      <service name="Blob"

               url="http://127.0.0.1:10000/"/>

      <service name="Queue"

               url="http://127.0.0.1:10001/"/>

      <service name="Table"

               url="http://127.0.0.1:10002/"

                    dbServer="localhost"/>

 

    </services>
</developmentStorageConfig>

 

Basta con establecer la cadena de conexión DevelopmentStorageDbConnectionString apuntado al servidor que nos interesa y el atributo dbServer del servicio Table a los valores adecuados para que nuestro Development Storage comienze a usar nuestro servidor y sabor favoritos de SQL Server. En la configuración anterior he configurado el sevidor local. Tras seguir estos pasos, cuando ejecutemos o depuremos nuestro proyecto de Azure por primera vez, veremos la siguiente pantalla:

Development Storage Initialization

Este el proceso de inicialización del Development Storage que crea la base de datos DevelopmentStorageDb. Si el proceso se ejecuta sin errores, a partir de este momento el Development Storage estará usando el servidor SQL Server que hayamos configurado.

Espero que os resulte útil.