Luis Fraile

Jejeje, en cuanto lo he visto me ha hecho tanta gracia que tenía que ponerlo 🙂

Pues si, efectivamente alguien ha hecho una aplicación que usando los eventos de TFS para las builds, tanto los eventos de cuando se completa una build, como de cuando se cambia la calidad, y los publica en Twitter, es curioso cuando menos :

El post del creador:

http://blogs.msdn.com/jasonba/archive/2008/09/22/buildtweeter-tfs-build-publisher-for-twitter.aspx

La aplicación:

BuildTweeter

¿Ves Bruno? ahora ya no te puedes meter conmigo por twittear 😛 ahora sirve para algo más allá del simple ocio jejeje.

Hace tiempo que tenía esto en la cabeza, pero por una cosa o por otra, no lo escribía, bueno si, porque andaba muy liado jeje.

La cosa es que a raíz de unos comentarios en un artículo, y hablando con un colega mío, inicialmente discrepábamos en un tema. Y es la importancia del equipo de desarrollo, yo siempre digo que tiene muchísima importancia, ya que es la fuerza productiva, los que contruyen el objetivo del proyecto, y esto, es importante por supuesto.

Sin embargo, mi compañero, que también es gran conocedor de todos estos temas me llevaba un poco a un tipo de realidad, y es, vale, todo esto en la teoría está muy bien, y es cierto que el equipo debería de tener un peso muy fuerte. ¿Pero qué ocurre cuando el equipo de desarrollo no es tan bueno?.

Efectivamente aquí surge un problema gordo, ya que si no puedes confiar plenamente en tu equipo de desarrollo, no puedes atribuirles las responsabilidades que les corresponden. En este caso, efectivamente, aún siendo importante, no aporta todo lo que debería aportar al proyecto, dando mayor relevancia a otros roles como el jefe de proyecto o un desarrollador jefe, dando lugar a cierta jerarquía de decisiones.

Ciertamente eso es una realidad, ya que uno de los puntos de “dolor” mayores suele ser encontrar y mantener a un equipo de desarrolladores altamente responsables. ¿Y por qué esto es así?, pues hay muchas razones, algunas como las que comentaba en anteriores posts acerca de la valoración a la gente, también hay otras, debidas al mercado actual, en el que sin importar muchas veces la calidad, lo que se hace es meter a más gente, con sueldos cada vez mayores, independientemente de si lo merecen o no.

Y esto se junta con que si un desarrollador “de los buenos” empieza a ver esta situación, lo normal es que acabe rotando.

Pero hay más razones, como no fomentar la formación (incluida la autoformación), la motivación a hacer mejores proyectos (contra el simplemente hacer más proyectos más rápido), una mala gestión de proyectos que desmotive a la gente, en fin infinidad de problemas.

Lo cierto es que esto es un tema de hablar. opinar, y tratar cada caso en particular, pero bueno, como siempre digo, si queréis que vuestros proyectos sean buenos, tenéis que rodearos de desarrolladores buenos, motivando, dándoles la responsabilidad que corresponde, las herramientas necesarias, apoyándoles. Si no, efectivamente, dependeremos de los “pocos buenos” que tengamos, y que cuando se nos vayan, pues bueno, tendremos un problema.

Por cierto, que nadie nace sabiendo, y si queremos tener desarrolladores buenos, no es necesario que simplemente vayamos a por los desarrolladores buenos, si no a los que realmente tienen potencial, y apoyarles en su carrera.

PD: Me recuerda mi colega, con gran razón, que no debemos de olvidarnos que existen otro tipo de personas también, a las que, aunque les des las mayores oportunidades, motivación, etc, jamás van a mover ni un dedo para mejorar, existen, si, y bueno hay que huir de ellos. El problema es que tal y como está el mercado, muchas veces a base de rotar, consiguen mayores sueldos y mejores puestos, … una pena.

Un par de compañeros MVPs de Team system, han comenzado un nuevo grupo de usuarios, con la novedad de que es “virtual”, con el objeto de favorecer la asistencia de gente de cualquier parte, aunque inicialmente las reuniones las harán en un horario más favorable para USA, pero bueno, siendo virtuales ….

Las reuniones por ahora plantean hacerlas en Second Life, algo en lo que yo nunca he estado registrado la verdad, ¿tendré que meterme ahora? …

