Mis respuestas sobre Scrum

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.

¿Se puede aprender Scrum en cinco minutos?

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. Scrum in five minutes es un documento que nos proporciona este vistazo de cinco minutos de Scrum. Se trata de un documento ideal para informar a la gerencia de en qué consiste ‘eso de Scrum’ y facilitarnos la tarea de buscar un sponsor que respalde nuestra labor si pensamos en implantar Scrum.

¿Destruir o mantener los proxies de WCF?

 


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 IDisposable. Pero desde el punto de vista del rendimiento, sin duda, crear y destruir el proxy tiene un coste bastante alto según mi experiencia y algunas pruebas no muy formales que he realizado.

En resumen, la idea es clara, si no sabes cuantos clientes vas a tener, cada proxy consume recursos del servidor, y por tanto esto afecta a la escalabilidad (el numero de clientes que puedes atender será menor). Pero también es cierto que si el número de proxys es finito no interesa abrir y cerrar los proxies, por el coste que tiene. La idea subyacente es la misma que con las conexiones de bases de datos, de hecho, un pool de proxies es algo que he leído que van a añadir a WCF en próximas versiones.

Este problema además se enmaraña un poco más si tenemos en cuenta la seguridad. Si creamos el proxy en cada ocasión también incurrimos en el coste de negociar un token de seguridad cada vez.

Si nos decantamos por utilizar un único proxy para todas las invocaciones, manteniéndolo abierto durante toda la vida del cliente, el problema de que surge es que, en algún momento puede haber contención, pero con las redes actuales es difícil que esto ocurra. Un solo socket es capaz de atender miles de peticiones WCF sobre todo si los mensajes que intercambiamos son óptimos.

Quien decide si mantener o no los proxies es el cliente, pero también hemos de tener en cuenta que las opciones de Throtlling limitan el número de sesiones concurrentes a un máximo de 10 por defecto. Si nos decidimos por mantener los proxies abiertos y estamos usando sesiones este valor va a limitar el número de conexiones, y por tanto hemos de cambiar el valor por defecto de la propiedad MaxConcurrentSessions.

También conviene recordar que si usamos un binding basado en TCP, por defecto vamos a tener una sesión implícitamente creada por cliente. De hecho usando como binding el netTcpBinding, no vamos a poder especificar que no queremos sesión, porque si en nuestro ServiceContract establecemos SesionMode a None, obtendremos el error ‘No se puede iniciar el servicio. System.InvalidOperationException: Contract does not allow Session, but Binding ‘NetTcpBinding’ does not support Datagram or is not configured properly to support it.’ al intentar arrancar el host del servicio.

Existe la alternativa de crearse un ‘custom binding’ que use TCP y que no requiera sesión tal y como está descrito aquí, pero creo que no tiene mucho sentido, que se trata de una optimización prematura. Las sesiones en sí consumen muy pocos recursos, según las pruebas que hice sobre este tema en su momento. Esto tiene toda la lógica, lo que consume recursos es lo que tu mantienes dentro de la sesión, y el hecho de poner y sacar cosas en la sesión, no la sesión en si, que es poco más que un simple diccionario. Tener sesiones vacias es algo que no va a afectar demasiado a la escalabilidad o el rendimiento de nuestro servicio.

Espero que esto que comento os ayude a tomar una decisión.

He dejado de ser MVP de Visual C++…

… para empezar a serlo de Visual Studio Team System. Esto solo supone cambiar el reconocimiento de una pasión por el reconocimiento en otra, el desarrollo en C++ por la ingeniería del software y la gestión de proyectos. !Esto no quita que vaya a seguir medoreando por todo lo que suene a C++¡, no se van a librar de mi en los grupos de noticias de C++…

Solo decir que intentaré estar a la altura de lo que la comunidad espera  y necesita de un MVP de una herramienta tan novedosa y pontente como Visual Studio Team System.

Evento en Bilbao: Acelere el Ciclo de Vida de sus Aplicaciones


Mañana 24 de Abril de 2007 se celebrará en el Hotel Ercilla de Bilbao un seminario sobre Visual Studio Team System en el que yo tendré el placer de participar junto a Aurelio Porras, arquitecto de software en la división de Plataforma y Desarrollo en Microsoft Ibérica. Si quieres saber como Team System puede ayudarte a gestionar el ciclo completo de vida de tus proyectos de desarrollo de software no dudes en inscribirte y asistir a este evento.


La agenda es:

10:00 – 10.30 Introducción solución ALM.
10.30 – 11.30 Acelere el ciclo de vida de sus aplicaciones a través de múltiples Roles: Arquitectos – Desarrolladores – Testers.
11:30- 12:00 Café
12.00 – 13.00 Cómo optimizar el rendimiento de sus Bases de Datos – Proyectos – Colaboración, trabajando en equipo.
13.00 – 13.30 Demostraciones de las novedades de .NET Framework 3.0

La máquina virtual de VSTS y TFS que siempre deseaste

Una de las pricipales trabas a la hora de aprender a trabajar con Visual Studio Team System y Team Foundation Server es montar la infraestructura necesaria para empezar a ‘trastear’. Montar un Team Foundation Server no es algo sencillo. Aunque muchos hemos superado la prueba de montar un TFS a base de tiempo y paciencia, el problema depués, es que no contamos con datos de un proyecto en los que podamos basar nuestro aprendizaje.

La excelente notica es que Microsoft, consciente del problema ha liberado una máquina virtual con un TFS complementamente funcional y lo mejor de todo, con toda la información de un proyecto ‘real’.

En resumen, un recurso imprescindible para aprender TFS o VSTS. Sin duda será de gran utilidad a todos aquellos que quieran preparar la nueva certificación en TFS.

Nueva versión de Fiddler con soporte para tests web de Team System