Para los que queráis más información http://www.tsug-ve.com/

No suelo hacerme eco en el blog de este tipo de cosas, pero esta me ha llegado jejeje, pues eso, abrazad a un desarrollador …

http://blip.tv/file/1061088

Pues sí, después de las vacaciones ya retomamos las charlas del grupo de usuario con la presencia de Jesús Jimenez, que vendrá a hablarnos de la gestión de código fuente con Team System, como siempre, para más información y registro, consultad en http://www.madriddotnet.com

Hoy mismo me han vuelto a preguntar sobre un tema que surge cada cierto tiempo, y es la integración del diseñador, y las herramientas de Expression, en los equipos gestionados con Team Foundation Server.

Recientemente mi compañero Bruno ya ha hablado de esto, acerca del post de Brian Harry a este respecto.

Los que ya hayáis leido estos post, sabréis que lo que se comenta, sin ser del todo oficial, es que las próximas herramientas de Expression, se integrarán con las típicas acciones que ya tenemos en Team Explorer con Visual Studio.

Yendo un poco más allá, si miramos la guía de procesos de por ejemplo MSF Agile, vemos que no hay un rol específico para el diseñador gráfico, comentábamos Rodrigo Corral y yo, que como punto de partida, y conociendo las dificultades de la personalización de la guía de procesos, se podría incluir al diseñador gráfico como un desarrollador más, en caso de que le tengamos dentro del equipo en el día a día, en otras metodologías como Scrum, esto no es necesario, ya que los roles que trabajamos son de alto nivel, y el diseñador gráfico no deja de ser un miembro más del equipo a la hora del reparto de tareas y responsabilidades (como daily meetings, etc.).

Y, ¿cómo trabajar a día de hoy con un diseñadores dentro del equipo?, bueno, el método más sencillo es instalar Team Explorer (previo pago de una CAL) en las máquinas de los diseñadores e instruirles en como usar sus acciones básicas, Check-out, Check-in, asociar a tareas, Shelves, etc.

¿Y cuándo no está dentro del equipo?, lo más sencillo es que el trato de los ficheros con Source Control, lo hagamos nosotros, dentro del equipo, con lo que nos envíe el diseñador, con lo que no necesitamos CAL para el, y a la hora de gestionar las tareas, lo que yo estoy haciendo, es crear un usuario para el diseñador en el TFS, y asignar las tareas de diseño a ese usuario, después creo una consulta para sus tareas, y las exporto a un Excel que tengo compartido con el responsable del diseño, que actualizará el Excel y yo me encargaré de volcar los cambios de las tareas a TFS. Por supuesto esto es un modo muy básico de gestionar las tareas y los diseños, pero por ahora, a mi me funciona y me vale de sobra, si alguno tiene más sugerencias, por aquí serán bienvenidas 🙂

Y estoy de vuelta del viaje, bueno, volví hace unos días, pero ya se sabe como es la vuelta de los viajes.

Y que decir de mi viaje, pufff tendría tantas cosas que contar, la verdad es que ha sido una experiencia increíble, cierto que no es un viaje típico, que físicamente, si ser duro, si es cansado, tanto de ejercicio como de las comodidades a las que estamos acostumbrados en nuestra vida diaria, aunque ese tipo de viaje ya lo he hecho en otras ocasiones, y luego el grupo de gente con el que he compartido el viaje, que ha sido realmente estupendo todos y cada uno de ellos, empezando por nuestro guía Pablo, que realmente se lo ha currado, como por cada uno de los otros nueve que íbamos, como mi compañero de kayak David (al que conocí en este viaje), los tremendos hermanos Palacios, Enric con sus historias de la vida :), y su compañero Sergio, un gran tipo, Mireia e Ignasi los xics de Granollers con sus castells, Jesús el otro madrileño del grupo :P, y nuestra amiga portuguesa Carla.