Me comentan mis compañeros Unai Zorrilla e Iván González, otros de los fans de la excelente herramienta Fiddler, que en la nueva versión han añadido soporte para que se entienda perfectametne con VSTS y sea capaz de capturar el tráfico y guardarlo en un formato que VSTS entienda. No he podido probar esta funcionalidad, pero suena espectacular, poder usar toda la potencia de Fiddler para depurar los problemas que nuestras pruebas web de VSTS puedan detectar.

Otra de las grandes novedades de la nueva versión es la posibilidad de capturar tráfico HTTPS.

En este post de Buck Hodges teneís más información sobre el tema.

La certificación en Team Foundation Server ya está disponible

Los que realizamos, hace unos meses, el examen beta de la certificación en Team Foundation Server hemos recibiido hoy los resultados (gracias Luis por el aviso). Esto significa que todos los que estábais esperando por esta certificación, que a tenor de las preguntas que he recibido sobre el tema sois muchos, la tenéis ya disponible (al menos en teoria, no he comprobado que ya se pueda hacer el registro).

Si quereís más información Preparation Guide for Exam 70-510.

Por cierto, a pesar de la poca fe que tenía ¡he aprobado!. El resultado de Luis no os le cuento, que el ya lo contará, supongo.

Si alguien está preparando esta certificación y quiere alguna aclaración sobre su alcance o lo que sea que no dude en pregutar en los comentarios de este post.

Ya veo!!!

Pues eso, que aprovechando el ‘parón’ de Semana Santa, ya tengo Vista. El motivo del cambio es que no podia seguir siendo el menos geek de Plain Concepts. Pero he de reconocer que estoy realmente alucinado con el trabajo de Microsoft, y eso que a priori era yo muy exceptico sobre la rentabilidad del cambio.

Me encanta Vista, simple, robusto y el salto desde XP me ha resultado temendamente naturar, no ha habido ninguna tarea que me haya resultado complicada de realizar. Solo puedo poner un pero, no fue capaz de actualizar mi instalación de XP anterior y esto me obligo ha instalar desde cero.

A pesar de que mi equipo, un Acer Travelmate 8003, con 2Gb de Ram ya tiene unos años y de que solo obtiene un 2.0 en la puntuación de Vista, todo va como la seda, incluso mejor que con XP diria yo (aunque lo hachaco más a la instalación desde cero, el XP anterior ya tenia 2 años y pico funcionando sin reinstalar y estaba muy guarreado). Bien es cierto que menos en el aspecto gráfico el resto de puntuaciones son más que decentes para un portatil con la edad que tiene el mio.

Por cierto curioso que la tarjeta gráfica, una ATI Mobility Radeon de 64MB, reponsable de ese 2.0 en la puntación, diese más nota (2.5) con los drivers de Microsoft que con los de ATI. Quiza los amigos de vista-tecnica lo puedan explicar. Aunque vien es cierto que se ve mucho mejor la pantalla con los de ATI y que yo no he notado ninguna merma.

Os dejo un pantallazo sobre lo que se puede hacer a pesar del 2.0 de puntuación, y animo a todo el mundo que lo estubiese pensando, como yo, a que se actualice, creo que merece la pena.

 

Unai espero tu llamada para reirte de mi tras leer esto… 😉

STLPort y Visual Studio 2005

Aunque la versión de STL que proporciona Visual C++ 2005 es en muchos aspectos superior a la de STLPort, aun hay mucha gente que utilizar STLPort por motivos históricos (la STL de Visual C++ 6.0 era pésima) o por cuestiones de portabilidad (STLPort está disponible para infinidad de plataformas).

Ya que me he visto en la necesidad de hacerlo, os cuento como usar STLPort con Visual C++ 2005, que puede ser un poco farragoso, sobre todo si es la primera vez:

  1. Descargar la última versión disponible de STLPort desde www.stlport.org, a la fecha de publicación de este post, la última versión disponible es la 5.1.3.
  2. Descomprimir el archivo zip, el directorio de igual, pero yo lo he descomprimido en %programfiles%STLport-5.1.3
  3. Compilar STLPort, esta es la parte más propensa a errores:
    1. Abre una ventana de msdos usando el acceso directo Visual Studio Command Prompt que encontrarás en Inicio > Programas > Microsoft Visual Studio 2005 > Visual Studio Tools.
    2. Ejecuta el comando vcvarsall.bat, que establece las variables de sistema necesarias para poder compilar desde línea de comandos con comodidad. A partir de ahora siempre utilizaremos la ventana msdos que ya tienes abierta
    3. Muévete al subdirectorio buildlib bajo el directorio en que descomprimiste STLPort (%programfiles%STLport-5.1.3buildlib, en mi caso).
    4. Ejecuta configure -c msvc8
    5. Ejecuta nmake /fmsvc.mak para compilar STLPort.
    6. Ejecuta nmake /fmsvc.mak install.
  4. En Visual Studio 2005 estableceremos que el compilador busque los archivos de cabecera en el directorio de STLPort. Para ello, vamos al menu Tools > Options… y en el cuadro de dialogo que aparece seleccionamos, Projects and Solutions > VC++ Directories. En el combo Show directories for, seleccionamos Include Files y añadimos el directorio stlport ($(ProgramFiles)STLport-5.1.3stlport, en mi caso) al principio de la lista.
  5. De modo similar al paso anterior, en Visual Studio 2005 estableceremos que el compilador busque los archivos de librería en el directorio de STLPort. Para ello, en el combo Show directories for, seleccionamos Library Files y añadimos el directorio lib de STLPort ($(ProgramFiles)STLport-5.1.3lib, en mi caso) al principio de la lista.

Esto es todo!!! A partir de este momento estaremos usano la STL de STLPort en lugar de la de Microsoft.