Aunque no voy a contar el viaje completo, ya que sería muy largo, el viaje empieza con el vuelo Madrid-Copenhage, donde pasamos una noche en un hotel situado en una zona, ejem, un poco curiosa, ese mismo día ya conocemos más gente que va a otros viajes de Groenlandia con Tierras Polares, pero ninguno de nuestro viaje (había conocido a David en el aeropuerto), en fin, pasamos la tarde/noche por allí. Al día siguiente, bien prontito cogemos un avión en dirección Narsarsuaq, pero tras unas 4h de vuelo, el piloto nos dice que no puede aterrizar (allí van casi a ojo) por que hay nubes bajas, y nos lleva de vuelta a Copenhage :(, con lo que este día pasamos casi 12h de avión, y nos alojan en otro hotel en Copenhage.

Al día siguiente ya va la vencida, conseguimos aterrizar, e inmediatamente la gente de Tierras Polares que ya nos estaba esperando, nos lleva en zodiac (50km) hasta Narsaq, donde conocemos  a Pablo nuestro guía, y preparamos los petates con lo que vamos a transportar durante los 11 días de kayak que tenemos por delante, sólo decir, que no llevamos barco de apoyo ni similar, todo lo que necesitamos, como comida, tiendas de campaña, ropa (muy poca), etc, lo llevamos en los kayak, ya que las zonas que vamos a “explorar” están inhabitadas, como “mal rollito”, decir que llueve :(.

Y comienza el paleo, el primer día todo nos impresiona, además sigue lloviendo (aunque poco), con lo que el comienzo no es todo lo impresionante que podría ser, salimos de un punto rodeados de iceberg, ninguno de nosotros está habituado a viajes en kayak con lo que todo nos sorprende y nos cuesta a partes iguales, pero ya nos empezamos a dar cuenta de lo impresionante que va a ser. Las jornadas suelen ser de esta manera: desayuno entre 7:30-8:00, recogida de campamento y a las 9:00-9:30 más o menos salimos, depende del día y de la hacemos más o menos horas de remo, pero suelen ser 3 ó 4, hasta las 5 más o menos los días “largos”, un par de días también hacemos algún trekking (unas 5h), y un día de los de trekking descansamos de remo, montar campamento, luego cena prontito a eso de las 20:00, y luego en el “tipi” (la tienda principal) a escuchar las divertidísimas historias de David, Enric, y el resto. En fin, no voy a detallar día a día, eso ya os lo contaré con unas cervezas delante

Y el viaje acaba dónde empezamos, tras unos 160km en kayak, con algunos trekking, volvemos a Narsaq, donde pasamos un par de noches antes de volver a Copenhage la última noche y de ahí a Madrid.

Cosas interesantes, realmente los paisajes son espectaculares, los iceberg, el inlandis, el comer pescado (bacalao y salmón), no sólo fresco del día sino pescado hace media hora por nuestros pescadores oficiales, David y los hermanos Palacios (que grandes Alberto y Javier), pero sobre todo el haber compartido esos días con un grupo de gente divertidísima que estoy encantado de conocer y que espero volver a verles (a ver si vamos al pueblo de Jesús), de verdad chavales, el  viaje no habría sido lo mismo sin todos y cada uno de vosotros, y por supuesto el guía, que ha estado en todo momento pendiente de nosotros y nos ha cuidado con su información, cocinando, calentando agua cuando más nos apetecía, y que nos ha llevado estupendamente.

Y me dejo muuuuchas cosas y muuuuchas anécdotas e historias por contar, pero sin unas cervezas delante no es lo mismo :).

Así que gracias a todos vosotros por hacer de este un viaje realmente increíble.

Por supuesto las fotos las tenéis en el link de arriba tanto en el de fotos como en el directo a Flickr.

Bueno antes de publicar el post sobre mi viaje, informaros de las dos nuevas secciones de mi blog, aunque realmente son lo mismo.

La primera es la de “Fotos“, aquí tenéis un slideshow en Silverlight de mis fotos en mi galería de Flickr.

Y la segunda “Flickr” es directamente un link a mi galería :).

Pues eso, que iré poniendo fotos por ahí …

Como muchos por aquí, … me tomo un pequeño “descanso” hasta el 20 de agosto, que será un descanso a medias, ya que como algunos ya sabéis me voy durante 17 días a hacer una travesía en kayak a Groenlandia, la verdad es que me voy bastante emocionado con el viaje, me encantan este tipo de experiencias, y hacía mucho que no hacía nada similar (lo cual es un reto más), me divertiré, pero seguro que también habrá esos momentos de sufrimiento ante una actividad así, pero bueno, se afrontan con ganas, a fin de cuentas el día a día ya es así ¿o no?, ciertamente será toda una experiencia a nivel personal, además que estaré esos 17 días sin correo, ni probablemente móvil ni nada de nada, casi me da más miedo mi inbox cuando vuelva del viaje 🙂

Para los más curiosos, me voy con una agencia que se llama Tierras Polares, y si hay suerte mi guía será el “Piza“, compañero de batallas en Barrabes de hace muchos años, y excelente persona para hacer un viaje de este tipo, y también dar las gracias desde aquí a los excelentes consejos que me ha dado Chema para el entrenamiento y a Carolina por todas las gestiones, la verdad es que se nota que es gente que disfruta con su trabajo y que además lo hace bien. Si seguís teniendo curiosidad, aquí podéis ver los detalles del viaje: http://www.tierraspolares.es/viaje.php?id=0000000031 y aquí la ruta. Ya traeré las fotos a la vuelta.

Lo dicho, hasta el 20 de agosto, y que disfrutéis vuestras vacaciones los que os vayáis también en estas fechas.

Ayer, hablando con una amiga sobre una situación que se había dado en su equipo, me hizo pensar en escribir algo sobre esto, y es el eterno tema de hacer los diseños técnicos, los funcionales, como mejorarlos, como usarlos para comunicar el trabajo, etc.

La situación, para ponernos en antecedentes, es una tarea que había hecho otra persona y que ella tenía que validar, la tarea, descrita en el funcional, era bien sencilla, hacer una validación de un campo y en caso de error mostrarle un mensaje al usuario, bien sencillo, sin embargo, la persona que lo hizo, en vez de mostrar un error, hacia otra cosa distinta.

¿Por qué había ocurrido esto?, el desarrollador, se había basado en lo que muchos desarrolladores se basan para hacer sus tareas, y que usamos habitualmente entre nosotros como nuestro modo de comunicación, el diseño técnico, pero ah, amigo, realmente donde está detallado ese funcionamiento es en el diseño funcional, que es el que solemos tomar para hacer las pruebas, la pregunta que surgía era, ¿cómo puedo hacer mejores diseños técnicos para que especifiquen este tipo de cosas?.

Mi opinión en esto, es ¿realmente debe un diseño técnico detallar este tipo de cosas funcionales?, vale, ya sabemos que muchas veces a nivel de desarrollo usamos el diseño técnico, pero este documento, gráfico, o cualquiera que sea nuestro diseño técnico, nos vale para detallar la arquitectura del sistema, los componentes,  como se van a comunicar, que tecnologías vamos a usar, y todos los detalles técnicos, pero, a pesar de que este documento es nuestra base de todo, lo que tenemos que tener realmente siempre presente a la hora de trabajar, es la funcionalidad (recordemos, aportar valor al cliente), y es este documento el que tenemos que usar para nuestro trabajo diario, para saber como tiene que funcionar la tarea que estamos haciendo.

¿Y cómo hacemos entonces correctamente un diseño funcional? porque lo cierto es que muchas veces son documentos que no es factible utilizarlos en el día a día del proyecto para el desarrollo, yo, por ejemplo, como muchos ya sabéis, me gusta especialmente SCRUM que lo que hace es que gestionamos ese trabajo del día a día en lo que se llama Sprint Backlog, que sin meterme mucho en detalles de como se genera, no es más que la lista de tareas, descritas a nivel funcional (o técnico cuando así se requiere), de lo que vamos a hacer en una iteración, así cuando un desarrollador coge una tarea a realizar, lo que ve es "En este campo se ha de mostrar un mensaje de error al usuario cuando el valor es incorrecto" y eso es lo que tiene que hacer, y no "página ASP.NET de introducción de datos mediante TextBox, y validación de los campos".

Por supuesto, SCRUM no es los únicos que tienen algo así, existen muchas más opciones, como las tarjetas de eXtremeProgramming, o los paneles de descomposición de tareas (Work Breakdown Structure) que tanto le gusta a mi amigo Enrique Blanco.

Y por supuesto esto es mi opinión, yo personalmente me siento más cómo trabajando sobre la descripción funcional, que sobre los diseños técnicos, que normalmente nos aportan más información sobre la arquitectura, o tienen más posibilidad de interpretación que las descripciones funcionales de las tareas, pero ya digo, es mi opinión.